Soon to be released versions of RPi4's firmware will take of care
passing their bootloader's configuration to the OS by copying it into
memory and creating a reserved memory node in the board's DT. In order
to make use of this information, this series introduces a new generic
nvmem driver that maps reserved-memory nodes into nvmem devices.
An alternative approach, less nice IMO, would be to create a
platform-specific 'soc' driver.
Regards,
Nicolas
---
Nicolas Saenz Julienne (6):
dt-bindings: nvmem: Add bindings for rmem driver
nvmem: Add driver to expose reserved memory as nvmem
ARM: dts: bcm2711: Add reserved memory template to hold firmware
configuration
ARM: dts: bcm2711: Expose boot-loader configuration
arm64: defconfig: Enable nvmem's rmem driver
ARM: multi_v7_defconfig: Enable nvmem's rmem driver
.../devicetree/bindings/nvmem/rmem.yaml | 35 +++++++
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 25 +++++
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm64/configs/defconfig | 1 +
drivers/nvmem/Kconfig | 8 ++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/rmem.c | 92 +++++++++++++++++++
7 files changed, 164 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/rmem.yaml
create mode 100644 drivers/nvmem/rmem.c
--
2.29.2
Firmware/co-processors might use reserved memory areas in order to pass
data stemming from an nvmem device otherwise non accessible to Linux.
For example an EEPROM memory only physically accessible to firmware, or
data only accessible early at boot time.
Introduce the dt-bindings to nvmem's rmem.
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
---
.../devicetree/bindings/nvmem/rmem.yaml | 35 +++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/rmem.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/rmem.yaml b/Documentation/devicetree/bindings/nvmem/rmem.yaml
new file mode 100644
index 000000000000..3037ebc4634d
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/rmem.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/rmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Reserved Memory Based nvmem Device
+
+maintainers:
+ - Nicolas Saenz Julienne <[email protected]>
+
+properties:
+ compatible:
+ enum:
+ - nvmem-rmem
+
+ memory-region:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the reserved memory region
+
+required:
+ - compatible
+ - memory-region
+
+additionalProperties: false
+
+examples:
+ - |
+ fw-config {
+ compatible = "nvmem-rmem";
+ memory-region = <&mem>;
+ };
+
+...
--
2.29.2
On Tue, Dec 15, 2020 at 04:56:20PM +0100, Nicolas Saenz Julienne wrote:
> Soon to be released versions of RPi4's firmware will take of care
> passing their bootloader's configuration to the OS by copying it into
> memory and creating a reserved memory node in the board's DT. In order
> to make use of this information, this series introduces a new generic
> nvmem driver that maps reserved-memory nodes into nvmem devices.
>
> An alternative approach, less nice IMO, would be to create a
> platform-specific 'soc' driver.
What kind of information is this and how would the kernel use it?
--
Catalin
Hi Catalin,
On Tue, 2020-12-15 at 18:44 +0000, Catalin Marinas wrote:
> On Tue, Dec 15, 2020 at 04:56:20PM +0100, Nicolas Saenz Julienne wrote:
> > Soon to be released versions of RPi4's firmware will take of care
> > passing their bootloader's configuration to the OS by copying it into
> > memory and creating a reserved memory node in the board's DT. In order
> > to make use of this information, this series introduces a new generic
> > nvmem driver that maps reserved-memory nodes into nvmem devices.
> >
> > An alternative approach, less nice IMO, would be to create a
> > platform-specific 'soc' driver.
>
> What kind of information is this and how would the kernel use it?
Sorry, I wasn't clear enough, the ultimate goal is to use this information from
user-space, through nvmem's sysfs interface. The kernel itself has no use for
it.
Regards,
Nicolas
On Tue, Dec 15, 2020 at 1:01 PM Nicolas Saenz Julienne
<[email protected]> wrote:
>
> Hi Catalin,
>
> On Tue, 2020-12-15 at 18:44 +0000, Catalin Marinas wrote:
> > On Tue, Dec 15, 2020 at 04:56:20PM +0100, Nicolas Saenz Julienne wrote:
> > > Soon to be released versions of RPi4's firmware will take of care
> > > passing their bootloader's configuration to the OS by copying it into
> > > memory and creating a reserved memory node in the board's DT. In order
> > > to make use of this information, this series introduces a new generic
> > > nvmem driver that maps reserved-memory nodes into nvmem devices.
> > >
> > > An alternative approach, less nice IMO, would be to create a
> > > platform-specific 'soc' driver.
> >
> > What kind of information is this and how would the kernel use it?
>
> Sorry, I wasn't clear enough, the ultimate goal is to use this information from
> user-space, through nvmem's sysfs interface. The kernel itself has no use for
> it.
That still leaves the first question.
Rob
On Tue, 2020-12-15 at 14:25 -0600, Rob Herring wrote:
> On Tue, Dec 15, 2020 at 9:56 AM Nicolas Saenz Julienne
> <[email protected]> wrote:
> >
> > Firmware/co-processors might use reserved memory areas in order to pass
> > data stemming from an nvmem device otherwise non accessible to Linux.
> > For example an EEPROM memory only physically accessible to firmware, or
> > data only accessible early at boot time.
> >
> > Introduce the dt-bindings to nvmem's rmem.
> >
> > Signed-off-by: Nicolas Saenz Julienne <[email protected]>
> > ---
> > .../devicetree/bindings/nvmem/rmem.yaml | 35 +++++++++++++++++++
> > 1 file changed, 35 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/nvmem/rmem.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/nvmem/rmem.yaml b/Documentation/devicetree/bindings/nvmem/rmem.yaml
> > new file mode 100644
> > index 000000000000..3037ebc4634d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/rmem.yaml
> > @@ -0,0 +1,35 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/nvmem/rmem.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Reserved Memory Based nvmem Device
> > +
> > +maintainers:
> > + - Nicolas Saenz Julienne <[email protected]>
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - nvmem-rmem
> > +
> > + memory-region:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description:
> > + phandle to the reserved memory region
>
> There's no need for this indirection. Just add a compatible to the
> reserved-memory node. See ramoops for example.
>
> Please make the compatible specific enough to define what the memory
> contains. If you want 'nvmem-rmem' as a fallback that's fine.
Ok, I'll look into it.
Regards,
Nicolas