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.bar...@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
