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

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

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

Postby haagch » Tue Jan 12, 2016 11:33 am

Ah I didn't know nouveau is already phasing out their ddx. Intel still is very active with theirs. I wanted to use modesetting on my laptop too, but it doesn't support dri2 prime offload sink capabilites yet...

Anyway, can you share your mainline config? I have tried to enable more stuff (for sound etc) a few times, but it keeps failing to boot at a black screen. Only my minimal config here seems to work...
haagch
 
Posts: 60
Joined: Thu Apr 02, 2015 5:36 pm

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

Postby tincman » Thu Jan 14, 2016 6:12 am

Right after I posted that, I saw a thread about adding in Maxwell DDX (perhaps there are some optimizations they want to implement?).

Anyways! Sorry for the delay, I was trying out the new linux-armv7 (not -rc) PKGBUILD they pushed with an updated kernel.its. The goodnews is it works for me!

...mine gets recognized as an HP Chromebook (tegra124-nyan-blaze), but the differences are so minute it boots and runs well enough.

I still made a few changes to the config (enable LPAE, enable charger, and disable "optimize for size"). You can find it here https://github.com/sctincman/PKGBUILDs/ ... mv7/config

Edit:
Sound still eludes me, but I think this is more userspace than anything kernel related (I had it working at one point...).
tincman
 
Posts: 25
Joined: Sat Feb 23, 2013 5:27 pm

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

Postby haagch » Thu Jan 14, 2016 1:57 pm

Thanks, much better.

I tried http://cgit.freedesktop.org/xorg/driver ... opentegra/. It works, but it feels exactly like the modesetting driver. No commits for 18 months, so I guess this driver is dead? Edit: Indeed, it was intended for pre-K1 tegra: https://www.phoronix.com/scan.php?page= ... px=MTU5Mzc

Edit: Suspending and then closing the lid causes the laptop to wake up. Any way to disable these wakeup events? On x86 chromebooks there's supposedly /proc/acpi/wakeup for that, but not on arm.
haagch
 
Posts: 60
Joined: Thu Apr 02, 2015 5:36 pm

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

Postby tincman » Tue Jan 19, 2016 6:27 pm

I was not able to reproduce the suspend problem you mentioned, but I have seen other people editing the udev entries for the lid events. Did you make these edits? They may be the cause of the spurious wakeups, or if you did not, this may be a good place to start.

There are some other things I've noticed as well on the mainline kernel:

The tegra-sdhci driver as of 4.4 does not implement tuning, and thus runs them at the lower speeds. However, UHS-1 tuning support was added in linux-next, so hopefully we'll see this soon (but, as I've started dogfooding with my chromebook, I may backport this patch to 4.4). Between my mainline Arch, and a chroot on the ChromeOS kernel (where nvidia implemented the sdhci tuning), this results in a difference of 20 vs 54 mb/s on the sdcard (UHS-1 class), and 40 vs 120 mb/s on the eMMC. (hdparm -Tt measurements).

Any sort of mapped filesystem does not work and the memory controller (tegra-mc) throws a series of EMEM address decode error, for example:
$this->bbcode_second_pass_code('', 'tegra-mc 70019000.memory-controller: ppcsahbslvw: write @0x00000000xxxxxxxx: EMEM address decode error (EMEM decode error)')
I discovered this trying to use dm-crypt on a usb-drive, and thought it was an AES/security-engine error (as the SE is a client on this bus), but I've been able to reproduce it when trying just LVM, and haven't been able to reproduce it with any other AES routines. However, I am able to use USB devices and mount normal drives properly. Doing these in a chroot on the ChromeOS kernel succeeds with no errors...

I haven't made sense of these errors yet, but hopefully it's a matter of adjusting the emc entries in the device tree?
tincman
 
Posts: 25
Joined: Sat Feb 23, 2013 5:27 pm

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

Postby haagch » Wed Jan 20, 2016 7:33 pm

