Date: Sun, 10 Jul 2022 18:02:24 -0300 From: "Dr. Rolf Jansen" <freebsd-rj@cyclaero.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Partition layout of ARM SD card images Message-ID: <45EC1E40-0615-4473-846F-8E9B5202FCC4@cyclaero.com> In-Reply-To: <FA446115-E78D-42C9-B5B0-21EF88075FC1@yahoo.com> References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com> <FA446115-E78D-42C9-B5B0-21EF88075FC1@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
=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)
=3D> 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>:
>=20
> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> =
wrote:
>=20
>> 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.
>=20
> 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:
>=20
> # 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)
>=20
> The 32768 is associated with:
>=20
> # more /usr/local/share/u-boot/u-boot-rock64/README=20
> U-Boot loader and related files for the Pine64 Rock64.
>=20
> 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
>=20
> where the sizes are:
>=20
> 103411 for idbloader.img
> 793560 for u-boot.itb
>=20
> 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.]
>=20
> [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).]
>=20
> Looking at what the official raspios arm64 images look
> like, for example:
>=20
> =
https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_a=
rm64-2022-04-07/2022-04-04-raspios-bullseye-arm64-lite.img.xz
>=20
> # 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)
>=20
> Note the 256M fat32lba instead of only 50M. This dates back
> to:
>=20
> 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
>=20
> rpi-update has logic that can produce the following
> kind of message:
>=20
> 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
>=20
> It has had that since 2019-Jun-24, 882f5c1 in:
>=20
> https://github.com/raspberrypi/rpi-update/commits/master/rpi-update
>=20
> I do not know when the 8192 usage started.
>=20
> 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.)
>=20
>> 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)
>=20
>=20
>=20
> =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?45EC1E40-0615-4473-846F-8E9B5202FCC4>