Date: Sun, 10 Jul 2022 13:48:59 -0700 From: Mark Millard <marklmi@yahoo.com> To: "Dr. Rolf Jansen" <freebsd-rj@cyclaero.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Partition layout of ARM SD card images Message-ID: <FA446115-E78D-42C9-B5B0-21EF88075FC1@yahoo.com> In-Reply-To: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com> References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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):
>=20
> # mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
> # gpart show md0 md0s2
>=20
> =3D> 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)
>=20
> =3D> 0 6187041 md0s2 BSD (3.0G)
> 0 57 - free - (29K)
> 57 6186880 1 freebsd-ufs (2.9G)
> 6186937 104 - free - (52K)
>=20
> 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 =3D 104448, which as a matter of fact is 4k aligned =
(104448*512/4096 =3D 13056) and 1M aligned as well (104448*512/1024/1024 =
=3D 51), however all this keeps looking strange.
>=20
> 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
=3D> 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=20
U-Boot loader and related files for the Pine64 Rock64.
To install this bootloader on an sdcard just do:
dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img =
of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync
dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb =
of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync
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_a=
rm64-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=20
# gpart show md1
=3D> 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:
>=20
> # gpart show mmcsd0 mmcsd0s2
> =3D> 63 62410689 mmcsd0 MBR (30G)
> 63 25 - free - (13K)
> 88 102312 1 fat32lba [active] (50M)
> 102400 62308352 2 freebsd (30G)
>=20
> =3D> 0 62308352 mmcsd0s2 BSD (30G)
> 0 56623104 1 freebsd-ufs (27G)
> 56623104 5685248 2 freebsd-swap (2.7G)
=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?FA446115-E78D-42C9-B5B0-21EF88075FC1>