Mainline Kernel on Tegra K1 (Acer Chromebook 13 CB5-311)

This forum is for supported devices using an ARMv7 nVidia SoC.

Mainline Kernel on Tegra K1 (Acer Chromebook 13 CB5-311)

Postby haagch » Fri Jan 08, 2016 8:47 am

Update: Works with linux-armv7 mainline kernel from archlinux arm

Working:
Keyboard with special keys (install xkeyboard-config-chromebook from AUR)
Touchpad (modprobe elan_i2c may be needed and run xinput set-prop "Elan Touchpad" "Synaptics Finger" 25 45 0 for a slightly better experience)
Suspend to Ram
Display Brightness
Wifi (a bit flakey at times)
Bluetooth
Battery status (modprobe bq24735_charger may be needed, also upower package with little patch, see somewhere in this thread)
Webcam
Sound (need to enable "Left|Right Speaker Mixer Left|Right DAC" (all 4))
3d acceleration, experimental

Here are some packages:
* Kernel with LPAE and battery charger module & updated device tree to activate the GPU
* upower with small patch for battery status
* https://github.com/Gnurou/xserver (uses nouveau via render nodes)
Code: Select all
http://haagch.frickel.club/files/linux-armv7-4.4.0-4-armv7h.pkg.tar.gz
http://haagch.frickel.club/files/linux-armv7-chromebook-4.4.0-4-armv7h.pkg.tar.gz
http://haagch.frickel.club/files/linux-armv7-headers-4.4.0-4-armv7h.pkg.tar.gz
http://haagch.frickel.club/files/upower-0.99.3-2-armv7h.pkg.tar.xz
http://haagch.frickel.club/files/xorg-server-common-git-.r14951.-1-armv7h.pkg.tar.gz
http://haagch.frickel.club/files/xorg-server-devel-git-.r14951.-1-armv7h.pkg.tar.gz
http://haagch.frickel.club/files/xorg-server-git-.r14951.-1-armv7h.pkg.tar.gz
http://haagch.frickel.club/files/xorg-server-xdmx-git-.r14951.-1-armv7h.pkg.tar.gz
http://haagch.frickel.club/files/xorg-server-xephyr-git-.r14951.-1-armv7h.pkg.tar.gz
http://haagch.frickel.club/files/xorg-server-xnest-git-.r14951.-1-armv7h.pkg.tar.gz
http://haagch.frickel.club/files/xorg-server-xvfb-git-.r14951.-1-armv7h.pkg.tar.gz
http://haagch.frickel.club/files/xorg-server-xwayland-git-.r14951.-1-armv7h.pkg.tar.gz


Here is https://github.com/Gnurou/nouveau, a more WIP nouveau module:
http://haagch.frickel.club/files/nouveau.ko.gz (3d8d0e6b2c0725f1779775bf37b4a96959543c03)



Original post:
See this: http://www.phoronix.com/scan.php?page=n ... Chromebook

Apparently 3D acceleration with nouveau works with the mainline kernel.

There are still a few glitches, like the touchpad does not work, but we will get those fixed in the coming days.


Is Archlinux ARM interested in providing mainline kernel packages?

Edit: Huh, brainfart, I meant providing support for the device, Making sure the config works, adding quirks if necessary, e.g. for the touchpad etc.
Last edited by haagch on Wed Jan 27, 2016 10:32 am, edited 4 times in total.
haagch
 
Posts: 32
Joined: Thu Apr 02, 2015 5:36 pm

Re: Mainline Kernel on Tegra K1 (Acer Chromebook 13 CB5-311)

Postby WarheadsSE » Fri Jan 08, 2016 12:29 pm

We do, linux-armv7
Core Developer
Remember: Arch Linux ARM is entirely community donation supported!
WarheadsSE
Developer
 
Posts: 6325
Joined: Mon Oct 18, 2010 2:12 pm

Re: Mainline Kernel on Tegra K1 (Acer Chromebook 13 CB5-311)

Postby haagch » Fri Jan 08, 2016 8:41 pm

