[U-Boot-Users] Ethernet port

[Ulf Samuelsson]

ons 2007-09-19 klockan 00:11 +0200 skrev Wolfgang Denk:
> In message <1190149063.4516.9.camel at aeglos.sweden.atmel.com> you wrote:
> >
> > > It is a terrible bad idea to set the IP address and especially the MAC
> > > address of your board in the config file, as then all your boards will
> > > share the same address, which will cause only trouble.
> > > 
> > > DO NOT DO THIS!!!
> > 
> > Unless you use this functionality to simplify factory programming of the
> > device.
> 
> It's still a very stupid thing to do, as you buy your own convenience
> at the cost of your customers.

You assume that the customers will see boards with this configuration.
I see this feature should be used by contract manufactures which
wants a simple environment.

The CEM will have test equipment containing preconfigured U-boot.
The CPU BootROM will download this code to SDRAM and execute.

The production system will generate a customized autoscript for each
board setting the ipaddr/ethaddr to a unique value.


The preconfigured bootcmd will download this autoscript, 
which will download at91bootstrap, generic u-boot, linux and
root-fs and program into flash and at the end, set the 
environment variables.

No need for any serial communication.


>
>  - it's they who will have the problems,
> not  you,  obviously.  And  it's  trivial  to  set  up  a  production
> envrionment  where  each and every board has it's own specific serial
> number, MAC address atf. in the U-Boot environment.

Add the requirement - no serial port, and you may understand.

> 
> Don't tell me it could not be done, or would be too complicated. It's
> all there, just use it.


> > By having a compile time setup of ethaddr/ipaddr/serverip, you can
> > easily connect to a production PC using a twisted cable.
> 
> It is NOT necessary to do this at compile time.
> 
> > If this "feature" is used, it must be possible to reconfigure
> > the ethaddr/ipaddr combination to something unique.
> > You do not want to ship this to end customers.
> 
> Then you have to make ethaddr and serial# unprotected, which IMHO  is
> a bad idea either. I don't want to have users messing around with the
> serial  number.  If  you intend for such a setup, you should at least
> use the CONFIG_OVERWRITE_ETHADDR_ONCE feature.

Yes, once the final data is there, it should not be changeable.

> 
> > An autoscript at the production PC can do this as part of the production
> > programming.
> 
> There are much easier ways which  don't  require  console  access  or
> booting  the system. See "board/tqm8xx/load_sernum_ethaddr.c" for one
> example wher ethis information can be written by the same programming
> sequence that programs the U-Boot image - it just programs some small
> data block in a second step.

A restriction is that at production time, all flash memories are clean.
You CAN'T have a small configuration area in a clean flash...
You CAN'T program that area into the flash using a serial port
or JTAG, because there are no ports in the system.

The production system will force the CPU to boot from the BootROM,
and then a temporary U-boot is loaded to SDRAM over the SPI bus.
The temporary U-boot is stored on a memory card (SD/MMC/Dataflashcard) 
or fixed SPI memory in the test system.

Since the on-board flash memory will never be programmed with
the compile time ipaddr/ethaddr, there is really no risk
of duplication of addresses...


> > it is probably advisable to disallow booting the linux kernel if
> > the ethaddr/ipaddr has not changed.
> 
> Too complicated, and not necessary.

Yes, comparing two strings is really rocket science.

> 
> Best regards,
> 
> Wolfgang Denk
> 
-- 
Best Regards,
Ulf Samuelsson          mail:   ulf at atmel.com
Atmel Nordic AB
Box 2033, 174 52 Sundbyberg
Kavallerivägen 24, 174 58 Sundbyberg
Sweden
Tel:    +46 8 441 54 22 GSM:    +46 706 224457