[RFC] Serial number on sunxi devices

[Paul Kocialkowski]

As far as I know, there is currently no mechanism in place to give each
device a unique serial number, that would be shown in
e.g. /proc/cpuinfo. This can seem not very useful, but it would be
nice to have that for USB gadget drivers that make use of it (e.g. ADB on
Android, fastboot, etc). This would allow having multiple sunxi devices
connected at the same time.

Normally, the serial number has to be figured out by the bootloader and
passed to the kernel through ATAGs. In U-Boot, it is defined using
get_board_serial, that is not yet implemented on sunxi.

I'm interested in figuring out the best way to do this. As far as I can
see, Allwinner SoCs have some e-fuses, known as SID (Security ID):
http://linux-sunxi.org/SID_Register_Guide for which Oliver has written a
mainline Linux driver. Those should have device-specific values, except
when they are set to 0.

Do you have any better idea to do this, or is there some reference that
I am missing?

Thanks,

--
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/

[Hans de Goede]

Hi,

On 15-03-15 22:38, Paul Kocialkowski wrote:
> As far as I know, there is currently no mechanism in place to give each
> device a unique serial number, that would be shown in
> e.g. /proc/cpuinfo. This can seem not very useful, but it would be
> nice to have that for USB gadget drivers that make use of it (e.g. ADB on
> Android, fastboot, etc). This would allow having multiple sunxi devices
> connected at the same time.
>
> Normally, the serial number has to be figured out by the bootloader and
> passed to the kernel through ATAGs. In U-Boot, it is defined using
> get_board_serial, that is not yet implemented on sunxi.
>
> I'm interested in figuring out the best way to do this. As far as I can
> see, Allwinner SoCs have some e-fuses, known as SID (Security ID):
> http://linux-sunxi.org/SID_Register_Guide for which Oliver has written a
> mainline Linux driver. Those should have device-specific values, except
> when they are set to 0.
>
> Do you have any better idea to do this, or is there some reference that
> I am missing?

AFAIK the only way to do a serial number on sunxi devices is using the SID,
note that Oliver's driver will only work on A10, A13 and A20, with the
A31, A23 and others the SID is burned into the pmic rather then the SoC
itself, but it should be easy to implement get_board_serial() in u-boot
as we already have a sunxi_get_sid() helper to do that in a SoC
independent way (this is currently used to set the ethernet MAC address).

Note that sunxi_get_sid() can fail, so you need to error check it,
and currently it will happily return an all 0 SID, you should probably
make it return an error in that case, as that check really belongs
inside sunxi_get_sid().

Regards,

Hans

[Jens Lucius]

Am Sonntag, 15. März 2015 22:39:05 UTC+1 schrieb con...@paulk.fr:

Do you have any better idea to do this, or is there some reference that
I am missing?

Currently the MAC address in U-Boot is generated that way, see:

http://lists.denx.de/pipermail/u-boot/2014-June/181879.html

[Olliver Schinagl]

Hey all,

On 16-03-15 09:12, Hans de Goede wrote:
> Hi,
>
> On 15-03-15 22:38, Paul Kocialkowski wrote:
>> As far as I know, there is currently no mechanism in place to give each
>> device a unique serial number, that would be shown in
>> e.g. /proc/cpuinfo. This can seem not very useful, but it would be
>> nice to have that for USB gadget drivers that make use of it (e.g.
>> ADB on
>> Android, fastboot, etc). This would allow having multiple sunxi devices
>> connected at the same time.
>>
>> Normally, the serial number has to be figured out by the bootloader and
>> passed to the kernel through ATAGs. In U-Boot, it is defined using
>> get_board_serial, that is not yet implemented on sunxi.
>>
>> I'm interested in figuring out the best way to do this. As far as I can
>> see, Allwinner SoCs have some e-fuses, known as SID (Security ID):
>> http://linux-sunxi.org/SID_Register_Guide for which Oliver has written a
>> mainline Linux driver. Those should have device-specific values, except
>> when they are set to 0.
>>
>> Do you have any better idea to do this, or is there some reference that
>> I am missing?
>
> AFAIK the only way to do a serial number on sunxi devices is using the
> SID,
> note that Oliver's driver will only work on A10, A13 and A20, with the
> A31, A23 and others the SID is burned into the pmic rather then the SoC

