From nobody Fri Oct 20 08:44:46 2023 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 4SBdSc5XxDz4xWXw for ; Fri, 20 Oct 2023 08:45:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SBdSb2yvkz4Gy5 for ; Fri, 20 Oct 2023 08:45:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=saa4CI2s; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1697791500; bh=3sMXK14q/vqmdDKc2BsxZOtIoQrE5zhC2f4XgFqrqnE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=saa4CI2sBdkenQPZXeRbwWxqW+T3nLT1ZomRK2Uylj/L1sYu//OpqK+w7Y9crGEfjEqunXYIY+SZbSWe5KlH9ZrUFC71SP039ZJrKMecSz2iH9L9ET+1P8ff9Ef7sCuRnDOLQDtJlPSb8BsgbqJxgQVTCWMGhwnqeDE8ikELXLfa9f74dPGDBoYSuKnzVAtd6IPeeE5ebrVi0r2xDss/jK5u882BHThIbCU1aDUwZD6fFtw7KgjCf7YW7EiHORnJc++NBBxe+bu3ba0+DubYcMK2d8f+IOh4B3COHD9aR6GjLRahlIVqqdeNKMLEv+mxVTD8BHKZ+/APKYZY0jMAKQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1697791500; bh=68VBtvHfPl/tECSh5O6//NflQ20PlwlKpHKJXBQMcGz=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EEWREhxTdfkpFTwFk5vPknBnXwchl9r15RQpSn9y4uyPMi+XBqYtBUG67DsFw3/jnXgEhD0qYPHbJdT5GaY6dkTqMCQhZoRq16D1J0YdchUKWcTcUmkPToG9zsETQe+3q+l+XdJGu+e1mw2D0cGaq9K8zWHUKctTQm4woyKQrTd9unvhPd7fMfC/OB6b+Un7WcgSV/FY2lQvEaerekwHRJK45xMTdpPdjvSKxqlelD7Kcy07UzpooYZRzVg9+Pu4CKkgvQxHx9B+8O0NA6hn8DEe3K68SrzlNA656bqQcd1mEkCRRRUmeHSOfRiZsFDK5PLDAXCbtdQDeUZXaIvssg== X-YMail-OSG: 14GdqGUVM1kk8sNneCgW9rzLxFlRj6mEbTzbX1CaSPUULP3KxWarjTbfYfIKXRK 3xRELQEWKUbQiw0Gd0xx4daaH8RHbBqc0c0AhN1sAa0pOCLvxOMrB.YsUAxZ1G0b7Ywt6mbXBxUV ksU4Kf3gywekqBLEFqxDHb9hbItvoC4C6ha9oqB6Kd0w0HpK9LLRJXgWQEyo85irRhTOUiHU_eEN XSbTNaIR.v.PvJV9nxfGRQzlVnQE0VoyUl.dBQkf3EAQI9u6uN6ntplOalaigcOye3VC.Bts0fQV 6rIKCxNqRaVGPzdkAa8ktlrDc1_2dJV5Q_OL8ixdW2nnXXEI8yWcTdaWL0wI1QwXaCDwSTTHMwtq SyBLN_2kDIdufueSEnko4IRuasHvtVqB9O_VyJ61Zof.TvrAC4O4ipJ4yEY1ePI9VeL300vWDTPi RaC8iFH6.haRwZVvtOM8xsxS0K3gas9zSDA0KQLiR78QH.I86.45KFVr9PPCrkGB6zYf_T06M6cG LHOCjay0KmhgaMbQe5_e94tqb_.VjYtI0xdQb7GJn8cf23a9ez3CLNrS8Aza5P3kS7iQ7LFYAmDN lYFy6HZFG6spzItWq0Eg6obkW1PO9n8YtaaH_AoeqiPfPkUHaL1Eh6aw39IMdJuES2o5sEN0lAcp ydjtOFO0_PzX9r8if93xFWjUtEBUyG.re2p9RMd40or4FHnDXmIbLi10xMYFEn0uUYtR6XzaYr8N SLoaOuPQVszUZsEtJ4Nv2K7agzToL0tqG2PCib4GQ8AUUKUqIV3jpiVTWKXDdWvYTy1dbEL9TzwI R8YZBcEHuOVoK6wOS0.q63KWewQfc4O36FBTk_B70e_0_JjNBhVJQhqMjadRGU3du41BBZwr6Aow zB9mRQJntUCgJyyr7.hKY3KCc8Ao2rP20W4_EFiXotFxUAXlRo9r9pVlVyE2RaqHhNEUoI8NQMbg 0wKpnRNBoweYVp6uARbFdGjdHrWCAjsSvCdcoMeGe.rkK47ZgCcAqltNZGU9QUwKlIGrDTN1ttKV 7rtWO5X9IcSOjqiZus7hFsroaRkYOxZRQFyPNVEM01lDni37DQwXwQdYCAjnr8ycn0nf7UpmTCKL NUdibtANuqGu5ChJLoxw.oKN1QwuArLj6c4fB1ye6.fNtcIsehE6p0Lcix0gx9k3I65_GYqrD9ry 2hHSCQowGN_1Py5D8dszRMN5v7q9guB8CGuH_xdro.c.XsVMGtmaemQf_VBybC9hbL8MDIzX4.AV ZkdHR2DteX3j3q_Mg9pjzRFtVwyvPywQwxuEXWGzbCU4XrS.mQtRLhKhatn92tR52fvN4fuZhZT8 UqUGglUFWf5YFgT2QZNIfCsW7Z.wpQzVW9uSMA7itO2zfYCj6NINy4tCRy2qmDeW7THoFwjLoE9j AST_wJioR8fZSF7jYojLnzMNxHQVjPLnAIELqILTBlg7nEQUCAZUKd13.lvQRqB0oWhzsHiKddpM wDA8lR6yt4M5135EvKQ4oR2LOJtVZasOtTCwVyC7BAcQXMevoAYi.CjGM9i3FP3Zen4JMoR7NODw wudfZGvGqm0AByevM9jRjByiVCSqpyCbQn5vNJCZH4_UJWugi6cbxiCDlDPi9pq3PYubSPqAdFiH kzslmWAvZKSTlADhxeWEzlSShaMwgH2gCAzBywihBDsHsX1pWdYwrHfLZoRXGilE7CBdrSsM78hY b.9gO5lA3NIvDHFXvkS2HdimMMC6MEmuIBjJtQnOXP950vSUbPUFUbjhlmNyrIsVe5ACs._XBmkl D1fJHIuhm5R9Fi9c8JjCWH4j14l4rXARQl220nQYzFCxZKnWwoUJhVEhIut4MpD_aEuJ8aqAq7z4 iweZYx9y7ILP8SuqBPGs.D9zWLz55EydYnCYTxxCr.8vkYK.ExEEAmLKUQz5fKjlTFtSBNvfkb3A _LCzbs95SCRqT98G1hk9qKe10JfeitNLFLpagNMAV8nIoThM3t8FKznJ2VZ.U08S1JIuWrPT57n9 7VQ0QXZkhEXtXrDAIy3ue.wvJzXzWkuxKGC3an5DDBLsstN5c4oBJLaJcAzCsYVrJ_oa2TklwYT1 U4.fHBflIS_TyKB.bz3GXSM.fozV6r2ak0zUstt1.wfOq8T2fW2Sbsxf_elSyz1FaPuJVrAf9tJd bc.7mtmnmgYmQCCzS0SNYN_8s1gbzp2kuGwXCiwpcYaPQEZhFoSV4uw99ZeLeY4J9XAwDglRag9R xX4DfHy3o_7ULSymq0gCLtoqghB5nj.pPhOu0VC4LlFbDiF2LohW2tpds0l6CMOPM5aC_ivJUNsE Ssg-- X-Sonic-MF: X-Sonic-ID: 0d194796-87b1-4a1e-af09-0a6d6e1284df Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 20 Oct 2023 08:45:00 +0000 Received: by hermes--production-gq1-59f5fd4df5-d6xz9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 04fac697c15978b09aab9ce8f262930b; Fri, 20 Oct 2023 08:44:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 \(3774.100.2.1.4\)) Subject: Re: State of the freebsd/crochet project? From: Mark Millard In-Reply-To: <6770937E-CBA2-4B50-AD7E-71707E36BFF1@yahoo.com> Date: Fri, 20 Oct 2023 01:44:46 -0700 Cc: Warner Losh , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87ttqrqnal.fsf@protonmail.com> <87wmvjjkae.fsf@protonmail.com> <33693188-5C53-4C9E-8F67-647655E957BD@yahoo.com> <8734y5amia.fsf@protonmail.com> <19481390-118F-4527-BEDC-9935C695A27D@yahoo.com> <6770937E-CBA2-4B50-AD7E-71707E36BFF1@yahoo.com> To: Rahul Rameshbabu X-Mailer: Apple Mail (2.3774.100.2.1.4) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.204:from]; BLOCKLISTDE_FAIL(0.00)[98.137.65.204:server fail]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_TO(0.00)[protonmail.com]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.204:from]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SBdSb2yvkz4Gy5 On Oct 20, 2023, at 00:39, Mark Millard wrote: > On Oct 20, 2023, at 00:31, Mark Millard wrote: >=20 >> On Oct 19, 2023, at 22:30, Rahul Rameshbabu = wrote: >>=20 >>> On Thu, 19 Oct, 2023 00:45:25 -0700 "Mark Millard" = wrote: >>>> On Oct 18, 2023, at 21:41, Rahul Rameshbabu = wrote: >>>>=20 >>>>> On Tue, 17 Oct, 2023 09:01:33 -0600 "Warner Losh" = wrote: >>>>>> On Tue, Oct 17, 2023, 7:44 AM void wrote: >>>>>>=20 >>>>>> On Tue, Oct 17, 2023 at 07:13:28AM -0600, Warner Losh wrote: >>>>>>=20 >>>>>>> Crochet has no active maintainers. Most people have moved on to = poudriere. >>>>>>=20 >>>>>> Does poudriere handle the msdos uboot *and* efi part when >>>>>> creating the image? >>>>>>=20 >>>>>> Yes. I worked with manu years ago to put all the needed metadata = for the different boards into the ports... >>>>>=20 >>>>> It does but it seems to have an unfortunate caveat. It assumes = that >>>>> FAT16 is supported by all embedded targets. The Raspberry Pi 4 and = I >>>>> assume the Pi 5 as well drop support for FAT16 >>>>=20 >>>> The snapshot images booted the RPI4B's that I have access to just = fine >>>> last I tried such. But release/arm64/RPI.conf and = release/tools/arm.subr >>>> which are used to build such uses (selective axtractions across = files): >>>>=20 >>>> FAT_SIZE=3D"50m -b 1m" >>>> FAT_TYPE=3D"16" >>>> . . . >>>> gpart add -t efi -l efi -a 512k -s ${FAT_SIZE} ${mddev} >>>> newfs_msdos -L efi -F ${FAT_TYPE} /dev/${mddev}s1 >>>>=20 >>>> FreeBSD release images are also build with such: efi partition >>>> type and a FAT16 file system. >>>>=20 >>>> Looking at a (my abbreviation) RaspiOS64 boot media used to boot >>>> the RPi4B's (official RPi* media content, not FreeBSD materials): >>>>=20 >>>> # newfs_msdos -N /dev/da0s1 >>>> /dev/da0s1: 523984 sectors in 32749 FAT16 clusters (8192 = bytes/cluster) >>>> BytesPerSec=3D512 SecPerClust=3D16 ResSectors=3D1 FATs=3D2 = RootDirEnts=3D512 Media=3D0xf0 FATsecs=3D128 SecPerTrack=3D63 Heads=3D255 = HiddenSecs=3D0 HugeSectors=3D524288 Hmm. Linux reports: # file -s /dev/sda1 /dev/sda1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", = sectors/cluster 4, Media descriptor 0xf8, sectors/track 32, heads 64, = sectors 524288 (volumes > 32 MB), FAT (32 bit), sectors/FAT 1020, = reserved 0x1, serial number 0xf92becc, label: "boot " I must have misinterpreted what "newfs_msdos -N /dev/da0s1" reports when /dev/da0s1 has an already exiting file system. Sorry for that and the resultant bad example. For completeness, FreeBSD reports for that media: # file -s /dev/da0s1 /dev/da0s1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", = sectors/cluster 4, Media descriptor 0xf8, sectors/track 32, heads 64, = sectors 524288 (volumes > 32 MB), FAT (32 bit), sectors/FAT 1020, serial = number 0xf92becc, label: "boot " Generating a valid example using, instead: = FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20231019-fb7140b1f928-266042.img.xz= expanded and dd'd to media: # file -s /dev/da0s1 /dev/da0s1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4 ", = sectors/cluster 8, root entries 512, sectors/FAT 50, sectors/track 63, = heads 255, sectors 102400 (volumes > 32 MB), serial number 0xc90a0d0f, = label: "EFI ", FAT (16 bit) I just used that to boot a RPi4B Rev 1.5 "C0T" part that has: RPi: BOOTLOADER release VERSION:8ba17717 DATE: 2023/01/11 TIME: 17:40:52 BOOTMODE: 0x06 partition 63 build-ts BUILD_TIMESTAMP=3D1673458852 serial = c740af3c boardrev d03115 stc 421180 Halt: wake: 1 power_off: 0 . . . Thu Oct 19 05:57:02 UTC 2023 FreeBSD/arm64 (generic) (ttyu0) login: root Password: Oct 19 05:59:46 generic login[1474]: ROOT LOGIN (root) ON ttyu0 FreeBSD 15.0-CURRENT (GENERIC) #0 main-n266042-fb7140b1f928: Thu Oct 19 = 04:52:33 UTC 2023 >>>> But it does have a partition type of fat32lba: >>>>=20 >>>> # gpart show -p /dev/da0 >>>> =3D> 63 468862065 da0 MBR (224G) >>>> 63 8129 - free - (4.0M) >>>> 8192 524288 da0s1 fat32lba (256M) >>>> 532480 468329648 da0s2 linux-data (223G) >>>>=20 >>>> Do you know some specific RPi4B EEPROM content for which a FAT16 >>>> file syatem is not supported? (The EEPROM has the RPi4B boot >>>> loader.) Or are you saying some U-Boot vintage is restricted to >>>> FAT32 file systems for loading FreeBSD's EFI/BOOT/bootaa64.efi ? >>>=20 >>> Yes, I believe that newer EEPROMs in 2020 and above (don't have the >>> exact release version but I can bisect if we need to know) no longer >>> support FAT16 unfortunately. >>=20 >> I just booted a RPi4B Rev 1.5 "C0T" part that has: >>=20 >> RPi: BOOTLOADER release VERSION:8ba17717 DATE: 2023/01/11 TIME: = 17:40:52 >> BOOTMODE: 0x06 partition 63 build-ts BUILD_TIMESTAMP=3D1673458852 = serial c740af3c boardrev d03115 stc 421180 >> Halt: wake: 1 power_off: 0 >>=20 >> off the (what I call) RaspiOS64 media that I referenced earlier. >>=20 >> That means FAT16 with a partition indicating fat32lba. I accidentally had used what was actually a FAT32 context: bad example. The rest of the types of notes should be okay, including the corrected example. >> There have been bug fixes, such as the 2022=3D01-31 EEPROM release = that >> reported: "FAT/GPT fixes and file-system performance improvements." >>=20 >>> Here is a relevant link on Raspberry Pi >>> forums but I can experiment with pinning an exact EEPROM version = from >>> the Raspberry PI repository if need be. When I got my Raspberry Pi 4 >>> board recently, I did an upgrade to the latest EEPROM version and >>> noticed this issue. >>>=20 >>> * https://forums.raspberrypi.com/viewtopic.php?t=3D278295#p1685235 >>=20 >> At that point (2020-06) there were only 2 tagged EEPROM content >> releases: >>=20 >> v2020.04.16-137ad >> v2019.09.10-137ad >>=20 >> There are 11 from after 2020-06. >>=20 >>> * https://github.com/raspberrypi/rpi-eeprom/releases >>>=20 >>> I am using the BOOT_UART feature of the Raspberry Pi 4 for this >>> debugging. I was debugging why the image I created at the had failed = and >>> noticed the bootloader was failing to actually access/read any = content >>> from the boot partition of the SD card. Switching to FAT32 resolved = the >>> issue for me immediately, making me trust the assumption about the = state >>> of later EEPROM releases from the repository. >>=20 >> As I've indicated, the official releases of official RPi* >> images have FAT16 files systems for the RPi* firmware --and >> they boot just fine when dd'd to the USB3 media that I use. >>=20 >> Similarly, the modern official FreeBSD images boot just fine >> and also have FAT16 for the msdosfs for the RPi* >> firmware+U-Boot+FreeBSED-UEFI-loader. >>=20 >> FreeBSD has had problems with a U-Boot vintage that was messed >> up for 8 GiByte RPi4B's. But that is now in the past. >>=20 >>> I noticed in that first link I added here, there seems to be mixed >>> opinions on whether the FAT16 file system is supported or not on = latest >>> EEPROM releases for the Pi 4. Let me go back and test once again = with a >>> FAT16 file system for my boot partition. I am currently running Jan = 11, >>> 2023 release (I see they have a new release for Oct 18, 2023). >>=20 >> I've not tested the 2023-10-18 release. >>=20 >>> On a side note for myself, might be nice to throw the rpi-eeprom = tools >>> into a port for others to easily grab. >>>=20 >>>>=20 >>>> Or may be you are referencing the partition type (expressed here >>>> in gpart terms), instead of the actual file system type that is >>>> contained? : >>>>=20 >>>> efi The system partition for computers that = use the >>>> Extensible Firmware Interface (EFI). The = scheme- >>>> specific types are "!239" for MBR, and >>>> "!c12a7328-f81f-11d2-ba4b-00a0c93ec93b" = for GPT. >>>> . . . >>>> fat16 A partition that contains a FAT16 = filesystem. The >>>> scheme-specific type is "!6" for MBR. >>>>=20 >>>> fat32 A partition that contains a FAT32 = filesystem. The >>>> scheme-specific type is "!11" for MBR. >>>>=20 >>>> fat32lba A partition that contains a FAT32 (LBA) >>>> filesystem. The scheme-specific type is = "!12" for >>>> MBR. >>>>=20 >>>> (It has been some time since last I tried it, but last I tried >>>> partition type fat16, the RPi4B's boot from it just fine if I >>>> remember right. But GPT is supported, not just MBR.) >>>>=20 >>>=20 >>> I am not referring to the partition type rather than the real = filesystem >>> type, but thanks for checking. In my boot flow with the image I >>> generate, I am using the efi partition type. >>>=20 >>>>> , so the boot partition >>>>> needs to be FAT32. >>>>>=20 >>>>=20 >>>> Not for the actual file system for any fairly modern vintage of >>>> RPi4B EEPROM content or U-Boot that I'm aware of. I've less >>>> certainty about the range of partition types, not having tested >>>> such in recent times. >>>>=20 >>>> Is there a chance you are using so large of an msdos file >>>> system that a FAT32/FAT32LBA file system is a requirement? >>>=20 >>> Great question but I believe that is not the case since for the same >>> msdos file system (though with different components from = rpi-firmware), >>> I am able to boot the Raspberry Pi 3 up correctly. Let me verify = once >>> more FAT16 (the filesystem) was indeed problematic for me since I = was >>> debugging other issues like not realizing the Pi 4 needed different >>> components from the rpi-firmware project compared to previous = boards. >>>=20 >>=20 >=20 > One more point: the 1st Capture.JPG image shows: >=20 > c-count 0 c-size 0 r-dir 0 r-sec 0 >=20 > As I understand it, that is showing that the information was corrupt > as read: valid FAT16 would not have that combination. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com