Installing this on an ASUS C201 Chromebook?

[duckdodger]

Hello, I was wondering if it's possible to use this kernel on my ASUS C201 Chromebook, which is based on the same RK3288 SoC. Currently I'm running Arch Linux ARM off a microSD card and it runs the 3.14 ChromeOS kernel that also comes with the Mali kernel space drivers (r12p0). But I'm currently unable to get any sort of hardware acceleration with the user space driver (r5p0 as shown here) that comes with Arch Linux, nor am I able to use any Wayland based window managers (Weston, Sway, KWin). Now there might be an easier solution to this than installing a custom kernel and user space drivers, but I can't figure it out. Maybe you can help me out.

How do I go about installing this kernel on Arch Linux? I would like to install it through the Arch Build System as detailed here: Kernels/Arch Build System since that allows me to manage the kernel using the package manager. But that would mean I have to modify the PKGBUILD for the official kernel distributed by Arch Linux here right? In that case, how do I include your patches into that kernel without changing anything else? I realize this is probably not your problem, but I'm getting desperate to get my graphics driver to work properly so that I can actually do something useful on my distro (ideally I would like to use it as my main OS while sidelining Chrome OS for casual use).

Thanks in advance!

[Miouyouyou]

Greetings,

I haven't tested this board... However, some Gentoo guys actually did that here : https://wiki.gentoo.org/wiki/Asus_Chromebook_C201 .

First, I'd suggest to understand how to create and boot your SBC kernels, using U-Boot and a /boot/extlinux/extlinux.conf file. The one I use on MiQi SBC is configured like this, however note that the /dev/ttyS2 line might be wrong for your system. I'd suggest to do a cat /proc/cmdline from a usable kernel first.
Also the label is false. I'm actually booting 4.14 kernels on my SBC.

label kernel-4.4
    kernel /boot/zImage
    fdt /boot/rk3288-veyron-speedy.dtb
    append  earlyprintk console=ttyS2,115200n8 rw root=/dev/mmcblk1p1 rootfstype=ext4 init=/sbin/init

Then you can grab a prebuilt kernel on my https://github.com/Miouyouyou/RockMyy-Build repository. The latest one that was "good enough" is this one : https://github.com/Miouyouyou/RockMyy-Build/releases/tag/v4.13-VPU-Test

Clone the project do a :

