RFC: Adding U-Boot version in FDT chosen node
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).
Francesco
Hi Francesco,
On 4/11/22 2:17 PM, 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).
Francesco
I think a standard way to communicate this would be nice. In the last project I needed to do this, I put the following in my board file
/* Use a version without spaces so we don't have to quote it */ const char version_string[] = PLAIN_VERSION;
and then I added "my-prefix.u_boot_ver=${ver}" to my bootargs. This works OK, but it's a bit ugly to read (you have to grep on /proc/cmdline).
Somethins to consider would be how we want to expose versions from different bootloader stages. For example, should SPL's version be added?
--Sean
On Mon, Apr 11, 2022 at 1:18 PM Francesco Dolcini francesco.dolcini@toradex.com 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).
Seems fine to me. Please add it here[1].
Rob
[1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/chose...
+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/
Francesco
On Wed, Apr 20, 2022 at 07:01:43PM +0200, Francesco Dolcini wrote:
+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/
So, the patch I applied had a matching update to the relevant DT schema. I don't see a problem with adding this information as well, but would suggest starting by having a matching schema change and explanation of use cases there. Thanks!
Date: Wed, 20 Apr 2022 19:01:43 +0200 From: Francesco Dolcini francesco.dolcini@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.
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@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.
No software artifact nor software configuration should be part of it, with the only exception of the chosen node [0].
Rob in cc can comment if I understood this wrong.
[0] https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
Francesco
Date: Thu, 21 Apr 2022 10:34:34 +0200 From: Francesco Dolcini francesco.dolcini@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@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
participants (5)
-
Francesco Dolcini -
Mark Kettenis -
Rob Herring -
Sean Anderson -
Tom Rini