Acer Chromebook CB5-311 mainline

$this->bbcode_second_pass_quote('vman', '
')$this->bbcode_list('a')

how exactly did you install libreboot? I see there is "nyan big" config in the source from git. And what is the effect of it? Do you get a boot menu? Can you boot distribution kernels?

[fedup]

Hello tegra-nyan-big users

@Manizuca
Nce to see there is a solution to the Mesa/Noveau blank screen. Just quite an effort to get it sorted.I run with nouveau.modeset=0 as I also find the nouveau experience worse than just using fbdev. I get mouse flicker, a sawtooth tearing when moving between workspaces and laggy performace. mpv seems to still work when using mpv -ao gpu so I'm not sure how it uses the gpu.I notice that some players like vlc try to use libvdpau_tegra.so which is usually provided by the grate driver for older tegra's. I've enabled tegra_vde in the kernel but it's not defined in either tegra124-nyan.dtsi or tegra124.dtsi so you can load the module but no devices appear. There is a patch the enables the encoder in the tegra124.dts for k1 jetsons etc so it should work on the nyans as well. I tried changing just the tegra124.dts on its own but the kernel didn't load. I'm not sure it will be possible to use libvdpau_tegra from fbdev or modeset/noveau xserver. There is the opentegra-xserver on the grate git which apparently works the the tegra124 boards. It seems there is limited Mesa support though. Would be interesting to see if the video encoder works well though as I'm not really interested in 3d graphics on this chromebook.

When playing h.264 video with the modesetting/noveau setup I see about 70% CPU which seems high. ffplay with same file is affected by the mesa blank screen and is using equally high CPU. It was working with earlier version of Mesa (18.2 I think). On a raspberry pi with omxplayer the cpu is about 13% so I use the instead.

I'll try mpv with nouveau.modeset=0 and see how the CPU on it's own copes with the h.264 encoding and report back.

[fedup]

Just report back on mpv and ffplay with nouveau.modeset=0.

mpv -vo[sdl] CPU at 90% and unable to play back 1080p full screen. judder etc.
Similar results with ffplay, this time I can also see the output,(this was blank with nouveau and Mesa).
So accelerated video is needed for h.264 playback.

Mpv seems to not to use mesa when using nouveau and the gpu. I'm using the i3 window manager. I think the Mesa 1.83+ commit renders some desktops unusable.

EDIT....
It seems that nouveau with modsetting, the gpu is used for rendering and then uses Glamour/Mesa for displaying. So mpv must be using the cpu only even though mpv says its using vo=gpu??

ffplay is using working but throws up "nouveau 57000000.gpu: gr: DATA_ERROR 0000009c" and blank, the issue caused by the commit in Mesa 18.3. So yes this patch need to be reverted or xorg updated to the latest version with git. Urgh. Mesa would be easier to do I guess.

EDIT....
After reverting the mesa commit Mesa 1.9.2 is working again. Still some problems though. Gnome-shell crashes so I'm unable to get wayland working. However playback with fplay works well and although screen tearing is occuring I tried compton for rendering but still getting the tearing. When laying hd content with bbc iplayer CPU is around 50-60 % there is judder caused by the 60 hz refresh rate which is not possible to reclock to 50 hz. Still getting mouse flicker. Still possibly the best I've seen on linux with the nyan.

I have mesa-vdpau-drivers but get this.

mpv --hwdec=vdpau --vo=vdpau
Failed to open VDPAU backend libvdpau_tegra.so:

vdpauinfo
display: :0 screen: 0
Failed to open VDPAU backend libvdpau_tegra.so: cannot open shared object file: No such file or directory
Error creating VDPAU device: 1

If I set VDPAU_DRIVER to nouveau. Is this an issue with firmware or is something else missing.
VDPAU_DRIVER=nouveau vdpauinfo
display: :0 screen: 0
tegra: driver missing
tegra: driver missing
Error creating VDPAU device: 23

[vman]

Hello fellow tegra-nyan-big users,

with the extensive reports from @Manizuca and @fedup I thought I'd try my luck again, on the road to video playback with a mainline kernel.

• I updated to Linux 5.5, using manizuca's config and
• I updated xorg-server to a git version using a the AUR package xorg-server-git

...still "no adaptors present" with xvinfo. So I guess the stock coreboot may be doing something that prevents video acceleration? You both replaced it, one with libreboot, and one with u-boot.

@fedup, you wrote about write-protection not having been enabled in your device, a year ago... and then you did a "flashrom [u-boot-img-for-nyan-big]" from chromeos, basically?

This seems simple enough, yet dangerous... looking at e.g. this manual for CB C201.

[fedup]

@vman
|I don't think coreboot/depthcharge is the issue with lack of glamour/mesa stack. I was able to use nouveau.modest=1 and have the modsetting/mesa/dri stack when using coreboot before I flashed the spi. If you are going to flash your spi I would recommend using tegratools described on page 13 of the thread. I nearly bricked my device as I flashed a uboot image that was to big fit on the spi. I was able to flash the old coreboot spi image which I'd backed up but I needed to use my raspberry pi with an spi clip. My mistake was using a uboot image I'd created from uboot git instead of using the uboot git pulled in by the tegra tools. There is a bug which created a 16MB uboot.bin file and the spi is 8MB! If you use the tegra tools you can test the uboot image first by loaing into memory.

Actually as far as I can establish we currently don't have anyway to use the gpu for video decoding. Although there was an anouncement that Mesa supported tegra through vdpau_terga it didn't work and was removed in from the config file in Jan 2019.
mpv calls vdpau_tegra.so but it's not there anymore. It falls back to the software rendering using the cpu. I can get 1080p 25fps at about 65-70% CPU load with no frame drops but it can't handle 1080p 50fps. There is tegra_vde in staging but we would need to alter the tegra124.dts and probably the tegra124-nyan.dts file to enable it. The only software that can access is the vpdau_tegra library from the grate project. I don't think this will work with the modsetting/nouveau stack and it looks as though we have 2 incompatible tegra stack with the grate driver for pre tegra124 and modesetting/vouveau for the us and newer tegra boards. The maintainer of tegra_vde has added support for tegra124 so maybe it can be accessed via Mesa by forking the code from the grade dirver's vpdau_tegra.

EDIT...
the video decoder node on tegra124 boards, Including nyan-big is seperate from the GPU and rendering. I modified the tegra124.dtsi to enable this encoder and the tegra_vde module loaded and created /dev/tegra_vde. So it seems to work. Unforunatly
the only code which can utilise this device is libvdpau-tegra from the grate drivers which I managed to compile and install. I had to install a fork of libdrm, also from the grate driver to /usr/local. Whilst keeping the main version of libdrm. I then tried VDPAU_DRIVER=tegra VDPAU_DRIVER_PATH=/usr/loca/lib/libvdpau_tegra.so mpv --hwdec=vdpau --vo=vdpau but it throws up errors. libvdpau-tegra uses opentegra xorg driver also from the grate drivers. So looks like it can't be used with the modsetting driver in its current state. Perhaps a rewrite or fork could be made to work with modesetting org or perhaps V4L2 can directly interface the tegra_vde (tegra decoder). Work was planned for V4L2.
https://lwn.net/Articles/741215/

[Manizuca]

$this->bbcode_second_pass_quote('vman', 'H')ello fellow tegra-nyan-big users,

with the extensive reports from @Manizuca and @fedup I thought I'd try my luck again, on the road to video playback with a mainline kernel.

• I updated to Linux 5.5, using manizuca's config and
• I updated xorg-server to a git version using a the AUR package xorg-server-git

...still "no adaptors present" with xvinfo. So I guess the stock coreboot may be doing something that prevents video acceleration? You both replaced it, one with libreboot, and one with u-boot.

@fedup, you wrote about write-protection not having been enabled in your device, a year ago... and then you did a "flashrom [u-boot-img-for-nyan-big]" from chromeos, basically?

This seems simple enough, yet dangerous... looking at e.g. this manual for CB C201.

[vman]

Hi Manizuca,

here is the data you asked about:

• dmesg with nouveau.modeset=0
• dmesg with nouveau.modeset=1

/dev/dri/by-path/ (with nouveau.modeset=0):
$this->bbcode_second_pass_code('', 'lrwxrwxrwx 1 root root 8 Feb 9 21:00 platform-50000000.host1x-card -> ../card0
lrwxrwxrwx 1 root root 13 Feb 9 21:00 platform-50000000.host1x-render -> ../renderD128')

/dev/dri/by-path/ (with nouveau.modeset=1):
$this->bbcode_second_pass_code('', 'lrwxrwxrwx 1 root root 8 Feb 9 21:51 platform-50000000.host1x-card -> ../card0
lrwxrwxrwx 1 root root 13 Feb 9 21:51 platform-50000000.host1x-render -> ../renderD128
lrwxrwxrwx 1 root root 8 Feb 9 21:51 platform-57000000.gpu-card -> ../card1
lrwxrwxrwx 1 root root 13 Feb 9 21:51 platform-57000000.gpu-render -> ../renderD129')

/sys/devices/soc0/57000000.gpu/uevent
$this->bbcode_second_pass_code('', 'OF_NAME=gpu
OF_FULLNAME=/gpu@0,57000000
OF_COMPATIBLE_0=nvidia,gk20a
OF_COMPATIBLE_N=1
MODALIAS=of:NgpuT(null)Cnvidia,gk20a')

/sys/devices/soc0/50000000.host1x/uevent
$this->bbcode_second_pass_code('', 'DRIVER=tegra-host1x
OF_NAME=host1x
OF_FULLNAME=/host1x@50000000
OF_COMPATIBLE_0=nvidia,tegra124-host1x
OF_COMPATIBLE_1=simple-bus
OF_COMPATIBLE_N=2
MODALIAS=of:Nhost1xT(null)Cnvidia,tegra124-host1xCsimple-bus')

With the latter two files there is just one difference when using nouveau.modeset=1:
/sys/devices/soc0/57000000.gpu/ueven has an extra first line:
$this->bbcode_second_pass_code('', 'DRIVER=nouveau')

It would be great if you could show me what I'm doing wrong! I'm using sddm as my login manager, and running kde plasma, in case that makes any difference.

$this->bbcode_second_pass_quote('vman', 'H')i Manizuca,

here is the data you asked about:

• dmesg with nouveau.modeset=0
• dmesg with nouveau.modeset=1

[Manizuca]

Well, after looking at kernelci.org, i think the iommu problem is a regression with v5.5 (im still in 5.4, and will probably stay for a time as it's an TLS kernel)

They have nyan-big boot logs with v5.4 [0] and v5.5 [1]. v5.5 has the same IOMMU errors as you, but v5.4 doesn't, so can you try with kernel 5.4? If that still doesn't work then is not a kernel/firmware problem, so you should start looking at the xorg logs

[0] https://kernelci.org/boot/id/5e40b7b3a0ff9089c3e1961a/
[1] https://kernelci.org/boot/id/5e4089425db614d403e19635/

So I'm on Linux 5.4.18, and my dmesg looks pretty much like yours, @Manizuca. Indeed my Xorg.0.log (comple log) is indicating some problem:

$this->bbcode_second_pass_quote('', '
')[ 12.217] (II) LoadModule: "glamoregl"
[ 12.217] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
[ 12.254] (II) Module glamoregl: vendor="X.Org Foundation"
[ 12.254] compiled for 1.20.7, module version = 1.0.1
[ 12.254] ABI class: X.Org ANSI C Emulation, version 0.4
[ 13.650] (EE) modeset(0): eglGetDisplay() failed
[ 13.679] (EE) modeset(0): glamor initialization failed