From imp@bsdimp.com Sat Jan 9 15:29:49 2016 Date: Sat, 9 Jan 2016 15:29:44 -0500 From: Warner Losh To: monthly@freebsd.org Subject: NanoBSD monthly report [[ Note: I have more of these to come, this one may require some minor copy-editing / wordsmithing ]] NanoBSD modernization Warner Losh imp@freebsd.org

The NanoBSD embedded updates target three main areas. First, building a NanoBSD image required root privs. Second, building for embedded platforms required detailed knowledge of the formate required to boot. Third, exact image sizes needed to be known to produce an image.

When NanoBSD was written, FreeBSD's build system required root privs from the install step forward. NanoBSD added to this by creating a md(4) device to construct the image. Some configurations of NanoBSD added further to this by creating a chroot to cleanly build packages. NanoBSD solves the first problem using the new NO_ROOT build options to create a meta file. NanoBSD also augments this file as files are created and removed. The meta file is then fed into makefs(8) to create a UFS image with the proper permissions. The UFS image, and sometimes a DOS FAT partition, are then passed to mkimg(1) to create the final SD image. The mtree manipulation has been written as a separate script to allow movement into the 'base' system for other build orchestration tools (though the move hasn't happened yet).

The detailed knowledge of how to build each embedded image (as well as some of the base images for qemu) has always been hard to enshrine. Crochet puts it into its build. The FreeBSD release system puts it into its system. NanoBSD, prior to this work, provided no way to access that. This work currently allows the user to set a simple image type and have it deal with all the knowledge needed to make that image type. This includes taking the u-boot ports and installing the right files into a FAT partition for that for FreeBSD to boot with ubldr(8), creating the wright boot1.elf file for powerpc64 qemu booting, or the more familiar (though needlessly complicated) x86 setup. Prior versions of NanoBSD required too much specialized knowledge. This work aims to concentrate the knowledge into a set of simple scripts for any build orchestration system to use.

Finally, NanoBSD images in the past have needed very specific knowledge of the target device. Part of this is a legacy of the BIOS state of the art a decade ago which required very careful matching of the image to the actual device in the deployed system. Although relevant at the time, such systems are now vanishingly rare. Support for them will be phased out (though given the flexibility of NanoBSD, it can be moved to the few remaining examples in the tree and also partially covered by the generic image scripts). Today the typical use case is to create an SD or microSD card image, and have it resize itself on boot. NanoBSD now supports that.

In addition to these items, a number of minor improvements have been made:

mkimg(8) needs to be augmented to create images for the i.MX6 and Allwinner (and others) SoCs. These SoCs require a boot image to be written after the MBR, but before the first partition starts. The chroot functionality of some NanoBSD configurations has not yet been migrated to a no-priv build. The functionality to manipulate mtree(8) files should be moved into the base for other build orchestration tools. The script to create a bootable image from one or more trees of files, as well as some creation of those trees, should be moved into the base system for use with other build orchestration tools. The growfs functionality works great for single images growing to the whole disk. However, NanoBSD would prefer that the boot FS / partition grow to approx 1/2 the size of the media and another identical (or close) partition be created for the ping-ponging upgrades that NanoBSD is setup for. This needs to be implemented in growfs rc.d(8) script.