Date: Fri, 20 Oct 2023 01:52:30 -0700 From: Mark Millard <marklmi@yahoo.com> To: Rahul Rameshbabu <sergeantsagara@protonmail.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: State of the freebsd/crochet project? Message-ID: <3D73D35C-ECD8-4280-85C7-5B9ACEF0331C@yahoo.com> In-Reply-To: <CEF4A520-453B-4747-A30F-5F78372231C3@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> <8734y5amia.fsf@protonmail.com> <19481390-118F-4527-BEDC-9935C695A27D@yahoo.com> <6770937E-CBA2-4B50-AD7E-71707E36BFF1@yahoo.com> <CEF4A520-453B-4747-A30F-5F78372231C3@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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:
>=20
>> On Oct 20, 2023, at 00:31, Mark Millard <marklmi@yahoo.com> wrote:
>>=20
>>> On Oct 19, 2023, at 22:30, Rahul Rameshbabu =
<sergeantsagara@protonmail.com> wrote:
>>>=20
>>>> 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:
>>>>>=20
>>>>>> 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:
>>>>>>>=20
>>>>>>> On Tue, Oct 17, 2023 at 07:13:28AM -0600, Warner Losh wrote:
>>>>>>>=20
>>>>>>>> Crochet has no active maintainers. Most people have moved on to =
poudriere.
>>>>>>>=20
>>>>>>> Does poudriere handle the msdos uboot *and* efi part when
>>>>>>> creating the image?
>>>>>>>=20
>>>>>>> Yes. I worked with manu years ago to put all the needed metadata =
for the different boards into the ports...
>>>>>>=20
>>>>>> 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
>>>>>=20
>>>>> 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):
>>>>>=20
>>>>> 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
>>>>>=20
>>>>> FreeBSD release images are also build with such: efi partition
>>>>> type and a FAT16 file system.
>>>>>=20
>>>>> Looking at a (my abbreviation) RaspiOS64 boot media used to boot
>>>>> the RPi4B's (official RPi* media content, not FreeBSD materials):
>>>>>=20
>>>>> # 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=3D512 Media=3D0xf0 FATsecs=3D128 SecPerTrack=3D63 Heads=3D255 =
HiddenSecs=3D0 HugeSectors=3D524288
>=20
> Hmm. Linux reports:
>=20
> # 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 "
>=20
> I must have misinterpreted what "newfs_msdos -N /dev/da0s1" reports
> when /dev/da0s1 has an already exiting file system.
>=20
> Sorry for that and the resultant bad example.
>=20
> For completeness, FreeBSD reports for that media:
>=20
> # 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 "
>=20
> Generating a valid example using, instead:
>=20
> =
FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20231019-fb7140b1f928-266042.img.xz=
>=20
> expanded and dd'd to media:
>=20
> # 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)
>=20
> I just used that to boot a RPi4B Rev 1.5 "C0T" part that has:
>=20
> RPi: BOOTLOADER release VERSION:8ba17717 DATE: 2023/01/11 TIME: =
17:40:52
> BOOTMODE: 0x06 partition 63 build-ts BUILD_TIMESTAMP=3D1673458852 =
serial c740af3c boardrev d03115 stc 421180
> Halt: wake: 1 power_off: 0
>=20
> . . .
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
>=20
> Thu Oct 19 05:57:02 UTC 2023
>=20
> FreeBSD/arm64 (generic) (ttyu0)
>=20
> 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
>=20
>>>>> But it does have a partition type of fat32lba:
>>>>>=20
>>>>> # 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)
>>>>>=20
>>>>> 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 ?
>>>>=20
>>>> 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.
>>>=20
>>> I just booted a RPi4B Rev 1.5 "C0T" part that has:
>>>=20
>>> RPi: BOOTLOADER release VERSION:8ba17717 DATE: 2023/01/11 TIME: =
17:40:52
>>> BOOTMODE: 0x06 partition 63 build-ts BUILD_TIMESTAMP=3D1673458852 =
serial c740af3c boardrev d03115 stc 421180
>>> Halt: wake: 1 power_off: 0
>>>=20
>>> off the (what I call) RaspiOS64 media that I referenced earlier.
>>>=20
>>> That means FAT16 with a partition indicating fat32lba.
>=20
> I accidentally had used what was actually a FAT32 context:
> bad example.
>=20
> The rest of the types of notes should be okay, including the
> corrected example.
>=20
>>> There have been bug fixes, such as the 2022=3D01-31 EEPROM release =
that
>>> reported: "FAT/GPT fixes and file-system performance improvements."
>>>=20
>>>> 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.
>>>>=20
>>>> * https://forums.raspberrypi.com/viewtopic.php?t=3D278295#p1685235
>>>=20
>>> At that point (2020-06) there were only 2 tagged EEPROM content
>>> releases:
>>>=20
>>> v2020.04.16-137ad
>>> v2019.09.10-137ad
>>>=20
>>> There are 11 from after 2020-06.
>>>=20
>>>> * https://github.com/raspberrypi/rpi-eeprom/releases
>>>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>>> 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).
>>>=20
>>> I've not tested the 2023-10-18 release.
>>>=20
>>>> On a side note for myself, might be nice to throw the rpi-eeprom =
tools
>>>> into a port for others to easily grab.
>>>>=20
>>>>>=20
>>>>> Or may be you are referencing the partition type (expressed here
>>>>> in gpart terms), instead of the actual file system type that is
>>>>> contained? :
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> fat32 A partition that contains a FAT32 =
filesystem. The
>>>>> scheme-specific type is "!11" for MBR.
>>>>>=20
>>>>> fat32lba A partition that contains a FAT32 (LBA)
>>>>> filesystem. The scheme-specific type is =
"!12" for
>>>>> MBR.
>>>>>=20
>>>>> (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.)
>>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>>>> , so the boot partition
>>>>>> needs to be FAT32.
>>>>>>=20
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Is there a chance you are using so large of an msdos file
>>>>> system that a FAT32/FAT32LBA file system is a requirement?
>>>>=20
>>>> 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.
>>>>=20
>>>=20
>>=20
>> One more point: the 1st Capture.JPG image shows:
>>=20
>> c-count 0 c-size 0 r-dir 0 r-sec 0
>>=20
>> As I understand it, that is showing that the information was corrupt
>> as read: valid FAT16 would not have that combination.
>>=20
>=20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D73D35C-ECD8-4280-85C7-5B9ACEF0331C>