I vaguely recall that the A31 had a SID aswell according to its
datasheet, I'll go over the datasheets for a23 and a33 to confirm on
those, and will look at the a31/a31s/a80's also.

> itself, but it should be easy to implement get_board_serial() in u-boot
> as we already have a sunxi_get_sid() helper to do that in a SoC
> independent way (this is currently used to set the ethernet MAC address).

I'l slowly (in a few weeks time) working on a patch to get the mac from
the EEPROM for the olinuxino's, though i think we need to upgrade the
i2c driver a bit (multiple adapter support).

>
> Note that sunxi_get_sid() can fail, so you need to error check it,
> and currently it will happily return an all 0 SID, you should probably
> make it return an error in that case, as that check really belongs
> inside sunxi_get_sid().

The big problem with the sunxi-sid, is that it can be often blank :S
very annoying. Also, which part of the SID do we want in /proc/cpuinfo?
The one is bigger then the other, though looking at
http://linux-sunxi.org/SID_Register_Guide there's a lot of
non-uniqueness that can be ignored (chip ID (1623 for example).

Olliver
>
> Regards,
>
> Hans

[Hans de Goede]

Hi,

Yes it has a SID entry in its memory map, that is probably a copy and paste error though,
the real SID is stored in the axp221, not in the A31 itself, reading from the
addresses in the memory map always returns 0 on all A31-s.

> I'll go over the datasheets for a23 and a33 to confirm on those, and will look at the a31/a31s/a80's also.
>> itself, but it should be easy to implement get_board_serial() in u-boot
>> as we already have a sunxi_get_sid() helper to do that in a SoC
>> independent way (this is currently used to set the ethernet MAC address).
> I'l slowly (in a few weeks time) working on a patch to get the mac from the EEPROM for the olinuxino's, though i think we need to upgrade the i2c driver a bit (multiple adapter support).

Hmm, not sure if that is really useful, 2 questions:

1) Is there anything wrong with the current SID based approach on the
olinuxino-s, AFAIK all olinuxino's have non pre-production SOCs and so
have proper SID-s and thus a proper MAC set.

2) Are the eeproms prepolulated on ALL olinuxino-s ? If they are not
populated from the factory, I see little added value and I think I may
end up nacking any patches for this, but first lets hear your arguments :)

>> Note that sunxi_get_sid() can fail, so you need to error check it,
>> and currently it will happily return an all 0 SID, you should probably
>> make it return an error in that case, as that check really belongs
>> inside sunxi_get_sid().
> The big problem with the sunxi-sid, is that it can be often blank :S very annoying. Also, which part of the SID do we want in /proc/cpuinfo? The one is bigger then the other, though looking at http://linux-sunxi.org/SID_Register_Guide there's a lot of non-uniqueness that can be ignored (chip ID (1623 for example).

Often? In my experience it is empty on cubieboard2 and some early
mele A1000 models, and that is it.

Regards,

Hans

[Hans de Goede]

Hi,

Oops, missed a bit to reply to, see below:

On 16-03-15 10:04, Olliver Schinagl wrote:

> Also, which part of the SID do we want in /proc/cpuinfo? The one is bigger then the other, though looking at http://linux-sunxi.org/SID_Register_Guide there's a lot of non-uniqueness that can be ignored (chip ID (1623 for example).

I would say all of it, serial numbers often also contain
a fixed bit with model info, for /proc/cpuinfo that is fine.


Regards,

Hans

[Olliver Schinagl]

Hey Hans,

