[U-Boot] Compiling fw_printenv tool

[U-Boot] Compiling fw_printenv tool

[Alexey Smishlayev]

Hello!

I'm trying to compile fw_printenv, to work with U-Boot environment 
variables under my linux os. I'm using commands:
$ cd u-boot/
$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- env

The tool compiles successfully, I get the executable under 
u-boot/tools/env/fw_printenv, but it seem to be compiled for my host 
machine.
On my device it says:
# ./fw_printenv: line 1: syntax error: "(" unexpected

How do I cross compile it for my embedded system? Do I just set the 
HOSTCC environment variable in the Makefile?

Best regards,
Alexey Smishlayev

[U-Boot] Compiling fw_printenv tool

[Detlev Zundel]

Hi Alexey,

> I'm trying to compile fw_printenv, to work with U-Boot environment
> variables under my linux os. I'm using commands:
> $ cd u-boot/
> $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- env
>
> The tool compiles successfully, I get the executable under
> u-boot/tools/env/fw_printenv, but it seem to be compiled for my host
> machine.
> On my device it says:
> # ./fw_printenv: line 1: syntax error: "(" unexpected
>
> 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

We should really turn this into an documentation item.  Does anybody
hava a good idea where to put it?

Cheers
  Detlev

-- 
Progress in  mathematics comes from  repeated acts of generalization.
If mathematics is anything, it is the art of chosing the most elegant
generalization for some abstract pattern.  Thus esthetics is central.
                                     -- Douglas Hofstadter
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Compiling fw_printenv tool

[Alexey Smishlayev]

Dear Detlev,

I ran
$ make HOSTCC=arm-none-linux-gnueabi-gcc env
and got the tools/env/fw_printenv executable. But the Make command 
returned error:
strip: Unable to recognise the format of the input file `fw_printenv'
make[1]: *** [fw_printenv] Error 1

I guess, HOSTSTRIP variable also has to be set.

However, I uploaded the unstripped executable to my embedded device, and 
ran:
$ chmod a+x fw_printenv
$ ./fw_printenv
-sh: ./fw_printenv: not found

I tried also manually stripping the executable.
What could be this error related to?

Best regards,
Alexey Smishlayev


On 2013.11.29. 13:17, Detlev Zundel wrote:
> Hi Alexey,
>
>> I'm trying to compile fw_printenv, to work with U-Boot environment
>> variables under my linux os. I'm using commands:
>> $ cd u-boot/
>> $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- env
>>
>> The tool compiles successfully, I get the executable under
>> u-boot/tools/env/fw_printenv, but it seem to be compiled for my host
>> machine.
>> On my device it says:
>> # ./fw_printenv: line 1: syntax error: "(" unexpected
>>
>> 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
>
> We should really turn this into an documentation item.  Does anybody
> hava a good idea where to put it?
>
> Cheers
>    Detlev
>

[U-Boot] Compiling fw_printenv tool

[Detlev Zundel]

Hi Alexey,

> Dear Detlev,
>
> I ran
> $ make HOSTCC=arm-none-linux-gnueabi-gcc env
> and got the tools/env/fw_printenv executable. But the Make command
> returned error:
> strip: Unable to recognise the format of the input file `fw_printenv'
> make[1]: *** [fw_printenv] Error 1
>
> I guess, HOSTSTRIP variable also has to be set.
>
> However, I uploaded the unstripped executable to my embedded device,
> and ran:
> $ chmod a+x fw_printenv
> $ ./fw_printenv
> -sh: ./fw_printenv: not found
>
> I tried also manually stripping the executable.
> What could be this error related to?

Oops, I really missed that mail, sorry.

This error message means that your cross-compiled binary does not run on
the embedded device (maybe the device uses different libraries than your
cross toolchain links agains).  To troubleshoot that, start with a
regular "hello-world.c" and continue to fw_printenv only if you have
this working.

Cheers
  Detlev

-- 
The  C++  STL, with its dyslexia-inducing syntax blizzard of colons and angle
brackets, guarantees that if you try to declare any reasonable data structure,
your first seven attempts will result in compiler errors of Wagnerian fierce-
ness.                         -- James Mickens
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Compiling fw_printenv tool

[Alexey Smishlayev]

Hello Detlev,

On 2014.01.14. 12:54, Detlev Zundel wrote:
> Hi Alexey,
>
>> Dear Detlev,
>>
>> I ran
>> $ make HOSTCC=arm-none-linux-gnueabi-gcc env
>> and got the tools/env/fw_printenv executable. But the Make command
>> returned error:
>> strip: Unable to recognise the format of the input file `fw_printenv'
>> make[1]: *** [fw_printenv] Error 1
>>
>> I guess, HOSTSTRIP variable also has to be set.
>>
>> However, I uploaded the unstripped executable to my embedded device,
>> and ran:
>> $ chmod a+x fw_printenv
>> $ ./fw_printenv
>> -sh: ./fw_printenv: not found
>>
>> I tried also manually stripping the executable.
>> What could be this error related to?
> Oops, I really missed that mail, sorry.
>
> This error message means that your cross-compiled binary does not run on
> the embedded device (maybe the device uses different libraries than your
> cross toolchain links agains).  To troubleshoot that, start with a
> regular "hello-world.c" and continue to fw_printenv only if you have
> this working.
>
> Cheers
>    Detlev
>

I've googled it and sorted it out. The problem was that executable was 
dynamically linked and the *.so was not found on the embedded system. I 
compiled it with -static and it runs.

Best regards,
Alexey

[U-Boot] Compiling fw_printenv tool

[Masahiro Yamada]

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.

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) $@


Best Regards
Masahiro Yamada

[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

[U-Boot] Compiling fw_printenv tool

[Detlev Zundel]

Hi Masahiro-san,

>> > 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.

You're not alone actually :) In a land far away in time, we used to
always cross-compile this tool.  But at a certain stage IIRC Mike
Frysinger convinced us that this tool should be compiled with the host
toolchain instead (honestly, I can't remember why).  So we accepted this
and documented it a later commit log:

commit 02bd475e343582b3c915b94ef4016d5876d4a4f1
Author: Daniel Hobi <daniel.hobi@schmid-telecom.ch>
Date:   Wed Nov 10 14:11:21 2010 +0100

    tools/env: cleanup host build flags
    
    This patch makes tools/env/Makefile more similar to tools/imls:
    - define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works.
    - include U-Boot headers using -idirafter to prevent picking up
      u-boot/include/errno.h.
    - use HOSTCFLAGS_NOPED (fw_env.c does not conform to -pedantic).
    
    In order to cross-compile tools/env, override the HOSTCC variable
    as in this example:
    
      make tools env HOSTCC=bfin-uclinux-gcc
    
    Signed-off-by: Daniel Hobi <daniel.hobi@schmid-telecom.ch>
    Tested-by: Detlev Zundel <dzu@denx.de>
    Tested-by: Steve Sakoman <steve.sakoman@linaro.org>

I for myself only "saved" the magic invocation needed and forgot the
reasoning...

> I think HOSTCC should be always "gcc".

Correct.  One should only switch this for one specific build target.

> In my understanding,  tools/env/fw_printenv is not a host program
> but a one for the target embedded Linux.

Correct.

> 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) $@

Personally I think I can now remember that the change was mostly done to
get the makefile somehow "more similar" to other makefiles.  So
considering your massive (and most welcome!) work on the build
infrastructure, I think you have become kind of an unspoken authority on
these issues ;) So if it helps in your cleanup and nobody objects, I'll
ack your changes.

Best wishes
  Detlev

-- 
Our choice isn't between a digital world where the NSA can eavesdrop and one
where the NSA is prevented from eavesdropping; it's between a digital world
that is vulnerable to allattackers, and one that is secure for all users.
                              -- Bruce Schneier
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Compiling fw_printenv tool

[Detlev Zundel]

Hi Alexey,

[...]

> I've googled it and sorted it out. The problem was that executable was
> dynamically linked and the *.so was not found on the embedded
> system. I compiled it with -static and it runs.

I'm glad you solved the problem.  I only like for such answers to show
up in archives so that other people can profit from the answer in
DuckDuckGo searches yet to come ;)

Cheers
  Detlev

-- 
Our choice isn't between a digital world where the NSA can eavesdrop and one
where the NSA is prevented from eavesdropping; it's between a digital world
that is vulnerable to allattackers, and one that is secure for all users.
                              -- Bruce Schneier
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Compiling fw_printenv tool

[Detlev Zundel]

Hi Gerhard,

[...]

Ok, thinking about your answer it kind of makes sense that fw_printenv
can easily be used _out of tree_ without much hassle.  On the other
hand, as part of the build process, it is surely "something to run on
the target" and thus something to compile with CC and not HOSTCC.

Bu tmaybe we can get the best of both worlds, but I admit that I'm not
that deep into the build infrastructure.  Even more so considering that
it is currently changing ;)

Cheers
  Detlev

-- 
Algebraists do it in a ring, in fields, in groups.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Compiling fw_printenv tool

[Alexey Smishlayev]

On 2014.01.17. 16:30, Detlev Zundel wrote:
> Hi Alexey,
>
> [...]
>
>> I've googled it and sorted it out. The problem was that executable was
>> dynamically linked and the *.so was not found on the embedded
>> system. I compiled it with -static and it runs.
> I'm glad you solved the problem.  I only like for such answers to show
> up in archives so that other people can profit from the answer in
> DuckDuckGo searches yet to come ;)
>
> Cheers
>    Detlev
>

In case someone needs that (before the Makefile changes are accepted), I 
used the

make HOSTCC='arm-none-linuex-gnueabi-gcc -static' env
command to get it working.

Best regards,
Alexey

[U-Boot] Compiling fw_printenv tool

[Detlev Zundel]

Hi Alexey,

[...]

> In case someone needs that (before the Makefile changes are accepted),
> I used the
>
> make HOSTCC='arm-none-linuex-gnueabi-gcc -static' env
> command to get it working.

We usually do put options into the HOSTCC variable.  Of course one can
argue about that, but the make documentation says about CC:

`CC'
     Program for compiling C programs; default `cc'.

and about

`CFLAGS'
     Extra flags to give to the C compiler.

So maybe you can do the same in a cleaner way like

make HOSTCC='arm-none-linux-gnueabi-gcc' HOSTCFLAGS='-static' env

Don't get me wrong, I don't want to win a beauty contest, but my
experience tells me that such "oh this works for me" quick and dirty
solutions tend to build up "debt" that can be hard to pay later on ;)

Cheers
  Detlev

-- 
The best way to predict the future is to invent it.
                                           -- Alan Kay
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de