"Beyond Buildworld" (was Re: RFC: "Crochet" build tool)

[Warner Losh]

On Apr 6, 2013, at 11:45 AM, Tim Kientzle wrote:

> 
> On Apr 4, 2013, at 10:40 PM, Adrian Chadd wrote:
> 
>> Hm, how about something a bit more modular?
>> 
>> As in, adding hooks to make release / nanobsd / tinybsd to let us tie
>> in the embedded platform requirements, like building bootloaders and
>> such;
> 
> George is setting up a DevSummit track for BSDCan (the
> "Beyond Buildworld" WG) about this exact issue.
> Will you be there?

I'll be there.

> I'll be there and here are a few of the issues I'd like to discuss:
> 
> * What hooks are appropriate?   In part, Crochet is an experiment
>   to explore ways of factoring these issues, but I don't know
>   release or nanobsd well enough to judge whether the
>   ideas I'm coming up with would fit well into those.

Most of the ones that NanoBSD has are quite useful... I'm sure there are many others that would be good in addition, since NanoBSD hasn't kept pace.

> * How do boot loaders get managed?  Crochet has been
>   downloading, patching, and building directly from upstream
>   sources, but that's getting tedious fast.  Can we maintain boot
>   loaders as ports?[1]

I think that we can and should, to the extent we need to do so. Most boards have a perfectly good boot loader already, but some like the popular RPi don't.  Thankfully, the images for the boot loaders tend to be separable from the main image that people load on them and run/boot.

> * What policy should FreeBSD project use to determine which
>   specific boards to release official images for?  For that matter,
>   should the project release "official images" at all?  Or should
>   we leave that in the hands of other parties?

In general, we shouldn't be aiming to release a general loader / kernel that runs everywhere. To release lots of other images will get difficult quickly. Alas, the current kernel infrastructure is a little weak to do this (actually it is impossible at the moment). We should have clear goals here, though, otherwise we'll quickly get bogged down. If we require multiple images, then we should automate the snot out of that, or if a popular board requires custom hacks.

To this end, I think we should examine making ubldr position independent code. Once we have this, it can relocate itself and load the actual kernel at a board specific location it can determine from the FDT...

> I'm not expecting to come up with final answers to these
> at BSDCan, but I'm hoping to get enough people involved to
> at least enumerate some of the avenues to explore.

Yea, if we can get a good consensus on a direction, we can all pull in that direction, rather in the somewhat fractured different directions we have been pulling in to doate.

> [1]   If someone wants to try creating a port of some boot loader
> as an experiment, I'm happy to collaborate on integrating it into
> Crochet to see how well that works.  I would suggest trying
> to build a port for RPi U-Boot as a first proof-of-concept.

That would be cool... Again, I worry about getting in the business of too many board support, but we may want to do that for the most popular ones.

Warner