Re: Partition layout of ARM SD card images
- In reply to: Dr. Rolf Jansen: "Re: Partition layout of ARM SD card images"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 10 Jul 2022 23:27:34 UTC
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>:
>>
>> 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
>>>
>>> => 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