[Bug 293574] Add [-b start] offset or partition type "free" to makefs(8) and/or mkimg(1) to enable u-boot-friendly images

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293574

            Bug ID: 293574
           Summary: Add [-b start] offset or partition type "free" to
                    makefs(8) and/or mkimg(1) to enable u-boot-friendly
                    images
           Product: Base System
           Version: 16.0-CURRENT
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: arm
          Assignee: [email protected]
          Reporter: [email protected]

Recent FreeBSD install media and VM-IMAGES are built with a combination of
makefs(8) and mkimg(1), which now support UFS and ZFS, and "msdosfs" for use
with root and EFI partitions respectively.

Several ARM64 "ISO-IMAGES" for single board computers such "RPI", "PINE64,
"ROCKPRO64" and similar are not released using makefs/mkimg, but rather with a
combination of scripts including src/tree/release/release.sh, and profiles such
as src/release/arm64/ROCKPRO64.conf.

With the introduction of packaged base, it would appear that this process can
be greatly simplified with the addition of a [-b start] offset flag/feature to
makefs(8) and/or mkimg(1). Currently, the ROCKPRO64.conf configuration file
includes the syntax: FAT_SIZE="50m -b 16m" which instructs to gpart to create
the first partition, used for dtb files and the EFI loader, at an offset of 16m
to allow for an empty/"free" range into which u-boot loader binaries are
installed into using dd(1) or presumably camdd(8). An example resulting layout
is:

=>      40  10485680  md5  GPT  (5.0G)
        40     32728       - free -  (16M)
     32768    102400    1  efi  (50M)
    135168  10350464    2  rootfs  (4.9G)
  10485632        88       - free -  (44K)

This layout can be reproduced with modern tooling including "root on ZFS" as
follows:

1. Mount and extract the freebsd-zfs root partition from a GENERIC ARM64 image,
which is presumably equivalent to the raw.zfs.img 5GB partition image generated
by makefs -t zfs during the release process.

2. Truncate, attach, and partition a destination image, adding a the first
partition with:

gpart add -t efi -l efiboot0 -a 512k -s 50m -b 16m /dev/md0

3. Formatting this efi partition with:

newfs_msdos -L efi -F 16 md0p1

4. Mounting the efi partition and copying in the contents of the FreeBSD-dtb
and FreeBSD-bootloader base packages, notably to <mountpoint>/dtb and
<mountpoint>/EFI/BOOT/bootaa64.efi .

5. Unmounting the efi partition, and optionally adding a swap partition.

6. Adding a 5GB freebsd-zfs partition, and dd'ing in the previously saved-off
root partition/raw.zfs.img .

7. dd'ing in the u-boot binaries per the package messages, or their duplicate
in the release scripts. (can be done at any stage after the first partition is
added)

8. Detach the memory device and image to a hardware device or boot under
bhyve/ARM64/u-boot.

This approach is tested on a "quartz64-a" board and bhyve/ARM64, with
"rockpro64", "pine64", and "RPI" boards to come.

Alternatively if mkimg(1) supported a "free" partition type, the u-boot
binaries could be installed to a 16m file and that file be passed in before the
efi partition.

To be verified: Given that the FreeBSD-dtb package includes support for many
boards, a common image could hopefully be tailored to each board with simply
the appropriate u-boot binaries. The current EFI partitions sizes are 33M, 50M,
and 54M for non-obvious but easily-valid reasons.

A better approach may obviously exist and feel free to close this if it is in
motion.

-- 
You are receiving this mail because:
You are the assignee for the bug.