Date: Sat, 21 Oct 2023 02:49:24 +0000 From: Rahul Rameshbabu <sergeantsagara@protonmail.com> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: State of the freebsd/crochet project? Message-ID: <8734y4g05q.fsf@protonmail.com> In-Reply-To: <3D73D35C-ECD8-4280-85C7-5B9ACEF0331C@yahoo.com> References: <87ttqrqnal.fsf@protonmail.com> <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> <3D73D35C-ECD8-4280-85C7-5B9ACEF0331C@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Oct, 2023 01:52:30 -0700 "Mark Millard" <marklmi@yahoo.com> wrot=
e:
> [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:
>>
>>> 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@protonma=
il.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 p=
oudriere.
>>>>>>>>
>>>>>>>> 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 f=
or 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 fi=
ne
>>>>>> last I tried such. But release/arm64/RPI.conf and release/tools/arm.=
subr
>>>>>> which are used to build such uses (selective axtractions across file=
s):
>>>>>>
>>>>>> 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/clust=
er)
>>>>>> BytesPerSec=3D512 SecPerClust=3D16 ResSectors=3D1 FATs=3D2 RootDirEn=
ts=3D512 Media=3D0xf0 FATsecs=3D128 SecPerTrack=3D63 Heads=3D255 HiddenSecs=
=3D0 HugeSectors=3D524288
>>
>> 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, se=
ctors
>> 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.
No worries. I did validate that Raspberry Pi OS images do use FAT32 for
the boot partition when initially debugging.
>>
>> 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, se=
ctors
>> 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, h=
eads
>> 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=3D1673458852 serial=
c740af3c boardrev d03115 stc 421180
>> Halt: wake: 1 power_off: 0
>>
>> . . .
>
> 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
>
I also can confirm that new EEPROM bins for the RPi4 support FAT16 just
fine. Oddly enough when using BOOT_UART to debug, I was getting serial
console output with no "Trying partition" messages which led to my
incorrect suspicion about FAT16 (sorry about that). The issue I faced
back then was also related to using start.elf rather than start4.elf,
etc, so maybe that was related to my problematic serial console output
at the time... Not sure why I would not see any "Trying partition"
messages though when trying to boot.
RPi: BOOTLOADER release VERSION:8ba17717 DATE: 2023/01/11 TIME: 17:40:52
BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=3D1673458852 serial 4=
7fdb11e boardrev c03115 stc 486375
PM_RSTS: 0x00001000
part 00000000 reset_info 00000000
uSD voltage 3.3V
Initialising SDRAM 'Micron' 16Gb x2 total-size: 32 Gbit 3200
DDR 3200 1 0 32 152
XHCI-STOP
xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
USBSTS 11
xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
xHC ports 5 slots 32 intrs 4
Boot mode: SD (01) order f4
USB2[1] 400202e1 connected
USB2 root HUB port 1 init
DEV [01:00] 2.16 000000:01 class 9 VID 2109 PID 3431
HUB init [01:00] 2.16 000000:01
SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div:=
512 (256) status: 0x1fff0000 delay: 276
SD HOST: 200000000 CTL0: 0x00800f00 BUS: 400000 Hz actual: 390625 HZ div:=
512 (256) status: 0x1fff0000 delay: 276
OCR c0ff8000 [150]
CID: 00035344534c303847805b8c0c5b00fc
CSD: 400e00325b5900003b377f800a404000
SD: bus-width: 4 spec: 2 SCR: 0x02358001 0x00000000
SD HOST: 200000000 CTL0: 0x00800f04 BUS: 50000000 Hz actual: 50000000 HZ =
div: 4 (2) status: 0x1fff0000 delay: 2
MBR: 0x0000003f, 102375 type: 0x0c
MBR: 0x00019400, 7708672 type: 0xa5
MBR: 0x00000000, 0 type: 0x00
MBR: 0x00000000, 0 type: 0x00
Trying partition: 0
type: 16 lba: 63 oem: 'BSD4.4 ' volume: ' ^ '
rsc 1 fat-sectors 50 c-count 12780 c-size 8
root dir cluster 1 sectors 32 entries 512
FAT16 clusters 12780
Consoles: EFI console =20
Reading loader env vars from /efi/freebsd/loader.env
>>
>> 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
>>>>>> =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.
>>>>
>>>> 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=3D1673458852 seri=
al 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.
>>
<snip>
No worries. I really appreciate the time you took to go over validating
the support of the Pi 4 bootloader release. This also means the
'embedded' target of 'poudriere image' and the image builds of the
FreeBSD project are fine as-is. Hoping to clean up the documentation on
the Raspberry Pi wiki page in general and would like to mark crochet as
public archive if possible.
--
Thanks,
Rahul Rameshbabu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8734y4g05q.fsf>