Okay, with the help of the people on #nouveau I figured out that https://gist.github.com/ChristophHaag/a ... c2f6d2a870 is needed to enable the GPU.

So here are new kernel packages (I also temporarily copied the nyan-big.dts over nyan-blaze.dts as an easy way to load the correct config):

http://haagch.frickel.club/files/linux- ... pkg.tar.gz
http://haagch.frickel.club/files/linux- ... pkg.tar.gz
http://haagch.frickel.club/files/linux- ... pkg.tar.gz

When I first started X, the laptop locked completely up, so I compiled https://github.com/Gnurou/nouveau which was a bit finnicky, because my linux-armv7-headers package didn't have *all* the headers, so I needed to copy two directories to /usr/lib/modules...etc. Here is the updated experimental nouveau from today, fitting for my kernel packages:

http://haagch.frickel.club/files/nouveau.ko.gz

I also built https://github.com/Gnurou/xserver

$this->bbcode_second_pass_code('', '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')

3d acceleration works, but prints some scary messages into dmesg and is kinda crashy. For example with kwin5 switching to xrender will lock up every time.

Image

Now I have trouble with wifi. After booting often it isn't loaded and doesn't work at all after loading the module. Rebooting into chromeos seems to be the only thing to "fix" it. Anyone else?

Edit: Played with the sound settings (there are so many!)
The ones that actually enable sound are "Right Speaker Mixer Right DAC", "Right Speaker Mixer Left DAC" and "Left Speaker Mixer Right DAC" and "Left Speaker Mixer Left DAC" on the GoogleNyanBig alsa mixer.
haagch
 
Posts: 60
Joined: Thu Apr 02, 2015 5:36 pm

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

Postby tincman » Wed Jan 20, 2016 10:31 pm

Hmmm, I had no problem with the mainline nouveau module and Xorg. What did your Xorg.0.log say when it locked up?

I did have a problem when I had tegra-drm and nouveau-drm compiled into the kernel (not modules) where my console framebuffer would not initialize (but Xorg would still start w/ the modesetting driver).

The majority of Gnurou's work that has not hit mainline yet seems to be focused on getting Tegra X1 (maxwell/gm20b) support, with some minor tweaks to gk20a clocks.

$this->bbcode_second_pass_quote('', 'I') also built https://github.com/Gnurou/xserver
...
3d acceleration works, but prints some scary messages into dmesg and is kinda crashy. For example with kwin5 switching to xrender will lock up every time.


Nice! I've been trying to compile his changes as a separate Xorg stack installed in /opt (to avoid clobbering a working system), but I have been banging my head against the wall just getting it to play nice with logind.

It's a shame to hear about it's stability. What sorts of error messages are they?

On a different front, I'm finally looking into xf86-video-nouveau code, and I'm seeing a few commits concerned about gk20a support (nothing major, mostly adding the chipset as a test case for certain branches)! xf86-video-nouveau already has DRI3/PRIME support, so hopefully it won't take too much more effort to have xf86-video-nouveau enable the gk20a gpu as a renderer provider (and then use xf86-video-modesetting with tegra-drm as a sink). If #nouveau is approachable from your experience, I think I may need to jump in there as well and get some more first hand info :]

My wifi hasn't given me trouble, but this sounds familiar, and I think I ran across this issue somewhere else (but cannot recall where, sorry :[). What are the specific dmesg errors?

With the patched upowerd from Raumzeit, I can finally modprobe bq23735-charger without upowerd segfaulting, and xfce4-power-manager properly reports the charger as a power-source (sadly, this change is not yet merged upstream....). ...however, I'm still having the problems with it I had before. The module will not autoload, and the /sys/class/power_supply entry will only appear if it's plugged in when I modprobe. If it's not plugged in, a modprobe succeeds, but dmesg complains and the enetry in /sys does not appear (and will not appear when plugged in, requiring me to rmmod, then modprobe again). These issues mean I still have to remove the "<power-supply> = ..." line in the sbs-battery entry of the device-tree to make sure that module does not sit and wait for bq24735-charger to appear.

