[U-Boot-Users] Proposal for patch to configure networkparameters

Ulf Samuelsson ulf at atmel.com
Mon Apr 23 11:24:54 CEST 2007


mån 2007-04-23 klockan 10:59 +0200 skrev Wolfgang Denk:
> In message <1177306991.4872.25.camel at elrond.sweden.atmel.com> you wrote:
> >
> > Since U-Boot does have a enviroment area. the natural place
> > to put compile time initialization is in the environment area
> > and compile the environment as a separate entity which is linked
> > to the environment. You can define a sector in the <board>.lds.
> > It will not handle "reset to factory defaults" though.
> > 
> > Then you can have compile time initialization AND 
> > if you so choose, you could during production decide
> > to first program u-boot into the flash, and then afterwards
> > modify the environment.
> > On a dataflash that is easy, since the minimium erase block is 1056
> > bytes and you have several blocks in the environment area.
> 
> It's good that we have an agreement here. This is exactly what I
> proposed to you a couple of times before.
> 

AFAIK; U-Boot currently do not support this, 
and the method still does not support reverting to factory defaults.
If someone implements this, I'd be happy to adopt it,
I am not going to do that work though.
I see no immediate benefit over a "factory default" command.


> > Doing it this way, still require you to *create* the environment data
> > Until there is a configuration method which allows your
> > grandmother to get networking running my proposed patch is still useful.
> 
> I cannot follow this conclusion, though.

The goal of the patch is to be able to define U-boot
environment variables outside the <board>.h files.

The environment should be changable by anyone
capable of programming a VHS video but without
any knowledge of U-boot.

Due to lack of good configuration in u-boot,
I have selected to generate the needed configuration
in buildroot, but I am sure that other build systems
like ptxdist/Eclipse could use the same.

A furster restriction, is that I do not want the user
to use hard to understand packages like "expect" 
to configure the board.
I also want a method to do configuration without
connecting a serial port at all.
Only port needed is Ethernet.

Your worry about "bad" ethernet configurations beeing
propagated to users can be handled by refusing to boot
if the ethernet address is within a certain range of values.
U-Boot should always allow "experimental" ethaddr variables
to be overwritten.
It is not done right now, but it is probably not hard to implement.

This still allows connecting to a host and downloading
the real configuration 

when I configure my buildroot system.
A maintainable way to do this, is




> > My goal is to make it easier for the user, and I hopefully 
> > will at a later stage will have a small application which
> > will generate a board specific script which can be installed
> > on the production PC and run once per board.
> > 
> > Currently the ethernet address is already set by u-boot.
> > It is set to 00:00:00:00:00:00, making it impossible 
> > to communicate over ethernet.
> 
> This is making it difficult to the user. I guess  each  board  has  a
> real  MAC  address,  so  why  don't  you use this one? [Also, IMO not
> setting the MAC address at all is still better than setting it  to  a
> non-working value.]
> 
No, Atmel does not ship AT91 boards with a MAC address.
They are shipped with the MAC address cleared.
I dont like that, but this is the way it is.
It is the buyers reponsibility to get a MAC address.
Since I am not shipping any boards, I do not set any boards
to a non-working value.

My buildroot allows the customer to set the ethaddr to a fixed value
or leave it empty, but he should be able to change that to a real value
at the manufacturing site.


> Best regards,
> 
> Wolfgang Denk
> 




More information about the U-Boot mailing list