cp -r lib/* /lib/
cp -r usr/* /usr/
cp boot/* /boot/

Then ensure that the extlinux.conf is configured to load /boot/zImage and use the /boot/rk3288-veyron-speedy.dtb DTB file.

Concerning the use of the Mali drivers, you could try my first tutorial draft, that explains how to test the drivers with the DRM/GLES interface : https://github.com/Miouyouyou/RockMyy/wiki/Mali-Midgard-user-space-binary-drivers

The main advantage is that this tutorial does not require you to modify your system libraries.

Also note that several Wayland compositors use a DRM node detection that is kinda broken, so they might tell you that your DRM drivers need to be fixed, even the glmark2-es2-drm work fine... That's another story though.

Anyway, follow the Gentoo tutorial. I'm pretty sure that you can use this tutorial on Arch Linux system.

Now, in order to execute the special commands provided by the Gentoo tutorial, you might need to cross-compile the whole kernel, from your x86 Linux computer, using a slightly modified version of my script here :
https://gist.github.com/anonymous/d0ce3911c933562154ca2e3f5fe602c5 .

The script does not depend on Gentoo but the export CROSS_COMPILE line might need to be adapted to the cross-compiler prefix used on your Linux system.
On Gentoo it's : armv7a-hardfloat-linux-gnueabi-
On Ubuntu it's : arm-linux-gnueabihf-

Avoid cross-compiler stating aarch in their name, as they target 64 bits CPU and don't necessarily understand armv7 GCC options.

Anyway, have a try at that tutorial and tell me where you're stuck.

[duckdodger]

Thanks for the input, I'm indeed stuck at one point in the tutorial. There are two patches mentioned in the modified script that are not in the patches/kernel/v4.13 directory and as a result the script gets stuck at that point:

0002-Readaptation-of-Rockchip-DRM-patches-provided-by-ARM.patch
0007-brcmfmac-wififix.patch

The tutorial does not mention where to get these patches from (only that I have to copy them to the aforementioned v4.13/ directory), and I've tried to look if it's in any other location in the RockMyy/ directory, but it's not as far as I could see.

You also mentioned that I might need to cross-compile the kernel on an x86 computer, why is that so? Is it not possible to compile this on the target system itself? Do I have to make some changes in order to compile it on my own computer (the C201 that is)?

First, I'd suggest to understand how to create and boot your SBC kernels, using U-Boot and a /boot/extlinux/extlinux.conf file. The one I use on MiQi SBC is configured like this, however note that the /dev/ttyS2 line might be wrong for your system. I'd suggest to do a cat /proc/cmdline from a usable kernel first.

I don't seem to have a /boot/extlinux/extlinux.conf file with the kernel I'm currently using (I've switched to mainline kernel 4.14 on Arch Linux since making this post, and it works albeit without any graphics drivers). Do I have to create one for the new kernel then? Also there is no such step in the Gentoo tutorial.

[Miouyouyou]

Well, in order :

• You can compile the kernel on the SoC itself. The thing is, it's just slower and wear out the eMMC pretty fast given that it's a LOT of small files that will weight up to 5GB of disk when done compiling.
  If you intend to compile the kernel on the machine itself, just comment the export CROSS_COMPILE line.

• You don't need a /boot/extlinux/extlinux.conf . This information is provided just in case you didn't know how to configure your current distribution bootloader and want to know how to boot a kernel built without the special scripts provided by the distribution.

• The first patch is an old patch provided by myself, that I split into two others afterwards. The old one is there : https://github.com/Miouyouyou/RockMyy/blob/acc20e18f2a21d704c1a4680b3eba8a839520727/patches/kernel/v4.13/0002-Readaptation-of-Rockchip-DRM-patches-provided-by-ARM.patch

It's now split up into :

• https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.13/0002-fbdev-Mali-Add-the-FBIOGET_DMABUF-interface.patch
• https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.13/0010-Rockchip-DRM-GEM-Prime-import-SG-Table-Support.patch

The second patch, wififix, is provided by the writer of the tutorial and is accessible through his Github gist link, just below the modified script.

[Miouyouyou]

Here's the wififix patch : https://gist.github.com/anonymous/d0ce3911c933562154ca2e3f5fe602c5#file-0007-brcmfmac-wififix-patch

[duckdodger]

Thanks, I was able to successfully compile the kernel and modules on an x86 computer and transfer them to mine. I installed the kernel and modules as stated in the tutorial and did nothing else, and rebooted. I was able to boot into the tty, but I noticed some failure messages during the boot, and it turns out my wifi doesn't work anymore -- or at least that's what I believe, I tried connecting to my wifi with NetworkManager and it didn't connect, but I am however able to see all the wifi networks available in the vicinity. I don't know what else doesn't work because I don't know how to test for the others. I have pasted my dmesg log below so that you can perhaps find out what I'm talking about: https://gist.github.com/duckdodger/45ab6306c5e1157e9e359d040ab556df

[Miouyouyou]

Hmm, there seems to be several issues with the DTS GPIO definitions... Every GPIO property query seems to fail for unknown reasons. I'll have to take a look at the DTS file to understand why.

However, the Mali drivers seem to load fine.

As for the WLAN, could you provide the output of lsmod and rfkill ?

[duckdodger]

$ lsmod
Module                  Size  Used by
brcmfmac              221184  0
mali_kbase            520192  0
brcmutil               16384  1 brcmfmac
dw_hdmi_i2s_audio      16384  0
cros_ec_devs           24576  0

$ rfkill
ID TYPE DEVICE      SOFT      HARD
 0 wlan phy0   unblocked unblocked

I notice the number of active modules here is less than what I had before. Bluetooth is missing for instance.

[Miouyouyou]

Strange, the only error in your dmesg logs related to brcmfmac seems to indicate that some operations fail since the chip is busy (-EBUSY → -16). However, I don't know why that would be.

Also, I don't see any firmware loading command. The code seems to indicate there's some firmware in the chip, however I don't know if it must be loaded through the Linux driver, or if it's already integrated into the chip.

Anyway, beside all the issues, does the Mali drivers work with the DRM output ?

[duckdodger]

Well, I don't know how to test it since I don't have wifi to download the user space drivers and install them, and then also build glmark2. I suppose I could download them on another system or on Chrome OS, put them on a USB drive and install them locally...

[Miouyouyou]

Indeed...

Beside trying a new version of the Broadcom firmware, I don't know what could solve the issue...

If you disable NetworkManager and try to setup wpa-supplicant by creating a configuration file like this in /tmp :

network={
    ssid="TheWonderfulNameOfMyWifi"
    scan_ssid=1
    key_mgmt=WPA-PSK
    psk="MyS3cr3tPassw#rd"
}

and executing :

# sudo wpa-supplicant -c /tmp/that-config-file.conf 

Does it fail too ?

[Miouyouyou]

Also, you might to try some solutions provided when searching for "set p2p_disc error"

For example I stumbled into this : https://bbs.archlinux.org/viewtopic.php?id=216639

[Miouyouyou]

There's also a few advices here about how to set-up wpa-supplicant and network manager to "maybe" avoid that kind of issue : https://forum.ubuntuusers.de/topic/wlankarte-wird-nicht-erkannt-2/

[jbowren]

I have also been trying to build a working kernel for the c201, but still have had no success. I followed your instructions here, the kernel built fine, but when booting I only get 4 print statements to the tty:

[0.661560] i2c i2c-21: of_12c: modalias failure on /dp@ff970000/ports
[0.895605] rockchip-dp ff970000.dp: Timeout of video streamclk ok
[0.895607] rockchip-dp ff970000.dp: unable to config video
[1.053894] mmcblk2: error -110 transferring data, sector 0, nr 8, cmd response 0x900, car status 0x0

Also, if I wait long enough, the kernel panics. It sounds like either the graphics driver or emmc driver is preventing it from going forward. If it is the emmc, it might be similar to the white screen issue others seem to get with the mainline kernel without patches. Any idea what might be the problem here? I tried booting off both a usb drive and a microsd card with no luck.

My ultimate goal is to get a libre kernel working, so the internal wifi issue shouldn't be a problem. I'll be using an atheros wifi dongle. For now, I am just trying to get any kernel working at all. So far, the kernels I've built only either white screen on boot, display the above message with several others, black screen on boot, or kernel panic (the case with the original 3.14 kernel). Right now I am using prebuilt 3.14 kernels to get anything done. Any help is greatly appreciated.

[Miouyouyou]

Hmm, which kernel did you try ? Did you try one the latest 4.18 ?

It seems that something is not answering in time, which generally means that some clocks are not enabled at runtime. I don't know if 3.14 kernels use DTS files. If that's the case, could you take a look at the how the Display port and the i2c at address ff970000 is initialized ? Or at least link it here.

Concerning the MMC error... It's basically sending a "110 ETIMEDOUT" which seems to be related.

Do the rockchip 4.4 kernels work with your setup ? I'm pretty sure that some clocks definitions are missing in the DTS files, causing all sorts of timeouts.

[jbowren]

I tried 4.13, like @duckdodger. 3.14 does use DTS files (at least the chromium version), though I am not sure how to check for what you are asking (the device has HDMI, but not Display port). Did you mean check the DTS file? I posted it at the bottom of this post. The whole kernel can be cloned with:

git clone https://chromium.googlesource.com/chromiumos/third_party/kernel linux-chromium

The Debian wiki page suggests a solution for the emmc problem, but it hasn't fixed the problem for me.

I haven't tried 4.4 yet, though there isn't a patch directory for it in RockMyy. Did you mean mainline without patches?

rk3288-veyron-speedy.dts:

/dts-v1/;
#include "rk3288-veyron-chromebook.dtsi"
#include "cros-ec-sbs.dtsi"

/ {
    model = "Google Speedy";
    compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
             "google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
             "google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
             "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
             "google,veyron-speedy", "google,veyron", "rockchip,rk3288";

    panel_regulator: panel-regulator {
        compatible = "regulator-fixed";
        enable-active-high;
        gpio = <&gpio7 14 GPIO_ACTIVE_HIGH>;
        pinctrl-names = "default";
        pinctrl-0 = <&lcd_enable_h>;
        regulator-name = "panel_regulator";
        startup-delay-us = <100000>;
        vin-supply = <&vcc33_sys>;
    };

    vcc18_lcd: vcc18-lcd {
        compatible = "regulator-fixed";
        enable-active-high;
        gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>;
        pinctrl-names = "default";
        pinctrl-0 = <&avdd_1v8_disp_en>;
        regulator-name = "vcc18_lcd";
        regulator-always-on;
        regulator-boot-on;
        vin-supply = <&vcc18_wl>;
    };

    backlight_regulator: backlight-regulator {
        compatible = "regulator-fixed";
        enable-active-high;
        gpio = <&gpio2 12 GPIO_ACTIVE_HIGH>;
        pinctrl-names = "default";
        pinctrl-0 = <&bl_pwr_en>;
        regulator-name = "backlight_regulator";
        vin-supply = <&vcc33_sys>;
        startup-delay-us = <15000>;
    };
};

&backlight {
    power-supply = <&backlight_regulator>;
};

&cpu_alert0 {
    temperature = <65000>;
};

&cpu_alert1 {
    temperature = <70000>;
};

&edp {
    /delete-property/pinctrl-names;
    /delete-property/pinctrl-0;

    force-hpd;
};

&panel {
    power-supply= <&panel_regulator>;
};

&rk808 {
    pinctrl-names = "default";
    pinctrl-0 = <&pmic_int_l>;
};

&sdmmc {
    disable-wp;
    pinctrl-names = "default";
    pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd_disabled &sdmmc_cd_gpio
            &sdmmc_bus4>;
};

&vcc_5v {
    enable-active-high;
    gpio = <&gpio7 21 GPIO_ACTIVE_HIGH>;
    pinctrl-names = "default";
    pinctrl-0 = <&drv_5v>;
};

&vcc50_hdmi {
    enable-active-high;
    gpio = <&gpio5 19 GPIO_ACTIVE_HIGH>;
    pinctrl-names = "default";
    pinctrl-0 = <&vcc50_hdmi_en>;
};

&pinctrl {
    backlight {
        bl_pwr_en: bl_pwr_en {
            rockchip,pins = <2 12 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };

    buck-5v {
        drv_5v: drv-5v {
            rockchip,pins = <7 21 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };

    hdmi {
        vcc50_hdmi_en: vcc50-hdmi-en {
            rockchip,pins = <5 19 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };

    lcd {
        lcd_enable_h: lcd-en {
            rockchip,pins = <7 14 RK_FUNC_GPIO &pcfg_pull_none>;
        };

        avdd_1v8_disp_en: avdd-1v8-disp-en {
            rockchip,pins = <2 13 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };

    pmic {
        dvs_1: dvs-1 {
            rockchip,pins = <7 12 RK_FUNC_GPIO &pcfg_pull_down>;
        };

        dvs_2: dvs-2 {
            rockchip,pins = <7 15 RK_FUNC_GPIO &pcfg_pull_down>;
        };
    };
};

[Miouyouyou]

Hmm, did you apply this patch ?

https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.18/DTS/0010-ARM-DTSI-rk3288-Adding-missing-EDP-power-domain.patch

The EMMC timeout seems to coincide with the EDP timeout, but I don't know if either of these error messages could be a red herring. Do you have happen to be able to get the full dmesg output (or full noisy serial output) of a RockMyy 4.18-rc4 kernel booting on this system ?

Meanwhile, you can also try to remove the &edp and panels references in the DTS file and see how it fares.

I'll take a look at the chromium kernel.

At last, the Rockchip 4.4 kernel I'm referencing is https://github.com/rockchip-linux/kernel/ But there's also the official Rockchip mainline kernel here : https://github.com/mmind/linux-rockchip

@JeffyCN did you hear about issues with the Display Port output on Chromebooks, using mainline kernels ?

[Miouyouyou]

The only big change I can see in the rk3288-veyron.dtsi file between the chromium kernel and the mainline kernel is this entry :

&power {
    assigned-clocks = <&cru SCLK_EDP_24M>;
    assigned-clock-parents = <&xin24m>;
};

Try adding this to the rk3288-veyron.dtsi file or the rk3288-veyron-speedy.dts at the end of the file, recompile and see how it goes.

[Miouyouyou]

I almost forgot : Can you paste the content of the kernel panic OOPS message, when it's stuck ?

[jbowren]

4.18 gives the error message:

[0.000000] rockchip_mmc_get_phase: invalid clk rate
[0.000000] rockchip_mmc_get_phase: invalid clk rate
[0.000000] rockchip_mmc_get_phase: invalid clk rate
[0.000000] rockchip_mmc_get_phase: invalid clk rate
[0.000000] rockchip_mmc_get_phase: invalid clk rate
[0.000000] rockchip_mmc_get_phase: invalid clk rate
[0.000000] rockchip_mmc_get_phase: invalid clk rate
[0.000000] rockchip_mmc_get_phase: invalid clk rate
[1.092656] elan_i2c 4-0015: invalid report id data (ff)

Can't get dmesg output since I never get to a shell. I cannot even get these messages to print to log files (copying by hand right now). 4.18 also panics if I wait long enough, the output is too long to type, but the stack trace mentions the symbols: mmc_switch, mmc_flush_cache, _mmc_hw_reset, mmc_hw_reset, mmc_blk_mq_rw_recovery, andmmc_blk_mq_complete_prev_req, process_one_work, work_thread, and kthread.

Still working on trying the patch you linked for 4.18, the 4.4 kernel, and the dts modification, though it definitely seems like an mmc issue.

Do you also need the 3.14 panic output?

[jbowren]

It turns out the patch you linked was already included in my 4.18 build (I built with the GetPatchAndCompileKernel.sh build script).

[jbowren]

The DTS power modification did not make a difference, same output.

[Miouyouyou]

Okay, let's take another approach then :

Was there any mainline 4.x kernel that worked for you ? You can test with various versions of my old MyyQi repositories if needed, since I made releases back then containing the kernel files themselves : https://github.com/Miouyouyou/MyyQi/releases?after=v4.12-rc4

Armbian ( https://armbian.com ) also have various images for various boards... Though I don't think they have Chromebook releases.

It seems that @phhusson already encountered this issue at some point too. Searching for mmc_switch rk3288 on Google leads to some irc://irc.freenode.net/#linux-rockchip logs ( https://irclog.whitequark.org/linux-rockchip/2017-01-25 ) . Maybe asking on that IRC channel could provide you a lead.

Anyway, the approach is to take a mainline kernel that works and go one version forward until the boot sequence locks up again. "Works" mean it boots. The screen issue seems to be unrelated to the boot lock up, so even if you got a gray screen, if it boots up and you can get a SSH on it, we'll say that it "works" for this case. Of course, if you can't even SSH and see anything, you'll have a hard time knowing that it booted... Once you can pinpoint when any mainline kernel started to fail booting, then I can take a look at the logs on the mainline kernel ( https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/ ) and see what changed between those two versions in the MMC code.

I took a look at the MMC definitions in the chromium kernel DTS files but they seem identical to the mainline ones... I'll have a look at the code tomorrow.

@TonyMac32 Do you have a Chromebook ? Does it boot form the eMMC ?

[jbowren]

The mainline Debian Stretch kernel without patches (4.9) boots to a white screen, haven't checked yet if I can ssh in. I also got linux-libre 4.17.3 to boot to a white screen once, but this time I used the RockMyy config file and got the same invalid clk rate error. Perhaps this issue is dependent on the kernel configuration.

[JeffyCN]

Hi @jbowren , the "invalid clk rate" is caused by https://patchwork.kernel.org/patch/10258067/, which seems harmless, and likely only happen during early boot.

i'm not sure would it related to the emmc hang, but maybe we can try to revert that, or git bisect the mainline kernel?

and for the white screen, maybe we can try to built-in drm drivers if not, and maybe even enable CONFIG_DRM_FBDEV_EMULATION & CONFIG_FRAMEBUFFER_CONSOLE.

[Tonymac32]

@Miouyouyou I do, but this is a project that got run over by life. I want to bring it back though, because honestly chrome OS is kind of... well...

I want to get an Armbian iamge running on it, I have a veyron-jerry. But so far no actual attempts have been made. @JeffyCN shouldn't the clocks be set up in u-boot, so not read 0?

[jbowren]

Hi @JeffyCN, I reverted the change and it removed the invalid clk rate error, but it does not fix the main problem (not booting). Now it only prints

[1.100640] elan_i2c 4-0015: invalid report id data (ff)

I know the kernel is not frozen because the cursor is still blinking and if I plug a flash drive in it prints messages about the drive. The kernel proceeds to panic with the same stack trace as before if I leave it running long enough. This definitely seems to be due to the emmc.

BTW, I can't ssh into the Debian kernel. I installed a prebuilt kernel for the white screen, but I believe I was able to also get a white screen when building linux-libre 4.17, though I don't seem to have the setup on hand. I originally got the white screen issue when following this tutorial: https://github.com/NuclearKev/dragora-c201. They claim if you try booting enough, the system should get past the white screen, but I have had no luck.

[Tonymac32]

Hmmm, libreboot. Has anyone stuffed U-boot onto this thing? I see it in the sources, but everyone keeps sticking libreboot on it. is it actually better?

[Tonymac32]

https://wiki.gentoo.org/wiki/Asus_Chromebook_C201

they like them some RockMyy

[jbowren]

I forgot to switch to the branch recommended by the debian page for the c201 in the chromium kernel before posting the dts file. There does not seem to be a rk3288-veyron-speedy.dts file, instead the debian page uses the file rk3288-speedy.dts, which is displayed at the bottom of this post.

The kernel panics on boot, but I was able to get a small glimpse of what was printed to the screen before the panic. It prints a lot of messages, but most importantly it says something like "rockchip-drm display-subsystem.4: registered panic not..." The stock kernel also panics on boot when not running chromeos, so I think it has something to do with that.

rk3288-speedy.dts:

/dts-v1/;
#include "rk3288-veyron-chromebook.dtsi"
#include "rk3288-veyron-lpddr.dtsi"
#include "cros-ec-sbs.dtsi"

/ {
    model = "Google Speedy";
    compatible = "google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
             "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
             "google,veyron-speedy", "google,veyron", "rockchip,rk3288";

    panel_regulator: panel-regualtor {
        compatible = "regulator-fixed";
        enable-active-high;
        gpio = <&gpio7 14 GPIO_ACTIVE_HIGH>;
        pinctrl-names = "default";
        pinctrl-0 = <&lcd_enable_h>;
        regulator-name = "panel_regulator";
        vin-supply = <&vcc33_sys>;
    };

    vcc18_lcd: vcc18-lcd {
        compatible = "regulator-fixed";
        enable-active-high;
        gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>;
        pinctrl-names = "default";
        pinctrl-0 = <&avdd_1v8_disp_en>;
        regulator-name = "vcc18_lcd";
        regulator-always-on;
        regulator-boot-on;
        vin-supply = <&vcc18_wl>;
    };

    backlight_regulator: backlight-regulator {
        compatible = "regulator-fixed";
        enable-active-high;
        gpio = <&gpio2 12 GPIO_ACTIVE_HIGH>;
        pinctrl-names = "default";
        pinctrl-0 = <&bl_pwr_en>;
        regulator-name = "backlight_regulator";
        vin-supply = <&vcc33_sys>;
        startup-delay-us = <15000>;
    };
};

&gpio_keys {
    power {
        gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
    };
};

&backlight {
    power-supply = <&backlight_regulator>;
};

&panel {
    power-supply= <&panel_regulator>;
};

&rk808 {
    pinctrl-names = "default";
    pinctrl-0 = <&pmic_int_l &dvs_1 &dvs_2>;
    dvs-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>,
            <&gpio7 15 GPIO_ACTIVE_HIGH>;
};

&sdmmc {
    pinctrl-names = "default";
    pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd_disabled &sdmmc_cd_gpio
            &sdmmc_bus4>;
    disable-wp;
};

&thermal {
    #include "rk3288-speedy-thermal.dtsi"
};

&vcc_5v {
    enable-active-high;
    gpio = <&gpio7 21 GPIO_ACTIVE_HIGH>;
    pinctrl-names = "default";
    pinctrl-0 = <&drv_5v>;
};

&vcc50_hdmi {
    enable-active-high;
    gpio = <&gpio5 19 GPIO_ACTIVE_HIGH>;
    pinctrl-names = "default";
    pinctrl-0 = <&vcc50_hdmi_en>;
};

&edp {
    pinctrl-names = "default";
    pinctrl-0 = <&edp_hpd>;
};

&pinctrl {
    backlight {
        bl_pwr_en: bl_pwr_en {
            rockchip,pins = <2 12 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };

    buck-5v {
        drv_5v: drv-5v {
            rockchip,pins = <7 21 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };

    edp {
        edp_hpd: edp_hpd {
            rockchip,pins = <7 11 RK_FUNC_2 &pcfg_pull_down>;
        };
    };

    emmc {
        /* Make sure eMMC is not in reset */
        emmc_deassert_reset: emmc-deassert-reset {
            rockchip,pins = <2 9 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };

    hdmi {
        vcc50_hdmi_en: vcc50-hdmi-en {
            rockchip,pins = <5 19 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };

    lcd {
        lcd_enable_h: lcd-en {
            rockchip,pins = <7 14 RK_FUNC_GPIO &pcfg_pull_none>;
        };

        avdd_1v8_disp_en: avdd-1v8-disp-en {
            rockchip,pins = <2 13 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };

    pmic {
        dvs_1: dvs-1 {
            rockchip,pins = <7 12 RK_FUNC_GPIO &pcfg_pull_down>;
        };

        dvs_2: dvs-2 {
            rockchip,pins = <7 15 RK_FUNC_GPIO &pcfg_pull_down>;
        };
    };
};

[Miouyouyou]

@TonyMac32 They sure do :smiley_cat:

@jbowren I guess that, since it's a laptop, you can't use the serial output ? In that case, your best bet might be get a photo of the screen when it panics, and maybe a small video of the boot sequence... at max FPS if possible, else things might just be extremely blurry.

The speedy.dts really resembles the veyron-speedy.dts . Except that two things are added in the pinctrl listing :

    edp {
        edp_hpd: edp_hpd {
            rockchip,pins = <7 11 RK_FUNC_2 &pcfg_pull_down>;
        };
    };

    emmc {
        /* Make sure eMMC is not in reset */
        emmc_deassert_reset: emmc-deassert-reset {
            rockchip,pins = <2 9 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };

Try adding this... and set up the &edp node to reference at least the edp_hpd pinctrl :

&edp {
    pinctrl-names = "default";
    pinctrl-0 = <&edp_hpd>;
};

Now I don't know where the emmc_deassert_reset is referenced...

Anyway, the official file is here, for comparaison : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288-veyron-speedy.dts?h=v4.18-rc4

[Miouyouyou]

Also there's a reference to rk3288-veyron-lpddr.dtsi and a typo in panel_regulator in that rk3288-speedy.dts file.

[jbowren]

I thought I tried this before, but apparently not. I built mainline with the RockMyy config without patches and though the kernel cannot boot the emmc, it can boot SD cards and USB drives. Since there is only 16GB on the device this is a decent workaround. Maybe I could use this to find out why the emmc wasn't working too, but this is not as important. The issue is definitely failing to read the emmc, the newer kernels wait indefinitely to hear back from the emmc (which is why the workaround works).

I'm now trying to get wireless working with an external Atheros USB adapter. In the 4.8 kernel wireless worked, but it seemed flaky. In the 4.17 (also 4.18) kernel for some reason the Atheros kernel modules do not load, and trying to manually load them results in the kernel complaining that the modules has unknown symbols. In the 4.8 kernel the modules are loaded in the correct order automatically.

One last issue seems to be that when running Debian with a graphical desktop environment, the desktop seems to freeze when loading files from the SD card (when mousing over a menu item in LXDE or MATE). This does not happen in Devuan, my guess would be because it does not use systemd (that seems to be the main difference between the two setups). Maybe systemd needs a ramdisk to perform quickly, I really don't now, but I can now generate one while booted into these newer kernels.

[Miouyouyou]

Now that you're able to start a system, could you provide the result of dmesg ?

SystemD makes heavy use of cgroups, tmpfs and shmfs IIRC.

[jbowren]

dmesg attached at the bottom. So it seems sometimes the system does not boot, but sometimes does, similar to the white screen issue. However, when it is working, it can be rebooted several times without problems, and when it is not working, it takes several tries to get working again.

Also, it seems in order for USB devices to work, they need to be connected at boot, which is why the Atheros modules were not loading. However the USB adapter is still not working because it is missing some firmware file that doesn't seem to be provided by Debian's firmware package. Check the dmesg for details.

dmesg_athworking.log

[Miouyouyou]

I see a lot of references to misinterpreted GPIO entries... Are you able to boot one of my kernels using a SDCard ? If it works, could you also provide that dmesg for comparaison.

Those MMU warnings seems like a problem I solved not too long ago...

[jbowren]

By "one of your kernels" did you mean running the rockmyy script to build the latest kernel. That worked. Here is the dmesg dmesg_rockmyy.log

As far as the atheros issue, I tried building the firmware from source, but when I attempt to bring the device up it claims that it is not ready, and the device stays down. Trying to set up a connection with wpa_supplicant results in a kernel panic.

Still no idea why the booting process is intermittent.

[Miouyouyou]

In the logs, I see that the driver tries to look for a file named : ath9k_htc/htc_9271-1.4.0.fw

When it comes to the "binary blobs firmwares" with recent kernels, the only viable solution is to clone https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ into /lib/firmware .

That said, it seems that the "wp" properties on the MMC nodes definition are not parsed correctly... I wonder why and if it would be better to remove these properties.

[Miouyouyou]

Also, I don't know what is mmcblk2, but it has some weird name (HAG2e\u0005) The last character might generate issues. I don't know if it's possible to change it.

It seems to be the eMMC though... If you could change it to something like "EMMC", that might avoid issues with drivers not expecting names with the "Control" character. That said, I don't remember the tools used to operate on MMC, right now, and I'm at work so I can't test anything.

[jbowren]

The firmware for this device in particular is free software, so it can be built from source, though I tried the linux firmware you mentioned. I was able to establish a connection and download some files, but the kernel panicked after some time. The exact network adapter I am using is this one.

It seems the issue with the wifi is actually not related at all to the atheros wifi firmware, but the usb dwc2 driver, see https://github.com/qca/open-ath9k-htc-firmware/issues/124. Not sure how to get around this issue...

USB devices still don't work unless plugged in at boot.

As for mmcblk2, it definitely seems to be the eMMC, though I don't know what HAG2e\u0005 refers to, or how I would change it. For the wp properties, I am guessing they are in rk3288-veyron-speedy.dts, I'll see if I can remove them and see what happens.

[Miouyouyou]

Well, first, can you format the eMMC ? (Using something like gparted). Also, HAG2e\u0005 seems to the name of the eMMC. I haven't check how to modify it. I'll check tonight if I remember.

Concerning the USB issues, if it works with the chromeos kernel and not with mainline kernels, then it's just a driver problem. Maybe the driver has been patched to work around hardware issues in the chromeos kernel... that's not uncommon in the RK3288 world...

Still, could you paste the content of the kernel panic if you can ?

[jbowren]

I tried formating the eMMC with gparted a while ago, but it just produced errors. I'll try again soon, but I am a bit busy with the contents of my eMMC at the moment. When I reflash Chrome OS I can try the atheros dongle too, but I don't think it has the atheros modules. ath.log

USB devices only being registered at boot has me perplexed. Looking on a working 3.14 system, there are several modules regarding other filesystems like vfat and usb modules like usbcore, but on the 4.17 system they are not there (instead, a module called uas is present). When I run modprobe usbcore, I do not get an error about the module missing (though I can't find it in the modules directory). Missing modules return an error, so maybe the newer kernel incorporates these older modules in kernel itself?

For some reason, I am now getting the USB deinitialized error like that in the link I posted. I can't reproduce the kernel panic/get the device up. Also strange, I don't seem to have the problem with the Debian system freezing upon loading files in a graphical desktop environment anymore. I must have changed some configuration somewhere, but I can't pinpoint it. Perhaps it was when I was building with the patches. For now, I think it is best to build with the RockMyy config file without patches for the best results on the c201.

EDIT: The broadcom internal wifi works fine with the proprietary firmware provided by Chrome OS (doesn't seem to be in linux-firmware).

[Miouyouyou]

Well, with my default configuration, a lot of drivers are included in the kernel, not as modules.

If you do find /lib/modules/4.18* what do you get ?

Anyway, most of the patches target Tinkerboard/MiQi boards issues, not really Chromebook ones (since I don't own any), so you can do without them.

About USB devices, I haven't checked on my Tinkerboard but there might something going on with Mainline kernels and USB hotplug. I'll try to check what's wrong next week. I guess that the Atheros issue and the USB issue are indeed related : https://github.com/qca/open-ath9k-htc-firmware/issues/1

[jbowren]

The modules being built into the kernel explains a lot, and why the initramfs is not needed. The find output is find_4.18.log

I think the lack of hotplug support might be due to the kernel parameters, the parameters I am using are:

console=ttyS2,115200n8 earlyprintk=ttyS2,115200n8 console=tty1 init=/sbin/init root=/dev/mmcblk0p2 rootwait rw noinitrd

[jbowren]

gparted seems to fail silently on attempting to partition the emmc, but it produces the output:

/dev/mmcblk0: unrecognised disk label
Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 11841536 blocks) or continue with the current setting?

The second warning is regarding the flash drive I booted off of running devsus, so it is unrelated.

The partitioning seems to work according to the GUI, but when trying to add partiions gparted claims there is no partition table. Partitioning with cgpt works a bit better, though it usually complains about needing to use the secondary gpt table since the primary is supposedly corrupt.

[Miouyouyou]

Before wiping up everything on the eMMC, if you can boot the chromium kernel, try to check if gparted claims the same thing there.

The lack of hotplug might just be due to some random kernel bug that got introduced in some random versions. I haven't checked that part for a while. I mainly focus on testing Video output and OpenGL support, so I might have let this passed for a few versions.

One way to know when this bug has been introduced, would be to test a few random previous versions, see if you can find one with USB hotplugging working.

Maybe I forgot an option in the .config too. But I have no idea which one could lead to such issues.

[jbowren]

Great news, hotplug works fine on 4.13. I haven't checked yet if chromium has gparted, so it might be a bit hard to test the chromium os kernel in case it is not there.

[jbowren]

HDMI audio devices don't seem to be recognized, but the module dw_hdmi_i2s_audio is loaded. Android devices also don't seem to appear in adb, but they show up in lsusb. The android device works fine with adb on my other Debian computer.

EDIT: My android device did show up, but only after leaving it plugged in for a while. It is reported offline, despite having udev configured appropriately with the debian android packages.

EDIT 2: I plugged in another phone and the kernel endlessly loops trying to enumerate the device:

[ 5070.394927] usb 1-1: new high-speed USB device number 20 using dwc2
[ 5070.574145] usb 1-1: device descriptor read/all, error -71
[ 5070.735984] usb 1-1: new high-speed USB device number 21 using dwc2
[ 5071.312920] usb 1-1: device not accepting address 21, error -71
[ 5071.475877] usb 1-1: new high-speed USB device number 22 using dwc2
[ 5071.497459] usb 1-1: device descriptor read/8, error -71
[ 5071.621142] usb 1-1: device descriptor read/8, error -71
[ 5071.889767] usb 1-1: new high-speed USB device number 23 using dwc2
[ 5072.312737] usb 1-1: device not accepting address 23, error -71
[ 5072.319395] usb usb1-port1: unable to enumerate USB device
[ 5073.482879] usb 1-1: new high-speed USB device number 24 using dwc2
[ 5073.661302] usb 1-1: device descriptor read/all, error -71
[ 5073.823861] usb 1-1: new high-speed USB device number 25 using dwc2
[ 5074.400773] usb 1-1: device not accepting address 25, error -71
[ 5074.563791] usb 1-1: new high-speed USB device number 26 using dwc2
[ 5074.585274] usb 1-1: device descriptor read/8, error -71
[ 5074.709244] usb 1-1: device descriptor read/8, error -71
[ 5074.973700] usb 1-1: new high-speed USB device number 27 using dwc2
[ 5075.199225] usb 1-1: device descriptor read/8, error -71
[ 5075.325307] usb 1-1: device descriptor read/8, error -71
[ 5075.432670] usb usb1-port1: unable to enumerate USB device

EDIT 3: I plugged in yet a third phone and this time adb worked as expected. I guess this must be another issue with the dw2 driver. This driver seems to be significantly limiting the device.

[Miouyouyou]

The audio is due to another issue... I remember that I saw that issue somewhere, but can't remember where exactly. I thought this was resolved though...

Still I can't focus on that one at the moment.

Concerning the DWC2 driver issues, does this issue also on that 4.13 kernel ? Doe this issue also appear on RockMyy 4.13 ( https://github.com/Miouyouyou/RockMyy/archive/1867b165e1f6063ff39431b942d23f6516abfa62.zip ) ?

If I can determine when the problem started to appear, this might help resolving it. Now, it could be buggy in the mainline tree since it was integrated, I don't know...

[jbowren]

I suspect this is a bug in the mainline tree. Every kernel that I have tried has had problems. It seems the kernel panic I mentioned for the atheros wifi dongle (but thought was unreproducible) happens on kernel 4.13. Kernel 4.17 and 4.18 just don't create a device (wlan0 or wlx*) when the dongle is plugged in. I am not sure where to submit bug reports about dw2, but since others have encountered the issue maybe these bugs are already being addressed.

I'll test your 4.13 build.

[jbowren]

It seems the sound on some videos played on youtube come in as static, whereas sound from videos played locally on the machine always show up as static. To get sound working, I had to copy UCM sound profiles from chromeos into my Debian install, maybe this has something to do with it. The is documented on the Debian howto.