Re: [U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses
[re-adding mailing lists to Cc]
On Mon, 29 Oct 2007 11:21:25 +0100 "Ulf Samuelsson" ulf@atmel.com wrote:
Haavard, For production use, you want to be able to set up a default address.
I don't think this is necessary in our production setup at least.
All production PCs would have a dedicated Ethernet board, with a predetemined IP address. Nothing but the production PC and the board under production is connected to this Ethernet. Thus there is not a problem to have a fixed ethernet address on the AVR32 board.
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.
This way you can define a bootcmd which downloads an Autoscript which in its turn programs the linux kernel and the address. When everything is finished, then the etherent address should be programmed with its real value.
So you need to define other environment variables anyway? Why can't you patch in a default ethernet address at the same time?
To avoid problems, the linux kernel should not be bootable if the kernel address is this "special" address.
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
[re-adding mailing lists to Cc]
On Mon, 29 Oct 2007 11:21:25 +0100 "Ulf Samuelsson" ulf@atmel.com wrote:
Haavard, For production use, you want to be able to set up a default address.
I don't think this is necessary in our production setup at least.
All production PCs would have a dedicated Ethernet board, with a predetemined IP address. Nothing but the production PC and the board under production is connected to this Ethernet. Thus there is not a problem to have a fixed ethernet address on the AVR32 board.
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.
Not if you do the check I propose at the end.
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.
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.
This way you can define a bootcmd which downloads an Autoscript which in its turn programs the linux kernel and the address. When everything is finished, then the etherent address should be programmed with its real value.
So you need to define other environment variables anyway? Why can't you patch in a default ethernet address at the same time?
Because I want to download the setting over Ethernet, and I cannot get access to the "serverip", without an Ethernet address.
To avoid problems, the linux kernel should not be bootable if the kernel address is this "special" address.
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.
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.
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.
Best Regards Ulf Samuelsson
On Mon, 29 Oct 2007 12:45:54 +0100 "Ulf Samuelsson" ulf@atmel.com wrote:
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.
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
On Mon, 29 Oct 2007 12:45:54 +0100 "Ulf Samuelsson" ulf@atmel.com wrote:
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.
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.
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@atmel.com
On Mon, 29 Oct 2007 16:29:35 +0100 "Ulf Samuelsson" ulf@atmel.com wrote:
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.
Ok. I think I understand. You don't want the CONFIG_ETHADDR definitions to go away altogether. Right?
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.
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.
It is important, to solve the problem with duplicate ethernet addresses.
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
On Tue, 30 Oct 2007 08:53:40 -0400 "Robin Cutshaw" robin@interlabs.com wrote:
Does Atmel not have an Ethernet vendor allocation?
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 ;-)
Ideally, a unique MAC would be included on a sticker on each board. This would provide something for each developer to use.
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_PH... http://www.avrfreaks.net/wiki/index.php/Documentation:STK1000/Ethernet_PHY_a...
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?
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
On Tue, Oct 30, 2007 at 08:53:40AM -0400, Robin Cutshaw wrote:
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?
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:
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?
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.
On Tue, 30 Oct 2007 20:13:41 +0100 Ulf Samuelsson ulf@atmel.com wrote:
I have long proposed that we deliver development kits with preprogrammed Ethernet addresses, with little success.
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? ;-)
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.
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:
On Tue, 30 Oct 2007 20:13:41 +0100 Ulf Samuelsson ulf@atmel.com wrote:
I have long proposed that we deliver development kits with preprogrammed Ethernet addresses, with little success.
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? ;-)
Won't claim that, since I only proposed that to the AT91 team, which still delivers without ethernet address.
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.
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
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.
On Mon, 29 Oct 2007 12:45:54 +0100 "Ulf Samuelsson" ulf@atmel.com wrote:
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.
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.
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@atmel.com
participants (4)
-
Haavard Skinnemoen -
Robin Cutshaw -
Scott Wood -
Ulf Samuelsson