Ah, okay, I never tested it on those as i don't have hardware. I do have
an A33 based device, so i'll probe /dev/mem to see if we have a SID
there. I guess some a23 device owners can probe their sid's aswell then.

>
> > I'll go over the datasheets for a23 and a33 to confirm on those, and
> will look at the a31/a31s/a80's also.
>>> itself, but it should be easy to implement get_board_serial() in u-boot
>>> as we already have a sunxi_get_sid() helper to do that in a SoC
>>> independent way (this is currently used to set the ethernet MAC
>>> address).
>> I'l slowly (in a few weeks time) working on a patch to get the mac
>> from the EEPROM for the olinuxino's, though i think we need to
>> upgrade the i2c driver a bit (multiple adapter support).
>
> Hmm, not sure if that is really useful, 2 questions:
>
> 1) Is there anything wrong with the current SID based approach on the
> olinuxino-s, AFAIK all olinuxino's have non pre-production SOCs and so
> have proper SID-s and thus a proper MAC set.

That's still an "illegal", e.g. it is a mac address based on the
'internal development'. We have a mac prefix and want to base our mac
partially on our serial numbers (and it has to be _guaranteed_ unique
etc). So we will be storing our serial numbers in the eerpom anyway and
be basing the mac on that anyhow.

>
> 2) Are the eeproms prepolulated on ALL olinuxino-s ? If they are not
> populated from the factory, I see little added value and I think I may
> end up nacking any patches for this, but first lets hear your
> arguments :)

We will be using Lime2's which all have them, all lime's have them.
Obviously there will be a check, to check if there is a valid eeprom
with valid data, but for our product it will be required.

Since we will be flashing a generic image (all devices equal) and thus
need to have the 'uniqueness' of a device in the eeprom

>
>>> Note that sunxi_get_sid() can fail, so you need to error check it,
>>> and currently it will happily return an all 0 SID, you should probably
>>> make it return an error in that case, as that check really belongs
>>> inside sunxi_get_sid().
>> The big problem with the sunxi-sid, is that it can be often blank :S
>> very annoying. Also, which part of the SID do we want in
>> /proc/cpuinfo? The one is bigger then the other, though looking at
>> http://linux-sunxi.org/SID_Register_Guide there's a lot of
>> non-uniqueness that can be ignored (chip ID (1623 for example).
>
> Often? In my experience it is empty on cubieboard2 and some early
> mele A1000 models, and that is it.

I should have said 'sometimes' :) My bad. It is not yet guaranteed to be
unique unfortunately.
>
> Regards,
>
> Hans

[Hans de Goede]

Hi,

Right, it is not an assigned MAC, that is true.

>> 2) Are the eeproms prepolulated on ALL olinuxino-s ? If they are not
>> populated from the factory, I see little added value and I think I may
>> end up nacking any patches for this, but first lets hear your arguments :)
> We will be using Lime2's which all have them, all lime's have them. Obviously there will be a check, to check if there is a valid eeprom with valid data, but for our product it will be required.
>
> Since we will be flashing a generic image (all devices equal) and thus need to have the 'uniqueness' of a device in the eeprom

I see, yes using olinuxino's embedded in factory devices is a valid reason,
so I will be happy to take patches for reading the MAC from the eeprom,
we will need to do some tests to make sure that we only do this on
valid eeproms though, I think it would be good to add a checksum +
all 00 test, or a crc check, note a checksum is fine by me, but if
there is ready to use crc code somewhere in u-boot that works for me too.

Regards,

Hans

[Olliver Schinagl]

Hey Hans,

Yeah, absolutly. We probably want have a little very quick brainstorm as
to how and what we want to store. In our case, I think we probably want
the eeprom it its full form stored at the beginning of the eeprom, some
checksum/crc, followed by a few reserved bytes maybe. After that a
serial number. My first thought was to store the serial number in the
eeprom and create a mac from that, but now, that sounds like a bad idea.
Optionally, it could be possible to store the mac-prefix and serial
number seperatly, and the LSB is used for the second half of the mac? I
don't know yet, just throwing up some idea's.

The biggest problem right now is to get the 2nd and 3rd i2c adapters
working, as the current marvell driver only supports single I2C devices.
But I hope to send patches for that in a few weeks/couple of months.

Olliver
>
> Regards,
>
> Hans

[Hans de Goede]

Hi,

On 16-03-15 11:16, Olliver Schinagl wrote:
> Hey Hans,

<snip>

>>> We will be using Lime2's which all have them, all lime's have them. Obviously there will be a check, to check if there is a valid eeprom with valid data, but for our product it will be required.
>>>
>>> Since we will be flashing a generic image (all devices equal) and thus need to have the 'uniqueness' of a device in the eeprom
>>
>> I see, yes using olinuxino's embedded in factory devices is a valid reason,
>> so I will be happy to take patches for reading the MAC from the eeprom,
>> we will need to do some tests to make sure that we only do this on
>> valid eeproms though, I think it would be good to add a checksum +
>> all 00 test, or a crc check, note a checksum is fine by me, but if
>> there is ready to use crc code somewhere in u-boot that works for me too.
> Yeah, absolutly. We probably want have a little very quick brainstorm as to how and what we want to store. In our case, I think we probably want the eeprom it its full form stored at the beginning of the eeprom, some checksum/crc, followed by a few reserved bytes maybe. After that a serial number. My first thought was to store the serial number in the eeprom and create a mac from that, but now, that sounds like a bad idea. Optionally, it could be possible to store the mac-prefix and serial number seperatly, and the LSB is used for the second half of the mac? I don't know yet, just throwing up
> some idea's.
>
> The biggest problem right now is to get the 2nd and 3rd i2c adapters working, as the current marvell driver only supports single I2C devices. But I hope to send patches for that in a few weeks/couple of months.

Ok, note if you work on this please just convert the driver to the
driver model, rather then using the old multiple i2c adapter stuff.

Regards,

Hans

[Olliver Schinagl]

Hey,

Noted ;)

> Regards,
>
> Hans

[Olliver Schinagl]

Hey,

but isn't the serial in /proc/cpuinfo limited to a certain number of
bits? I investigated if we could simply 'dump' the sid into the cpuinfo
structure in the 3.4 days, but there was not bits available to print
everything. If memory serves me well that is.

Olliver
>
>
> Regards,
>
> Hans

[Hans de Goede]

Hi,

On 16-03-15 13:31, Olliver Schinagl wrote:
> Hey,
>
> On 16-03-15 10:52, Hans de Goede wrote:
>> Hi,
>>
>> Oops, missed a bit to reply to, see below:
>> On 16-03-15 10:04, Olliver Schinagl wrote:
>>
>>> Also, which part of the SID do we want in /proc/cpuinfo? The one is bigger then the other, though looking at http://linux-sunxi.org/SID_Register_Guide there's a lot of non-uniqueness that can be ignored (chip ID (1623 for example).
>>
>> I would say all of it, serial numbers often also contain
>> a fixed bit with model info, for /proc/cpuinfo that is fine.
> but isn't the serial in /proc/cpuinfo limited to a certain number of bits?

Could be, whomever writes patches for this needs to look into that, and
if necessary truncate the SID somehow.

Regards,

Hans

[Stefan Monnier]

> if necessary truncate the SID somehow.

Or hash it,


Stefan

[Paul Kocialkowski]

As far as I can see, the SID has (at least) 4 32bit words. It seems that
there is more on e.g. A20 but those are not always populated, so I think
it's safer to go with those 4 words and somewhat use them to come up
with a serial.

The Linux kernel serial ATAG (shown in cpuinfo) is only 2 32bit words,
so we will have to get rid of half of the (usable) SID.

The first half seems prefixed depending on the SoC platform, which
reduces the possible number of different combinations (but that's
probably not really a problem) and as Hans mentioned, it isn't unusual
to have a common part depending on the model. I suggest going with it.

What do you think about it?

[Paul Kocialkowski]

Le lundi 16 mars 2015 à 17:50 -0400, Stefan Monnier a écrit :
> > if necessary truncate the SID somehow.
> Or hash it,

For some reason, I kinda like the idea of having the serial match
something directly readable in the hardware instead of something that
just looks about random. Furthermore, having a common part of the serial
among devices using the same Allwinner SoC gives it some kind of
identity.

My two cents,

[Paul Kocialkowski]

Why exactly is it a problem if the SID is 0 here? I don't see a big
difference between providing a zero serial and not providing any serial
at all (in any case, Linux will keep it at 0 when none is provided).

U-Boot doesn't check the return code of setup_serial_tag either and
isn't designed to not include the tag if it somewhat failed to grab the
serial number.

Hence my point is, let's not bother whether it's zero or not: it will
just improve the situation on the vast majority of devices that have (at
least) the first 4 32bit words of the SID populated and leave others
with a zero serial, as it was until now.

[Iain Paton]

On 16/03/15 09:51, Hans de Goede wrote:

> 2) Are the eeproms prepolulated on ALL olinuxino-s ? If they are not
> populated from the factory, I see little added value and I think I may
> end up nacking any patches for this, but first lets hear your arguments :)

The eeproms are physically present on all boards as far as I can tell,
however on every olinuxino I have, they are blank from the factory (i.e.
content of every byte is 0xFF).

If Olimex have defined a format for the contents of the eeprom, I've
not been able to find it.

So while I have no objection to using the eeprom for something like this,
can we at least try to come up with something that:

1) Is optional.
2) Is disabled by default.
3) Allows for configurable format
4) Allows for configurable i2c bus and address (i.e. so you can add an
eeprom to a cb2)

That way we don't stomp all over existing users while allowing people who
want the feature to easily enable it.

It would obviously also be good if when the feature is disabled, or we
detect that the eeprom contains invalid data, then we fall back to using
the current SID based method for generating the MAC.


There's one obvious question for me with any scheme like this. Olliver
might want a 10 character serial number, I might want 12, someone else
wants 15. How do we handle that?

Would have been easier if Olimex put a unique serial number in the
eeprom, but as it's already too late for that we shouldn't put ourselves
in a corner that results in everyone using the same set of serial numbers.

Is there any chance of using something in DT to define the format?

[Olliver Schinagl]

Hey Iain,

On 17-03-15 01:38, Iain Paton wrote:
> On 16/03/15 09:51, Hans de Goede wrote:
>
>> 2) Are the eeproms prepolulated on ALL olinuxino-s ? If they are not
>> populated from the factory, I see little added value and I think I may
>> end up nacking any patches for this, but first lets hear your arguments :)
> The eeproms are physically present on all boards as far as I can tell,
> however on every olinuxino I have, they are blank from the factory (i.e.
> content of every byte is 0xFF).

Yeah they are all blank, with good purpose, it's for the user to define
what to do with it ;)

> If Olimex have defined a format for the contents of the eeprom, I've
> not been able to find it.
>
> So while I have no objection to using the eeprom for something like this,
> can we at least try to come up with something that:
>
> 1) Is optional.
> 2) Is disabled by default.
> 3) Allows for configurable format
> 4) Allows for configurable i2c bus and address (i.e. so you can add an
> eeprom to a cb2)

That's almost so obvious it may be overlooked, but of naturally. I think
i put it in one of the previous e-mails, but that's why you want a
crc/checksum, if it's valid, use it, if not don't. Making it
configurable is also one of those obvious things of course.

As for 3, not sure how feasible that is. Where do you store the storage
definition? First few bytes defines the storage, then the actual
storage? While possible, it adds a lot of overhead. But as always,
everything is up for discussion.

>
> That way we don't stomp all over existing users while allowing people who
> want the feature to easily enable it.

of course :)

