[Buildroot] [v3, 0/4] Supporting building a second Barebox config

[Pieter Smith <pieter@boesman.nl>]

On Tue, Feb 16, 2016 at 10:27:46PM +0100, Yegor Yefremov wrote:
> On Tue, Feb 16, 2016 at 7:55 PM, Pieter Smith <pieter@boesman.nl> wrote:
> > On Tue, Feb 16, 2016 at 12:55:30PM +0100, Yegor Yefremov wrote:
> >> Hi Pieter,
> >>
> >> On Wed, Jan 20, 2016 at 11:43 PM, Pieter Smith <pieter@boesman.nl> wrote:
> >> > This patch-set in 4 parts adds support for building barebox with up to 2
> >> > configurations. It can be used to build the barebox x-loader or MLO (also
> >> > called Secondary Program Loader) in addition to the standard barebox build
> >> > (Tertiary Program Loader). This implements the design proposed in
> >> > http://elinux.org/Buildroot#Todo_list:
> >> > 1. Have boot/barebox/ containing the common stuff.
> >> > 2. Add two separate packages boot/barebox-1/ and boot/barebox-2/.
> >> > 3. There is only one version selection, but each package allows to
> >> >    define the configuration to be used.
> >> > 4. Design is a little bit like package/gcc, where we have multiple gcc builds,
> >> >    but share a lot of common definitions between the packages.
> >> >
> >> > To demonstrate that it works as advertized, the last patch adds a defconfig for
> >> > the beaglebone black that makes use of the added functionality.
> >>
> >> I've applied the patches and built both MLO and barebox.bin binaries.
> >> The patches are working as expected.
> >
> > Glad to hear it.
> >
> >> I have following use case: I have one board, but want provide
> >> different environment scripts per project. These scripts should be
> >> stored in BR2_EXTERNAL folder. I'd like to also embed them into
> >> barebox.bin. How can I do it in BR?
> >
> > If I understand you correctly, you would like to customize the barebox
> > environment integrated into barebox.bin on a per-project basis. This is
> > something I spent a few hours looking into, but I have not found an adequate
> > solution. It may be easier to bake a new buildroot environment and flash that.
> >
> > Will this satisfy your use-case?
> 
> I've found a solution: http://patchwork.ozlabs.org/patch/583444/
> 
> The question is should enable both inetrnel and external env image? I
> think we should keep both in parallel.

I agree with having both in parallel. I have a personal preference for a
baked-in environments. It allows environment resetting with an erase or delete
(not the case with a separate env image). I can however come up with a number
of use-cases where an external env image is useful from a manufacturing
perspective.
 
> Yegor

- Pieter