Date: Fri, 20 Oct 2023 05:30:59 +0000 From: Rahul Rameshbabu <sergeantsagara@protonmail.com> To: Mark Millard <marklmi@yahoo.com> Cc: Warner Losh <imp@bsdimp.com>, freebsd-arm@freebsd.org Subject: Re: State of the freebsd/crochet project? Message-ID: <8734y5amia.fsf@protonmail.com> In-Reply-To: <33693188-5C53-4C9E-8F67-647655E957BD@yahoo.com> References: <87ttqrqnal.fsf@protonmail.com> <ZS6FAjRlRimUVoWR@int21h> <CANCZdfq%2B4L-guWeEck5OqgFTuXLv%2B6BLOfcDuqVgUSvm7X9SUg@mail.gmail.com> <ZS6PuBrr9wChkhov@int21h> <CANCZdfqAhAeuc-K6O3T-E6FGgy-Lktutc3NSfcmRO5OrhSxYJg@mail.gmail.com> <87wmvjjkae.fsf@protonmail.com> <33693188-5C53-4C9E-8F67-647655E957BD@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Oct, 2023 00:45:25 -0700 "Mark Millard" <marklmi@yahoo.com> wrot=
e:
> On Oct 18, 2023, at 21:41, Rahul Rameshbabu <sergeantsagara@protonmail.co=
m> 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 poudri=
ere.
>>>
>>> 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 th=
e 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=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
>
> 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=3D512 SecPerClust=3D16 ResSectors=3D1 FATs=3D2 RootDirEnts=3D=
512 Media=3D0xf0 FATsecs=3D128 SecPerTrack=3D63 Heads=3D255 HiddenSecs=3D0 =
HugeSectors=3D524288
>
> But it does have a partition type of fat32lba:
>
> # 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)
>
> 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. 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=3D278295#p1685235
* 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.
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).
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 t=
he
> Extensible Firmware Interface (EFI). The sch=
eme-
> specific types are "!239" for MBR, and
> "!c12a7328-f81f-11d2-ba4b-00a0c93ec93b" for G=
PT.
> . . .
> 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.
--
Thanks,
Rahul Rameshbabu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8734y5amia.fsf>