ATSTK1002: Remove default ethernet addresses

Wolfgang is right: It's not a good idea to set up default initial ethernet addresses for a board, even though they belong to the local range.

This will change the failure mode from "IT manager screams at you for using duplicate ethernet addresses" to a nice error message explaining that the ethernet address hasn't been set properly.

---
 include/configs/atstk1002.h |   11 +++--------
 1 files changed, 3 insertions(+), 8 deletions(-)

index 1809fc5..b33e26f 100644
@@ -114,15 +114,10 @@
 #define CONFIG_AUTOBOOT_STOP_STR	" "
 
 /*
- * These are "locally administered ethernet addresses" generated by
- * ./tools/gen_eth_addr
- *
- * After booting the board for the first time, new addresses should be
- * generated and assigned to the environment variables "ethaddr" and
- * "eth1addr".
+ * After booting the board for the first time, new ethernet addresses
+ * should be generated and assigned to the environment variables
+ * "ethaddr" and "eth1addr". This is normally done during production.
  */
-#define CONFIG_ETHADDR			6a:87:71:14:cd:cb
-#define CONFIG_ETH1ADDR			ca:f8:15:e6:3e:e6
 #define CONFIG_OVERWRITE_ETHADDR_ONCE	1
 #define CONFIG_NET_MULTI		1
 

1.5.3.4

[re-adding mailing lists to Cc]

I don't think this is necessary in our production setup at least.

If you want this, feel free to patch it back into your production images. But as soon as someone erases the pre-programmed environment on two or more boards, you'll have chaos on the network they're connected to.

Btw, why don't you just pre-program a default environment sector right after you program the u-boot image? That way, you can have all the custom settings you want.

So you need to define other environment variables anyway? Why can't you patch in a default ethernet address at the same time?

No way. I'm not adding bogus special-casing in the Linux kernel to cope with a problem I'm not even sure exists. Besides, you don't have to boot the kernel to experience problems; running "dhcp" from u-boot is enough to wreak havoc on the network.

We've tried using a default ethernet address on both STK1000 and NGW100 for a while now, and it causes a lot more problems than it solves. I'm turning it off unless someone can point to a specific, valid use-case that breaks.

H?vard

Not if you do the check I propose at the end.

It is easier to do it inside U-boot, than outside U-boot. It is easier to download one file, instead of downloading two files. The effect is the same.
If you happen to change the address of the Environment in U-Boot you need a mechanism to check that this is taken care of..

Also: I am not proposing a "default" address
just that the user can, by running a command, set the ethaddr to something which is useful for production.
If the user does not run the command, then the address will remain unset. Once the ethaddr is set to a different value, it should, as usual, not be possible to change it.

Because I want to download the setting over Ethernet, and I cannot get access to the "serverip", without an Ethernet address.

This would be an U-Boot check.

If the Ethernet address is the predefined ethernet address then the bootm command will give an error message.

Best Regards
Ulf Samuelsson

Oh. But why are you opposed to this change which simply removes the default address? You can still use setenv to set ethaddr to anything you want.

H?vard

I am not opposed to the change, I just point out that there is a use for an initial ethernet address and an initial ip address.

I want to be able to download linux/root fs without connecting to a serial port at all. To provide a setenv command, I then have to put it in the bootcmd.
I do want to avoid having a 1 kB+ large bootcmd,
which would be required if you want to set up the environment this way.

The proposed method will allow the board to reset to a known state easily, something which is not possible if you program the environment or program the board using setenv command.

The bootcmd, would, using the proposed method,
run the command to define the environment, and then download
an autoscript which would define the rest of the environment.
There is no need for a serial communication which may, or may not be availbable.

It all boils downto, that some people prefer a certain way and others prefer to do it in a different way. I believe in letting the customer decide his method.

It is important, to solve the problem with duplicate ethernet addresses.

Best Regards
Ulf Samuelsson ulf at atmel.com

Ok. I think I understand. You don't want the CONFIG_ETHADDR definitions to go away altogether. Right?

Sure. So the customer can add those definitions back, along with a default bootcmd and possibly an IP address. What is the problem?

Actually, there is a problem: If the environment containing the real ethernet address(es) is erased, the "temporary" addresses will be restored. I'm not going to actively prevent anyone from shooting themselves in the foot though; as long as it isn't the default, I consider the problem solved.

