mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Trent Piepho <tpiepho@kymetacorp.com>
To: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: In flash vs compiled environment for omap, rasp-pi, socfpga
Date: Tue, 20 Oct 2015 01:15:44 +0000	[thread overview]
Message-ID: <1445303748.13196.89.camel@rtred1test09.kymetacorp.com> (raw)

On most boards, it seems the in flash environment is at some fixed
location, and board code will create /dev/env0 from it using
devfs_add_partition().  But a few boards don't work this way, and
instead use a file located in a FAT filesystem in a flash partition.
This is done for omap, raspberry-pi, and socfpga.  The ROM bootloader
supporting partition tables probably has a lot to do with adding this
feature.

It looks like the ability to load the env from a FAT file was first
added in a7b2114, "ARM omap4: panda board", in 2011.  In this patch it
was made to depend on CONFIG_DEFAULT_ENVIRONMENT.

But DEFAULT_ENVIRONMENT is "Compile in default environment".  It causes
the default environment to be compiled into the barebox binary, to be
used if the in flash env can not be used for some reason.  It's an
orthogonal issue to where in flash the environment should come from, a
fixed sector or a file in FAT partition.  It's possible to compile in or
not compile in a default env with either method of storing the flash
env.

So why does loading the env from a FAT partition depend on
DEFAULT_ENVIRONMENT?  It does in the omap and socfpga code, but in the
rasp-pi code it doesn't.

If one tries to build socfpga with DEFAULT_ENVIRONMENT off, you get no
env at all, i.e. a broken barebox.  The env code tries to load
from /dev/env0, which doesn't exist since there is no board code to
create it for socfpga.  And no compiled in default since that was turned
off.

If you turn it on, then you get the env in the FAT partition.  But you
also get the env compiled into the barebox binary.  If there are large
FPGA images stored in the env, this is very undesirable!  A too large
barebox binary would seem to be the primary reason compiling in the env
is supposed to be an optional setting.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

             reply	other threads:[~2015-10-20  1:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-20  1:15 Trent Piepho [this message]
2015-10-21  5:30 ` Sascha Hauer
2015-10-21 23:54   ` Trent Piepho
2015-10-22  7:31     ` Sascha Hauer
2015-11-02 20:25       ` Trent Piepho
2015-11-03  7:17         ` 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=1445303748.13196.89.camel@rtred1test09.kymetacorp.com \
    --to=tpiepho@kymetacorp.com \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox