Hey Hans,
On 16-03-15 11:13, Hans de Goede wrote:
Hi,
On 16-03-15 10:56, Olliver Schinagl wrote:
Hey Hans,
On 16-03-15 10:51, Hans de Goede wrote:
Hi,
On 16-03-15 10:04, Olliver Schinagl wrote:
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
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.
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.
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.
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
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
