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. Regards, Simon
