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

[haagch]

So I updated with your patches and had mainline nouveau with the patched X server. It does hang the system very quickly. Sometimes already when starting lightdm, most often right after typing the password, sometimes logging in is possible, but it will hang very quickly. With gnurou's nouveau it worked stable in gnome3 and xfce. mesa and drm from gnurou seems to be a bit old... Maybe I look later.

I can't get wifi to work at all anymore in arch. In chrome os it works fine, but rebooting to arch it looks just like the hardware isn't there at all. Also bluetooth doesn't work, I guess, it's the same. Time to try a build of only the module and adding some printk statements again to see where it fails *sigh*

Also linux-armv7-rc 4.5 is in the repository, so I'm going to try that too

[tincman]

Thanks My intention is to submit these upstream after I make sure they are good, clean, well-tested, granular, etc...

I was excited to see 4.5-rc1 as well! It has the sdhci tuning which I was eagerly awaiting (20 mb/s is starting to get on my nerves...)

I haven't had a chance to make further progress on the GPU side of things, and I have no idea why mainline nouveau would crash so badly/so often... I also am still unsure why your wifi is not working... you have 'linux-firmware' package installed as well, correct?

Side-note: I messed up patches in my package, aside from the one you pointed out on my repo. I've fixed them now, so should be good.

[haagch]

Compiled and installed 4.5-rc1, now wifi and bluetooth works again.

But the log is spammed. This patch does fix it: https://patchwork.ozlabs.org/patch/571083/

edit: dmesg still has several issues: https://gist.github.com/ChristophHaag/2 ... 71bca065ed

[kristoferus75]

Hi !

I have also this Acer Laptop and I have currently Arch Linux with the kernel 3.10.18 in use !

Now i want to test the new kernel 4.4 from the git tincman but I can't compile because of this errors:

linux-armv7/

makepkg -si

make[1]: *** No rule to make target `firmware/am335x-pm-firmware.bin', needed by `firmware/am335x-pm-firmware.bin.gen.o'. Stop

I copied the missing files to the right location but after the next compile attempt i got this error:

cat: arch/arm/boot/dts/armada-370-smileplug.dtb: No such file or directory
==> ERROR: A failure occurred in package_linux-armv7-smileplug().
Aborting...:


kind regards

kristoferus

[tincman]

@haagch, excellent! I also patch/compiled 4.5-rc1 and have the increased mmc speed (50 mb/s on sdcard, 100 mb/s on emmc).

That is an awesome find on the log spam patch! That was really getting on my nerves.

@kristoferus75, that is good to hear, more to test the merrier :]

For starters, I never figured those problems out and never bothered investigating much. That firmware is for the beaglebone black, and that dtb is for a different board, so I just removed both...

Which, makes me think you're pulling from my master branch (which I have just tracking upstream), my patches are in the 'nyan-kernel' branch (https://github.com/sctincman/PKGBUILDs/tree/nyan-kernel).

If you 'git clone'd, be sure to checkout the nyan-kernel branch.

[WarheadsSE]

We are watching this thread, BTW. Keep up the strong progress.

[kristoferus75]

Hi tincman !

ok it was my mistake : now i have used the right branch !

Compile worked perfect but now i get this error:

Error: Could not prepare the operation (Can not satisfy dependencies) :: gpu-nvidia-tegra-k1-nvrm: need linux-tegra-k1

Please help

kind regards

kristoferus

[tincman]

@kristoferus75 the 'gpu-nvidia-tegra-k1' will only work with the downstream kernel. You'll have to remove that package before continuing. Keep in mind, GPU acceleration of Xorg/Weston is one of the things not currently working upstream.

@haagch, I've noticed in Xorg that having two driver entries will mark the second one as a "GPUdevice", I've been experimenting with xf86-video-nouveau to have it try and provide the GPU offloading. I needed to apply a small patch (tell it to use GART instead of VRAM), and currently it's failing to create buffer objects. As far as I can tell, the buffer creation is causing a similar "EMEM decode error" as I got when trying to use dm-crypt. Did you get these messages when trying to use Gnurou's packages? This might explain the crashing you experience.

I've ported the emc-timing codes from the downstream kernel to the newer format upstream for ram-codes 0, and 4 in an attempt to fix this. ...I've only tested 4, but I had ported code 0 due to a misunderstanding (and discovering the need to add "long-ram-code" in tegra124 now...).

While my system has been stable with these timings, this is unfamiliar territory for me, and I do not know how to fully test these and the consequences of bad timings (despite triple checking all those registers...), so I've split these patches off in a separate branch "nyan-kernel-timings"

Sadly, while it would seem to have reduced the number of "EMEM decode error"s thrown while trying to mount dm-crypt partitions, it hasn't fully eliminated them, and I'm still unable to use dm-crypt, and this has had no effect on using xf86-video-nouveau...

[haagch]

I tried gnurou's xorg server (same build that worked before) on stock nouveau from 4.5-rc2 and when starting X it remains completely black and writes the same emem address decode error to the kernel log. Not sure since when it "broke" (I think it didn't work with rc1 either) and I haven't really tested more...

I don't really know anything about gpu hardware drivers, so I'll just repeat my recommendation of #nouveau on freenode. They also recommended #tegra.

[haagch]

$this->bbcode_second_pass_quote('', 'I')'ve been experimenting with xf86-video-nouveau