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

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

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

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

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