[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[Haavard Skinnemoen]

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.

Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
---
 include/configs/atstk1002.h |   11 +++--------
 1 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/include/configs/atstk1002.h b/include/configs/atstk1002.h
index 1809fc5..b33e26f 100644
--- a/include/configs/atstk1002.h
+++ b/include/configs/atstk1002.h
@@ -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

[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[Haavard Skinnemoen]

[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

[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[Ulf Samuelsson]

> [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

[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[Haavard Skinnemoen]

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

[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[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.
> 

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

[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[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.
> 

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

[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[Haavard Skinnemoen]

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

[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[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?

Robin

[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[Haavard Skinnemoen]

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_PHY
http://www.avrfreaks.net/wiki/index.php/Documentation:STK1000/Ethernet_PHY_and_connectors

> 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

[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[Scott Wood]

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

[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[Ulf Samuelsson]

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.

-- 
Best Regards,
Ulf Samuelsson

[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[Ulf Samuelsson]

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.

-- 
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

[U-Boot-Users] [PATCH] ATSTK1002: Remove default ethernet addresses

[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? ;-)

> 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