Re: State of the freebsd/crochet project?

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
>>> 
>>> 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.
>> 
> 

One more point: the 1st Capture.JPG image shows:

c-count 0 c-size 0 r-dir 0 r-sec 0

As I understand it, that is showing that the information was corrupt
as read: valid FAT16 would not have that combination.


===
Mark Millard
marklmi at yahoo.com