On Thu, 2018-06-21 at 17:50 +0100, Andre Przywara wrote: > Hi, Hi Andre, > 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. My idea was passing to the to the kernel both the firmware version and the device it was booted from with the assumption that you can only upgrade the firmware that you currently booted from. Maybe it's a bit too restrictive but it's easier to approach. In this way you can also ship different firmware images for different medium (SD, eMMC, SPI, etc...). > 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. It's U-Boot itself that is going to tell you where it was booted from, so in theory no need to check the medium also because (see later) this is not always on option. > 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. The problem is that the storage is not always readily available. For example on the chromebook I'm working on U-Boot is stored into the SPI and the only way (so far) to access the SPI content is by using flashrom. So reading the whole SPI with flashrom only to check the version is not really an option. I would like to rely only on the information passed by U-Boot itself into the DTB to detect whether we need to upgrade the firmware or not. > 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). Can't we just add the node before jumping? > > > 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. Yup, agree. > Cheers, > Andre. Thanks. -- 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
