Hi Rob,
On Fri, 14 Jul 2023 at 11:57, Simon Glass sjg@chromium.org wrote:
Hi Rob,
On Fri, 14 Jul 2023 at 10:58, Rob Herring robh@kernel.org wrote:
On Tue, Jul 11, 2023 at 3:18 PM Simon Glass sjg@chromium.org wrote:
Add a motivation and purpose for this new proposed node.
Signed-off-by: Simon Glass sjg@chromium.org
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@chromium.org
+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.
+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