Re: State of the freebsd/crochet project?
- Reply: Mark Millard : "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: Fri, 20 Oct 2023 08:44:46 UTC
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.
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
. . .
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.
>> 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