[U-Boot] Compiling fw_printenv tool

[Gerhard Sittig]

On Tue, Jan 14, 2014 at 20:47 +0900, Masahiro Yamada wrote:
> 
> Hello Detlev
> 
> 
> > > How do I cross compile it for my embedded system? Do I just set the
> > > HOSTCC environment variable in the Makefile?
> > 
> > No changes in any makefiles are needed, just do
> > 
> > make HOSTCC=arm-none-linuex-gnueabi-gcc env
> 
> It looks weird to me.
> 
> I think HOSTCC should be always "gcc".
> 
> In my understanding,  tools/env/fw_printenv is not a host program
> but a one for the target embedded Linux.

Here is my interpretation (keep in mind that I'm not an authority
on the matter, it's just what I get from looking at the Makefile
and README, and seeing how fw_printenv(1) was used in external
projects).


You may either adjust the builtin environment in the source code
(in the board specific config file).  This is rather inflexible,
pollutes the source with stuff that may be individual to one
specific site instead of the general use of the board, results in
binaries which apply those settings to wherever they run, and is
frowned upon.  Patches of this style outright get rejected these
days.

You may create a default U-Boot executable, start it on a target
(with its builtin environment), get a prompt, interactively
inspect and modify the environment, save it and then grab the
resulting binary image of the environment by arbitrary means, and
transport the binary image back to your development machine for
further deployment.  This is tedious, and requires access to a
target which may not be available at build time.  If you have the
hardware, you may lack ways to control the interactive session.

You may re-invent the wheel, and create a custom tool which runs
on your build machine and duplicates lots of U-Boot's internal
logic to interpret and manipulate the environment and its binary
presentation on media.  This is quite an effort and keeps causing
trouble and maintenance issues.


Then there is the tools/env/ directory which comes with the
U-Boot source.  It knows how to deal with the environment (the
interpretation and manipulation of the data), knows how to
process and update the binary image of the environment, including
often forgotten aspects like redundancy and padding and
endianess(?), and comes with ready instructions to build the tool
from source.

Looking from this perspective, the fw_printenv(1) tool really is
a host tool to get used at build time on your build machine, and
allows the creation and inspection of binary environment images
which you can ship with the U-Boot executable or with mere dumps
that are flashable images, without the need for access to a
target machine or a prompt therein.  The Makefile reflects this
approach, and uses HOSTCC (and other host related settings).

It's a nice byproduct that you can override HOSTCC (and
HOSTSTRIP) and easily receive an fw_printenv(1) tool that can run
on the target as well.  But this is not the primary use.
Depending on your audience/customers, you don't want to suggest
to them that the boot loader's configuration can get tweaked.
And you probably don't want to unconditionally provide the
command line tool to carry out the manipulation.  It's already
bad enough (from the support POV) that the tool is on disk in the
product.  Having "interested" users brick their product is no
fun, and telling them to not fiddle with internals is hard.
Still you may want to have that tool for remote diagnostics, or
to evaluate U-Boot settings at boot time, or to adjust boot
configurations from within a running Linux yet wrap this
manipulation in tested tools that always create working
combinations and refuse to break stuff.


I can't tell how many developers prefer mkimage(1) and scripts
over pre-built binary environment images.  Mind though that
running those scripts which may manipulate the environment still
depend on target access, and involve the task of getting back the
target's binary env image to the development machine.

Other approaches to environment manipulation or deployment could
have made the fw_printenv(1) tool obsolete or less desirable,
too.  But I haven't followed these approaches too closely, so I
can't comment on that.

It really depends on your platform, U-Boot's configuration for
your project, where the environment is stored on media, how often
you change the environment before production or "how individual"
each machine's initial environment is, how you put the initial
software onto blank hardware, how you integrate the Linux system
with the boot loader, how your organization communicates and
deals with external partners and customers, etc, how useful the
fw_printenv(1) tool is for you, whether you see it as a host tool
or a target binary, and how much you value its being accessible
easily in either form.


> Is there any reason that we don't fix tools/env/Makefile?
> 
>   $(obj)fw_printenv:      $(HOSTSRCS) $(HEADERS)
>           $(HOSTCC) $(HOSTCFLAGS_NOPED) $(HOSTLDFLAGS) -o $@ $(HOSTSRCS)
>           $(HOSTSTRIP) $@
> 
> to
> 
>   $(obj)fw_printenv:      $(HOSTSRCS) $(HEADERS)
>           $(CC) $(HOSTCFLAGS_NOPED) $(HOSTLDFLAGS) -o $@ $(HOSTSRCS)
>           $(STRIP) $@

Two things:  When you s/HOSTCC/CC/, you probably want to adjust
the other specs as well (i.e. not use host flags for cross
builds).  And given the focus on the build time host tool,
changing the build instructions to "target binary" would not be
appropriate either (would not qualify as a "fix").


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de