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

[vman]

So I tried building and using the core/linux-armv7 from the tincman repo given by you Manizuka, in your last post on this topic. First I had to learn some basic GIT, to be able to switch branch and revision. Having done that I got Kernel 4.7.1 - but I had to change the config a little before it would actually compile:
$this->bbcode_second_pass_code('', '
LD drivers/gpu/drm/built-in.o
LD drivers/gpu/built-in.o
LD drivers/built-in.o
make[1]: *** No rule to make target 'firmware/am335x-pm-firmware.elf', needed by 'firmware/am335x-pm-firmware.elf.gen.o'. Stop.
make: *** [Makefile:987: firmware] Error 2
')

It did compile when I had removed "am335x-pm-firmware.elf" (and the other blob names) from
$this->bbcode_second_pass_code('', '
Device Drivers ->
Generic Driver Options ->
External firmware blobs to build into the kernel binary
')

But when I try to boot with this kernel installed I just get a blank screen: first black, than after about a second a different shade of black (darker, if I remember correctly).

So I'm back to the 3.10 kernel with Nvidia blob compiled in. E-Mail and Chromium are working fine, but the fun alread ends when I'm trying to scroll in LibreOffice (and Firefox has similar issues).

Do I need this mysterious firmware blob?

Or does anyone else have a working simple kernel config for a recent Kernel?

[haagch]

I think only 4.4 and 4.5 are known to work well, so try to checkout a commit that has a PKGBUILD for 4.5. Personally I've not bothered to update from my 4.5-rc4 build from february so far.

That said, I would like to update. Has anyone tried 4.9 final? Still problematic? Are the upstream maintainers aware that there is/was a problem?

[haagch]

Looks like I have really good timing: https://github.com/Gnurou/xserver/issue ... -267937951

[Manizuca]

just tried 4.9 final. all seems to work, but i just used it a couple of minutes, have to test more.

[haagch]

So the patched X can soon be retired.

I've made a PKGBUILD for the patched mesa here: https://gist.github.com/ChristophHaag/7 ... f6c3294a04
Just replace extra/mesa/PKGBUILD with this one and build. If it complains about libdrm_intel missing, just run makepkg again. I don't know why this happens (edit: I just realized that this happens because autogen.sh runs configure with default options). Possibly libdrm-git with --enable-tegra-experimental-api is required.

Caveats:
1. The tegra kernel module needs to be loaded before nouveau. This can be achieved by making a file /etc/modprobe.d/nouveau.conf with content "blacklist nouveau" and then modprobe nouveau manually after boot (I tried to put it into a config file in /etc/modules-load.d/, but it doesn't load for some reason). This is only until https://github.com/Gnurou/mesa/commit/a ... bfb18cc3cc is replaced with autodiscovery of the nvidia gpu.
2. kmscube works as user, but in X you need root for being allowed to send the tegra ioctls, for some reason. I tried adding my user to the video group, because /dev/dri/card1 has write permissions for root:video, but it doesn't help. I suppose dealing with https://github.com/torvalds/linux/blob/ ... ctl.c#L488 is somehow required.

[haagch]

So I installed linux-armv7-rc + linux-armv7-rc-chromebook and wrote /boot/vmlinux.kpart to the boot partition. So far it looks good. The audio device is named differently, so the config of my desktop mixer needed to be adjusted.

Graphics performance is super bad now compared to with 4.5, so something like
sudo bash -c "echo 04 > /sys/kernel/debug/dri/128/pstate"
is really required.

Otherwise it looks good so far. Has anyone found anything that doesn't work with linux-armv7-rc from the repository yet?

[vman]

$this->bbcode_second_pass_quote('', 'S')o I installed linux-armv7-rc + linux-armv7-rc-chromebook and wrote /boot/vmlinux.kpart to the boot partition. So far it looks good.

[haagch]

Yes that is basically what I did. Only my boot partition is /dev/mcblk0p6, because I set it up with dual booting from the internal flash.

Only two things:

I don't boot directly to starting X, just to a tty. Sometimes starting X too quickly doesn't work...

I just tried kde plasma and it locks up after a couple of clicks, even with the compositor disabled. Looks like nouveau is still not fixed in 4.10-rc2. xfce with xfwm4 with compositing is very stable though.

[vman]

Thanks for the quick reply!

Unfortunately I don't have a deeper understanding of the Linux boot process, especially on this Chromebook. One thing I'm particularly unclear about is the kernel command line. 'dmesg' gives me a 'cros_secure console=tty1 init=sbin/init root=PARTUUID=[UID]/PARTNROFF=1 rootwait rw noinitrd lsm.module_locking=0' when I'm booting the Arch system I set up with the linux-nyan kernel. The [UID] is the UID of the Linux kernel partition itself (/dev/mmcblk0p6). Now I have that system on the internal flash, and a modified version on the external flash, where I tried to install a mainline kernel.

Maybe I should start over again on the internal flash, avoiding the linux-nyan kernel and depending packages?

I just thought it would be better to have Chrome OS on the internal flash, and Linux on the external system, so that I could choose which one to boot on the OS verification screen: either CTRL+D for Chrome, oder CTRL+U for Linux (USB). Does anyone know of a different way for having a per-boot choice?

I also though it would be saver to not have my Linux data on the internal flash, which might get erased by accident if someone presses the wrong key in the OS verification screen.

[raumzeit]

@vman:
This sounds odd, my Chromebook runs smoothly with the Kernel/GPU packages that I set up. Over Christmas I also got some feedback of other users who just set up their Chromebook using my installer script without any problems.

The default installation uses p6 for the kernel and p7 for the rootfs. Therefore, your kernel commandline should have the UUID of /dev/mmcblk0p7 instead of p6!