Re: Partition layout of ARM SD card images

Well, I thought the arm64-RPi one is a general purpose layout becase the armv7 one is identical:

mdconfig -a -u 0 -t vnode -f diskimg/FreeBSD-13.1-RELEASE-arm-armv7-GENERICSD.img
gpart show md0 md0s2

   =>     63  6291393  md0  MBR  (3.0G)
          63     2016       - free -  (1.0M)
        2079   102312    1  fat32lba  [active]  (50M)
      104391  6187041    2  freebsd  (3.0G)
     6291432       24       - free -  (12K)

   =>      0  6187041  md0s2  BSD  (3.0G)
           0       57         - free -  (29K)
          57  6186880      1  freebsd-ufs  (2.9G)
     6186937      104         - free -  (52K)

Must be something historical.

> Am 10.07.2022 um 17:48 schrieb Mark Millard <marklmi@yahoo.com>:
> 
> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> wrote:
> 
>> For example let's have a llok on the partition layout of, FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
>> 
>> # mdconfig -a -u 0 -t vnode -f diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
>> # gpart show md0 md0s2
>> 
>>  =>     63  6291393  md0  MBR  (3.0G)
>>         63     2016       - free -  (1.0M)
>>       2079   102312    1  fat32lba  [active]  (50M)
>>     104391  6187041    2  freebsd  (3.0G)
>>    6291432       24       - free -  (12K)
>> 
>>  =>      0  6187041  md0s2  BSD  (3.0G)
>>          0       57         - free -  (29K)
>>         57  6186880      1  freebsd-ufs  (2.9G)
>>    6186937      104         - free -  (52K)
>> 
>> The start of the fat32 boot slice s1 (containing the u-boot) stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The start of the BSD payload slice s2 and its size are odd as well. The padding of 57 blocks within s2 lets the UFS partition start on a globally even base, namely 104391+57 = 104448, which as a matter of fact is 4k aligned (104448*512/4096 = 13056) and 1M aligned as well (104448*512/1024/1024 = 51), however all this keeps looking strange.
>> 
>> Are there reasons for this partition layout besides making it look more interesting? If yes, some insights would be good.
> 
> The layout details are more specific to the aarch64 RPi* context
> than to general aarch64 SD card images. For example, the Rock64
> image is different:
> 
> # mdconfig -a -u 0 -t vnode -f  FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
> # gpart show md0
> =>     40  6291376  md0  GPT  (3.0G)
>       40    32728       - free -  (16M)
>    32768   102400    1  efi  (50M)
>   135168  6156160    2  freebsd-ufs  (2.9G)
>  6291328       88       - free -  (44K)
> 
> The 32768 is associated with:
> 
> # more /usr/local/share/u-boot/u-boot-rock64/README 
> U-Boot loader and related files for the Pine64 Rock64.
> 
> To install this bootloader on an sdcard just do:
> dd if=/usr/local/share/u-boot/u-boot-rock64/idbloader.img of=/path/to/sdcarddevice seek=64 bs=512 conv=sync
> dd if=/usr/local/share/u-boot/u-boot-rock64/u-boot.itb of=/path/to/sdcarddevice seek=16384 bs=512 conv=sync
> 
> where the sizes are:
> 
> 103411 for idbloader.img
> 793560 for u-boot.itb
> 
> In other words: assocaited with having room for
> the idbloader and U-Boot as required by the Rock64.
> [Most U-Boot's(/whatever's) are not placed inside
> a file system and the positions/sizes vary. The
> Rock64 is just an example that I happen to have
> access to.]
> 
> [If I make my own partitioning, I tend to use the 32768 so
> U-Boot/whatever fairly generally have room to be replaced.
> But I've not checked if any u-boot/whatever ports require
> even more space up front. I tend to set up to also allow
> the RPi* to boot as well as the likes of the Rock64 (or
> whatever).]
> 
> Looking at what the official raspios arm64 images look
> like, for example:
> 
> https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_arm64-2022-04-07/2022-04-04-raspios-bullseye-arm64-lite.img.xz
> 
> # mdconfig -a -u 1 -t vnode -f 2022-04-04-raspios-bullseye-arm64-lite.img 
> # gpart show md1
> =>     33  3907551  md1  MBR  (1.9G)
>       33     8159       - free -  (4.0M)
>     8192   524288    1  fat32lba  (256M)
>   532480  3375104    2  linux-data  (1.6G)
> 
> Note the 256M fat32lba instead of only 50M. This dates back
> to:
> 
> QUOTE
> 2019-06-20:
>  * Based on Debian Buster
> . . .
>  * Boot partition size set to 256M
>  * Linux kernel 4.19.50
>  * Raspberry Pi firmware 88ca9081f5e51cdedd16d5dbc85ed12a25123201
> END QUOTE
> 
> rpi-update has logic that can produce the following
> kind of message:
> 
> QUOTE
> Partition size $(( $PARTSIZE >> 20 ))M may not be sufficient for new Pi4 files
> This could result in a system that will not boot.
> 256M FAT partition is recommended. Ensure you have a backup if continuing.
> END QUOTE
> 
> It has had that since 2019-Jun-24, 882f5c1 in:
> 
> https://github.com/raspberrypi/rpi-update/commits/master/rpi-update
> 
> I do not know when the 8192 usage started.
> 
> It is possible that the FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
> structure just dates back to matching far earlier Raspberry Pi
> images. (I did not look that far back.)
> 
>> For the time being, I created a second SD card from the initial one for my RPi 4, and it's partition table is as follows:
>> 
>> # gpart show mmcsd0 mmcsd0s2
>>  =>      63  62410689  mmcsd0  MBR  (30G)
>>          63        25          - free -  (13K)
>>          88    102312       1  fat32lba  [active]  (50M)
>>      102400  62308352       2  freebsd  (30G)
>> 
>>  =>       0  62308352  mmcsd0s2  BSD  (30G)
>>           0  56623104         1  freebsd-ufs  (27G)
>>    56623104   5685248         2  freebsd-swap  (2.7G)
> 
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com