>
> It would obviously also be good if when the feature is disabled, or we
> detect that the eeprom contains invalid data, then we fall back to using
> the current SID based method for generating the MAC.
>
>
> There's one obvious question for me with any scheme like this. Olliver
> might want a 10 character serial number, I might want 12, someone else
> wants 15. How do we handle that?

We can prefix the serial with a length byte :)

>
> Would have been easier if Olimex put a unique serial number in the
> eeprom, but as it's already too late for that we shouldn't put ourselves
> in a corner that results in everyone using the same set of serial numbers.

Easier, yes, but not useful at all. On our end, for example, we want to
have our own unique serial numbering scheme, unrelated to Olimex's
numbering. Now we may use olimex boards, in the future, we may decide to
build our own boards, for example.

>
> Is there any chance of using something in DT to define the format?
>

Good question ...

[Olliver Schinagl]

Hey Paul,

Yeah I agree with you there, To bad we don't know the meaning of the SID
fields, so we can determine which bytes are more important than others ;)
>

[Paul Kocialkowski]

Each user manual gives no more information than "root key", but the A20
user manual also shows more fields (boot key, sjtag key, config & vendor
key, etc). Apparently, that root key can be used by the SS subsystem
directly. That's about all I could find about it. It looks like a public
key pre-populated by Allwinner, but then I don't see why it would be
different across devices, or at least devices from the same
manufacturer.

[Hans de Goede]

Hi,

On 16-03-15 23:02, Paul Kocialkowski wrote:
> Le lundi 16 mars 2015 à 14:45 +0100, Hans de Goede a écrit :
>> Hi,
>>
>> On 16-03-15 13:31, Olliver Schinagl wrote:
>>> Hey,
>>>
>>> On 16-03-15 10:52, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> Oops, missed a bit to reply to, see below:
>>>> On 16-03-15 10:04, Olliver Schinagl wrote:
>>>>
>>>>> Also, which part of the SID do we want in /proc/cpuinfo? The one is bigger then the other, though looking at http://linux-sunxi.org/SID_Register_Guide there's a lot of non-uniqueness that can be ignored (chip ID (1623 for example).
>>>>
>>>> I would say all of it, serial numbers often also contain
>>>> a fixed bit with model info, for /proc/cpuinfo that is fine.
>>> but isn't the serial in /proc/cpuinfo limited to a certain number of bits?
>>
>> Could be, whomever writes patches for this needs to look into that, and
>> if necessary truncate the SID somehow.
>
> As far as I can see, the SID has (at least) 4 32bit words. It seems that
> there is more on e.g. A20 but those are not always populated, so I think
> it's safer to go with those 4 words and somewhat use them to come up
> with a serial.
>
> The Linux kernel serial ATAG (shown in cpuinfo) is only 2 32bit words,
> so we will have to get rid of half of the (usable) SID.

AFAIK ATAG-s are pretty much dead when using a devicetree enabled platform,
how does this work in the devicetree world ?

> The first half seems prefixed depending on the SoC platform, which
> reduces the possible number of different combinations (but that's
> probably not really a problem) and as Hans mentioned, it isn't unusual
> to have a common part depending on the model. I suggest going with it.

Actually if we need to truncate I think it would be good to have as
much random bits in there as possible, we've a collection of SID-s here:

http://linux-sunxi.org/SID_Register_Guide

As you can see the last 32bit word is the most random one, for MAC
addresses we use the least significant byte of the first 32bit word
(which seems to be random in that table, but seems to be a fixed
value on later Axx SOCs) combined with the entire last 32 bit
word. So for the serial we could use the first and last 32 bit words,
this will give us the model prefix, instantly showing the soc model
in the serial + 32 unique bits per board.

Regards,

Hans

[Paul Kocialkowski]

You're right, ATAGs are not used anymore when devicetree is there.
As far as I could see, the kernel command line is provided through the
"chosen" dt node, but the serial number, as well as revision, are not
passed to the kernel at all this way, so they always remain blank.

