[U-Boot] serial atag tag in devicetree ?

Hans de Goede hdegoede at redhat.com
Tue Mar 24 09:01:53 CET 2015


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 ?

Regards,

Hans


More information about the U-Boot mailing list