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>
|
<tt>relaunchd</tt>.</p>
|
||||||
</body>
|
</body>
|
||||||
</project>
|
</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>
|
</report>
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue