Re: Partition layout of ARM SD card images

Reply: Dr. Rolf Jansen: "Re: Partition layout of ARM SD card images"
Reply: Dr. Rolf Jansen: "Re: Partition layout of ARM SD card images"
In reply to: Dr. Rolf Jansen: "Partition layout of ARM SD card images"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 10 Jul 2022 20:48:59 UTC
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