See my edit. The config they used is linked in the article: https://kushaldas.in/tegra_config. It has a lot of differences to the linux-armv7 config, so I haven't looked whether all the relevant things are activated in arch.

I have first tried setting up a dual boot with the archlinux linux-armv7-rc and linux-armv7-rc-chromebook packages following this modified chrubuntu script: https://www.tbi.univie.ac.at/~ronny/acer-cb5-311.html because I figured even if the config doesn't match 1:1 there's a good chance it could at least boot (I know it's not following the archlinux arm procedure with external usb memory).
Here is what I changed so far: https://github.com/ChristophHaag/LinuxOnAcerCB5-311.
Basically I removed the installation of the tegra stuff and replaced it with with installing archlinux linux-armv7-rc and linux-armv7-rc-chromebook, and then added flashed the chromebook stuff to the boot partition: "dd if=/boot/vmlinux.kpart of=/dev/${target_kern}"

But when I try to boot it, the screen flashes a bit and then boots chrome os.
So I suppose either I did something wrong or the linux-armv7-rc kernel does not support the Tegra K1 chromebooks. I looked around a bit and saw that there is a kernel.its config for the K1 (tegra128-nyan) that is not included in the archlinux arm kernel package: https://github.com/RaumZeit/PKGBUILDs/b ... l-nyan.its. Should it work without this config? At least the linux-armv7-rc package includes /boot/dtbs/tegra-124-nyan-big.dtb...

I don't know much about booting on arm chromebooks, but before reading full documentation I wanted to ask here whether I'm wasting my time and just need to build my own kernel with the nyan config and its.
So far I can chroot into the archlinux system and install packages without problems, so it's easy to experiment.
haagch
 
Posts: 32
Joined: Thu Apr 02, 2015 5:36 pm

Re: Mainline Kernel on Tegra K1 (Acer Chromebook 13 CB5-311)

Postby tincman » Mon Jan 11, 2016 5:42 am

haagch wrote:See my edit. The config they used is linked in the article: https://kushaldas.in/tegra_config. It has a lot of differences to the linux-armv7 config, so I haven't looked whether all the relevant things are activated in arch.


