Le mardi 17 mars 2015 à 09:36 +0100, Hans de Goede a écrit :
> 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 ?

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!

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

-- 
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 linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to