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