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