On Thu, Jun 21, 2018 at 10:10 AM, Andre Przywara <andre.przywara@xxxxxxx> wrote: > Hi, > > On 21/06/18 17:58, Olof Johansson wrote: >> 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. > > Yes, that would be useful. For instance for Allwinner we have this > information, put into SRAM by the BootROM. And we print it already in > U-Boot: > U-Boot SPL 2018.07-rc2 (21 Jun 2018 - 12:21:46 +0100) > DRAM: 2048 MiB > Trying to boot from MMC1 > ... > > But still this is somewhat detached from the update scenario: You might > deliberately want to boot from SD card *once* to update an old and/or > broken version on the SPI flash, which is where you normally boot from. > So in this case the SD card might already have been removed and/or is > not the one you wanted to upgrade in the first place. Policy belongs in userspace, in particular of what device to update and what to boot next. The updater will need to know where to update for what, but a very useful piece of information for it to do so will be to find out where the system was booted from. Having something such as /firmware/u-boot/boot-device could help. Note: It should be where _u-boot_ was loaded from, not where u-boot is loading kernel/ramdisk/dtb from. >>> 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. > > 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 -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