I think it would be worth providing the serial and revision back through
the dt logic, so I'll perhaps try to come up with something for both
U-Boot and Linux. However, serial and revision are specific to ARM and
the dt logic in the kernel is common (at least the part that handles
cmdline), so I have yet to figure out how to get it right.

In the meantime, it still makes sense to provide it through ATAGs for
the 3.4 kernel and to have it for internal use in U-Boot (e.g. for USB
Download gadgets such as fastboot).

> > The first half seems prefixed depending on the SoC platform, which
> > reduces the possible number of different combinations (but that's
> > probably not really a problem) and as Hans mentioned, it isn't unusual
> > to have a common part depending on the model. I suggest going with it.
>
> Actually if we need to truncate I think it would be good to have as
> much random bits in there as possible, we've a collection of SID-s here:
>
> http://linux-sunxi.org/SID_Register_Guide
>
> As you can see the last 32bit word is the most random one, for MAC
> addresses we use the least significant byte of the first 32bit word
> (which seems to be random in that table, but seems to be a fixed
> value on later Axx SOCs) combined with the entire last 32 bit
> word. So for the serial we could use the first and last 32 bit words,
> this will give us the model prefix, instantly showing the soc model
> in the serial + 32 unique bits per board.

That looks like a fair bargain to me. I was starting to worry that some
of the first 64 bit words from the SID look too much alike on some
devices such as the Cubietruck.

I'll try to come up with a patch for this soon (tomorrow if possible).

Thanks for your input!

[Henrik Nordström]

mån 2015-03-16 klockan 11:13 +0100 skrev Hans de Goede:

> I see, yes using olinuxino's embedded in factory devices is a valid reason,
> so I will be happy to take patches for reading the MAC from the eeprom,
> we will need to do some tests to make sure that we only do this on
> valid eeproms though, I think it would be good to add a checksum +
> all 00 test, or a crc check, note a checksum is fine by me, but if
> there is ready to use crc code somewhere in u-boot that works for me too.

The MAC eeproms I have seen do not have any CRC. Just the raw MAC in a
dedicated page. Better to follow common practice in how MAC is stored.
There is room for additional data in other pages as well.

Regards
Henrik

[Olliver Schinagl]

Hey Henrik,

I'm all for common methods, but you are suggesting to use a single
dedicated page purely for the MAC address? Where is it defined which
page that is? And what about using the subsequent page for stuff like a
crc/checksum and verify the mac against that? It would yield in an easy
way to verify if there is actually a MAC stored there or not.

Olliver
>
> Regards
> Henrik
>

[Henrik Nordström]

ons 2015-03-18 klockan 08:55 +0100 skrev Olliver Schinagl:
> I'm all for common methods, but you are suggesting to use a single
> dedicated page purely for the MAC address? Where is it defined which
> page that is? And what about using the subsequent page for stuff like a
> crc/checksum and verify the mac against that? It would yield in an easy
> way to verify if there is actually a MAC stored there or not.

What I am saying is that unless you are doing a very high volume then
the most practical approach to get a real MAC is to buy them as
preprogrammed eeproms, for example Microchip 24AA02E48. There is no
checksum what so ever in these devices, only the MAC at a predefined
location (write protected). There is also some small amount of
unprotected space for custom data if needed (can often be protected
after programming).

Regards
Henrik

[Irgendeiner]

Just to get the technical aspects cleared:

As far as I believe to know, each manufacturer of products with Ethernet
interfaces is obliged to apply for MAC addresses for the products he puts
on the market. If he does not follow that rule then it is somehow a rouge
product?

Most often these addresses are stored in an eeprom directly connected to
the interface chip, but other locations have been found in the wild.

I think that for the MAC used, sunxi must make sure that on all supported
hardware the MAC planned by the board manufacturer will be used as default.

If a board manufacturer somewhere permanently stores a serial number,
sunxi should try to display that number. If no such number is present, it
seems to be a good idea to show the MAC number as a serial number.

