On Fri, Jun 22, 2018 at 4:09 AM, Carlo Caione <carlo.caione@xxxxxxxxx> wrote:
> On Fri, 2018-06-22 at 09:13 +1000, Stewart Smith wrote:
>> Olof Johansson <olof@xxxxxxxxx> writes:
>> > > Mmh, but a:
>> > > u-boot-version = "2018.07-rc2 (21 Jun 2018 - 12:21:46
>> > > +0100)";
>> > > would be fairly small as well, wouldn't it?
>> > > Or is there any other data we would want to advertise?
>> >
>> > That doesn't belong in chosen, but it'd be fine in something such
>> > as
>> > /firmware/u-boot/version
>>
>> We have something that looks a bit like that for OpenPower systems,
>> perhaps something common could be achieved?
>>
>> It looks something like this (key,value) = (component,version)
>>
>> ibm,firmware-versions {
>> version = "open-power-habanero-v1.14-45-g78d89280c3f9-
>> dirty";
>> skiboot = "5.4.0";
>> occ = "d7efe30";
>> linux = "4.4.32-openpower1";
>> };
>>
>> https://open-power.github.io/skiboot/doc/device-tree/ibm,firmware-ver
>> sions.html
>
> That's really good to encode the U-Boot version. Any other parameters
> that can be useful in userspace?
>
> It was already discussed that probably having the booting device would
> be really handy but I tried to think a way to detect the firmware
> booting device from U-Boot but it looks like it really is platform
> dependent and not always easy.
>
> The other problem is that sometimes we have SPL in a device and the
> second stage in a different device (i.e. on the rk3288 you can have SPL
> into the SPI and U-Boot into eMMC) so that is adding one more layer.
> Maybe we should have also something like "spl,$key"?
I think it's reaching a point where it might be easier to start
discussing with a draft binding proposal, but you can always add
spl-<attribute> versions if you need a "bl1-path" and a "bl2-path" or
something like that. It would of course be extra useful if they have
phandles to actual DT nodes instead of userspace having to resolve
that separately, but it might be challenging in some cases (especially
if, say, the SPL device isn't described in DT for some reason).
Keeping the total number of various ways these are enumerated and
described down would be useful for the userspace toolmakers, so
getting input from several platform maintainers on what makes sense on
their platform would be valuable.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