I have a slightly modified version of linux-armv7-rc running on my chromebook. The only config changes I made were to enable LPAE (to access the full 4GB of memory), and adding support for the BQ24735 charger (which doesn't work anyways and causes my upowerd to crash... still trying to figure that one out, but the sbs-battery works well enough w/o it with a hack to the device-tree).

But when I try to boot it, the screen flashes a bit and then boots chrome os.
So I suppose either I did something wrong or the linux-armv7-rc kernel does not support the Tegra K1 chromebooks. I looked around a bit and saw that there is a kernel.its config for the K1 (tegra128-nyan) that is not included in the archlinux arm kernel package: https://github.com/RaumZeit/PKGBUILDs/b ... l-nyan.its. Should it work without this config? At least the linux-armv7-rc package includes /boot/dtbs/tegra-124-nyan-big.dtb...

I don't know much about booting on arm chromebooks, but before reading full documentation I wanted to ask here whether I'm wasting my time and just need to build my own kernel with the nyan config and its.
So far I can chroot into the archlinux system and install packages without problems, so it's easy to experiment.


If the kernel fails to boot, but then boots into ChromeOS, then it was not able to begin executing the kernel. If you open a shell under ChromeOS, you can check how many times it failed with "cgpt show /dev/mmcblk1" (assuming you are attempting to boot from an sd-card). What did ${target_kern} eval to? The ChromeOS bootloader is picky about what partitions are kernel partitions and what ones will boot. You may have to "re-enable" the partition.

More details on the boot process w.r.t. tries vs failures can be found here (http://www.chromium.org/chromium-os/chr ... the-kernel) This page also has more info on the partition layout, and the wiki in general has a lot of good info on ChromiumOS internals and boot processes and such.

From my attempts, the linux-armv7-rc kernel should get far enough in the boot process and "hang" at just a blank screen.

As far as the kernel.its, this is somewhat annoying. The bootloader will pass in a model/compatability string for the kernel to match to a device tree, but the Acer chromebooks have a "rev{x}.{y}" string that the mainline kernel dts's don't have. This causes the kernel to load the wrong device-tree during boot (it actually loads the tegra-nyan-blaze for the HP Chromebook 13). The kernel.its is a way to include the compiled binary device-tree blobs in the kernel and select one at boot.

You can either modify the tegra124-nyan-big.dts compatabile line to include "google,nyan-big-rev{x}", or you can cheat (like I did) and make a kernel.its file that only includes the nyan-big dtb

Code: Select all
/dts-v1/;

/ {
    description = "Chrome OS kernel image with one or more FDT blobs";
    images {
        kernel@1{
            description = "kernel";
            data = /incbin/("arch/arm/boot/zImage");
            type = "kernel_noload";
            arch = "arm";
            os = "linux";
            compression = "none";
            load = <0>;
            entry = <0>;
        };
        fdt@1{
            description = "tegra124-nyan-big.dtb";
            data = /incbin/("arch/arm/boot/dts/tegra124-nyan-big.dtb");
            type = "flat_dt";
            arch = "arm";
            compression = "none";
            hash@1{
                algo = "sha1";
            };
        };
    };
    configurations {
        default = "conf@1";
        conf@1{
            kernel = "kernel@1";
            fdt = "fdt@1";
        };
    };
};


And accelerated graphics currently do not work. The GPU is disabled by default (but can easily be turned on by tweaking the device tree). Nouveau will recognize the GPU and load the KMS drivers for it (the work nouveau/Nvidia has been doing on this front is awesome and exciting).

The problem is the embedded architecture. Xorg/Weston assume the rendering device is the display controller as well, which is not true in this case. There is good work being done using render/control nodes to do dma-buf sharing and allow these sort of heterogenous setups (similar to PRIME, but this requires a Xorg DDX driver, which gk20a does not have).

However, the Tegra display DRM works, and the modesetting driver works very well for software rendering (and I'm shocked at how snappy it is as well).

Lastly, the touchpad _does_ work, but the module needs to be loaded manually for it to work, just add "elan_i2c" to '/etc/modules-load.d/elan_touchpad.conf'

Addendum:
The problems with the touchpad not being automatically loaded seem to be from the cros-ec being flaky during boot. Any ideas on how to get this working better would be appreciated.

The sbs-battery has the bq24735 charger as a power supply listed in the device-tree. However, when the charger is not plugged in, this power-supply becomes "absent" and the battery errors out, saying the probe is deferred until all the necessary supplies are present. Even adding the "force_load" parameter _does not_ get around this behavior. The only way I got this to work was to remove the power-supply line from the device-tree. This work well (and sbs-battery properly reports charging/discharging that upowerd picks up), however I'm fairly certain this change is not the right-way-to-do-it. Any advice or ideas would be greatly appreciated.

Sound is complicated... I HAD it working, reflashed and it stopped working. No idea what I did that made it work, and have not been able to get it to work again...

I'm also currently trying to patch xorg-server to use render/control nodes for accelerated graphics, similar to what was previously "hacked" in https://github.com/Gnurou/xserver/commi ... 3f14193ebb
Last edited by tincman on Tue Jan 12, 2016 2:04 am, edited 1 time in total.
tincman
 
Posts: 23
Joined: Sat Feb 23, 2013 5:27 pm

Re: Mainline Kernel on Tegra K1 (Acer Chromebook 13 CB5-311)

Postby haagch » Mon Jan 11, 2016 10:07 am

Thanks for all the info, will read later. I was so far to try to build a kernel including a modified version of https://github.com/RaumZeit/PKGBUILDs/b ... l-nyan.its, but so far simply running
Code: Select all
make

in a chroot always segfaults:
Code: Select all
#0  0xb6d7fe24 in strlen () from /usr/lib/libc.so.6
#1  0xb6d7fb30 in strdup () from /usr/lib/libc.so.6
#2  0x0001f784 in xstrdup ()
#3  0x0002a164 in define_variable_in_set ()
#4  0x0000e3ec in main ()


Edit: The modified chrubuntu script that I used created /dev/mmcblk0p6 as the kernel partition and /dev/mmcblk0p7 as the archlinux root partition. So I dd'ed vmlinux.kpart to /dev/mmcblk0p6 and as the script says did cgpt add -i 6 -P 5 -T 1 /dev/mmcblk0 and rebooted.

edit2: Just tried cgpt add -i 6 -P 15 -T 3 -S 0 /dev/mmcblk0, rebooted and got this:

Code: Select all
       start        size    part  contents
           0           1          PMBR (Boot GUID: 8A0FC77B-9897-0E43-B57A-25A1A735635B)
           1           1          Pri GPT header
           2          32          Pri GPT table
     8671232    12496896       1  Label: "STATE"
                                  Type: Linux data
                                  UUID: C53CDB10-4C5B-4C43-9B9A-A22265C9D0C1
       20480       32768       2  Label: "KERN-A"
                                  Type: ChromeOS kernel
                                  UUID: 34689828-F93B-5B4F-AC29-B0E352C683F5
                                  Attr: priority=1 tries=0 successful=1
     4476928     4194304       3  Label: "ROOT-A"
                                  Type: ChromeOS rootfs
                                  UUID: 22C14705-496E-2546-B06E-1E73D099A31D
       53248       32768       4  Label: "KERN-B"
                                  Type: ChromeOS kernel
                                  UUID: C7CC1DC4-5F41-014D-A37B-2441D3D57D3C
                                  Attr: priority=3 tries=0 successful=1
      282624     4194304       5  Label: "ROOT-B"
                                  Type: ChromeOS rootfs
                                  UUID: D50371B5-3A82-2646-9F52-4605BB3EB151
    21168128       32768       6  Label: "KERN-C"
                                  Type: ChromeOS kernel
                                  UUID: AC88214E-BD14-7546-AD04-95A0272045B0
                                  Attr: priority=0 tries=0 successful=0
    21200896    39845888       7  Label: "ROOT-C"
                                  Type: ChromeOS rootfs
                                  UUID: B1FCD495-E2DA-294C-AD39-3FBF4D391C22
       86016       32768       8  Label: "OEM"
                                  Type: Linux data
                                  UUID: A4FE55E2-472D-0C41-B1B6-B26692FAC9D3
       16450           1       9  Label: "reserved"
                                  Type: ChromeOS reserved
                                  UUID: CACDD268-715D-A046-8B93-6D001F7C5E36
       16451           1      10  Label: "reserved"
                                  Type: ChromeOS reserved
                                  UUID: D76F9EA9-8238-7248-9A43-1AD62A3B2E44
          64       16384      11  Label: "RWFW"
                                  Type: ChromeOS firmware
                                  UUID: FD682148-7817-9149-B068-7978DA81C86B
      249856       32768      12  Label: "EFI-SYSTEM"
                                  Type: EFI System Partition
                                  UUID: 8A0FC77B-9897-0E43-B57A-25A1A735635B
    61079519          32          Sec GPT table
    61079551           1          Sec GPT header

No tries left on partition 6. :/

edit 3: Would you mind uploading the packages somewhere?
haagch
 
Posts: 32
Joined: Thu Apr 02, 2015 5:36 pm

Re: Mainline Kernel on Tegra K1 (Acer Chromebook 13 CB5-311)

Postby raumzeit » Mon Jan 11, 2016 12:28 pm

Good to see, that mainline kernel support seems to work. I still have not found the time yet to try it myself, but I'll report back as soon as I made it working for my Chromebook. The issue with adding the corresponding device tree stuff for the nyan boards into the kernel.its seems the only 'major' thing that needs to be added to linux-armv7(-rc).

Regarding the segmentation faults of upower, there is a fix available for that. The problem is, that udev reports back the battery with a string that contains an invalid '@' character. At least upower regards that as invalid. However, a simple patch solves this problem quite elegantly, see https://bugs.freedesktop.org/show_bug.cgi?id=93095 and my upower package here: https://github.com/RaumZeit/PKGBUILDs/b ... r/PKGBUILD . I already use this patched version of upower for the chromeOS kernel 3.10 to avoid upower constantly segfaulting...

Cheers

RaumZeit
Acer CB5-311, Samsung ARM Chromebook, NSA 325, WandBoard Quad, Raspberry Pi B, BeagleBoard ...and a dead Pandaboard :sad:
raumzeit
 
Posts: 65
Joined: Mon Oct 17, 2011 8:37 pm
Location: Vienna AT

Re: Mainline Kernel on Tegra K1 (Acer Chromebook 13 CB5-311)

Postby haagch » Mon Jan 11, 2016 1:21 pm

Ah, I got it.

@raumzeit
In your guide you didn't mention running "crossystem dev_boot_usb=1 dev_boot_signed_only=0", so I didn't do it yet. I finally thought to try it on an SD card and ran it and thought that I might as well try booting with that before doing anything with the SD card and indeed, it "boots" to a black screen with the stock linux-armv7-rc kernel. (and resetting it 3 times, because I have set 3 tries with power+refresh boots chromeos again).

Reading up on it, dev_boot_signed_only doesn't have the obvious meaning - that it only boots signed kernels, but it means, that it only boots kernels signed by google... Maybe you could mention this in your guide.

The make segfault is something with the chrome terminal:
Code: Select all
Program received signal SIGSEGV, Segmentation fault.
0xb6d37e24 in strlen () from /usr/lib/libc.so.6
(gdb) bt full
#0  0xb6d37e24 in strlen () from /usr/lib/libc.so.6
No symbol table info available.
#1  0xb6d37b30 in strdup () from /usr/lib/libc.so.6
No symbol table info available.
#2  0x00026c2c in xstrdup (ptr=ptr@entry=0x0) at ./misc.c:259
        result = <optimized out>
#3  0x0003129c in define_variable_in_set (name=name@entry=0x377f8 "MAKE_TERMOUT", length=length@entry=12, value=0x0,
    origin=origin@entry=o_default, recursive=recursive@entry=0, set=0x4d6d0 <global_variable_set>, flocp=flocp@entry=0x0) at ./variable.c:243
        v = 0x5b390
        var_slot = 0x4f498
        var_key = {name = 0x377f8 "MAKE_TERMOUT", value = 0x30e034a3 <error: Cannot access memory at address 0x30e034a3>, fileinfo = {
            filenm = 0x5693a5c9 <error: Cannot access memory at address 0x5693a5c9>, lineno = 889999999}, length = 12, recursive = 1, append = 1,
          conditional = 1, per_target = 1, special = 1, exportable = 1, expanding = 1, private_var = 0, exp_count = 3154, flavor = f_recursive,
          origin = o_override, export = v_noexport}
#4  0x00015a18 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ./main.c:1404
        stdin_nm = 0x0
        makefile_status = 0
        read_files = <optimized out>
        current_directory = "/root/make-4.1\000\377", '\000' <repeats 1756 times>...
        restarts = <optimized out>
        syncing = <optimized out>

In a real tty, make works.

Edit: So now that I could use make, I have changed the linux-armv7-rc package a bit to build only the nyan-big config: https://github.com/ChristophHaag/PKGBUI ... x-armv7-rc

Here are packages:
http://haagch.frickel.club/files/linux- ... pkg.tar.xz
http://haagch.frickel.club/files/linux- ... pkg.tar.xz
http://haagch.frickel.club/files/linux- ... pkg.tar.xz

It boots and starts X. Yay. You did not lie, X works very well. In xephyr the xfce4 compositor was very slow, but in a real xorg server, it speeds things up a lot. When trying to connect to my wifi, networkmanager just immediately failed without setting my password, but going into settings and setting the password manually made it work for some reason. I do not have the elan_i2c module. I'll try with CONFIG_MOUSE_ELAN_I2C=m.

Edit2: elan_i2c is built with this config option and the touchpad works, updated my uploaded packages.

Also: Weston starts! Input is dodgy (internal keyboard and touchpad don't work, external usb keyboard only works when it's plugged in while wayland is running, usb mouse sometimes need to be plugged in while wayland runs too), but it works! xwayland also works, but so far only with llvmpipe: http://i.imgur.com/3FbHbyn.png
haagch
 
Posts: 32
Joined: Thu Apr 02, 2015 5:36 pm

Re: Mainline Kernel on Tegra K1 (Acer Chromebook 13 CB5-311)

Postby WarheadsSE » Mon Jan 11, 2016 3:38 pm

Nice.
Core Developer
Remember: Arch Linux ARM is entirely community donation supported!
WarheadsSE
Developer
 
Posts: 6325
Joined: Mon Oct 18, 2010 2:12 pm

Re: Mainline Kernel on Tegra K1 (Acer Chromebook 13 CB5-311)

Postby haagch » Mon Jan 11, 2016 10:20 pm

tincman wrote:and adding support for the BQ2375 charger

Uhm... I didn't find any reference to that, so I booted chromeos and looked at dmesg... It's bq24735. But setting CONFIG_CHARGER_BQ24735 doesn't seem to have any effect.

tincman wrote:I'm also currently trying to patch xorg-server to use render/control nodes for accelerated graphics, similar to what was previously "hacked" in https://github.com/Gnurou/xserver/commi ... 3f14193ebb

Very cool, but... Have xf86-video-nouveau developers interest in doing this?

The config I took from the fedora blog post really isn't the best. I also added
CONFIG_BT_MRVL=m
CONFIG_BT_MRVL_SDIO=m
for working bluetooth.

I also enabled
CONFIG_SND_SOC_TEGRA30_AHUB=m
CONFIG_SND_SOC_TEGRA30_I2S=m
but it doesn't look like the snd_sic_tegra30_i2s module was built. I don't even have snd_hda_tegra. Hmmmm, maybe I should just switch to the mainline config again.
haagch
 
Posts: 32
Joined: Thu Apr 02, 2015 5:36 pm

Re: Mainline Kernel on Tegra K1 (Acer Chromebook 13 CB5-311)

Postby tincman » Tue Jan 12, 2016 2:03 am

raumzeit wrote:Good to see, that mainline kernel support seems to work. I still have not found the time yet to try it myself


Your work and posts were of great help. Thanks!

raumzeit wrote:Regarding the segmentation faults of upower, there is a fix available for that. The problem is, that udev reports back the battery with a string that contains an invalid '@' character. At least upower regards that as invalid. However, a simple patch solves this problem quite elegantly, see https://bugs.freedesktop.org/show_bug.cgi?id=93095 and my upower package here: https://github.com/RaumZeit/PKGBUILDs/b ... r/PKGBUILD . I already use this patched version of upower for the chromeOS kernel 3.10 to avoid upower constantly segfaulting...


Excellent! That helps a lot :D


haagch wrote:CONFIG_CHARGER_BQ24735 doesn't seem to have any effect.


That's the one, and similar to the elan_i2c, it needs to be manually inserted, and only seems to succeed if the power adapter is plugged in when it is. Hopefully, with the patch RaumZeit mentioned, I can get this module to play nice and not require a patched device-tree.

haagch wrote:
tincman wrote:I'm also currently trying to patch xorg-server to use render/control nodes for accelerated graphics, similar to what was previously "hacked" in https://github.com/Gnurou/xserver/commi ... 3f14193ebb

Very cool, but... Have xf86-video-nouveau developers interest in doing this?


I haven't found much on the Xorg/DDX side for the gk20a. I think the general trend has been to move away from architectural/driver specific DDX code and focus more on using glamor and kms (for example, xf86-video-nouveau dropped glamor support, instructing people to use xf86-video-modesetting for glamor, coupled with the fact they are not adding Maxwell support to xf86-video-nouveau and are suggesting people to use xf86-video-modesetting w/ glamor instead).

And everything for that is almost in place. Nouveau works with the gk20a and has libdrm/mesa/egl support, and the Tegra DRM in upstream handles the host1x display controller beautifully. The problem is just getting the buffers moving between them.
tincman
 
Posts: 23
Joined: Sat Feb 23, 2013 5:27 pm

Next

Return to nVidia

Who is online

Users browsing this forum: No registered users and 1 guest