svn commit: r48058 - head/en_US.ISO8859-1/htdocs/news/status

Mon Jan 18 22:35:02 UTC 2016

Author: bjk
Date: Mon Jan 18 22:35:01 2016
New Revision: 48058
URL: https://svnweb.freebsd.org/changeset/doc/48058

Log:
  Add nanobsd entry from imp

Modified:
  head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml

Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml
==============================================================================

--- head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml	Mon Jan 18 22:00:24 2016	(r48057)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml	Mon Jan 18 22:35:01 2016	(r48058)
@@ -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 at 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>
