Hi Rob, On Fri, 14 Jul 2023 at 11:57, Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > Hi Rob, > > On Fri, 14 Jul 2023 at 10:58, Rob Herring <robh@xxxxxxxxxx> wrote: > > > > On Tue, Jul 11, 2023 at 3:18 PM Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > > > > > Add a motivation and purpose for this new proposed node. > > > > > > Signed-off-by: Simon Glass <sjg@xxxxxxxxxxxx> > > > --- > > > > > > dtschema/schemas/firmware.yaml | 83 ++++++++++++++++++++++++++++++++++ > > > 1 file changed, 83 insertions(+) > > > create mode 100644 dtschema/schemas/firmware.yaml > > > > > > diff --git a/dtschema/schemas/firmware.yaml b/dtschema/schemas/firmware.yaml > > > new file mode 100644 > > > index 0000000..4439a70 > > > --- /dev/null > > > +++ b/dtschema/schemas/firmware.yaml > > > @@ -0,0 +1,83 @@ > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-clause > > > +# Copyright 2023 Google LLC > > > +# > > > + > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/firmware.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: /firmware Node > > > + > > > +maintainers: > > > + - Simon Glass <sjg@xxxxxxxxxxxx> > > > + > > > +description: | > > > + The '/firmware' node does not represent a real device, but serves as a place > > > + for recording information about the main firmware used on the device, such as > > > + a map of its contents. This is used by the Operating System (OS), user space > > > + programs and possibly other firmware components. Data in the '/firmware' node > > > + does not itself represent the hardware. > > > + > > > + Properties in this node should be common to (and used by) at least two > > > + firmware projects, such as U-Boot and TF-A. Project-specific subnodes can be > > > + used for properties which are specific to a single project. > > > + > > > + Purpose of '/firmware' node > > > + --------------------------- > > > + > > > + Firmware has traditionally been fairly opaque to the OS, with the OS taking > > > + no interest in its contents, version, layout or how it might be updated. This > > > + is less than ideal, since firmware is an important part of the system and > > > + visibility into its operation is every bit as important as visbility into the > > > + OS and user-space programs within the system. > > > + > > > + The traditional approach has been to let firmware deal with firmware, and the > > > + OS deal with everything else. Updating firmware has been handled by firmware. > > > + For example, the UEFI spec defines a way for the OS to post a 'capsule' which > > > + is discovered next time the system boots, permitting firmware updates. But > > > + firmware updates in firmware are highly problematic. They require a reboot > > > + and a sometimes-lengthy wait with a strange-looking interface unfamiliar > > > + to most users. It seems better to make the update as transparent as possible > > > + to the user. As an example of that, ChromeOS has full knowledge of the > > > + firmware version and layout, updates it in the background from user space and > > > + instantly selects the new firmware when the user reboots or logs out. > > > > Perhaps if OS based firmware updates are useful, then UEFI should gain > > that capability rather than inventing some way to do it with DT. Seems > > like a worthy goal, just needs wider review IMO. > > Perhaps it should, although it would involve changing the spec, etc. > In any case it would be a very strange world if we mandated UEFI > everywhere. > > Yes I am looking for wider review, partly since the work to document > all the firmware-image complexity is happening mostly in U-Boot at > present. > > > > > > + A common objection to considering the system holistically is that some parts > > > + of the system are inaccessible to the OS, such as a secure enclave. However > > > + this does not preclude providing visibility into what is present in that > > > + enclave. Firmware-version information is still useful. Firmware updates are > > > + still needed and can still be initiated from user space. > > > + > > > + Another objection is that firmware should provide an interface to the OS, > > > + while keeping its structure private. This thinking is largely driven by > > > + extrapolating from how firmware has been handled in the 'BIOS' days. > > > > It's also the case that the OS may not have direct access to the h/w needed. > > I tried to cover that in the paragraph you quote immediately > above...what is missing? > > > > > > + It should be considered a degenerate case rather than the norm. As complexity > > > + increases, it creates an artificial boundary between two pieces of the whole. > > > + Mechanisms then need to be invented to cross this unnecessary chasm. An > > > + example of this is Intel's Dynamic Platform and Thermal Framework (DPTF), > > > + which consists of user-space, OS and firmware components all working towards > > > + a shared goal. We need a standard description of these cross-system pieces. > > > + > > > + In order to 'teach the OS about firmware', we need a place to put this > > > + information. That is the purpose of this node. > > > + > > > + In an Open Source world the entire model of firmware needs to adjust to be > > > + more open, more visible and managed just like any other part of the system. > > > + The major goal is to standardise how firmware is presented to the OS and user > > > + space, so that common utilities can be used to manage the entire system, > > > + including the firmware. For example, fwupd can look in this node for > > > + information on how to update the firmware, similar to how VBE works. [1] > > > + It is likely that other purposes will come to light over time. > > > > It's good we're documenting /firmware, but your use seems different to > > what's already in place. Generally, /firmware has been for providers > > which are implemented by firmware and are not on any bus. SCMI for > > example. PSCI is another example, but it predated using /firmware so > > it's typically just put at the top level (and also PSCI should have > > been made discoverable like any SMCCC interface). > > The intent here is that the node is not on any bus. > > I'm happy to create a new node if that is better. > > > > > > + > > > + [1] https://github.com/fwupd/fwupd/tree/main/plugins/vbe > > > + > > > +properties: > > > + $nodename: > > > + const: firmware > > > + > > > + "#address-cells": true > > > + "#size-cells": true > > > > What address space is this? It's not memory mapped because you don't > > have 'ranges'. > > Probably this should be 'false' ? I suppose there may be an address > space, for example in memory-mapped SPI flash, but that is not very > common. The firmware could be stored in eMMC or UFS, which are not > memory-mapped. Are there any other comments on this? Is there a way to tag it so that other firmware people might see it? Regards, Simon
