Re: State of the freebsd/crochet project?
- Reply: Mark Millard : "Re: State of the freebsd/crochet project?"
- In reply to: Rahul Rameshbabu : "Re: State of the freebsd/crochet project?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 20 Oct 2023 07:31:50 UTC
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 >> >> 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. There have been bug fixes, such as the 2022=01-31 EEPROM release that reported: "FAT/GPT fixes and file-system performance improvements." > 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. > > * https://forums.raspberrypi.com/viewtopic.php?t=278295#p1685235 At that point (2020-06) there were only 2 tagged EEPROM content releases: v2020.04.16-137ad v2019.09.10-137ad There are 11 from after 2020-06. > * https://github.com/raspberrypi/rpi-eeprom/releases > > 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. 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. 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. 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. > 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). I've not tested the 2023-10-18 release. > On a side note for myself, might be nice to throw the rpi-eeprom tools > into a port for others to easily grab. > >> >> Or may be you are referencing the partition type (expressed here >> in gpart terms), instead of the actual file system type that is >> contained? : >> >> 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. >> >> fat32 A partition that contains a FAT32 filesystem. The >> scheme-specific type is "!11" for MBR. >> >> fat32lba A partition that contains a FAT32 (LBA) >> filesystem. The scheme-specific type is "!12" for >> MBR. >> >> (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.) >> > > 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. > >>> , so the boot partition >>> needs to be FAT32. >>> >> >> 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. >> >> Is there a chance you are using so large of an msdos file >> system that a FAT32/FAT32LBA file system is a requirement? > > 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. > === Mark Millard marklmi at yahoo.com