mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Trent Piepho <>
To: Sascha Hauer <>
Subject: Re: Board specific environments and broken configs
Date: Mon, 17 May 2021 13:57:56 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, May 17, 2021 at 12:38 AM Sascha Hauer <> wrote:
> On Fri, May 14, 2021 at 11:46:38PM -0700, Trent Piepho wrote:
> >
> > An issue with CONFIG_DEFAULT_ENVIRONMENT_PATH is that it applies to
> > all boards in a config.  If multiple boards are built at once, e.g.
> > imx_v7_defconfig, then there is no way for each board to have a
> > different extra env this way.
> Thanks for spotting this. It shows some points that could be cleaned up.
> Generally I suggest to remove the unused files. When they are unused
> nobody should miss them. For some boards we could think about removing

Maybe the documentation could be improved, as it appears to say that a
board env dir will automatically included?  I wonder if some boards,
e.g. skov, thought this too and didnt' realize their env was unused.

> them as well, like for example the i.MX boards that are still not
> converted to multiimage support.

If I understand correctly, with multimage support one puts the env
directory in the board makefile and then board code will add it.
Doesn't this mean that every env for a supported board will be in barebox?

I was thinking there might be a way to avoid that and also avoid board
specific code.

Pass an env overlay, or overlays, in the u-boot dtb that the pbl
provides.  Do it like a FIT image... e.g:
bbenv@0 {
    compatible = "barebox,environment-data";
    barebox-bbenv-data = (raw data of the .bbenv goes here);

The raw data is injected during build the same way a FIT image puts in
the data for a kernel, dtb, initramfs, etc. into the FIT.

This way the env is only in the board specific image with the board
specific barebox dtb.  And common code for barebox's dtb handler can
trigger on the node and add it to the dtb instead of duplicating that
in the board code.  One could also pass additional env to a chained
barebox, though I don't know what one would do with that exactly.

barebox mailing list

  reply	other threads:[~2021-05-17 20:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-15  6:46 Trent Piepho
2021-05-17  7:38 ` Sascha Hauer
2021-05-17 20:57   ` Trent Piepho [this message]
2021-05-18 11:40     ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: Board specific environments and broken configs' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox