On Thu, Jun 21, 2018 at 9:50 AM, Andre Przywara <andre.przywara@xxxxxxx> wrote: > 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 the binding can include a property that tells you where the firmware was booted from, so you can go read that device and see what version is stored there. Hopefully firmware itself can figure out where it was booted from based on either information on the SoC (some register state saying where it fetched from), or other means. > 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. /chosen is for fairly well-defined smaller properties of shared usefulness to the next-running image, such as stdout, boot device. A /firmware/u-boot node or similar (with a binding, please) is probably better for this kind of data. -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
