Date: Wed, 18 Dec 2024 17:51:04 +0100 From: Klaus Cucinauomo <maciphone2@googlemail.com> To: Toby Kurien <toby@tobykurien.com>, freebsd-arm@freebsd.org Subject: Re: EFI framebuffer blanks during boot Message-ID: <AA283475-86B1-4765-B6CF-44AA62BB4FB7@googlemail.com> In-Reply-To: <20241218115610.Horde.ZMws8aj0Si_tufYawGSkq16@cloud.nextcloudhosting.co.za> References: <20241218115610.Horde.ZMws8aj0Si_tufYawGSkq16@cloud.nextcloudhosting.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
This issue, exactly as you describe, is known to me from the RK3328(after en= abled an hdmi-driver in u-boot there) but not from the RK3399(efifb always w= orked there). > Am 18.12.2024 um 12:56 schrieb Toby Kurien <toby@tobykurien.com>: >=20 > =EF=BB=BFAn update on this, I did some more digging into why the display o= utput 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 t= he device tree, and it seems it's the rk3399_cru0 module that ends up resett= ing the panel. If that's disabled, the screen stays on and continues display= ing output, although of course the kernel panics. I'll dig into the rk3399_c= ru code, but if anyone has any pointers into what I could try, that would be= super helpful. Thanks. > =20 > -- =20 > tobykurien.com > =20 >=20 > "Toby Kurien" toby@tobykurien.com =E2=80=93 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: >> =20 >> 1. Loader does not display on the EFI FB, instead it appears in the seria= l console. I tried adding `console=3D"efi"` to loader.conf but to no avail. A= ny ideas why this might be even though (as below) some kernel output appears= on EFI FB? >> =20 >> 2. However, after loader, the kernel starts loading on the screen (even s= howing VT(efifb): resolution 720x1440), up until rk3399_cru0 is detected, th= en soon after it blanks. I took a video of the process to pinpoint where it b= lanks out, and it appears to be when rk_grf1 (general register files) is loa= ded and/or when the fixed regulators are being initialized. >> =20 >> I did some digging, and I suspect that either the power to the panel is b= eing interrupted, and/or the LCD reset pin is being set. I guess either of t= hese will reset the panel, thus then requiring it to be re-initialized. I co= nfirmed that rk_grf1 controls the GPIOs responsible for powering and resetti= ng the LCD. Any ideas on how to prevent the GPIOs from being changed during b= ootup (if EFI FB is available)? Or maybe I'm mistaken and something else is g= oing on? Any help would be appreciated, thanks! >> =20 >> --=20 >> =20 >> http://tobykurien.com >> =20 >> =20 >>=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AA283475-86B1-4765-B6CF-44AA62BB4FB7>