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?
- /* GUID in UEFI format: 77126730-a4ca-4386-b341-881fe18e7f7d */
- u-boot,uefi-spi-io-guid = [30 67 12 77 ca a4 86 43
b3 41 88 1f e1 8e 7f 7d];
We need to define first in the DT spec the format for GUIDs. I don't think there are any existing cases though some have been proposed. IMO, I would make this a string instead. The byte array is not that readable with its little endian order. A GUID as a string is readily identifiable as a GUID.
Why is this u-boot specific? Another UEFI implementation doesn't need the GUID?
Rob