Date: Sun, 10 Jul 2022 16:27:34 -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: <5547037B-20E2-44F7-9BC1-74A81B9F9463@yahoo.com> In-Reply-To: <CBE9BE5E-3201-4636-B12A-6DFCD8414DDA@cyclaero.com> References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com> <FA446115-E78D-42C9-B5B0-21EF88075FC1@yahoo.com> <45EC1E40-0615-4473-846F-8E9B5202FCC4@cyclaero.com> <598CB7EE-BFF9-4E8F-89CE-B51F3D1B4338@yahoo.com> <CBE9BE5E-3201-4636-B12A-6DFCD8414DDA@cyclaero.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Jul-10, at 15:25, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> = wrote: >> Am 10.07.2022 um 18:44 schrieb Mark Millard <marklmi@yahoo.com>: >>=20 >> On 2022-Jul-10, at 14:02, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> = wrote: >>=20 >>> Well, I thought the arm64-RPi one is a general purpose layout becase = the armv7 one is identical: >>=20 >> 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. >>=20 >> 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. >>=20 >>> 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. >>=20 >> Just for reference for 32-bit (hard float) raspios: >>=20 >> = https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_a= rmhf-2022-04-07/2022-04-04-raspios-bullseye-armhf-lite.img.xz >>=20 >> # 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) >>=20 >> So the same use of 8192 and 256M these days for 32-bit >> raspios. >=20 > 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. >=20 > 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=3D"50m -b 1m" /usr/main-src/release/arm/GENERICSD.conf:FAT_TYPE=3D"16" /usr/main-src/release/arm/RPI-B.conf:FAT_SIZE=3D"50m" /usr/main-src/release/arm/RPI-B.conf:FAT_TYPE=3D"16" /usr/main-src/release/arm64/PINE64-LTS.conf:FAT_SIZE=3D"54m -b 1m" /usr/main-src/release/arm64/PINE64-LTS.conf:FAT_TYPE=3D"16" /usr/main-src/release/arm64/PINE64.conf:FAT_SIZE=3D"54m -b 1m" /usr/main-src/release/arm64/PINE64.conf:FAT_TYPE=3D"16" /usr/main-src/release/arm64/PINEBOOK.conf:FAT_SIZE=3D"54m -b 1m" /usr/main-src/release/arm64/PINEBOOK.conf:FAT_TYPE=3D"16" /usr/main-src/release/arm64/ROCK64.conf:FAT_SIZE=3D"50m -b 16m" /usr/main-src/release/arm64/ROCK64.conf:FAT_TYPE=3D"16" /usr/main-src/release/arm64/ROCKPRO64.conf:FAT_SIZE=3D"50m -b 16m" /usr/main-src/release/arm64/ROCKPRO64.conf:FAT_TYPE=3D"16" /usr/main-src/release/arm64/RPI.conf:FAT_SIZE=3D"50m -b 1m" /usr/main-src/release/arm64/RPI.conf:FAT_TYPE=3D"16" /usr/main-src/release/riscv/GENERICSD.conf:FAT_SIZE=3D"54m -b 8m" /usr/main-src/release/riscv/GENERICSD.conf:FAT_TYPE=3D"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. =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?5547037B-20E2-44F7-9BC1-74A81B9F9463>