Re: Partition layout of ARM SD card images
Mark Millard <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On 2022-Jul-10, at 15:25, Dr. Rolf Jansen <[email protected]> wrote: >> Am 10.07.2022 um 18:44 schrieb Mark Millard <[email protected]>: >> >> On 2022-Jul-10, at 14:02, Dr. Rolf Jansen <[email protected]> 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 >>> >>> => 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. >> >> Just for reference for 32-bit (hard float) raspios: >> >> https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-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 >> # gpart show md2 >> => 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. > > 2079 and 8192 are starting blocks of the fat32 partition, and 2079 vs. 8192 is the difference between non-aligned and aligned. My concern is not the size but whether the partitions are aligned. > > BTW, I use FreeBSD-13.1-RELEASE-arm-armv7-GENERICSD.img for the BeagleBone Black's and for these I also changed the partitions so the fat32 becomes 4k aligned. FYI: I happen to be looking around to see if I can notice why the stable/13 snapshots fail to build images. So I happen to have done the below that might be of interest: # grep -r FAT_ /usr/main-src/release/ | more /usr/main-src/release/arm/GENERICSD.conf:FAT_SIZE="50m -b 1m" /usr/main-src/release/arm/GENERICSD.conf:FAT_TYPE="16" /usr/main-src/release/arm/RPI-B.conf:FAT_SIZE="50m" /usr/main-src/release/arm/RPI-B.conf:FAT_TYPE="16" /usr/main-src/release/arm64/PINE64-LTS.conf:FAT_SIZE="54m -b 1m" /usr/main-src/release/arm64/PINE64-LTS.conf:FAT_TYPE="16" /usr/main-src/release/arm64/PINE64.conf:FAT_SIZE="54m -b 1m" /usr/main-src/release/arm64/PINE64.conf:FAT_TYPE="16" /usr/main-src/release/arm64/PINEBOOK.conf:FAT_SIZE="54m -b 1m" /usr/main-src/release/arm64/PINEBOOK.conf:FAT_TYPE="16" /usr/main-src/release/arm64/ROCK64.conf:FAT_SIZE="50m -b 16m" /usr/main-src/release/arm64/ROCK64.conf:FAT_TYPE="16" /usr/main-src/release/arm64/ROCKPRO64.conf:FAT_SIZE="50m -b 16m" /usr/main-src/release/arm64/ROCKPRO64.conf:FAT_TYPE="16" /usr/main-src/release/arm64/RPI.conf:FAT_SIZE="50m -b 1m" /usr/main-src/release/arm64/RPI.conf:FAT_TYPE="16" /usr/main-src/release/riscv/GENERICSD.conf:FAT_SIZE="54m -b 8m" /usr/main-src/release/riscv/GENERICSD.conf:FAT_TYPE="16" /usr/main-src/release/tools/arm.subr: chroot ${CHROOTDIR} gpart add -t efi -l efi -a 512k -s ${FAT_SIZE} ${mddev} /usr/main-src/release/tools/arm.subr: chroot ${CHROOTDIR} newfs_msdos -L efi -F ${FAT_TYPE} /dev/${mddev}p1 /usr/main-src/release/tools/arm.subr: chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZE} ${mddev} /usr/main-src/release/tools/arm.subr: chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE} /dev/${mddev}s1 # grep -r "gpart " /usr/main-src/release/ | more /usr/main-src/release/tools/arm.subr: chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev} /usr/main-src/release/tools/arm.subr: chroot ${CHROOTDIR} gpart add -t efi -l efi -a 512k -s ${FAT_SIZE} ${mddev} /usr/main-src/release/tools/arm.subr: chroot ${CHROOTDIR} gpart add -t freebsd-ufs -l rootfs -a 64k ${mddev} /usr/main-src/release/tools/arm.subr: chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZE} ${mddev} /usr/main-src/release/tools/arm.subr: chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev} /usr/main-src/release/tools/arm.subr: chroot ${CHROOTDIR} gpart add -t freebsd ${mddev} /usr/main-src/release/tools/arm.subr: chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2 /usr/main-src/release/tools/arm.subr: chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k ${mddev}s2 This was source from main [so: 14]. But it looks like stable/13 and releng/13.1 match. Looking, it seems that efi (GPT) and msdosfs (MBR) have -a 512k specified and that each freebsd-ufs has -a 64k specified. Looks like it is trying for an alignment. (By contrast freebsd and bsd for MBR do not specify such.) But I'd also expect the various "-b 1m" and "-b 16m" and "-b 8m" to override the -a ??k usage. But, if nothing else, the above gives an idea where to look at the scripting for FreeBSD's producing of SBC images. === Mark Millard marklmi at yahoo.com