On Thu, 13 Apr 2023 at 19:44, Stefan Wahren <stefan.wahren@xxxxxxxx> wrote:
Hi Ivan,
Am 13.04.23 um 20:18 schrieb Ivan T. Ivanov:
On 04-13 18:15, Stefan Wahren wrote:
Hi Ivan,
Am 13.04.23 um 10:52 schrieb Ivan T. Ivanov:
From: Tim Gover <tim.gover@xxxxxxxxxxxxxxx>
Make a copy of the bootloader secure-boot public key available to the OS
via an nvmem node. The placement information is populated by the
Raspberry Pi firmware if a public key is present in the BCM2711
bootloader EEPROM.
It would be nice to have a helpful link like:
https://www.raspberrypi.com/documentation/computers/configuration.html#nvmem-nodes
Yep, make sense.
+
+ /*
+ * RPi4 will copy the binary public key blob (if present) from the bootloader
+ * into memory for use by the OS.
+ */
+ blpubkey: nvram@1 {
+ compatible = "raspberrypi,bootloader-public-key", "nvmem-rmem";
Yes this looks better, but this introduce a new dtbs_check issue. The new
Oops, yes, I forgot to make this check.
compatible must be documented in
Documentation/devicetree/bindings/nvmem/rmem.yaml in a separate patch and
reviewed by the DT guys.
Or I can drop the new compatible string altogether? It looks like
only alias is strictly required?! Tim Gover is this correct?
i cannot speak for the firmware side, but i think we should try to keep
it compatible with the vendor DTB here.
The firmware doesn't look at the compatible string. It locates the
nodes to update using the 'blconfig' and 'blpubkey' aliases. Userspace
scripts (including the documentation example) should also use these
aliases.
Therefore, I don't think it matters if the compatible strings is
modified, but I won't pretend to know what the correct DT style is
here :)
Tim