Re: State of the freebsd/crochet project?
- In reply to: Mark Millard : "Re: State of the freebsd/crochet project?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 21 Oct 2023 02:49:24 UTC
On Fri, 20 Oct, 2023 01:52:30 -0700 "Mark Millard" <marklmi@yahoo.com> wrote: > [I've dropped Warner from my CC.] > > On Oct 20, 2023, at 01:44, Mark Millard <marklmi@yahoo.com> wrote: > >> On Oct 20, 2023, at 00:39, Mark Millard <marklmi@yahoo.com> wrote: >> >>> On Oct 20, 2023, at 00:31, Mark Millard <marklmi@yahoo.com> wrote: >>> >>>> On Oct 19, 2023, at 22:30, Rahul Rameshbabu <sergeantsagara@protonmail.com> wrote: >>>> >>>>> On Thu, 19 Oct, 2023 00:45:25 -0700 "Mark Millard" <marklmi@yahoo.com> wrote: >>>>>> On Oct 18, 2023, at 21:41, Rahul Rameshbabu <sergeantsagara@protonmail.com> wrote: >>>>>> >>>>>>> On Tue, 17 Oct, 2023 09:01:33 -0600 "Warner Losh" <imp@bsdimp.com> wrote: >>>>>>>> On Tue, Oct 17, 2023, 7:44 AM void <void@f-m.fm> wrote: >>>>>>>> >>>>>>>> On Tue, Oct 17, 2023 at 07:13:28AM -0600, Warner Losh wrote: >>>>>>>> >>>>>>>>> Crochet has no active maintainers. Most people have moved on to poudriere. >>>>>>>> >>>>>>>> Does poudriere handle the msdos uboot *and* efi part when >>>>>>>> creating the image? >>>>>>>> >>>>>>>> Yes. I worked with manu years ago to put all the needed metadata for the different boards into the ports... >>>>>>> >>>>>>> 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 >>>>>> >>>>>> 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): >>>>>> >>>>>> FAT_SIZE="50m -b 1m" >>>>>> FAT_TYPE="16" >>>>>> . . . >>>>>> gpart add -t efi -l efi -a 512k -s ${FAT_SIZE} ${mddev} >>>>>> newfs_msdos -L efi -F ${FAT_TYPE} /dev/${mddev}s1 >>>>>> >>>>>> FreeBSD release images are also build with such: efi partition >>>>>> type and a FAT16 file system. >>>>>> >>>>>> Looking at a (my abbreviation) RaspiOS64 boot media used to boot >>>>>> the RPi4B's (official RPi* media content, not FreeBSD materials): >>>>>> >>>>>> # newfs_msdos -N /dev/da0s1 >>>>>> /dev/da0s1: 523984 sectors in 32749 FAT16 clusters (8192 bytes/cluster) >>>>>> BytesPerSec=512 SecPerClust=16 ResSectors=1 FATs=2 RootDirEnts=512 Media=0xf0 FATsecs=128 SecPerTrack=63 Heads=255 HiddenSecs=0 HugeSectors=524288 >> >> 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. No worries. I did validate that Raspberry Pi OS images do use FAT32 for the boot partition when initially debugging. >> >> 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=1673458852 serial c740af3c boardrev d03115 stc 421180 >> Halt: wake: 1 power_off: 0 >> >> . . . > > The console log for this shows that the RPi* firmware reported: > > MBR: 0x00000800, 102400 type: 0x0c > MBR: 0x00019800,468757680 type: 0xa5 > MBR: 0x00000000, 0 type: 0x00 > MBR: 0x00000000, 0 type: 0x00 > Trying partition: 0 > type: 16 lba: 2048 oem: 'BSD4.4 ' volume: ' ^ ' > rsc 1 fat-sectors 50 c-count 12783 c-size 8 > root dir cluster 1 sectors 32 entries 512 > FAT16 clusters 12783 > I also can confirm that new EEPROM bins for the RPi4 support FAT16 just fine. Oddly enough when using BOOT_UART to debug, I was getting serial console output with no "Trying partition" messages which led to my incorrect suspicion about FAT16 (sorry about that). The issue I faced back then was also related to using start.elf rather than start4.elf, etc, so maybe that was related to my problematic serial console output at the time... Not sure why I would not see any "Trying partition" messages though when trying to boot. RPi: BOOTLOADER release VERSION:8ba17717 DATE: 2023/01/11 TIME: 17:40:52 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1673458852 serial 47fdb11e boardrev c03115 stc 486375 PM_RSTS: 0x00001000 part 00000000 reset_info 00000000 uSD voltage 3.3V Initialising SDRAM 'Micron' 16Gb x2 total-size: 32 Gbit 3200 DDR 3200 1 0 32 152 XHCI-STOP xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb USBSTS 11 xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb xHC ports 5 slots 32 intrs 4 Boot mode: SD (01) order f4 USB2[1] 400202e1 connected USB2 root HUB port 1 init DEV [01:00] 2.16 000000:01 class 9 VID 2109 PID 3431 HUB init [01:00] 2.16 000000:01 SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276 SD HOST: 200000000 CTL0: 0x00800f00 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276 OCR c0ff8000 [150] CID: 00035344534c303847805b8c0c5b00fc CSD: 400e00325b5900003b377f800a404000 SD: bus-width: 4 spec: 2 SCR: 0x02358001 0x00000000 SD HOST: 200000000 CTL0: 0x00800f04 BUS: 50000000 Hz actual: 50000000 HZ div: 4 (2) status: 0x1fff0000 delay: 2 MBR: 0x0000003f, 102375 type: 0x0c MBR: 0x00019400, 7708672 type: 0xa5 MBR: 0x00000000, 0 type: 0x00 MBR: 0x00000000, 0 type: 0x00 Trying partition: 0 type: 16 lba: 63 oem: 'BSD4.4 ' volume: ' ^ ' rsc 1 fat-sectors 50 c-count 12780 c-size 8 root dir cluster 1 sectors 32 entries 512 FAT16 clusters 12780 Consoles: EFI console Reading loader env vars from /efi/freebsd/loader.env >> >> 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: >>>>>> >>>>>> # gpart show -p /dev/da0 >>>>>> => 63 468862065 da0 MBR (224G) >>>>>> 63 8129 - free - (4.0M) >>>>>> 8192 524288 da0s1 fat32lba (256M) >>>>>> 532480 468329648 da0s2 linux-data (223G) >>>>>> >>>>>> 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 ? >>>>> >>>>> 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. >>>> >>>> I just booted 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=1673458852 serial c740af3c boardrev d03115 stc 421180 >>>> Halt: wake: 1 power_off: 0 >>>> >>>> off the (what I call) RaspiOS64 media that I referenced earlier. >>>> >>>> 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. >> <snip> No worries. I really appreciate the time you took to go over validating the support of the Pi 4 bootloader release. This also means the 'embedded' target of 'poudriere image' and the image builds of the FreeBSD project are fine as-is. Hoping to clean up the documentation on the Raspberry Pi wiki page in general and would like to mark crochet as public archive if possible. -- Thanks, Rahul Rameshbabu