RFC: Adding U-Boot version in FDT chosen node

[Mark Kettenis]

> Date: Thu, 21 Apr 2022 10:34:34 +0200
> From: Francesco Dolcini <francesco.dolcini at toradex.com>
> 
> Hello Mark
> 
> On Wed, Apr 20, 2022 at 11:51:44PM +0200, Mark Kettenis wrote:
> > > Date: Wed, 20 Apr 2022 19:01:43 +0200
> > > From: Francesco Dolcini <francesco.dolcini at toradex.com>
> > > 
> > > +Tom
> > > 
> > > On Mon, Apr 11, 2022 at 08:17:55PM +0200, Francesco Dolcini wrote:
> > > > Hello all,
> > > > I have a need to pass the u-boot version string to the operating
> > > > system and I'm thinking at adding `u-boot,version` property storing
> > > > `version_string` in it in the FDT `chosen` node.
> > > > 
> > > > Is this something that would be generally useful? Would be a patch like
> > > > that acceptable in upstream u-boot? Is there any other obvious way to
> > > > achieve something like that already implemented (using the cmdline would
> > > > work without any code change, but probably not the nicest solution).
> > > 
> > > Any concern on this Tom? I'm asking you directly since you recently
> > > acknowledged another change [0] related to the chosen node.
> > > 
> > > [0] https://lore.kernel.org/all/20220412201444.GN14282@bill-the-cat/
> > 
> > To be honest, putting this in the "chosen" node feels odd.
> > Traditionally device trees have a node dedicated to the firmware.  For
> > example Sun OpenFirmware systems had a "openprom" node with a
> > "version" property.  And OpenPOWER systems have an
> > "ibm,firmware-versions" node.
> 
> I would personally not mind the parent node of this property, however
> from my partial understanding on the recent device tree architecture
> decisions we do want only the description of the hardware and real
> devices into it.

Well, if that were true, device trees for virtualized platforms
(e.g. QEMU with virtio devices) wouldn't work.  And things like PSCI
on arm64 wouldn't be discoverable.  The boundary between "real
hardware" and "firmware" is somewhat vague anyway.  The hardware may
be an integrated microcontroller running a firmware, where the
firmware is what actually defines the programming interface.

> No software artifact nor software configuration should be part of it,
> with the only exception of the chosen node [0].

The device tree specification itself uses slightly different text:

  "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. It shall be a child of the root node."

I wouldn't call the U-Boot version number a "paramater chosen or
specified by the system firmware at run time".

On the other hand, U-Boot doesn't provide some sort of U-Boot specific
firmware interface to the OS.  The firmware interfaces it does provide
are industry standard interfaces such as UEFI, SMBIOS and PSCI.  And
what you're trying to do is just provide some static information about
the U-Boot version that is providing those interfaces.  Note U-Boot
already provides its version number is provided through the UEFI and
SMBIOS interfaces.  But of course not all "boards" enable those
interfaces.

Anyway, I'm just pointing out here that I think "/chosen" isn't
necessarily the "obvious" place to provide this information, and that
there is a precedent for providing this information in a separate
top-level node.

> Rob in cc can comment if I understood this wrong.
> 
> [0] https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt