Re: EFI framebuffer blanks during boot
- In reply to: Toby Kurien : "Re: EFI framebuffer blanks during boot"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 18 Dec 2024 16:51:04 UTC
This issue, exactly as you describe, is known to me from the RK3328(after enabled an hdmi-driver in u-boot there) but not from the RK3399(efifb always worked there). > Am 18.12.2024 um 12:56 schrieb Toby Kurien <toby@tobykurien.com>: > > An update on this, I did some more digging into why the display output blanks during boot. Firstly, I can confirm that the backlight stays on throughout, so that it not the issue. I tried disabling "grf" and "cru" in the device tree, and it seems it's the rk3399_cru0 module that ends up resetting the panel. If that's disabled, the screen stays on and continues displaying output, although of course the kernel panics. I'll dig into the rk3399_cru code, but if anyone has any pointers into what I could try, that would be super helpful. Thanks. > > -- > tobykurien.com > > > "Toby Kurien" toby@tobykurien.com – December 16, 2024 3:15 PM >> On the Pinephone Pro I installed u-boot with EFI framebuffer support. Two strange things happen during the FreeBSD bootup: >> >> 1. Loader does not display on the EFI FB, instead it appears in the serial console. I tried adding `console="efi"` to loader.conf but to no avail. Any ideas why this might be even though (as below) some kernel output appears on EFI FB? >> >> 2. However, after loader, the kernel starts loading on the screen (even showing VT(efifb): resolution 720x1440), up until rk3399_cru0 is detected, then soon after it blanks. I took a video of the process to pinpoint where it blanks out, and it appears to be when rk_grf1 (general register files) is loaded and/or when the fixed regulators are being initialized. >> >> I did some digging, and I suspect that either the power to the panel is being interrupted, and/or the LCD reset pin is being set. I guess either of these will reset the panel, thus then requiring it to be re-initialized. I confirmed that rk_grf1 controls the GPIOs responsible for powering and resetting the LCD. Any ideas on how to prevent the GPIOs from being changed during bootup (if EFI FB is available)? Or maybe I'm mistaken and something else is going on? Any help would be appreciated, thanks! >> >> -- >> >> http://tobykurien.com >> >> >> >