Date: Tue, 6 Nov 2012 22:45:43 -0800 From: Tim Kientzle <tim@kientzle.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: announcing the availability of packages for the Arm architecture Message-ID: <82153B9C-2707-400F-994A-DAD9C2AE0678@kientzle.com> In-Reply-To: <CAJ-Vmo=tf1sucY5S%2BofJFEvCoR1PP0569=0LxZJK9EOM05%2BS_Q@mail.gmail.com> References: <CANuCnH_pKuUPhYe-AQ6MpK_XXPSdpft5zhQzEjFBSpfWAPRqKA@mail.gmail.com> <1351606727.1120.17.camel@revolution.hippie.lan> <5097263F.5090802@jetcafe.org> <1D4ECD72-D01D-48D3-B837-735176CC49D3@kientzle.com> <50983301.9040406@jetcafe.org> <162A6F5A-8CC4-44DE-9B46-D9D6D8CC00CE@kientzle.com> <7D9E09AD-95C6-4DD5-9D47-9A04D950DB36@bsdimp.com> <CAJ-Vmo=tf1sucY5S%2BofJFEvCoR1PP0569=0LxZJK9EOM05%2BS_Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 6, 2012, at 11:21 AM, Adrian Chadd wrote: > On 6 November 2012 08:43, Warner Losh <imp@bsdimp.com> wrote: >=20 >>> 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. >>=20 >> 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. >=20 > 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? >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?82153B9C-2707-400F-994A-DAD9C2AE0678>