From nobody Sat Oct 22 00:16:40 2022 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 4MvMMd3nkSz4g5TJ for ; Sat, 22 Oct 2022 00:16:45 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MvMMc10G5z3khG for ; Sat, 22 Oct 2022 00:16:44 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x335.google.com with SMTP id o20-20020a05600c4fd400b003b4a516c479so3120523wmq.1 for ; Fri, 21 Oct 2022 17:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=message-id:in-reply-to:to:references:date:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=LLKIhsmFvlE1pYmWEBQFfbgWSErlYPUF/mJkbC2N2Dg=; b=mX+RB7DcjZ5R+gkEFZCaDZROsJn+IhQlenGscDu1oU4Cxat+vZ24T8YYlpRrdjwS8J QVHv62/VJszBOSRqcGmsI3eZj+FRsw32XIHrJPEHyTKwz1nwg3OHSWDHjNb4i14nd2TR yWffgutAyi7R1dKzZVUvGarDM9uNrkmSleqEaujH7Cswb/Gc62mQLgLOuiJswS0DdLGN b6DjZ/uxKRhH9ntQ+LoK7I/YztT5BBoyLuf1X7R/BgcMWnbdt325/K7OUNeQOeWGiqy4 5qqMPTmMszOvxxgH9hWuVlEYMbyIiozJmkhZQsfkzucjbhJVOEt4I142mP+61/2Ld88z dwEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=message-id:in-reply-to:to:references:date:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LLKIhsmFvlE1pYmWEBQFfbgWSErlYPUF/mJkbC2N2Dg=; b=UD9JL3t5blNZLnHTU/Q9u3R1417648t5HgyrCj15+VC6D3ZXgvNQ3rILeEXkqZxAMm YLRcu2LWM5q0kqUMHMTvJYR7YIN6odjdERXvJu+RYOI+2O0nSdsgLcOWojzR4BzHn/nO 2oJ3z51Vl0OZfJeDG9HWTKBftcR85+Xpx3X9SWBTC1anP/EQAUsNcwEhSub3rhr5HIg8 qi8/3VVuoHl3uPaoXw0P9jcOmhQ5OMEiCmlpL0uTZB+AWyI31BVRvtzZRgZ40TDHJK6i kQQB8xpEGK7nYbqEtlJbTUzE0GLxk4ADJy0g9BkdEwDT5oOopb3Bw+iKKE7I1X2r+Fsd Xoew== X-Gm-Message-State: ACrzQf0WXea3DFvL5ebLEJF8TY9CPMUQtlW+v/qH50mgC1BCHu9loW/7 0yhpzsD1HQVGiTc87am69snxQX0HQLY= X-Google-Smtp-Source: AMsMyM7D7jA4ElZXk6ISIeD/vjenGfkKLiWWX5UcJmpav3l8eurYWbUSp2IoJz6GBRQY0QttPm1r0A== X-Received: by 2002:a1c:2543:0:b0:3c6:b7bd:a474 with SMTP id l64-20020a1c2543000000b003c6b7bda474mr33865546wml.95.1666397802441; Fri, 21 Oct 2022 17:16:42 -0700 (PDT) Received: from smtpclient.apple (dynamic-046-114-187-162.46.114.pool.telefonica.de. [46.114.187.162]) by smtp.googlemail.com with ESMTPSA id l35-20020a05600c1d2300b003b477532e66sm11967085wms.2.2022.10.21.17.16.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Oct 2022 17:16:42 -0700 (PDT) From: =?utf-8?Q?Klaus_K=C3=BCchemann?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Date: Sat, 22 Oct 2022 02:16:40 +0200 References: <20221004001857.GA7109@www.zefox.net> <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com> <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com> <20221005034608.GA12761@www.zefox.net> <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com> <20221005160737.GA15227@www.zefox.net> <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com> <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com> <20221021175142.GA62386@www.zefox.net> <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com> To: Mark Millard , freebsd-arm@freebsd.org In-Reply-To: <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com> Message-Id: <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com> X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MvMMc10G5z3khG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=googlemail.com header.s=20210112 header.b=mX+RB7Dc; dmarc=pass (policy=quarantine) header.from=googlemail.com; spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::335 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com X-Spamd-Result: default: False [-3.47 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.97)[-0.966]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::335:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[googlemail.com]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DKIM_TRACE(0.00)[googlemail.com:+]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N > Am 21.10.2022 um 22:21 schrieb Mark Millard : >=20 > On 2022-Oct-21, at 12:53, Mark Millard wrote: >=20 >> On 2022-Oct-21, at 10:51, bob prohaska wrote: >>=20 >>> Mixed success has been obtained using EDK2 on a pair of Pi3 >>> systems, one running 13-stable and one running -current.=20 >>>=20 >>> The 13-stable machine is at stable/13-ef2aa7753 >>> The -current machine is at main-n258665-e03b7883e97c >>>=20 >>> The 13-stable machine boots reliably with an EDK2 microSD card >>> and will boot almost as reliably with no microSD card at all. >>> This seems true with both JMS561 and JMS578 usb-serial bridges. >>>=20 >>> The -current machine uses an ASMT bridge and is unresponsive >>> with either the EDK2 microSD or no microSD at all. It does boot >>> reliably using the "special bootcode.bin" file from the Pi = foundation. >>> It appears to be the newer of the two Pi3's, having a non-latching >>> microSD receptacle.=20 >>=20 >> Which context does the "need bootcode.bin" problem follow? >>=20 >> A) Where the ASMT bridge is used vs. not? >> B) Which RPi3B is used vs. not? >> C) Which OS version is used vs. not? >> D) It gets messier to specify if combinations of 2 or more >> those need to be specified. I'll not list all the >> possibilities. >>=20 >> Does the newer RPi3B indicate that its USB booting has >> been enabled? (You may need to use the likes of a >> RaspiOS variant to check this.) >>=20 >> I'm confused about the "special bootcode.bin": bootcoce.bin >> is a normal part of the RPi* firmware, just ignored by >> RPi4B related RPi*'s that have an alternate means of doing >> things. Is this the bootcode.bin in the standard RPi* >> firmware releases? Some other version? >>=20 >> bootcode.bin always has more recent, bugfixed USB boot code >> than a RPi3B has built in, as far as I know. The RPi3B's >> do not have a supported means of updating what is built-in >> for such functionality. bootcode.bin is used instead. >>=20 >>=20 >>> On balance EDK2 appears to be useful, or at least having some >>> promise. >>=20 >> I'm glad it seems to have helped. But there are things to >> know. >>=20 >> Point #0: EDK2 versions and testedness >>=20 >> The only tested RPi3B EDK2 versions are the ones that the >> developers release. They do not test EDK2 updates after >> they make an EDK2 release, at least until they again work >> on making a new RPi3B EDK2 release. >>=20 >> Similarly, they do not test using newer RPi* firmware than >> they bundle. Only a small subset of the overall RPi* >> firmware is in their RPI3B release. For example, a lack of >> most of the overlays. They do have references to at least >> using one overlay that they do not include, as I remember. >> But use of any other overlays is untested/not-supported as >> far as I can tell. >>=20 >> The same goes for the RPi4B related EDK2 releases vs. later >> EDK2 updates vs. overlays and such. >>=20 >> The RPi3B vs. RPi4B EDK2 releases are not based on the same >> vintage of EDK2 materials --or on the same vintage of RPi* >> materials. >>=20 >> This means that using the FreeBSD port will not pick out >> the release-matching EDK2 materials as are in the RPi3B >> or RPI4B EDK2 releases. Also, the RPi* firmware has to be >> separately supplied. Overall: an untested combination >> results, a combination that is unsupported by the RPi3B EDK2 >> developers and the RPi4B EDK2 developers. >>=20 >> I've no clue if or how well the the port's builds might work. >>=20 >> Another issue is that some software that is upstream of >> EDK2 tends to have problems staying inside the C language >> definition and when this happens, EDK2 builds fail, despite >> it not being EDK2's own code that needs the fix. >>=20 >> Point #1: RPi3B microsd slot use is messed up >>=20 >> In my RPi3B EDK2 related testing, trying to use a microsd >> card in the RPi3B slot for such can corrupt the contents. >> It does not even reliably lead to even correct file name >> displays in ls output. >>=20 >> By contrast, using a USB reader/writer continued to work >> just fine. >>=20 >> So just leave a RPi3B EDK2 microsd card in the slot >> after booting. >>=20 >> I've no clue of the status for things like sound and such. >>=20 >> Point #2: RPi4B does not even start to use the microsd card >>=20 >> In my RPi4B EDK2 use, microsd card in the slot are not >> supported --by being ignored as I remember. >>=20 >> By contrast, using a USB reader/writer continued to work >> just fine. >>=20 >> So just leave a RPi4B EDK2 microsd card in the slot >> after booting. >>=20 >> I've no clue of the status for things like sound and such. >>=20 >>=20 >>> Bugzilla traffic suggests work is stalled, can it be >>> unstuck? >>>=20 >>=20 >> I expect that at some point that some variation on my >> patches to allow the builds to at least complete will >> be committed so the likes of aarch64 FreeBSD builds >> become possible. (So long as EDK2+its-upstream stays >> inside the language definition.) >>=20 >> But I do not know how useful builds are now when built >> on amd64 or the like --that will also be true for the >> aarch64 built ones. See the above "Point #0: EDK2 >> versions and testedness" notes. >>=20 >> It may end up being more effective to stick to >> downloading and using releases made by the RPi3B EDK2 >> and RPi4B EDK2 folks if EDK2 is to be used for these >> RPi* families. >=20 > Side note on what type of video interfaces are in use > for EDK2, at least for RPi4B EDK2 . . . >=20 > =46rom https://bodhi.fedoraproject.org/updates/FEDORA-2022-1c6a1ca835 >=20 > QUOTE of jlinton > It looks fine on my RPI4+PFTF UEFI as well, although it > should be noted that it's running on the EFI framebuffer > in both DT and ACPI mode with that firmware.. This > shouldn't be unexpected. At some point, I will update > the DT with one that has the vc4 bindings. > END QUOTE >=20 > I do not know if RPi3B EDK2 also uses the EFI framebuffer > for its Device Tree vs. ACPI vs. both modes. EFI > framebuffer mode would likely be less performant. >=20 > =E2=80=A6=E2=80=A6=E2=80=A6. FreeBSD will always run it`s framebuffer driver as long as there is no VC4 driver implemented in FreeBSD. So there=E2=80=99s nothing to bind to VC4 in DT nor ACPI. Regards Klaus