[U-Boot] serial atag tag in devicetree ?

[Paul Kocialkowski]

Le jeudi 26 mars 2015 à 23:30 -0500, Rob Herring a écrit :
> On Thu, Mar 26, 2015 at 4:11 AM, Paul Kocialkowski <contact at paulk.fr> wrote:
> > Le jeudi 26 mars 2015 à 09:53 +0100, Hans de Goede a écrit :
> >> Hi,
> >>
> >> On 25-03-15 23:35, Paul Kocialkowski wrote:
> >> > Le mardi 24 mars 2015 à 09:01 +0100, Hans de Goede a écrit :
> >> >> Hi,
> >> >>
> >> >> On 24-03-15 00:12, Rob Herring wrote:
> >> >>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede at redhat.com> wrote:
> >> >>>> Hi,
> >> >>>>
> >> >>>>
> >> >>>> On 22-03-15 22:01, Rob Herring wrote:
> >> >>
> >> >> <snip>
> >> >>
> >> >>>>> There is already "serial-number" (a string) which exists for
> >> >>>>> OpenFirmware. Also, "copyright" corresponds to vendor/manufacturer
> >> >>>>> string. Both of these are supported by lshw already.
> >> >>>>
> >> >>>>
> >> >>>> Ok, so if I understand you correctly then you're saying that we
> >> >>>> should set a "serial-number" string property at the dt root level
> >> >>>> and that this may contain pretty much anything, e.g. in the
> >> >>>> sunxi case the full 128 bit SID in hex.
> >> >>>
> >> >>> Right.
> >> >>>
> >> >>>> Is the use of the "serial-number" string property already documented
> >> >>>> somewhere? If not I'll submit a kernel patch to document it.
> >> >>>
> >> >>> Not that I'm aware of. It is something that predates our documentation
> >> >>> requirements. It could be in OpenFirmware specs. Documenting it in the
> >> >>> DT bindings does not hurt.
> >> >>
> >> >> Ok.
> >> >>
> >> >>>> And for older kernels we should not set any serial atag (u-boot
> >> >>>> always sets it, so this leaves it at 0) and old kernel users are
> >> >>>> out of luck wrt getting to the serial ?
> >> >>>
> >> >>> If there is sufficient reason to support this on old kernels you could.
> >> >>
> >> >> One problem with supporting this for older kernels is that if a non 0
> >> >> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
> >> >> should really show the same number in /proc/cpuinfo which means adding
> >> >> code to the kernel to get the devicetree "serial-number" string property
> >> >> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
> >> >> but given that the "serial-number" string could be hex or decimal or
> >> >> what ever and > 64 bits that will likely require a platform specific
> >> >> solution. All doable, but the question then becomes is this worth the
> >> >> effort ?
> >> >
> >> > After investigating a bit more, I found out that the USB serial number
> >> > is expected to be a string of 32 bytes, so a 128 bit numeric serial
> >> > doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
> >> > so there is no room left for the terminating null byte), hence it makes
> >> > sense to keep a 64 bit limitation for the serial number, if users are
> >> > going to rely on it as USB serial string. Moreover, it seems that
> >> > Android devices are mostly used 64 bit numbers for serial numbers/
> >> >
> >> > I was initially going to suggest that we set it in stone that serial
> >> > must be 64 numeric bits (as it was in the ATAGs days) and that
> >> > bootloaders would pass it that way to the kernel through device tree
> >> > (with two 32 bits numeric integers), but Hans talked me out of it.
> >> > I just want to expose the situation (especially the USB and Android
> >> > thing) here to double-check that everyone still is convinced that a
> >> > string approach in device tree is best (which is fine with me).
> >>
> >> There are already existing users of the serial-number property in devicetree,
> >> and these already use a free-format string, so AFAICT we have no choice
> >> but to do the same as the existing users.
> >>
> >> But Rob is the expert here, so lets see what Rob has to say.
> >>
> >> > This way, users that still want to use the serial passed through device
> >> > tree as a USB serial number will have to use a string of 32 bits,
> >> > including the null terminating byte (which is what I'll suggest for
> >> > sunxi by using only 64 bits for the serial number).
> >> >
> >> > Also, I suggest that we show that serial-number string as-is in cpuinfo
> >> > as well
> >>
> >> We cannot do that because we must guarantee that the serial shown
> >> in cpu info is a 64 bits / 16 hex values (0 padded) number, anything
> >> else would break the kernel <-> userspace API and potentially break
> >> userspace apps. So we must do the devicetree -> serialnumber low/high
> >> -> /proc/cpinfo version to guarantee that this format does not change.
> >>
> >> And as discussed before if you want a non 0 serial in cpuinfo then
> >> the devicetree -> serialnumber low/high should be done in sunxi
> >> specific kernel code, as on sunxi we will know that the string in
> >> devicetree will be a hex value, but we've no such guarantee for
> >> other platforms, so we cannot simply have a generic function to
> >> populate erialnumber low/high from the devicetree serial-number
> >> string.
> >>
> >>  > and instead make a string out of the serial ATAG in the kernel
> >> > prior to showing it in cpuinfo (as opposed to translating the string
> >> > coming from device tree to a numeric value that cpuinfo will end up
> >> > showing as a string at the end of the day). Thus, the serial number
> >> > coming from device tree will still be shown in cpuinfo as well and no
> >> > ABI gets broken.
> >>
> >> You're forgetting the userspace <-> kernel ABI here, the serial line
> >> in /proc/cpuinfo is not a free form string it is a 64 bit int shown
> >> as 0 padded hex, and we cannot change that as changing that would be
> >> an ABI break.
> >
> > IMHO this really is all about interpretation. If you consider that the
> > serial is already a *string* and not a hex-representation of a number
> > (which it is when using ATAGs, but has no reason to be in general), then
> > my suggestion will introduce no ABI break.
> >
> > Generally speaking, I found no documentation that indicates that the
> > serial has to be in that format. It just happens to be the case when
> > using ATAGs.
> >
> > Also, I found an email from Rob suggesting he would be fine with wiring
> > the dts serial-number string to cpuinfo:
> > http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02975.html
> >
> > I think it's the most flexible solution and we can think of it as an
> > extension of the current scheme: the serial string will no longer be
> > limited to a hex representation of a number but can become any string.
> >
> > Now I would appreciate it if Rob could weigh-in and state whether he
> > changed his mind on this or not.
> 
> The only ABI is on platforms that used ATAGS as any DT only platform
> has so far had a serial# in cpuinfo of 16 0's. With a variable length
> string we can still have a fixed 16 char hex serial number that is
> compatible with ATAGS. I can't imagine that we have userspace that
> cares about the length and yet doesn't care the value is always 0's
> since converting to DT. As long as we keep 16 0's as the default I
> don't see an issue with allowing other lengths.
> 
> It is only an ABI if someone notices and if we find an ABI issue later
> we can always fix it.

Alright then, I think that all makes sense. I have a first proposal in
that direction ready then.

Russell, I'll just wait for your ack and start sending this to both the
U-Boot and ARM kernel lists.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150327/9dd67b13/attachment.sig>