U-Boot, video console, and visual artifacts

[z4v4l]

I saw this funny thing, when playing with my own UEFI OS Loader on a RK3399 board. But it was on the HDMI interface.
I break uboot flow manually and command it to load and jump into my UEFI OSL (fatload, bootefi). My OSL shows things as expected, no artifacts, then I press a key and my unfinished yet OSL returns to uboot, then I type bootdefault, forgot the exact command name and uboot types reporting about loading linux, and right after jump into linux, this stripy image appears on the screen. definitely looks like linux overwriting the GOP framebuffer.

[dsimic]

right after jump into linux, this stripy image appears on the screen. definitely looks like linux overwriting the GOP framebuffer.

I agree that it looks like the framebuffer is overwritten and filled with garbage, but I think that's just one part of the mix that causes this issue.

In one of the attempts to fix this issue, I've modified the U-Boot drivers for the RK3399 eDP output and the RK3399 VOP to get removed and turn the hardware off before booting into the Linux kernel, which made the "second plaid" (the one when the kernel starts) pattern to disappear, but also caused my PineBook Pro to lock up while attempting to boot the kernel.  I still need to debug that.

[pkubaj]

Hello,

we previously talked on IRC about how I don't get a display. I use Gentoo with Manjaro kernel 5.11.16 and that works, but using even vanilla 5.11.16 fails to display anything. I found that using I have to use two Manjaro patches to get display working and they are still present in Manjaro's repo:
https://gitlab.manjaro.org/manjaro-arm/p...hack.patch
https://gitlab.manjaro.org/manjaro-arm/p...tcpm.patch

I'm not sure how the screen behaves on 5.13, my experience is with 5.11.16. I'm now planning to upgrade to 5.13.

I use uboot 2021.07.

[pkubaj]

Display works on 5.13.2 with those patches.

[zackw]

I also see the green plaid pattern, but for me it replaces the text instead of being overlaid on it.

I investigated the scary-looking message about a bad SPI CRC checksum; it turns out to be unrelated and harmless. It just means that there isn't any U-Boot configuration stored in the SPI flash. Unfortunately I don't think it can be gotten rid of except by moving the entire bootloader into the SPI, or by code changes to U-Boot. See https://lists.denx.de/pipermail/u-boot/2...53338.html (no response, alas)

[dsimic]

My apologies for the delayed response.

we previously talked on IRC about how I don't get a display. I use Gentoo with Manjaro kernel 5.11.16 and that works, but using even vanilla 5.11.16 fails to display anything. I found that using I have to use two Manjaro patches to get display working and they are still present in Manjaro's repo:
https://gitlab.manjaro.org/manjaro-arm/p...hack.patch
https://gitlab.manjaro.org/manjaro-arm/p...tcpm.patch

I'm not sure how the screen behaves on 5.13, my experience is with 5.11.16. I'm now planning to upgrade to 5.13. I use uboot 2021.07.

Thank you very much for providing this feedback!  I've had a rather detailed look at those two patches, but I'm still not exactly sure why are they required to make the video output work.  I'll have another look at that.

I investigated the scary-looking message about a bad SPI CRC checksum; it turns out to be unrelated and harmless.  It just means that there isn't any U-Boot configuration stored in the SPI flash.  Unfortunately I don't think it can be gotten rid of except by moving the entire bootloader into the SPI, or by code changes to U-Boot. See https://lists.denx.de/pipermail/u-boot/2...53338.html (no response, alas)

Right, that's a rather benign error message, as I've already explained in one of my earlier posts.

[alchemist]

Hi!

What is the status of those patches ?

[jpalus]

Hi!

What is the status of those patches ?

These patches are not required for working display panel on Pinebook Pro since kernel 5.15.5. They are required to get external display over USB-C working though. The issue before 5.15.5 was that external display was mandatory for proper display initialization but since it's not implemented it caused entire display subsystem to fail. So basically panel display did not function because external display did not function. With below upstream fix, external display was disabled in dts giving panel display a chance to initialize successfully:

https://git.kernel.org/pub/scm/linux/ker...7c9fbfa3b1

[alchemist]

OK thank you!

[Tazdevl]

Bump

Have the same with Kali (5.16.18 kernel). Not sure if it was caused by armbian & an update function in armbian-config or if it was included in Kali. It's an artifacts galore during bootup. I'm not even it does reboots...