In flash vs compiled environment for omap, rasp-pi, socfpga

Trent Piepho tpiepho at kymetacorp.com
Mon Oct 19 18:15:44 PDT 2015


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.



More information about the barebox mailing list