From nobody Sun Jan 5 10:48:02 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YQvDX4wmQz5j0LN for ; Sun, 05 Jan 2025 10:48:28 +0000 (UTC) (envelope-from toby@tobykurien.com) Received: from spe14.ucebox.co.za (spe14.ucebox.co.za [197.242.154.255]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.ucebox.co.za", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YQvDT5PP3z4YvV for ; Sun, 5 Jan 2025 10:48:25 +0000 (UTC) (envelope-from toby@tobykurien.com) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=tobykurien.com header.s=default header.b=SEZAMfig; spf=pass (mx1.freebsd.org: domain of toby@tobykurien.com designates 197.242.154.255 as permitted sender) smtp.mailfrom=toby@tobykurien.com; dmarc=none Received: from doxy.aserv.co.za ([154.0.166.100]) by spe3.ucebox.co.za with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1tUOB0-009sv9-LK for freebsd-arm@freebsd.org; Sun, 05 Jan 2025 12:48:14 +0200 Received: from cloud.tobykurien.com (unknown [41.79.79.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by doxy.aserv.co.za (Postfix) with ESMTPSA id E0D2A266129 for ; Sun, 5 Jan 2025 12:48:08 +0200 (SAST) DKIM-Signature: a=rsa-sha256; bh=ICkmc1MQmYmmVaydE0BziPdmDkRQUDH4OHAdNCCfcwc=; c=relaxed/relaxed; d=tobykurien.com; h=Subject:Subject:Sender:To:To:Cc:From:From:Date:Date:MIME-Version:MIME-Version:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Reply-To:In-Reply-To:In-Reply-To:Message-Id:Message-Id:References:References:Autocrypt:Openpgp; i=@tobykurien.com; s=default; t=1736074089; v=1; x=1736506089; b=SEZAMfig+fsq8T7fGr/dZyvtCTNUS0AsNVJ5qTMTpIxYikICGtP6Ll15pb/2cbirOuZDuZoQ odBi+GZHnhpKfotO6Mz+wYm80yfom6FqSG+3G9FddhA/RXvy+cnuBlktMWXZdbC4nNNMAzF82K3 pFwPOGWNado++uTS4mqSshnuOVCbHSqbfyNmA4j+2nzwBXXf4ScA4dNRa88aqaCSL5P8N1B/BGw XRK4PFvhVqp59KLu8vX6PH7JatOVS5vL3w7eB3ApsG9JtJ+7mTC0mgTtQG9vKi6z/PBZkC+CwnK n8XWlbjvhb4cOJHmhTVTCznEPW7wL+NGvjWT043784+1A== Received: by cloud.tobykurien.com (envelope-sender ) with ESMTPS id efd29e66; Sun, 05 Jan 2025 10:48:09 +0000 Date: Sun, 5 Jan 2025 12:48:02 +0200 From: Toby Kurien To: freebsd-arm@freebsd.org Subject: Re: EFI framebuffer blanks during boot Message-ID: References: <20241218115610.Horde.ZMws8aj0Si_tufYawGSkq16@cloud.nextcloudhosting.co.za> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Originating-IP: 154.0.166.100 X-Afrihost-Domain: doxy.aserv.co.za X-Afrihost-Username: 154.0.166.100 X-Afrihost-Outgoing-Class: ham X-Afrihost-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9mdHJkJEGDqVteTDib6odKPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wOvGg18h18lTsuUGH1KgAagLCWYuPCxwJEfxKP87A95+fH zJ6mVE7ewsipSVIfs4aPYs9Wj2g67stcO4BJ8hXvABHVTw1lV42ob3hDgXVUNbZJMuJHHFnTdGKa 3VxxhLA8U1774x9DQql3n5V1vHjnkuW1FFLwEW3UVQ/02r/eitdn5CXCG6zzUxxWbE5VnshrtABe TE0tY9RQlsEW5d+kXzxdcSEOF5ZgjdwpVsfMm9dCYgcgr835yVjKQZA6hJL1LiMHCxRezvZaFOrU Vh8zNqs59tg7m1SQLJtFApHh60KEcxAcIwRZNf0cSHBI/j8xKX6Z6/Qz1w7TE/bz3YPRDfgblxZ8 KT4UwlLW+nAm2eZE7YJwhBWCb1PmFojBOyjXs2KsRjKrCowEavDwQuKoDMwQiNpECc6NeluD4mMa /1YmDHeI9dU6Rq238kXYC+KNLtSRWKGmohoil/1AiKo+tkgXyuidojvEg3qjfiiAf/vg7iEFLP+S SY+Av5+AiC4+cZX8WknokmSP3xzvf1AnqkgFz88vkNuG2+19Snt2LnYwFCR7ot70rQU00NUAUIYt uctFVQp078svLEqHvTCZstIYjMKgSmf0fMSGkoiSbtO6UlGm0ycQh0Ylbt1+Ear3Y80OmAux3oN1 3+ztUzneeH9vrfuk7fRvn0o9yycTJzaslDewd9SvuBEMrxmqkujdsHSNrzIWTAsLxS0ncvwRNs5T Bl8VfoSfYIQ4LCBTzYP+xmzYtBWHAoRTGsqGxCCpv6/nAnrLfB175ek9DRRm9R/2gMGq0KWAzmMf +ibVDghxtC6SPrOXv6rESukjSA5vnpiNotwN38VVUYyvwlIhJdgQGsN+N1qJPtNMC+RP0KRvQDwO 6ur/Di47GnmH3wummAO4viSzvvpPzgJUfnLxUuXi8ijc+7N/ems+rzGkbzEvuGslKTrRIXcXpFg5 ivY= X-Report-Abuse-To: spam@spe1.ucebox.co.za X-Rspamd-Queue-Id: 4YQvDT5PP3z4YvV X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:197.242.144.0/20]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[tobykurien.com:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; DMARC_NA(0.00)[tobykurien.com]; R_DKIM_PERMFAIL(0.00)[tobykurien.com:s=default]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:37611, ipnet:197.242.144.0/20, country:ZA]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; HAS_XOIP(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[] I made some progress, this might help others who are facing a similar issue: - In /src/sys/dev/clk/rockchip/rk_cru.c:68 I commented out the "bus_write_4(...)" call, which stopped the screen from resetting during the clock initialization. This is a brute force hack. - The display now works for much longer but still got reset later on. I tracked this down to the regulators for the LCD power supply being shut off as being "unused", so I set it to "regulator-always-on" and "regulator-boot-on" in the DTB. This fixed the second reset. The screen now stays on and keeps displaying stuff! I could use advise on how to clean up the hack above: how can I detect that the clocks are already initialized in the hardware (by EFI) and avoid re-initializing it? -- tobykurien.com On Wed, Dec 18, 2024 at 05:51:04PM +0100, Klaus Cucinauomo wrote: > 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 : > > > > 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 > >> > >> > >> > >