The specific error is the same that appears in dmesg when unplugging the charger after [successfully] modprobing bq24735-charger:
$this->bbcode_second_pass_code('', '
[17506.004404] cros-ec-i2c-tunnel 7000d400.spi:cros-ec@0:i2c-tunnel: Error parsing EC i2c message -121
[17506.004421] bq24735-charger 6-0009: Failed to read manufacturer id : -121
[17506.004438] bq24735-charger: probe of 6-0009 failed with error -121
')

I'm still digging around to see why this is failing... no luck so far (other than turning up it's the ChromeOS EC setting an error-status bit in the I2C response...)

$this->bbcode_second_pass_quote('', 'E')dit: Played with the sound settings (there are so many!)
The ones that actually enable sound are "Right Speaker Mixer Right DAC", "Right Speaker Mixer Left DAC" and "Left Speaker Mixer Right DAC" and "Left Speaker Mixer Left DAC" on the GoogleNyanBig alsa mixer.

That did it!! Thanks so much! ...although sometimes the sound is reverbing weirdly. Hopefully I just need to play around with the [tons] of other settings... but I'm glad to hear SOMETHING coming out of the speakers again :D.

Edit: Never mind, the sound stuttering seems to be localized to pidgin's notifications sounds. Nothing else is having a problem :D Music in the background will even play fine while pidgin's sound will occasionally stutter, so my guess is this is an application specific issue.
tincman
 
Posts: 25
Joined: Sat Feb 23, 2013 5:27 pm

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

Postby haagch » Thu Jan 21, 2016 1:06 am

I had the non working tty too, but with the mainline build everything works fine.

I suspect the lockup with the mainline nouveau was actually the same lockup I see with gnurou's nouveau... I didn't really test it. There are no messages when it locks up, just everything stops and I have to reboot (haven't tested if it's still available through ssh), but at least journalctl -k -b -1 doesn't show any messages at the end.

And stability is maybe not the right word. In xfce with the xfwm4 compositor and playing games like tesseract it is stable, it's just some special reproducable situation that lock it up.

Well, xorg doesn't clobber the system much. I just took xorg-server-git and replaced the source git repository. And for easy going back and forth there is then pacman -U *.pkg.tar* and pacman -S $(pacman -Qqs xorg | sed "s/-git//g"), so...

Here is a dmesg: https://gist.github.com/ChristophHaag/a ... 4b3e7ae718
There's
Jan 20 21:18:04 alarm kernel: WARNING: CPU: 3 PID: 321 at include/drm/drm_gem.h:146 tegra_gem_set_tiling+0xec/0xf0 [tegra_drm]()
I guess it comes from this call or something https://github.com/Gnurou/xserver/commi ... 1ac8adR175

There are also a few other issues...

As you can see from the same dmesg, the mwifiex_sdio module simply didn't get loaded, no errors from the module. Loading the module doesn't produce any output in dmesg, but nothing happens, specifically no network device is created. Nouveau behaved very similarly and the reason there was that it wasn't activated in the device tree.
But since it works when rebooting from chromeos, it sounds more like one of these issues where the OS puts the wifi hardware in some special state before rebooting. Maybe something with powersaving? I notice it most when I reset when the laptop is frozen from a nouveau lockup (power + refresh). Maybe not shutting down properly has something to do with it.

Hm... with dri3, can the desktop compositor be offloaded to another GPU? With dri2 PRIME that didn't work at all.

Youtube sound was a bit stuttery for me. I also have these annoying messages max98090 0-0010: PLL unlocked in dmesg. Maybe something with the kernel log level...

Your charger error is interesting. I noticed that the battery status didn't work when the module is modprobed while not connected to power. But when it is modprobed while it is connected to power, it continues to work when it's unplugged. When unplugging I only get the first "Error parsing EC i2c message -121" error, I don't see the other two.

For stuttering sound usually increasing pulseaudio's fragment number and fragment size helps, but for playing youtube in chromium it doesn't help, still crackling. Hm.

