announcing the availability of packages for the Arm architecture

[Tim Kientzle]

On Nov 6, 2012, at 11:21 AM, Adrian Chadd wrote:

> On 6 November 2012 08:43, Warner Losh <imp at bsdimp.com> wrote:
> 
>>> The key piece right now is a concept of "board" that
>>> encapsulates how to partition a disk image for a
>>> particular system and what boot bits it requires.
>> 
>> I'd love to see a bigger framework akin to NanoBSD that allows one to mix in the application with the board to produce an image customized for your needs.  zrouter does this a bit, as does Tim's scripts, but we aren't quite to where we need to be.
> 
> So question #1: do we import those firmware image tools into
> /usr/src/contrib/, or do we just require that building these things
> requires certain ports to be installed?
> 
> I don't mind wrapping up my build binaries into ports (ie, mkuboot
> stuff with the right mklzma, mktplinkfw, mkubnt) and beginning the
> process of merging stuff into -HEAD.
> ARM is a bit more convoluted as there's sometimes a bootloader and
> bootblocks involved.

If you're lucky, there's only one.  ;-)

My RaspberryPi build currently chains three boot loaders:
   * The two-stage RaspberryPi boot (binary blobs)
   * GPLed U-Boot sources (heavily patched)
   * FreeBSD ubldr (from the FreeBSD tree, but it can't be built as part of buildworld or buildkernel)

I personally do not want to import U-Boot into the FreeBSD
tree, especially given that so far, every board I've looked at
requires a separately-tweaked version from a different source.
Having a megabyte or so of binary blobs for every different
board is also unappealing.

Having a single build framework in the FreeBSD tree that
somehow explicitly depends on particular ports is not
a bad idea, though.  That would keep the binary blobs and
bootloader sources out of our tree.  It narrows the core
problem down to a problem of describing how to build
images for a particular board (which is basically what I'm
trying to address in my scripts with the board/<name>/ directory,
though I know I still have a way to go).

BTW, I'd love to get hold of a MIPS or other dev board
and see what the boot process is like for those.  I think
that would help a lot to inform the work I'm doing.

I'm still not convinced that the overall structure of the work
I'm doing is yet flexible enough for a wide range of boards,
but there's definitely promise.

As to Warner's point, I haven't yet had a chance to play with
the pkgng tools.  I think they would allow me to add integrated
package installation, which is a big step towards adding
an "appliance" concept.  If I understand correctly, Warner is
asking for a way to say "I want <capability> on <hardware>"
(e.g., "webserver on RaspberryPi") and have the build
system just spit out a working image.

Tim