[PATCH 0/6] Expose RPi4'd bootloader configuration

[PATCH 0/6] Expose RPi4'd bootloader configuration

[Nicolas Saenz Julienne]

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

[PATCH 1/6] dt-bindings: nvmem: Add bindings for rmem driver

[Nicolas Saenz Julienne]

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 <nsaenzjulienne@suse.de>
---
 .../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 <nsaenzjulienne@suse.de>
+
+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

Re: [PATCH 1/6] dt-bindings: nvmem: Add bindings for rmem driver

[Rob Herring]

On Tue, Dec 15, 2020 at 9:56 AM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> 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 <nsaenzjulienne@suse.de>
> ---
>  .../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 <nsaenzjulienne@suse.de>
> +
> +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.

> +
> +required:
> +  - compatible
> +  - memory-region
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +        fw-config {
> +                compatible = "nvmem-rmem";
> +                memory-region = <&mem>;
> +        };
> +
> +...
> --
> 2.29.2
>

Re: [PATCH 1/6] dt-bindings: nvmem: Add bindings for rmem driver

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]

On Tue, 2020-12-15 at 14:25 -0600, Rob Herring wrote:
> On Tue, Dec 15, 2020 at 9:56 AM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> 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 <nsaenzjulienne@suse.de>
> > ---
> >  .../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 <nsaenzjulienne@suse.de>
> > +
> > +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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH 2/6] nvmem: Add driver to expose reserved memory as nvmem

[Nicolas Saenz Julienne]

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.

In order to expose this data to other drivers and user-space, the driver
models the reserved memory area as an nvmem device.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
 drivers/nvmem/Kconfig  |  8 ++++
 drivers/nvmem/Makefile |  2 +
 drivers/nvmem/rmem.c   | 92 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 102 insertions(+)
 create mode 100644 drivers/nvmem/rmem.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 954d3b4a52ab..fecc19b884bf 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -270,4 +270,12 @@ config SPRD_EFUSE
 	  This driver can also be built as a module. If so, the module
 	  will be called nvmem-sprd-efuse.
 
+config NVMEM_RMEM
+	tristate "Reserved Memory Based Driver Support"
+	help
+	  This drivers maps reserved memory into an nvmem device. It might be
+	  useful to expose information left by firmware in memory.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called nvmem-rmem.
 endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index a7c377218341..5376b8e0dae5 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -55,3 +55,5 @@ obj-$(CONFIG_NVMEM_ZYNQMP)	+= nvmem_zynqmp_nvmem.o
 nvmem_zynqmp_nvmem-y		:= zynqmp_nvmem.o
 obj-$(CONFIG_SPRD_EFUSE)	+= nvmem_sprd_efuse.o
 nvmem_sprd_efuse-y		:= sprd-efuse.o
