Re: Export firmware information to userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Hi,

On 21/06/18 14:44, Mark Rutland wrote:
> On Thu, Jun 21, 2018 at 02:27:28PM +0100, Carlo Caione wrote:
>> Hi,
>> this problem came up while I was trying to solve the problem: how do I
>> query the U-Boot version from userspace on an ARM platform so that I
>> can upgrade it when necessary.
>>
>> One possible solution (adopted also from ChromeOS IIRC) is basically to
>> export the firmware information into the DT. I think that this could be
>> a nice and elegant solution (the firmware itself is in charge to add
>> the information to the DTB before passing it down to the kernel).

That sounds like a nice solution (also see below), but I was wondering
if that is actually the right way. For some platforms there are multiple
ways to boot the firmware, for instance via some platform specific
USB-OTG interface, via SD card, eMMC or SPI flash.
Putting the *booted* U-Boot version in the DT would just expose the
currently used version, which is not really connected to what you might
want to upgrade: If you boot some version from SD card, that does not
tell you anything about the version in the SPI flash that you are going
to upgrade.

So you probably want a way to identify a U-Boot version by looking at
the storage it resides on. This seems more like a U-Boot problem, last
time I checked I couldn't find any generic way of doing that. The best
thing I could come up with was to scan the image for the U-Boot banner
string. That is pretty reliable on the SPL, because this image is much
smaller and the string to match is more specific: I did a memmem() for
"U-Boot SPL 20", which had only one hit in my case. But still this is a
bit dodgy.

So we might think about inserting some version field into the U-Boot
image, possibly with a magic and a checksum. Or we piggy back on the
.dtb embedded in an U-Boot image, and put the version into some node.
But this would not work if the .dtb comes from somewhere else (ATF or
separate storage).

>> Is this allowed by the DT specs? Is there already any bindings around
>> to carry this kind of information?
> 
> It's perfectly valid to come up with a device tree binding for U-Boot,
> which U-Boot could use to export information about itself to the kernel.

Mmh, would the /chosen node be the more natural location for that?
"The /chosen node does not represent a real device in the system but
describes parameters chosen or specified by the system firmware at run
time."
But anyway putting versioning information about the currently booted
firmware in the DT might be useful regardless of my above comment, as it
gives useful information for debugging.

Cheers,
Andre.

> For example, there's a binding for coreboot [1] which exposes firmware
> parameters in a memory area. So long as it's documented, that should be
> fine.
> 
> Thanks,
> Mark.
> 
> [1] Documentation/devicetree/bindings/firmware/coreboot.txt
> --
--
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



[Index of Archives]     [Device Tree]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Photos]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]

  Powered by Linux