On Sat, Dec 24, 2022 at 12:03:52PM +0000, Paul Barker wrote:
On 20/12/2022 15:55, Rob Herring wrote:
On Wed, Nov 23, 2022 at 05:50:06PM +0000, Paul Barker wrote:
Add properties to the Authenta SPI flash device node to enable access by a UEFI application using a fixed GUID.
Signed-off-by: Paul Barker paul.barker@sancloud.com
arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi | 13 ++++++++++--- arch/arm/dts/am335x-sancloud-bbe-lite.dts | 2 +- 2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi b/arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi index 01c105ebb383..6c4ff67f9a4b 100644 --- a/arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi +++ b/arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi @@ -38,7 +38,14 @@
&spi0 { u-boot,dm-pre-reloc;
- channel@0 {
u-boot,dm-pre-reloc;- };
+};
+&authenta_flash {
- u-boot,dm-pre-reloc;
- u-boot,uefi-spi-vendor = "micron";
- u-boot,uefi-spi-part-number = "mt25ql128abb";
Looks like a compatible string. Yet, the flash node compatible string, micron,spi-authenta, is not documented (though in use for spidev). So use a compatible string for the flash that is specific to the flash model. I assume there is some reason the specific model is needed?
For context, the UEFI Platform Initialization (PI) spec defines EFI_SPI_PART, EFI_SPI_PERIPHERAL and EFI_SPI_IO_PROTOCOL structures. I'm referencing v1.7 Errata A. See https://uefi.org/specifications for downloads.
The EFI_SPI_PART structure has "Vendor" and "PartNumber" fields. We need something to put in those fields and the device tree is the best place to store the data. These properties are in the `-u-boot.dtsi` file so they won't be submitted to the Linux kernel.
Well, IMHO, this doesn't belong in U-Boot only for forever. Just like other bindings/properties that we're working on getting merged upstream and so that there is really Just One Device Tree, this should go upstream I believe. This might be another case of starts in -u-boot.dtsi while things get sorted out.