+obj-$(CONFIG_NVMEM_RMEM) 	+= nvmem-rmem.o
+nvmem-rmem-y			:= rmem.o
diff --git a/drivers/nvmem/rmem.c b/drivers/nvmem/rmem.c
new file mode 100644
index 000000000000..d4fb36db0644
--- /dev/null
+++ b/drivers/nvmem/rmem.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/platform_device.h>
+
+struct rmem {
+	struct device *dev;
+	struct nvmem_device *nvmem;
+	struct reserved_mem *rmem;
+
+	const void *base;
+	phys_addr_t size;
+};
+
+static int rmem_read(void *context, unsigned int offset,
+		     void *val, size_t bytes)
+{
+	struct rmem *priv = context;
+	loff_t off = offset;
+
+	return memory_read_from_buffer(val, bytes, &off, priv->base, priv->size);
+}
+
+static int rmem_probe(struct platform_device *pdev)
+{
+	struct nvmem_config config = { };
+	struct device *dev = &pdev->dev;
+	struct device_node *rmem_np;
+	struct reserved_mem *rmem;
+	struct rmem *priv;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+	priv->dev = dev;
+
+	rmem_np = of_parse_phandle(dev->of_node, "memory-region", 0);
+	if (!rmem_np) {
+		dev_err(dev, "Failed to lookup reserved memory phandle\n");
+		return -EINVAL;
+	}
+
+	rmem = of_reserved_mem_lookup(rmem_np);
+	of_node_put(rmem_np);
+	if (!rmem) {
+		dev_err(dev, "Failed to lookup reserved memory\n");
+		return -EINVAL;
+	}
+
+	priv->rmem = rmem;
+	priv->size = rmem->size;
+
+	priv->base = devm_memremap(dev, rmem->base, rmem->size, MEMREMAP_WB);
+	if (IS_ERR(priv->base)) {
+		dev_err(dev, "Failed to remap memory region\n");
+		return PTR_ERR(priv->base);
+	}
+
+	config.dev = dev;
+	config.priv = priv;
+	config.name = "rmem";
+	config.size = priv->size;
+	config.reg_read = rmem_read;
+
+	priv->nvmem = devm_nvmem_register(dev, &config);
+	return PTR_ERR_OR_ZERO(priv->nvmem);
+}
+
+static const struct of_device_id rmem_match[] = {
+	{ .compatible = "nvmem-rmem", },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, rmem_match);
+
+static struct platform_driver rmem_driver = {
+	.probe = rmem_probe,
+	.driver = {
+		.name = "rmem",
+		.of_match_table = rmem_match,
+	},
+};
+module_platform_driver(rmem_driver);
+
+MODULE_AUTHOR("Nicolas Saenz Julienne <nsaenzjulienne@suse.de>");
+MODULE_DESCRIPTION("Reserved Memory Based nvmem Driver");
+MODULE_LICENSE("GPL");
-- 
2.29.2

[PATCH 3/6] ARM: dts: bcm2711: Add reserved memory template to hold firmware configuration

[Nicolas Saenz Julienne]

