From nobody Wed Dec 18 16:51:04 2024 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 4YD0Bz26tgz5hb32 for ; Wed, 18 Dec 2024 16:54:19 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YD0By6QWWz4bhl for ; Wed, 18 Dec 2024 16:54:18 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-aa69107179cso1233125966b.0 for ; Wed, 18 Dec 2024 08:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20230601; t=1734540856; x=1735145656; darn=freebsd.org; h=to:in-reply-to:references:message-id:date:subject:mime-version:from :content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=Ehjnf4ggGUr0iEkgjURxOwlNZ+jlHz5dDrwNAnGf+8M=; b=d8g5BkHvRpR5K3TJGg9kM1ECtHy2c7RMmH9mZTBV1HUigRhBtM0PVzZ06zsO6xvthA lWDnCcsFW8kwnO7p28f+u5pdB+6LbhRRDviC9ozXtuAQtBeqSIy8ULeQX4HpmfD+I+L4 /27yq4mokUPQbZ075dzy9OZ6gUGoSCwQaB7vzwGn7/WdGp85aPw9XmfRBZNEOSGxfQ1s gVUthvHoeMZ1LFb6GUPDcCAfzPh6HbXD7vV8EXqCEQKDagZBWLi3TCxleD4XPqgZC44y R0m7Ou23y3g2IOCvbMyVDOTGo/ZJPLIPJg2oqniM8vfSOe+zpf2n6qZAMWi4pq2C1ULW mrXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734540856; x=1735145656; h=to:in-reply-to:references:message-id:date:subject:mime-version:from :content-transfer-encoding:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=Ehjnf4ggGUr0iEkgjURxOwlNZ+jlHz5dDrwNAnGf+8M=; b=uGfT5ZTh0NsWt29g7stXH+xO1Mm0sO/paPn5g1uhn52Jp5hb25ZCIRgI4BC4IzsB5L kqxjzR5gfcTRfcuLvqrvPHFNsWtxi+LLwkpcEWQT1LBhT+U7aBa2VzHFPdvS1tHgnWoR NviSM/uSgiPWBpyVTyk1V3OD0q6wvqZgk1MlDBmVBhefiQ95dPSJcJSdH9vFrpwY6sWt PGYrU7LMkoyCRK2pjUhHmw7HGmicypKrdLJL5kRHHBcLadvb0CmeEmnHLVCMXodLDExd bM9N/xspVLRVDtYiYgDVHIjUFHsxtuWRtcx40Oru6eCGboC3yteWbYMoYCFD59X/tmDe akaA== X-Forwarded-Encrypted: i=1; AJvYcCUcgA7cDSFm914BFgG1eaZ19WljTiKMSTZ6CwiKWvlqh0ee5IrO2BJvjuZO8Uy69/mJ7lvlA7IUVv8AyQ==@freebsd.org X-Gm-Message-State: AOJu0Yz8R9A4RTJg4nanr28UxBg0atO8G1NXBq9M+FX3eP4uLzeasfVZ 2MHl1xBKDUla8s0NW/fiuP82fsZqYmtSlelTSUHZfNHSRSC4N9XPbDsjrg== X-Gm-Gg: ASbGncs7gSie5hS7NZUhYCxRg7hW9s3Psmhk9iJwt+G35qKjHBYsgrkkXQvUU4DSYB4 j80HuBfAEhCqePfIHL7nb6jxHI2jFdrouXKc+HYPDcYGmzE/crql6DFJXz2uaiH0SCWpy3ZqR8X iuI1xt7upHhc1lxACmNg/y/nVgIADnRuZmkEpD0Wq6yhEAJhu8LK5aIiKwyDcB/FnOnBc4wpznG mHK5kZSKxyZ7+PqaLrYssRs0H3XXxqpQj4l/Z9jkZykq5Zj6Zr4EaohVRvJSDuICH5bu/bhkKRJ h42YgfOwMDnNLmI1u8r0dz8TMb9MzhsqPenOE4CQZW6qjEeRmI3BbVy546W9yAHa X-Google-Smtp-Source: AGHT+IG645zx8jWiHF6XS+nV+uEQLdGgry/Zc8HKy6Do0E2bPOEP0y8PvbFMNaW4b4y9f/SQFceg5g== X-Received: by 2002:a17:907:9621:b0:aa6:7933:8b33 with SMTP id a640c23a62f3a-aac078fd89cmr8122066b.15.1734540856145; Wed, 18 Dec 2024 08:54:16 -0800 (PST) Received: from smtpclient.apple (dynamic-046-114-016-006.46.114.pool.telefonica.de. [46.114.16.6]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aabfbbb7a52sm69157466b.58.2024.12.18.08.54.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Dec 2024 08:54:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Klaus Cucinauomo 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 (1.0) Subject: Re: EFI framebuffer blanks during boot Date: Wed, 18 Dec 2024 17:51:04 +0100 Message-Id: References: <20241218115610.Horde.ZMws8aj0Si_tufYawGSkq16@cloud.nextcloudhosting.co.za> In-Reply-To: <20241218115610.Horde.ZMws8aj0Si_tufYawGSkq16@cloud.nextcloudhosting.co.za> To: Toby Kurien , freebsd-arm@freebsd.org X-Mailer: iPad Mail (22B91) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4YD0By6QWWz4bhl X-Spamd-Bar: ---- 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 : >=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