From nobody Sun Apr 17 22:14:55 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 CDB1611CF3A9 for ; Sun, 17 Apr 2022 22:15:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KhPWd57ZQz3rKV for ; Sun, 17 Apr 2022 22:15:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650233702; bh=HmjK3Lexx9rL0EWanOOhai5BhkYFnwdyJMf+SSBXWfQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=aTPw3+BXGm2aqUwpsb6pi3KCVlND9C00X7q11LcgmSmZ08bGrw/8bOegix7NXCCsHm0Kl+a+H4geKwluWoFMiwMK1DLO1IaTuSWAAb9I3a9K3aO6xnneZSunrn827KLTmBKOWWcDVgabBuiiW1kpdQhQREjHtx4zvMSNRirYWo3ilbuESnwt9VXQ8z/byKjlo80A7p0rMEd39P+e1C6+ksuZaazQmlmdBjFjQHu7bYvFkChwECwpSLJ2iP7omjp7jEuYSjmpQXX+5yi7edupNycDDNAKIHZQAeqQjuyc2f27g5Os0CXsZ9EXfkV88zRy9S64BzBhmfiKlS8NZT9csg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650233702; bh=nMobrbq7guBrlJUPszqfkfQOXDDg1Qs0HrvqY/NFIM9=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=EwUTwrlsrsB2l1J/7yJLQRApVMjP728TwurqxR2VgaQBYlA9DSsoVgfflQYPy/bk9VAYqEhj9isuFcP62rFdY5yrp7djmjscdi5e+L//QW7s3LAWQa97aimIXjIwRP732UI7rIZonH9YllaS040VveAsNcsDeEFeuV9gnsTzYCUMIZIVc6dMY2pAxA6xW4I0DEuqjoPlHm/wgLipMIXYmoJAycFUm9IiCfxHgWcfeZfERq4BApKYrXx8vpoLuzLnVwCfQAHugUT2ZanlXVg97OQQ4nySQ4YpTKQHUP5qwx0UPhPKY0ZxRd42LIjHQ/kQ83vLmsFqHAJokGoK0dgp7A== X-YMail-OSG: 5uGTomEVM1ninnQr2b4VZ8Lc_cD6TM9.1yWOYaGIi1azoNPFrOnPJzBWF6YEuOz aasJrFLrPscDeU9jJZVGkh88fhIZB16y0HCU3JxfOrngeqRLG1bdPn8CBfhUXd1y_wVAW1ErL3et EMnMDIL1Gfkxbq0aEJ0mrFrXWhQZW_i_OkM.vbzZOxQxh45mdi0NzN9hSKq_KldB_PpSWNH8Y2Tz HCzQTsft0CzzlghNCUeUqBMkqs29H_J6dFqKdtRzydyOIV8kqKdiJLM8ZUtyfy6crXYYe6lxYiUn JFxNBMBVs09ja77TBHz7br5vd2WjjDVX2A_K6d5BlgpXEvT2JQXh2dA1LYTQwvAOZ3Gr7aEBAzBZ Xv6L.dcY.z_.Br5dvbj3RTdoCQSiIii3SKMECJFjVmQ1aeFHMxdy2JZitupkCJIEhJRLRnNQSIPY i058w0S8KJfwJneaC0IdI9OAqBStf56wJBoImLDHGFIC59HZJWUtlV9tziT1UfRi6PRSdYb1BMSJ UXyTdODXTwLsimRiAbZzf063BFvSOeVcavVXuYzXQEZdO6vag_BFcZ8woJrXvnfBocj9WSCWeDDP f.JzR7D8OCt.LfNJxsRHXIvTxNTAK1IdBXWdK_5A9z5xqpJrYOH8OEO64bD.T0zRYIw7lbODCzWe nPsMts5RwULQdbxO.QjEmlx8.CIlOq2Ovw5RAZlYucm26zoGSLi2q94wPLun.JCM4gaU6tySZiBM pnx0WWDKHOdUlPm1GKv3rfhYrb2cQqjNRVfZPFt9fuueGFvorfW3.kHhnCoLprekRKoLJGo6fqe_ C57wNLANk4A4OwfdUfYWNqluUqYMjrwRXnzjTlIFbzcpAVWJbwx1WxmytW6BGUOMUW3vgdcGieC7 JobSAGUO1l1ZPjZgclAYy3SfldVHRZj_daaIvgJcPYT9gW4Y5mkd1I3gMyW1ttPDWXkIx0TjsfLS AElCRCkPgufSfsWtalKQLboyNhRTfaDx5WwbXEOMuHpfBJYy8m1JdkyhfGQRbGp9FGWN1galSEPP jRocfNGi2LML5Vd8EqMY9xoNU4Wz9XmkZ2zo_.TrbkyuUNoPLxC6Ckiy0t2GfYtbJLSalH0pfVfL G8QzdBdGDQ4y_5S7YPUA2CWAxLuDwyny8UoTbb9S4RxIO.XX1ICH3rKe_nhe3rjJNoLoh8gApKeS GzhlmxF0qhzr.nLb2xxXVVBQPHt3gBa4ZvzM1Bm7O21XDHzWooo6YAqRW8wWwPkd8qtzvjfdVYOs dQxifNwKOSUjvd9ZiFD7QKITcWlMBCDYW2yC4s.DSGxHvTth52nKCBy5_KL1EGL2OBkzyR5ex3gj LndSVVcLJFO3.ZPwPOn.QoFaMypBrbo43F7WLB4.jDbuUvftixBlR1Ghj_O9cS11xiQoWXTKERJb _5MjdzLouUQRmJGXlxdnaARloFMP0Q9n_qk8uVr_YBpdPFjyU8Q.RdooqJboXkCoY4Mt.GKE5gJV kPLHU_AqZk4d579EdIUBUsZQp261uNDEy4XmBQW0B6zDrjDcG3RfVw94pQWxt87DZG6Nil9tx1O7 J9AC8lnizPRRQXD0D6HI8sK2VVzRLYGObTDIJncffbElm_FEptExIk1EaZqcre5pFnxl8CqpSEiU 797kji33Egr7j.1Atw8MJNJkSuraYidKtK5EHdv0YFsZWJGO_9WtAoC4AXhl66g79O0OJn6GS0Dt KqqIzpMg.i_w0fE26bP0bHyS0HBIHUXP9YrfiWUqsjbMyy_EbcYx61K_LGp5mNTqXZZgAQuCLkoe rdPMHZshAARBbtcRMvHDQhAF3PjwUul2lwwpaCK3PUuD8unkRXi8gT8s3g6.u0P3FKgOZrjw8RDu rvqyHUZTl2Gj0zQ0GU69nzqCHEU9yWwzTDcPkE0RTOKJBqVKZ0G1PrCQFCF4IiV.8UGr5Sx1r5DZ QQ5xdui_wdXEduzzJFH0_.72FvUBSpOjxyTZ5g2rt6Xd7qvQ5BWF22x6wyq6kh5qa0Ii84xu5dl7 L6B.Xy8c1jTtSMhxFY__.1Tf.f2na4g0iMVc2zCqMZQlvp2d57DnGXUoyrti67xT_is7xPBArW6O aH6SvtxHDfL4FWLdUTH7bIaZh4ZrXUiccMaNknZPY.2PwKYEzCkBUJ10G0uQJ199c6Nl77ODWRhv 0HcdxKBKrlFwAxtIoX1S4N7ptNRk4QrS1x_fbLtcofYN._udFbvwIqno3NcRsiJWTgXPNNMVQBO3 6nRQwEtCNGrMGVQVUTLDWlWUqvRdczNnGP73WxhHhxexfj8HydQJ.C28KGxUYvPavdDJ7h7g- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 17 Apr 2022 22:15:02 +0000 Received: by hermes--canary-production-ne1-c7c4f6977-qcc8c (VZM Hermes SMTP Server) with ESMTPA ID 452077bd14071764b407a07c563c90a0; Sun, 17 Apr 2022 22:14:57 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii 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 14.0 \(3654.120.0.1.13\)) Subject: Re: A FreeBSD port to build a RPI_EFI.fd matching https://github.com/pftf/RPi4 versioning? Date: Sun, 17 Apr 2022 15:14:55 -0700 References: <4B03F462-5C34-4B36-9075-586CFE59037C@yahoo.com> To: Free BSD In-Reply-To: <4B03F462-5C34-4B36-9075-586CFE59037C@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KhPWd57ZQz3rKV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=aTPw3+BX; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.48 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.98)[-0.978]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-17, at 10:28, Mark Millard wrote: > On 2022-Apr-17, at 04:41, Mark Millard wrote: >=20 >> One of the things about the sysutils/edk2@rpi4 port flavor is that >> it does not build the same tested/in-use releases as the project >> that develops the EDK2 support for the RPi4: different commits >> are used. >>=20 >> I wonder if it would be worthwhile to have a port that has >> the purpose of building what matches some = https://github.com/pftf/RPi4 >> release. So I tried to make a variant of sysutils/edk2 that >> does build such. (I'm new to creating a port, even as a >> textually minor variation of another one.) >>=20 >> Part of the prompt for this is OpenBSD has taken the route of: >>=20 >> QUOTE of https://www.openbsd.org/arm64.html : >> Some Raspberry Pi models that do not work with the included >> U-Boot (e.g. Raspberry Pi 400) can instead be booted using >> EDK2-based UEFI firmware. >> END QUOTE >>=20 >> (Where the link in that text is to: https://github.com/pftf/RPi4 .) >>=20 >> I suspect such may well be true of the RPi4B C0T parts >> that do not have the odd size limitations, such as a >> 3 GiBytes limitation. >>=20 >> As for https://github.com/pftf/RPi4 vs. tianocore . . . >>=20 >> All https://github.com/pftf/RPi4 really does is hold a git >> repository that has the https://github.com/tianocore/edk2* >> and such needed as submodules --plus having a patch or two. >> (I ignore .github/workflows material here.) >>=20 >> I made a variant of sysutils/edk2 that only targets >> allowing tracking of what https://github.com/pftf/RPi4 >> uses from tianocore (and what that in turn uses). For now, >> I used the example of matching v1.33 for >> https://github.com/pftf/RPi4 (the most recent release). >>=20 >> The core of it is: >>=20 >> PORTNAME=3D edk2-pftf-rpi4 >> DISTVERSIONPREFIX=3D v >> DISTVERSION=3D 1.33 >> CATEGORIES=3D sysutils >> . . . >> COMMENT=3D EDK2 Firmware matching a github.com/pftf/RPi4 = version >>=20 >> # Tags for tianocore submodules needed. (Note: pftf/RPi3 does not >> # match pftf/RPi4 .) Same tags as git submodule status reports for >> # manually following the pftf/RPi4 steps. >> # Also later true of GH_TAGNAME for edk2. >> PLATFORM_TAG=3D 958fc02b15 >> NONOSI_TAG=3D 0320db9 >>=20 >> # Tags for non-tianocore submodules used by tianocore for the >> # pftf/RPi4 build. BROTLI_TAG has a 2nd use, handled via the >> # post-extract make target. (Some submodules are not listed >> # because they are unused for pftf/RPi4 .) Note: pftf/RPi3 >> # does not match pftf/RPI4 . >> OPENSSL_TAG=3D OpenSSL_1_1_1j >> SOFTFLOAT_TAG=3D b64af41 >> ONIGURUMA_TAG=3D v6.9.4_mark1 >> BROTLI_TAG=3D v1.0.9-36-gf4153a0 >> # Note: git submodule status showed v1.0.9-35-gf4153a0 but that >> # failed here and when I counted I got 36. So I tried 36 --and it >> # worked. >>=20 >> One oddity that I ran into is a known problem for FreeBSD's >> /lib/libgcc_s.so.1 vs. aarch64 g++ code generation. I documented >> that with: >>=20 >> USE_GCC=3D 11:build >> # Note: >> # I needed to use a -Wl,-rpath=3D/usr/local/lib/gcc* to work around >> # FreeBSD's /lib/libgcc_s.so.1 having incomplete/inaccurate >> # coverage for aarch64 g++ code generation's use of libgcc_s.so.1 . >> # Otherwise tools built, such as VfrCompile, get the following >> # when run: "ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 >> # required by /usr/local/lib/gcc11/libstdc++.so.6 not found". >> # I did not see a supported way to have an automatically >> # adjusting -Wl,-rpath=3D/usr/local/lib/gcc* . >> . . . >> # Avoid: "ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 >> # required by /usr/local/lib/gcc11/libstdc++.so.6 not found" >> # (that is from /lib/libgcc_s.so.1 having incomplete/inaccurate >> # coverage for aarch64 g++ code generation's use of libgcc_s.so.1 ): >> EXTRA_LDFLAGS+=3D -Wl,-rpath=3D${LOCALBASE}/lib/gcc11 >> . . . >> # Emulate source edk2/edksetup.sh >> MAKE_ENV+=3D WORKSPACE=3D${WRKDIR} \ >> = PACKAGES_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}:${WRKDIR}/edk2-platforms-${PL= ATFORM_TAG}:${WRKDIR}/edk2-non-osi-${NONOSI_TAG} \ >> CONF_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/Conf \ >> EDK_TOOLS_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/BaseTools = \ >> = PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/BaseTools/BinWrappers/PosixLike:${PATH= } \ >> PYTHON_COMMAND=3Dpython3 \ >> PYTHONHASHSEED=3D1 \ >> EXTRA_LDFLAGS=3D${EXTRA_LDFLAGS} >>=20 >> I kept the original patch file names. One I could list in >> EXTRA_PATCHES and the other was used via post-patch: >>=20 >> # Using same patch file names as pftf/RPi4 : >> EXTRA_PATCHES=3D = ${FILESDIR}/0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patc= h:-p1 >> . . . >> # Using same patch file names as pftf/RPi4 : >> post-patch: >> ${PATCH} -d ${WRKDIR}/edk2-platforms-${PLATFORM_TAG} -p1 -s < = ${FILESDIR}/0002-Check-for-Boot-Discovery-Policy-change.patch I've noticed that another difference vs. sysutils/edk2@rpi4 is that the equivalent of PLAT_ARGS is different for pftf/RPi4 than used in sysutils/edk2@rpi4 : sysutils/edk2@rpi4 : -D X64EMU_ENABLE=3DFALSE -D CAPSULE_ENABLE=3DFALSE pftf/RPi4 : -D SECURE_BOOT_ENABLE=3DTRUE -D = INCLUDE_TFTP_COMMAND=3DTRUE \ -D NETWORK_ISCSI_ENABLE=3DTRUE -D = SMC_PCI_SUPPORT=3D1 Nothing I did dealt with secure boot at all and I'm not so sure that a port should. (Example: secure boot's default keys.) So I might be more inclined to include something like: -D INCLUDE_TFTP_COMMAND=3DTRUE -D NETWORK_ISCSI_ENABLE=3DTRUE -D = SMC_PCI_SUPPORT=3D1 but I'm unsure about the -D X64EMU_ENABLE=3DFALSE -D = CAPSULE_ENABLE=3DFALSE . (Note: NETWORK_ISCSI_ENABLE is not something that pftf/RPi3 has.) >> pkg-descr and distinfo were updated as well. >>=20 >> poudriere testport seemed to be happy with things. >> portlint only complains about the limitation to >> exactly gcc11 (or whatever is listed there). >>=20 >> But I've not actually tested the image built (yet?). >> Note that, unlike sysutils/edk2@rpi4 , the port >> does build to completion. (sysutils/edk2@FLAVOR builds >> have been failing for a very long time for versions >> of gcc that handle C's newer VLA notation correctly >> (Variable Length Array). This is because brotli >> violated the C language definition but gcc10 and >> before ignored the issue. (Otherwise the other things >> likely would have also been broken.) But, even when it >> built, I avoided the mix of versions that no development >> team was testing for the platform(s) of interest to me.) >>=20 >> So I got far enough along to ask: does a port for this >> purpose seem worthwhile? >>=20 >> I'll note that FreeBSD still has no ACPI drivers >> supporting the use of the RPi4B's: >>=20 >> A) built-in microsd card slot >> B) built-in EtherNet port >>=20 >> I use USB devices for such when using >> https://github.com/pftf/RPi4 . >>=20 >> It is possible that I'll get access to a RPi4B with >> a C0T part (no odd size limitations) that is also >> Rev 1.5 (new PMIC) instead of Rev 1.4 . So I may end >> up able to test booting and operation of an example >> of such. >>=20 >=20 > I should have noted that I've not done anything (yet?) > about getting a copy of the RPi* firmware that > https://github.com/pftf/RPi4 bundles in a release > (v1.33 here). As stands, it is only the EDK2's RPI_EFI.fd > that is provided. >=20 > Part of what https://github.com/pftf/RPi4 provides is that > they develop a working combination and update when > problems are discovered, such a reverting to older RPi* > firmware. >=20 Hmm. Looking at the details for that last it is not what I expected for how it is implemented. In essence, the RPi* firmware needs to be extracted from an already built pftf/RPi4 release in order to be reproducible . . . The pftf/RPi4 builds themselves normally just grab from https://github.com/raspberrypi/firmware/ 's master branch. So, if rerun after master has changed, would produce a different result. They do patch in a more specific reference to specific files when they release in order to revert one or more files. But the other RPi* files are left as grabbed from master. In such cases they are testing and releasing RPi* firmware materials from a mix of time frames. (Also not what I would have guessed.) Still, they do make such adjustments when problem occur and folks help them test. I know how to look up what version a start*.elf is from --and the fixup*.dat needs to be from the same version. But I do not know a reasonable way to identify how to find the .dtb or .dtbo files to grab from github in order to have a match to what is in a pftf/RPi4 release. =3D=3D=3D Mark Millard marklmi at yahoo.com