Yes, and that's what I'm trying to do. Setting CONFIG_ETHADDR and CONFIG_ETH1ADDR in the u-boot source shipped from us was a mistake, and I don't think you really disagree with that. I'm not proposing that the macros should go away altogether.

H?vard

Does Atmel not have an Ethernet vendor allocation? Ideally, a unique MAC would be included on a sticker on each board. This would provide something for each developer to use. I'm not crazy about having a "default" address for reasons already mentioned. What about a randomly generated MAC address should there not be one already set in flash? This would provide for Ulf's no touch initial setup and still provide for a mostly non-dup solution?

Robin

Yes, we do. Each board is shipped with a unique ethernet address. The problem arises when people reprogram u-boot, mess with the flash, etc. (iow use their development board in the way it was intended to be used ;-)

The following pages explain how you can calculate the board's "official" ethernet addresses from the serial number for NGW100 and STK1000:

http://www.avrfreaks.net/wiki/index.php/Documentation:NGW/NGW100_Ethernet_PHY
http://www.avrfreaks.net/wiki/index.php/Documentation:STK1000/Ethernet_PHY_and_connectors

For the NGW100, the best solution would be to ask the board controller if it hasn't been set in the environment. That's something we definitely want to implement. Until that happens, I think it's better to fail with a clear error message than trying to use a fixed ethernet address.

H?vard

You'd need a non-deterministic random seed... and an RTC doesn't count if all the boards come back from a power outage at once. :-)

-Scott

tis 2007-10-30 klockan 08:53 -0400 skrev Robin Cutshaw:

I have long proposed that we deliver development kits with preprogrammed Ethernet addresses, with little success.
Allocating a random address within this address is the worst of all ideas.
In my own version of U-Boot, I allow for generation of a default ethernet address at compile time, but this only becomes valid, if the user runs a special command "defenv".

If the user does not run the command, then the machine does not have an ethernet address.

This allows the user to set the environment without big hassle, and then the user can automatically configure the machine by an autoscript which downloaded from default server defined at compile time.

Haavards stuff is for people which compile their own version of u-boot, and they will be responsible for allocating their own address when they configure the board.

Best Regards,
Ulf Samuelsson

But we do! Like I said, both STK1000 and NGW100 ship with unique preprogrammed ethernet addresses in Atmel's vendor range. The NGW100 even has a "backup" stored in the board controller's internal flash memory, and you can calculate the board's original ethernet address using the board's serial number.

Maybe someone actually listened to your proposal? ;-)

People who build their own boards are responsible for allocating their own address. People who use boards provided by Atmel should use the ethernet addresses provided by Atmel. At least for the AVR32 boards shipping today -- I have no idea if it's true for the AT91 boards.

And "my stuff" is the stuff that is used in production of the AVR32 boards and shipped with the AVR32 BSPs, so I don't think your assertion holds. Before sending this patch, I asked our lead AVR32 development board designer if it would cause any problems to remove the default ethernet addresses, and he said no.

But hey, if someone who designs their own board thinks your solution is better, I'm certainly not going to stop them. And this patch makes no difference whatsoever to other boards than the STK1000 (although the NGW100 will be changed in the same way.)

H?vard

tis 2007-10-30 klockan 21:57 +0100 skrev Haavard Skinnemoen:

Won't claim that, since I only proposed that to the AT91 team, which still delivers without ethernet address.

I think you misunderstood.
I meant that the work you do to ensure U-Boot mainstream source is working in a certain way, is primarily for vendors recompiling U-Boot, and these guys have to select their own addresses.

This means that Robins proposal that Atmel provides an ethernet address is really not applicable.

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

I am not opposed to the change, I just point out that there is a use for an initial ethernet address and an initial ip address.

I want to be able to download linux/root fs without connecting to a serial port at all. To provide a setenv command, I then have to put it in the bootcmd.
I do want to avoid having a 1 kB+ large bootcmd,
which would be required if you want to set up the environment this way.

The proposed method will allow the board to reset to a known state easily, something which is not possible if you program the environment or program the board using setenv command.

The bootcmd, would, using the proposed method,
run the command to define the environment, and then download
an autoscript which would define the rest of the environment.
There is no need for a serial communication which may, or may not be availbable.

Best Regards
Ulf Samuelsson ulf at atmel.com