[U-Boot PATCH v4 5/6] arm: dts: am335x-sancloud-bbe-lite: UEFI SPI export

Heinrich Schuchardt xypron.glpk at gmx.de
Thu Oct 6 06:12:43 CEST 2022


On 10/5/22 14:18, Paul Barker wrote:
> Add properties to the Authenta SPI flash device node to enable access by
> a UEFI application using a fixed GUID. Also specify that this device is
> JEDEC compatible so that it is correctly initialized when running
> `sf probe`.
>
> Signed-off-by: Paul Barker <paul.barker at sancloud.com>
> ---
>   arch/arm/dts/am335x-sancloud-bbe-lite.dts | 10 ++++++++--
>   1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/am335x-sancloud-bbe-lite.dts b/arch/arm/dts/am335x-sancloud-bbe-lite.dts
> index d6ef19311a91..f1ff9d6024cb 100644
> --- a/arch/arm/dts/am335x-sancloud-bbe-lite.dts
> +++ b/arch/arm/dts/am335x-sancloud-bbe-lite.dts
> @@ -37,14 +37,20 @@
>   	pinctrl-names = "default";
>   	pinctrl-0 = <&bb_spi0_pins>;
>
> -	channel at 0 {
> +	authenta-flash at 0 {
>   		#address-cells = <1>;
>   		#size-cells = <0>;
>
> -		compatible = "micron,spi-authenta";
> +		compatible = "micron,spi-authenta", "jedec,spi-nor";

I cannot find "micron,spi-authenta" in Linux'
Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml. Should it be
added?

>
>   		reg = <0>;
>   		spi-max-frequency = <16000000>;
>   		spi-cpha;
> +
> +		uefi-spi-vendor = "micron";
> +		uefi-spi-part-number = "mt25ql128abb";

These properties seem to be neither UEFI nor SPI specific. Why should
they be prefixed with uefi-spi?

> +		/* GUID in UEFI format: 77126730-a4ca-4386-b341-881fe18e7f7d */
> +		uefi-spi-io-guid = [30 67 12 77 ca a4 86 43
> +				    b3 41 88 1f e1 8e 7f 7d];

The suggested properties which are required to set up the
EFI_SPI_IO_PROTOCOL need to be standardized and documented. The right
place would be a yaml file in Linux' Documentation/devicetree/bindings/mtd/.

Best regards

Heinrich

>   	};
>   };



More information about the U-Boot mailing list