[PATCH 1/2] schemas: Add firmware node schema

[Rob Herring]

On Tue, Jul 11, 2023 at 3:18 PM Simon Glass <sjg at chromium.org> wrote:
>
> Add a motivation and purpose for this new proposed node.
>
> Signed-off-by: Simon Glass <sjg at 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 at 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.

> +  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.

> +  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).

> +
> +  [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'.

Rob