Edit: almost forgot: Does anyone know something about reclocking? https://github.com/NVIDIA/tegra-nouveau-rootfs says to use /sys/class/drm/card1/device/pstate but it doesn't exist (neither for card0). Is it automatically reclocking already? Where can I check the clocks?
haagch
 
Posts: 60
Joined: Thu Apr 02, 2015 5:36 pm

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

Postby tincman » Thu Jan 21, 2016 5:24 pm

Regarding the mwifiex. That is weird, there's no messages from the module, but the coredump reports it as being loaded...

Hmmm, indeed the tiling function is the one that crashes it. Did these errors happen when using mainline nouveau? One of the non-gm20b changes gnurou made to his module was to add the ability for nouveau to set it's tiling mode. It's possible nouveau is not outputting the buffer format tegra_drm expects and is thus crashing it... This may explain the edge cases: the buffer format works for simple things, but certain more complicated outputs break the buffer format assumptions. My suggestion would be to use his entire stack (nouveau module, libdrm, mesa, xserver).

I was unaware compositors didn't work with DRI2/PRIME, but from what I've been reading, DRI3 added all the GEM handle sharing that PRIME utilized, and did a better job of automatically detecting/offloading it. For DRI2/PRIME, I think you had to set DRI_PRIME=1 to enable GPU offloading, correct? Perhaps there was just not an easy way to do that for the root window/compositor?

$this->bbcode_second_pass_quote('', 'E')dit: almost forgot: Does anyone know something about reclocking? https://github.com/NVIDIA/tegra-nouveau-rootfs says to use /sys/class/drm/card1/device/pstate but it doesn't exist (neither for card0). Is it automatically reclocking already? Where can I check the clocks?

"Manual" reclocking is disabled by default. You can enable it by adding this to a modprobe.d file (eg, /etc/modprobe.d/nouveau.conf)
$this->bbcode_second_pass_code('', '
# enable manual powertstate management

options nouveau pstate=1
')

Regarding sound: now that it is working for me, I set about fixing headphone detection/switching. Turns out the problems on mainline were twofold:
1) The headphone detection pin was incorrectly set to "invert" aka it was disabling/muting the headphones when inserted, and unmuting when removed
2) [this is shared by the ChromeOS kernel] the headphone jack detection was labelled as "Headphones" where ALSA/Pulseaudio expected it to be labelled as "Headphone Jack"

while editing the pulseaudio paths files would have been the easier option, "Headphone Jack" seems the de-facto default for other drivers, so I changed the required files in the drivers, and it works! No extra acpid scripts needed :D

I took this chance to make real patches for this and the other changes I've been tweaking. My PKGBUILD that implements them is located here: https://github.com/sctincman/PKGBUILDs/ ... inux-armv7
tincman
 
Posts: 25
Joined: Sat Feb 23, 2013 5:27 pm
Top

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

Postby tincman » Tue Jan 26, 2016 5:38 am

I was able to fix the errors with bq24735-charger. This is entirely adapted from the version in Acer's linux tree.

The main problem was (as stated in the source comment), that without an AC adapter attached, but with an AC-detect pin, the bq24735 may not respond to i2c messages.

With these changes (and the patched upowerd) I was able to re-insert the "power-supplies" line in the nyan device-tree, and the bq24735 module loads without errors and reports the charger status properly

I have an updated PKGBUILD with the patches on my github page (https://github.com/sctincman/PKGBUILDs/tree/nyan-kernel).
tincman
 
Posts: 25
Joined: Sat Feb 23, 2013 5:27 pm

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

Postby haagch » Tue Jan 26, 2016 10:54 am

You're doing good work, searching for this stuff and testing it.

Are you going to send this to some mailing list to get the fixes upstreamed?
haagch
 
Posts: 60
Joined: Thu Apr 02, 2015 5:36 pm

PreviousNext

Return to nVidia

Who is online

Users browsing this forum: No registered users and 3 guests