Date: Sun, 10 Jul 2022 14:44:44 -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: <598CB7EE-BFF9-4E8F-89CE-B51F3D1B4338@yahoo.com> In-Reply-To: <45EC1E40-0615-4473-846F-8E9B5202FCC4@cyclaero.com> References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com> <FA446115-E78D-42C9-B5B0-21EF88075FC1@yahoo.com> <45EC1E40-0615-4473-846F-8E9B5202FCC4@cyclaero.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Jul-10, at 14:02, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> = wrote: > Well, I thought the arm64-RPi one is a general purpose layout becase = the armv7 one is identical: So far as I'm aware, the RPi*'s are unique in having all the content in a file system instead of having some content outside any file system. This tends to make them generally unusual in various respects as far a Small Board Computers go. It is also why I can normally add a RPi* dual-boot configuration adjustment to a configuration for another Small Board Computer (such as the Rock64): no conflict is generated by the 2 U-Boots or other such. > mdconfig -a -u 0 -t vnode -f = diskimg/FreeBSD-13.1-RELEASE-arm-armv7-GENERICSD.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 > Must be something historical. Just for reference for 32-bit (hard float) raspios: = https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_a= rmhf-2022-04-07/2022-04-04-raspios-bullseye-armhf-lite.img.xz # mdconfig -a -u 2 -t vnode -f = 2022-04-04-raspios-bullseye-armhf-lite.img=20 # gpart show md2 =3D> 63 3940289 md2 MBR (1.9G) 63 8129 - free - (4.0M) 8192 524288 1 fat32lba (256M) 532480 3407872 2 linux-data (1.6G) So the same use of 8192 and 256M these days for 32-bit raspios. The 256M may in part be from what some linux updaters do: rename the original files with added .bak suffixes and put down the new files with the original file names. So: 2 instances of the files that do not have brand-new names (some .bak/no-.bak pairs possibly being of 2 distinct vintages). I'll note that a lot of the more modern RPi*'s can boot directly from media that uses GPT instead of MBR. Some older ones can do that only via a microsd card that has a sufficiently modern bootcode.bin that loads first and provides the updated context. There may be some that just can not boot via GPT partitioned media at all. (Unsure.) To avoid microsd card and bootcode.bin requirements ending up involved sometimes, FreeBSD will likely stick with MBR. [I use GPT where I can if I'm setting up media for myself.] >> 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: The sizes below were extracted from "ls -Tld" output, so "byte count" for units for each. >> 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?598CB7EE-BFF9-4E8F-89CE-B51F3D1B4338>