Re: State of the freebsd/crochet project?

On Fri, 20 Oct, 2023 01:52:30 -0700 "Mark Millard" <[email protected]> wrote:
> [I've dropped Warner from my CC.]
>
> On Oct 20, 2023, at 01:44, Mark Millard <[email protected]> wrote:
>
>> On Oct 20, 2023, at 00:39, Mark Millard <[email protected]> wrote:
>>
>>> On Oct 20, 2023, at 00:31, Mark Millard <[email protected]> wrote:
>>>
>>>> On Oct 19, 2023, at 22:30, Rahul Rameshbabu <[email protected]> wrote:
>>>>
>>>>> On Thu, 19 Oct, 2023 00:45:25 -0700 "Mark Millard" <[email protected]> wrote:
>>>>>> On Oct 18, 2023, at 21:41, Rahul Rameshbabu <[email protected]> wrote:
>>>>>>
>>>>>>> On Tue, 17 Oct, 2023 09:01:33 -0600 "Warner Losh" <[email protected]> wrote:
>>>>>>>> On Tue, Oct 17, 2023, 7:44 AM void <[email protected]> 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.

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, 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
>>
>> . . .
>
> 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=1673458852 serial 47fdb11e 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  
      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
>>>>>> =>       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.
>>

<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