Das U-Boot - Universal Bootloader

Simon,

>>> is there a tool to create a binary environment block from a text file 
>>> on the host?
>>
>> No, not yet.
> 
> That would be *so* useful for our nightly builds...

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
--- tools/Makefile      28 Sep 2004 21:39:46 -0000      1.10
+++ tools/Makefile      25 May 2005 13:12:49 -0000
@@ -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 $<

Steven,

I've created a tool for doing this in our environment.  See attached =
tar.bz2.  You'll have to adjust the Makefile to build in your =
environment, as it has a define to point to your u-boot sources.

The tool uses stdin for the text file and stdout for the binary.  See =
README file.

Dan

-----Original Message-----
From: u-boot-users-admin@...
[mailto:u-boot-users-admin@... Behalf Of Steven
Scholz
Sent: Wednesday, May 25, 2005 4:05 AM
To: u-boot-users@...
Subject: [U-Boot-Users] tool to create environment on host?


Hi there,

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

If not what would be the best point to start?

--=20
Steven


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit =
http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22005
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@...
https://lists.sourceforge.net/lists/listinfo/u-boot-users

In message <4294507C.1050104@...> you wrote:
>
> >>is there a tool to create a binary environment block from a text file on the 
> >>host?
...
> That would be *so* useful for our nightly builds...

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@...
Only in our dreams we are free.  The rest of the time we need  wages.
                                    - Terry Pratchett, _Wyrd Sisters_

Daniel,

> I've created a tool for doing this in our environment.  See attached tar.bz2.  You'll have to adjust the Makefile to build in your environment, as it has a define to point to your u-boot sources.
> 
> The tool uses stdin for the text file and stdout for the binary.  See README file.

20 min to late! :-(

Thanks anyway!

--
Steven

In message <42946E59.5090902@...> you wrote:
>
> How do I handle the byteorde of the CRC?

Use the target's host byte order.

> Where is this done in U-Boot?

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

Wolfgang Denk wrote:
> In message <4294507C.1050104@...> you wrote:
> 
>>>>is there a tool to create a binary environment block from a text file on the 
>>>>host?
> 
> ...
> 
>>That would be *so* useful for our nightly builds...
> 
> 
> Why so? If correctly configured, the environment is  built  automati-
> cally with the U-Boot image anyway.
> 

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
 http://www.appliancestudio.com

In message <42948C33.4010209@...> you wrote:
>
> The environment for a single board may vary slightly depending on the 
> product it is going into (e.g. different mtdparts kernel bootarg).  Our 

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

>   Steven's idea means we can keep the environment in 'source' format and 
> build the binary on the fly.

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

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

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@...
You are only young once, but you can stay immature indefinitely.

Wolfgang Denk wrote:
> 
> OK - so you have  several  configurations,  which  require  different
> environment settings. Right?
> 

Right.

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

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

--
Simon Poole
 http://www.appliancestudio.com

> You can have several (default) configuration stored  simply  in  your
> board's  config  file and select these for example by using different
> Makefile targets.
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.

In message <200505251312.29064.ngustavson@...> you wrote:
>
> 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.

There are solutions for this, too.

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

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@...
Even if you can deceive people about  a  product  through  misleading
statements, sooner or later the product will speak for itself.
- Hajime Karatsu

In message <6.2.0.14.1.20050525131123.03ce4e30@...> you wrote:
>
> I have written a simple u-boot environment modifying tool that you guys may 
> find useful.  (Attached).  The tool is essential for our company since our devices

Why didn't you simply use the existing tool/env/fw_env*  code?  Looks
like it does the same, just in a more flexible way?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@...
There is only one way to console a widow.  But remember the risk.
                                                   -- Robert Heinlein

Wolfgang Denk wrote:

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

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

--
Steven

In message <42957FBE.6010202@...> you wrote:
> 
> > 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.
> 
> And if you update U-Boot in the field these information get lost!?

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@...
I'm a programmer: I don't buy software, I write it.
                                                  -- Tom Christiansen

On Wednesday 25 May 2005 10:37, Peter Asemann wrote:
> Another problem is that the mpcbdm I use to test the SDRAM takes up to
> 30 secs to read/write about 60K of data into/out of RAM (burst mode
> disabled). Is that a mpcbdm issue? I can't believe the SDRAM can be so
> slow.
In my experience the BDM connection is much, much slower than the RAM.

If I load a kernel into the RAM with the BDM I have to get up and walk away, 
get a sandwitch, have a soda, etc...
But If I transfer it in over TFTP it's nearly instantaneous.

NZG.

On 5/25/05, Armand Ciejak <armand.ciejak@...> wrote:
> I'm having problem in debugging U-boot for a MPC8540 processor.
> I'm debugging the very first instructions with the BDI2000. The system
> crash at 2 places in start.S:
>=20
> 1- when clearing debug registers
> 2- when setting up interrupt vectors

I'm assuming you mean "the system crashes if I set a breakpoint at
...".  The 85xx is a real pain in this regard, because it wants to
fetch andexecute the debug exception vector first thing, so BDM
debugging only works if the debug exception is enabled and its vector
is fetchable.  So the two points you list below: 1) disable debug
exceptions 2) overwrite the base address for exceptions.

I just work around this by using TI to step through this very early code.

Also, btw, you'll encounter a similar problem when debugging early
linux startup b/c u-boot doesn't currently relocate exception vectors
to ram.  I posted a u-boot patch for this issue a month or so back;
you might want to google for that.

Cheers,
Kylo