On Tue, 8 Feb 2022 at 16:26, Michal Simek <mon...@monstr.eu> wrote:
>
> po 7. 2. 2022 v 19:21 odesÃlatel Sughosh Ganu <sughosh.g...@linaro.org>
> napsal:
> >
> > In the FWU Multi Bank Update feature, the information about the
> > updatable images is stored as part of the metadata, which is stored on
> > a dedicated partition. Add the metadata structure, and a driver model
> > uclass which provides functions to access the metadata. These are
> > generic API's, and implementations can be added based on parameters
> > like how the metadata partition is accessed and what type of storage
> > device houses the metadata.
> >
> > A device tree node fwu-mdata has been added, which is used for
> > pointing to the storage device which contains the FWU metadata. The
> > fwu-mdata node is u-boot specific, and can be added the platform's
> > u-boot dtsi file.
> >
> > Signed-off-by: Sughosh Ganu <sughosh.g...@linaro.org>
> > ---
> >
> > Changes since V3:
> > * Move the FWU metadata access to driver model
> > * Get the storage device containing the metadata from a device tree
> > property instead of a platform helper function
> >
> > arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi | 7 +
> > .../firmware/fwu-mdata.txt | 18 +
> > drivers/Kconfig | 2 +
> > drivers/Makefile | 1 +
> > drivers/fwu-mdata/Kconfig | 7 +
> > drivers/fwu-mdata/Makefile | 6 +
> > drivers/fwu-mdata/fwu-mdata-uclass.c | 434 ++++++++++++++++++
> > include/dm/uclass-id.h | 1 +
> > include/fwu.h | 51 ++
> > include/fwu_mdata.h | 67 +++
> > 10 files changed, 594 insertions(+)
> > create mode 100644 doc/device-tree-bindings/firmware/fwu-mdata.txt
> > create mode 100644 drivers/fwu-mdata/Kconfig
> > create mode 100644 drivers/fwu-mdata/Makefile
> > create mode 100644 drivers/fwu-mdata/fwu-mdata-uclass.c
> > create mode 100644 include/fwu.h
> > create mode 100644 include/fwu_mdata.h
> >
> > diff --git a/arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi
> > b/arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi
> > index 06ef3a4095..3bec6107f7 100644
> > --- a/arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi
> > +++ b/arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi
> > @@ -4,3 +4,10 @@
> > */
> >
> > #include "stm32mp157a-dk1-u-boot.dtsi"
> > +
> > +/ {
> > + fwu-mdata {
> > + compatible = "u-boot,fwu-mdata";
> > + fwu-mdata-store = <&sdmmc1>;
> > + };
> > +};
> > diff --git a/doc/device-tree-bindings/firmware/fwu-mdata.txt
> > b/doc/device-tree-bindings/firmware/fwu-mdata.txt
> > new file mode 100644
> > index 0000000000..c766b595ef
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/firmware/fwu-mdata.txt
> > @@ -0,0 +1,18 @@
> > +FWU Metadata Access Devicetree Binding
> > +
> > +The FWU Multi Bank Update feature uses a metadata structure, stored on
> > +a separate partition for keeping information on the set of updatable
> > +images. The device tree node provides information on the storage
> > +device that contains the FWU metadata.
> > +
> > +Required properties :
> > +
> > +- compatible : "u-boot,fwu-mdata";
> > +- fwu-mdata-store : should point to the storage device which contains
> > + the FWU metadata partition.
>
> In 0/11 you are describing GPT partitions but I don't think this
> binding is generic enough to describe
> other cases. It is saying device but not where exactly it is.
> I didn't read the whole series yet but arm spec recommends GPT but dt
> binding should be generic enough to describe
> also other cases.
> We are saving this structure to qspi for example but current binding
> can't be used for it.
I would wait to see Masami's implementation of this feature. If I am
not wrong, his platform too is enabling this feature with a spi as the
storage device. Maybe we can instead put a list of <device partition>
tuples which can then list the device and partition number of the
metadata partitions.
-sughosh
>
> > +
> > +Example :
> > + fwu-mdata {
> > + compatible = "u-boot,fwu-mdata";
> > + fwu-mdata-store = <&sdmmc1>;
> > + };
>
> I don't think this is aligned with getting these u-boot nodes to any
> standard locations.
> Simon had that discussion with Rob some time ago. Was there any
> outcome from this discussion where u-boot nodes should go?
>
> Thanks,
> Michal
