[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