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
