| Message ID | 20201215155627.2513-1-nsaenzjulienne@suse.de (mailing list archive) |
|---|---|
| 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 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?
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 <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
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