Add nanobsd entry from imp
This commit is contained in:
Benjamin Kaduk
parent
04efebac66
commit
f32a0494e1
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=48058
1 changed files with 117 additions and 0 deletions
|
|
@ -3820,4 +3820,121 @@
|
|||
<tt>relaunchd</tt>.</p>
|
||||
</body>
|
||||
</project>
|
||||
|
||||
<project cat='misc'>
|
||||
<title>NanoBSD Modernization</title>
|
||||
|
||||
<contact>
|
||||
<person>
|
||||
<name>
|
||||
<given>Warner</given>
|
||||
<common>Losh</common>
|
||||
</name>
|
||||
<email>imp@FreeBSD.org</email>
|
||||
</person>
|
||||
</contact>
|
||||
|
||||
<body>
|
||||
<p>The NanoBSD updates target three main areas. First,
|
||||
building a NanoBSD image required root privileges. Second,
|
||||
building for embedded platforms required detailed knowledge of the
|
||||
formate required to boot. Third, the exact image sizes needed to
|
||||
be known to produce an image.</p>
|
||||
|
||||
<p>When NanoBSD was written, &os;'s build system required root
|
||||
privileges for the install step and onward. NanoBSD added to this
|
||||
by creating a <tt>md(4)</tt> device to construct the image. Some
|
||||
configurations of NanoBSD added further to this by creating a
|
||||
chroot in which to cleanly build packages. NanoBSD solves the
|
||||
first problem using the new <tt>NO_ROOT</tt> build option to
|
||||
create a meta file. NanoBSD also augments this record as files
|
||||
are created and removed. The meta file is then fed into
|
||||
<tt>makefs(8)</tt> to create a UFS image with the proper
|
||||
permissions. The UFS image, and sometimes a DOS FAT partition,
|
||||
are then passed to <tt>mkimg(1)</tt> to create the final SD image.
|
||||
The mtree manipulation has been written as a separate script to
|
||||
allow it to move into the base system where it could assist with
|
||||
other build orchestration tools (though the move has not happened
|
||||
yet).</p>
|
||||
|
||||
<p>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 this knowledge into its builds. The
|
||||
&os; release system puts it into its system. NanoBSD, prior to
|
||||
the current work, provided no way to access its knowledge of how
|
||||
to build images. The current state of this project allows the
|
||||
user to set a simple image type and have NanoBSD deal with all of
|
||||
the details needed to create that image type. This includes using
|
||||
the u-boot ports and installing the right files into a FAT
|
||||
partition so that &os; can boot with <tt>ubldr(8)</tt>, creating
|
||||
the right <tt>boot1.elf</tt> file for powerpc64 qemu booting, or
|
||||
the more familiar (though needlessly complicated) x86 setup.
|
||||
Previous versions of NanoBSD required too much specialized
|
||||
knowledge from the user. This work aims to concentrate the
|
||||
knowledge into a set of simple scripts for any build orchestration
|
||||
system to use.</p>
|
||||
|
||||
<p>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 the image resize itself on
|
||||
boot. NanoBSD now supports that workflow.</p>
|
||||
|
||||
<p>In addition to these items, a number of minor improvements
|
||||
have been made:</p>
|
||||
|
||||
<ul>
|
||||
<li>Support for <tt>CPUTYPE</tt>-specialized builds. This
|
||||
includes both NanoBSD support as well as important bug fixes
|
||||
in the base system.</li>
|
||||
|
||||
<li>Support for marking MBR partitions as active.</li>
|
||||
|
||||
<li>Support for more partition types.</li>
|
||||
</ul>
|
||||
</body>
|
||||
|
||||
<help>
|
||||
<task>
|
||||
<p><tt>mkimg(8)</tt> 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.</p>
|
||||
</task>
|
||||
|
||||
<task>
|
||||
<p>The chroot functionality of some NanoBSD configurations
|
||||
has not yet been migrated for non-privileged builds.</p>
|
||||
</task>
|
||||
|
||||
<task>
|
||||
<p>The functionality to manipulate <tt>mtree(8)</tt> files
|
||||
should be moved into the base system for use by other build
|
||||
orchestration tools.</p>
|
||||
</task>
|
||||
|
||||
<task>
|
||||
<p>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.</p>
|
||||
</task>
|
||||
|
||||
<task>
|
||||
<p>The <tt>growfs</tt> functionality works great for single
|
||||
images growing to the whole disk. However, NanoBSD would prefer
|
||||
that the boot FS/partition grow to approximately 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 the <tt>growfs</tt> <tt>rc.d(8)</tt>
|
||||
script.</p>
|
||||
</task>
|
||||
</help>
|
||||
</project>
|
||||
</report>
|
||||
|
|
|
|||
Loading…
Reference in a new issue