RPi4's co-processor will copy the board's bootloader configuration into
memory for the OS to consume. Introduce a reserved-memory area template
for the co-processor to edit before booting the system so as for Linux
not to overwrite that memory.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index 403bacf986eb..c58e58e8ce39 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -25,6 +25,7 @@ aliases {
 		emmc2bus = &emmc2bus;
 		ethernet0 = &genet;
 		pcie0 = &pcie0;
+		eeprom = &eeprom;
 	};
 
 	leds {
@@ -218,6 +219,19 @@ &pwm1 {
 	status = "okay";
 };
 
+&rmem {
+	/*
+	 * RPi4's co-processor will copy the board's bootloader configuration
+	 * into memory for the OS to consume. It'll also update this node with
+	 * its placement information.
+	 */
+	eeprom: eeprom@0 {
+		reg = <0x0 0x0 0x0>;
+		no-map;
+		status = "disabled";
+	};
+};
+
 /* SDHCI is used to control the SDIO for wireless */
 &sdhci {
 	#address-cells = <1>;
-- 
2.29.2

Re: [PATCH 3/6] ARM: dts: bcm2711: Add reserved memory template to hold firmware configuration

[Rob Herring]

On Tue, Dec 15, 2020 at 9:56 AM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> wrote:
>
> RPi4's co-processor will copy the board's bootloader configuration into
> memory for the OS to consume. Introduce a reserved-memory area template
> for the co-processor to edit before booting the system so as for Linux
> not to overwrite that memory.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
>  arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> index 403bacf986eb..c58e58e8ce39 100644
> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> @@ -25,6 +25,7 @@ aliases {
>                 emmc2bus = &emmc2bus;
>                 ethernet0 = &genet;
>                 pcie0 = &pcie0;
> +               eeprom = &eeprom;

I don't see the need for this...

>         };
>
>         leds {
> @@ -218,6 +219,19 @@ &pwm1 {
>         status = "okay";
>  };
>
> +&rmem {
> +       /*
> +        * RPi4's co-processor will copy the board's bootloader configuration
> +        * into memory for the OS to consume. It'll also update this node with
> +        * its placement information.
> +        */
> +       eeprom: eeprom@0 {

But it's not an eeprom. It's just memory with some format to the contents.

> +               reg = <0x0 0x0 0x0>;
> +               no-map;
> +               status = "disabled";
> +       };
> +};
> +
>  /* SDHCI is used to control the SDIO for wireless */
>  &sdhci {
>         #address-cells = <1>;
> --
> 2.29.2
>

[PATCH 4/6] ARM: dts: bcm2711: Expose boot-loader configuration

[Nicolas Saenz Julienne]

RPi4's co-processor will copy the board's bootloader configuration in
memory. Expose it to user-space by using 'nvmem-rmem'.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index c58e58e8ce39..261169eb5e3b 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -26,6 +26,17 @@ aliases {
 		ethernet0 = &genet;
 		pcie0 = &pcie0;
 		eeprom = &eeprom;
+		fw_config = &fw_config;
+	};
+
+	fw_config: fw-config {
+		compatible = "nvmem-rmem";
+		memory-region = <&eeprom>;
+		/*
+		 * Will be enabled by the bootloader if the reserved memory
+		 * region is valid.
+		 */
+		status = "disabled";
 	};
 
 	leds {
-- 
2.29.2

[PATCH 5/6] arm64: defconfig: Enable nvmem's rmem driver

[Nicolas Saenz Julienne]

It'll be used by the RPi4 family of boards to access its bootloader
configuration.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 838301650a79..68d6a7e024c0 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1062,6 +1062,7 @@ CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_NVMEM_SUNXI_SID=y
 CONFIG_UNIPHIER_EFUSE=y
 CONFIG_MESON_EFUSE=m
+CONFIG_NVMEM_RMEM=m
 CONFIG_FPGA=y
 CONFIG_FPGA_MGR_STRATIX10_SOC=m
 CONFIG_FPGA_BRIDGE=m
-- 
2.29.2

[PATCH 6/6] ARM: multi_v7_defconfig: Enable nvmem's rmem driver

[Nicolas Saenz Julienne]

It'll be used by the RPi4 family of boards to access its bootloader
configuration.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index c5f25710fedc..7a326c5eff7a 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1107,6 +1107,7 @@ CONFIG_ROCKCHIP_EFUSE=m
 CONFIG_NVMEM_SUNXI_SID=y
 CONFIG_NVMEM_VF610_OCOTP=y
 CONFIG_MESON_MX_EFUSE=m
+CONFIG_NVMEM_RMEM=m
 CONFIG_FSI=m
 CONFIG_FSI_MASTER_GPIO=m
 CONFIG_FSI_MASTER_HUB=m
-- 
2.29.2

Re: [PATCH 0/6] Expose RPi4'd bootloader configuration

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

On Tue, 2020-12-15 at 16:56 +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.
> 
> Regards,
> Nicolas

There's a typo in the Subject, it should look like this:

'Expose RPi4's bootloader configuration'

Regards,
Nicolas


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 0/6] Expose RPi4'd bootloader configuration

[Catalin Marinas]

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

Re: [PATCH 0/6] Expose RPi4'd bootloader configuration

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 0/6] Expose RPi4'd bootloader configuration

[Rob Herring]

On Tue, Dec 15, 2020 at 1:01 PM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> 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

Re: [PATCH 0/6] Expose RPi4'd bootloader configuration

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

Hi Rob, thanks for having a look at this.

On Tue, 2020-12-15 at 13:54 -0600, Rob Herring wrote:
> On Tue, Dec 15, 2020 at 1:01 PM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> 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.

It's the bootloader configuration, stuff like boot order, TFTP IP, etc... See
more here:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md

I'll add a new paragraph explaining all this on next version's cover letter.

Regards,
Nicolas


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]