tool to create environment on host?

Hi there,

is there a tool to create a binary environment block from a text file on the host?

If not what would be the best point to start?

Steven

No, not yet.

tools/env/fw_env.[ch]

Replace the flash_io() code with something that simply writes the data to a regular file.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Always borrow money from a pessimist; they don't expect  to  be  paid
back.

That would be *so* useful for our nightly builds...

--
Simon Poole
www.appliancestudio.com

Simon,

Quick and Dirty Hack attached!

Good luck,

Steven

--
Index: tools/Makefile
===================================================================
RCS file: /cvsroot/u-boot/u-boot/tools/Makefile,v
retrieving revision 1.10

diff -u -r1.10 Makefile
@@ -21,9 +21,9 @@
  # MA 02111-1307 USA
  #
 
-BINS   = img2srec$(SFX) mkimage$(SFX) envcrc$(SFX) gen_eth_addr$(SFX) 

bmp_logo$(SFX)
+BINS = img2srec$(SFX) mkimage$(SFX) envcrc$(SFX) gen_eth_addr$(SFX)
bmp_logo$(SFX) txt2env$(SFX)

-OBJS = environment.o img2srec.o mkimage.o crc32.o envcrc.o gen_eth_addr.o
bmp_logo.o
+OBJS = environment.o img2srec.o mkimage.o crc32.o envcrc.o gen_eth_addr.o
bmp_logo.o txt2env.o

ifeq ($(ARCH),mips)
BINS += inca-swap-bytes$(SFX)
@@ -121,6 +121,9 @@
envcrc$(SFX): envcrc.o crc32.o environment.o

                 $(CC) $(CFLAGS) -o $@ $^

+txt2env$(SFX): txt2env.o crc32.o environment.o
+ $(CC) $(CFLAGS) -o $@ $^
+
img2srec$(SFX): img2srec.o

                 $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^
                 $(STRIP) $@
@@ -152,6 +155,9 @@
  envcrc.o:      envcrc.c
                 $(CC) -g $(CFLAGS) -c $<

+txt2env.o: txt2env.c
+ $(CC) -g $(CFLAGS) -c $<
+
crc32.o: crc32.c

                 $(CC) -g $(CFLAGS) -c $<

-------------- next part --------------
A non-text attachment was scrubbed...
Name: txt2env.c
Type: text/x-csrc
Size: 5927 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050525/c4485490/attachment.c

...

Why so? If correctly configured, the environment is built automati- cally with the U-Boot image anyway.

Even if there is good reason for split off environment sectors or for storing the environment in EEPROM (oops, no, impossible - there cannot be any good resons to do that) you can (and should) define a valid and useful default environment, which can even take care of automatic initialization of the "external" environment storage. This requires just a single line of command definitions.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Only in our dreams we are free.  The rest of the time we need  wages.
                                    - Terry Pratchett, _Wyrd Sisters_

Our nightly build produces the full u-boot, kernel, rootfs for our products and wraps it up into a nice single firmware image ready for flashing onto the boards.

The environment for a single board may vary slightly depending on the product it is going into (e.g. different mtdparts kernel bootarg). Our current procedure is to run u-boot on the board, setup the environment correctly, save a binary image of it and put that in the nightly build.
Steven's idea means we can keep the environment in 'source' format and
build the binary on the fly.

I might have missed a trick though if this can be done as part of the normal u-boot build?

Simon.
--
Simon Poole
www.appliancestudio.com

OK - so you have several configurations, which require different environment settings. Right?

You can have several (default) configuration stored simply in your board's config file and select these for example by using different Makefile targets.

Add the required definitions to your board config file, and select these as different make targets. See for example tre adjustment of
the U-Boot image file name on the TFTP server in
"include/configs/TQM5200.h" (search for CONFIG_U_BOOT_SUFFIX), or see the different initialization of the environment depending on flash size (CONFIG_FLASH_8MB) and whether or not the hush shell is activated (CFG_HUSH_PARSER) in "include/configs/trab.h"

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You are only young once, but you can stay immature indefinitely.

Right.

Thanks for the pointers. I'll have a play...

--
Simon Poole
www.appliancestudio.com

That's a good idea, but doesn't work for us because we distribute the boards with valid MAC's in the enviornment, hence every one must be different, and gets hand programmed.
I don't know that there's a way to get around this, but if someone has come up with a tool, I would love to get my hands on it!

NZG.

There are solutions for this, too.

See "board/tqm8xx/load_sernum_ethaddr.c" - on these boards the unused space at the end of the last U-Boot flash sector is used: we store some data structure in the last 64 bytes of this sector containing the serial number, MAC address and som configuration information of the board. These 64 bytes are programmed after all the software has been installed, right before testing the boards.

U-Boot will check if the envrionment variables "serial#" and
"ethaddr" are already defined - if this is the case, nothing happens; if not they get auto-initialized from this data structure. This is completely transparent to the user.

You see, all these problems were already addressed somewhere :-)

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Even if you can deceive people about  a  product  through  misleading
statements, sooner or later the product will speak for itself.
- Hajime Karatsu

And if you update U-Boot in the field these information get lost!?

--
Steven

By then the information has long been saved to the normal environment (it get's written with the first "saveenv"). You just have to make sure that the standard update procedure takes care to keep the old environment - but you want to do this anyway.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I'm a programmer: I don't buy software, I write it.
                                                  -- Tom Christiansen

How do I handle the byteorde of the CRC?
Where is this done in U-Boot?

--
Steven

Use the target's host byte order.

U-Boot or the fw_env tools are always running on the target, so they just use the native byte order.

If your tool is running on the host, you must add appropriate conversion.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The word "fit", as I understand it, means "appropriate to a purpose",
and I would say the body of the Dean is supremely appropriate to  the
purpose of sitting around all day and eating big heavy meals.
                                 - Terry Pratchett, _Moving Pictures_