| Message ID | 20201215155627.2513-1-nsaenzjulienne@suse.de |
|---|---|
| Headers | show |
| Series | Expose RPi4'd bootloader configuration | expand |
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
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
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 >
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
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