If the number displayed is somehow 'wrong' imho this does not really harm?

I don't understand why checksums and other nasty problems come to play a
role?

I.Irgendeiner

[Henrik Nordström]

ons 2015-03-18 klockan 10:16 +0100 skrev Irgendeiner:

> I think that for the MAC used, sunxi must make sure that on all supported
> hardware the MAC planned by the board manufacturer will be used as default.

Problem with most boards is that there is no MAC, and if there is one
then it's not in a by any means standardized storage, personalized in
the NAND bootloader arguments which is easily lost when dealing with
other software.

So far I only know of some Olimex boards having an eeprom specifically
for the MAC address, but not sure it actually is an MAC in there.

> I don't understand why checksums and other nasty problems come to play a
> role?

Not for MAC assignment, but general configuration data or integrity
validation purpose sure.

Regards
Henrik

[Tomas Novotny]

Hi,

Yes, this is exactly our case.
We have LIME with additional board with Microchip MCP79401. This is
RTC+EEPROM with preprogrammed (and somehow protected) MAC. That particular
EEPROM has only 64-bits without any checksum. I just trust that the MAC is
stored in I2C EEPROM at address X in a register Y.
Best regards,

Tomas

> Regards
> Henrik

[Al Thomas]

> From: Henrik Nordström <hen...@henriknordstrom.net>

> To: linux...@googlegroups.com
> Sent: Wednesday, 18 March 2015, 10:17
> Subject: Re: [linux-sunxi] Re: [RFC] Serial number on sunxi devices

The MAC should have bit 0 of the first octet unset so it is unicast,

not multicast. Also if you are using a locally created MAC, not

universally allocated, then bit 1 of the same octet should be set.


For more details see:
http://linux-sunxi.org/Ethernet#Setting_the_MAC_address
http://www.denx.de/wiki/view/DULG/WhereCanIGetAValidMACAddress
Al

[Paul Kocialkowski]

Just sent a patch to the u-boot list and tested on the devices I had at
disposal (A13 and A20). I would appreciate it if someone could test on
devices that have the SID registers on the AXP.

In U-Boot, printenv shows:
serial#=1625428e04815f6a

When using U-Boot with USB in gadget mode and fastboot, I get (on the
host):
# fastboot devices
1625428e04815f6a fastboot

I only booted the sunxi-3.4 kernel on sun5i/A13 to test that the ATAG
went through, resulting in:
root@localhost:~# cat /proc/cpuinfo
Processor : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 1001.88
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc08
CPU revision : 2

Hardware : sun5i
Revision : 0000
Serial : 1625428e04815f6a

So everything looks good. The patch goes on top of the patches I
submitted a few days ago.

[sels...@gmail.com]

On 17/03/15 07:15, Olliver Schinagl wrote:
> Hey Iain,
>
> On 17-03-15 01:38, Iain Paton wrote:
>
>> The eeproms are physically present on all boards as far as I can tell,
>> however on every olinuxino I have, they are blank from the factory (i.e.
>> content of every byte is 0xFF).
>
> Yeah they are all blank, with good purpose, it's for the user to define
> what to do with it ;)

That's all good, up until we hard-code a format into u-boot or the kernel
at which point the user doesn't get to decide anymore.

>> 3) Allows for configurable format

> As for 3, not sure how feasible that is. Where do you store the storage
> definition? First few bytes defines the storage, then the actual
> storage? While possible, it adds a lot of overhead. But as always,
> everything is up for discussion.

Perhaps it could be something defined in a Kconfig entry? Compile time
configurable will probably be ok for most things.

> Easier, yes, but not useful at all. On our end, for example, we want to
> have our own unique serial numbering scheme, unrelated to Olimex's
> numbering. Now we may use olimex boards, in the future, we may decide to
> build our own boards, for example.

Exactly. I simply want something that, as far as possible, covers all of
those possibilities. Not something that only fits a single, use for a
single person, where the rest of us have to carry patches to make it useful
for us as well.