ons 2007-09-19 klockan 00:11 +0200 skrev Wolfgang Denk:
In message 1190149063.4516.9.camel@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