Re: Running qemu tests on RISC-V

[Heinrich Schuchardt]

On 2/7/22 19:19, Simon Glass wrote:

Hi Tom,

On Mon, 7 Feb 2022 at 09:49, Tom Rini  wrote:


On Mon, Feb 07, 2022 at 11:34:17AM -0500, Sean Anderson wrote:



On 2/7/22 10:53 AM, Heinrich Schuchardt wrote:

On 2/7/22 16:38, Simon Glass wrote:

Hi,

I am trying to run the SPL tests for riscv32 but it dies with an
illegal instruction. I have tried building qemu 4.2 but it seems to
happen on various versions. Has anyone seen this?


Did you try to run qemu-riscv32_spl_defconfig in the Docker container we
are using for Gitlab?


No, I want to run it outside docker. I can see that it works in the
docker container, but not sure why it fails for me.



We are using QEMU v6.1.0 according to tools/docker/Dockerfile.

With all that duplicate output below it is hard to understand what is
going. Why is each byte written twice to the serial?


If I had to guess there are 2 harts, and they both trigger an illegal
instruction. In situations like these, I have added a spinlock around puts.


There are 4 CPUs I think.



It might also be worth asking why such an old QEMU?  I know my
host-provided QEMU is 4.2.1 but I just don't use it since it's too old
for everything we do, especially on something as fast moving as RISC-V.


I tried 6.x and went back to 4.2.1 because I thought that might be the problem.



And as an aside, if anyone has tips on changes that would need to be
made to our Dockerfile so that some of those tools that let you run app
from a container "normally" would work with our container, that'd be
handy and appreciated.


I'm not sure what that means, probably because I am not an expert in that area.

Regards,
Simon


Hello Simon,

The qemu-riscv32_spl_defconfig image built inside Docker with

wget -O -
https://github.com/riscv/opensbi/releases/download/v0.9/opensbi-0.9-rv-bin.tar.xz
export
OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin
tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl

runs flawlessly on Ubuntu Jammy with:

qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \
-device loader,file=u-boot.itb,addr=0x8020 -smp cpus=4

This is a QEMU 6.0

Please, provide a reproducible instruction for your problem.

Best regards

Heinrich

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Masami Hiramatsu]

Hi Sughosh,

Thanks for updating the series. I have some comment on this patch.

2022年2月8日(火) 3:21 Sughosh Ganu :
[snip]
> +
> +/**
> + * fwu_get_active_index() - Get active_index from the FWU metadata
> + * @active_idx: active_index value to be read
> + *
> + * Read the active_index field from the FWU metadata and place it in
> + * the variable pointed to be the function argument.
> + *
> + * Return: 0 if OK, -ve on error
> + *
> + */
> +int fwu_get_active_index(u32 *active_idx)
> +{
> +   int ret;
> +   struct fwu_mdata *mdata = NULL;
> +
> +   ret = fwu_get_mdata(&mdata);
> +   if (ret < 0) {
> +   log_err("Unable to get valid FWU metadata\n");
> +   goto out;

Again, as we discussed previous series, please don't return unused
allocated memory if the function returns an error.
That is something like putting a burden on the callers. They always
needs to initialize the pointer before call and free it even if the
function is failed.

> +   }
> +
> +   /*
> +* Found the FWU metadata partition, now read the active_index
> +* value
> +*/
> +   *active_idx = mdata->active_index;
> +   if (*active_idx > CONFIG_FWU_NUM_BANKS - 1) {
> +   log_err("Active index value read is incorrect\n");
> +   ret = -EINVAL;
> +   }
> +
> +out:
> +   free(mdata);
> +
> +   return ret;
> +}
> +
> +/**
> + * fwu_update_active_index() - Update active_index from the FWU metadata
> + * @active_idx: active_index value to be updated
> + *
> + * Update the active_index field in the FWU metadata
> + *
> + * Return: 0 if OK, -ve on error
> + *
> + */
> +int fwu_update_active_index(u32 active_idx)
> +{
> +   int ret;
> +   void *buf;
> +   struct fwu_mdata *mdata = NULL;
> +
> +   if (active_idx > CONFIG_FWU_NUM_BANKS - 1) {
> +   log_err("Active index value to be updated is incorrect\n");
> +   return -1;
> +   }
> +
> +   ret = fwu_get_mdata(&mdata);
> +   if (ret < 0) {
> +   log_err("Unable to get valid FWU metadata\n");
> +   goto out;
> +   }
> +
> +   /*
> +* Update the active index and previous_active_index fields
> +* in the FWU metadata
> +*/
> +   mdata->previous_active_index = mdata->active_index;
> +   mdata->active_index = active_idx;
> +
> +   /*
> +* Calculate the crc32 for the updated FWU metadata
> +* and put the updated value in the FWU metadata crc32
> +* field
> +*/
> +   buf = &mdata->version;
> +   mdata->crc32 = crc32(0, buf, sizeof(*mdata) - sizeof(u32));

I would like to suggest moving this crc32 calculation in the fwu_update_mdata().
If the crc32 is for detecting a broken metadata on the "storage
media", I think it should be calculated in the fwu_update_mdata() to
simplify the code and avoid unexpected bugs from mistakes. If the
crc32 is calculated right before updating metadata, we can ensure that
the crc32 is always sane except for someone breaking it on the storage
media.

Thank you,



-- 
Masami Hiramatsu

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Sughosh Ganu]

hi Masami,

On Tue, 8 Feb 2022 at 15:04, Masami Hiramatsu
 wrote:
>
> Hi Sughosh,
>
> Thanks for updating the series. I have some comment on this patch.
>
> 2022年2月8日(火) 3:21 Sughosh Ganu :
> [snip]
> > +
> > +/**
> > + * fwu_get_active_index() - Get active_index from the FWU metadata
> > + * @active_idx: active_index value to be read
> > + *
> > + * Read the active_index field from the FWU metadata and place it in
> > + * the variable pointed to be the function argument.
> > + *
> > + * Return: 0 if OK, -ve on error
> > + *
> > + */
> > +int fwu_get_active_index(u32 *active_idx)
> > +{
> > +   int ret;
> > +   struct fwu_mdata *mdata = NULL;
> > +
> > +   ret = fwu_get_mdata(&mdata);
> > +   if (ret < 0) {
> > +   log_err("Unable to get valid FWU metadata\n");
> > +   goto out;
>
> Again, as we discussed previous series, please don't return unused
> allocated memory if the function returns an error.
> That is something like putting a burden on the callers. They always
> needs to initialize the pointer before call and free it even if the
> function is failed.

I would like to keep the convention consistent. The function that
declares the pointer will also be responsible for free'ing it up. I
find the alternative to be more confusing, where in some instances the
callee frees up the memory, while in some cases it is the caller that
frees it up. If there is no stated convention in u-boot which forbids
this style of memory handling, I would like to keep this as is. I
would say that this makes the implementation easier for the callee,
since it is the responsibility of the caller to free up the memory.

>
> > +   }
> > +
> > +   /*
> > +* Found the FWU metadata partition, now read the active_index
> > +* value
> > +*/
> > +   *active_idx = mdata->active_index;
> > +   if (*active_idx > CONFIG_FWU_NUM_BANKS - 1) {
> > +   log_err("Active index value read is incorrect\n");
> > +   ret = -EINVAL;
> > +   }
> > +
> > +out:
> > +   free(mdata);
> > +
> > +   return ret;
> > +}
> > +
> > +/**
> > + * fwu_update_active_index() - Update active_index from the FWU metadata
> > + * @active_idx: active_index value to be updated
> > + *
> > + * Update the active_index field in the FWU metadata
> > + *
> > + * Return: 0 if OK, -ve on error
> > + *
> > + */
> > +int fwu_update_active_index(u32 active_idx)
> > +{
> > +   int ret;
> > +   void *buf;
> > +   struct fwu_mdata *mdata = NULL;
> > +
> > +   if (active_idx > CONFIG_FWU_NUM_BANKS - 1) {
> > +   log_err("Active index value to be updated is incorrect\n");
> > +   return -1;
> > +   }
> > +
> > +   ret = fwu_get_mdata(&mdata);
> > +   if (ret < 0) {
> > +   log_err("Unable to get valid FWU metadata\n");
> > +   goto out;
> > +   }
> > +
> > +   /*
> > +* Update the active index and previous_active_index fields
> > +* in the FWU metadata
> > +*/
> > +   mdata->previous_active_index = mdata->active_index;
> > +   mdata->active_index = active_idx;
> > +
> > +   /*
> > +* Calculate the crc32 for the updated FWU metadata
> > +* and put the updated value in the FWU metadata crc32
> > +* field
> > +*/
> > +   buf = &mdata->version;
> > +   mdata->crc32 = crc32(0, buf, sizeof(*mdata) - sizeof(u32));
>
> I would like to suggest moving this crc32 calculation in the 
> fwu_update_mdata().
> If the crc32 is for detecting a broken metadata on the "storage
> media", I think it should be calculated in the fwu_update_mdata() to
> simplify the code and avoid unexpected bugs from mistakes. If the
> crc32 is calculated right before updating metadata, we can ensure that
> the crc32 is always sane except for someone breaking it on the storage
> media.

Makes sense. I will make the change as you are suggesting. Thanks.

-sughosh

>
> Thank you,
>
>
>
> --
> Masami Hiramatsu

[PATCH] arm: pdu001: Fix dt to work with the current am33xx dtsi files

[Felix Brack]

The changes introduced with commit 6337d53fdf45 ("arm: dts: sync am33xx
with Linux 5.9-rc7") prevent the PDU001 from operating correctly.
This patch fixes the configuration of the pin multiplexer and uart3.

Signed-off-by: Felix Brack 
---

 arch/arm/dts/am335x-pdu001-u-boot.dtsi | 20 ++--
 configs/am335x_pdu001_defconfig|  4 
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/am335x-pdu001-u-boot.dtsi 
b/arch/arm/dts/am335x-pdu001-u-boot.dtsi
index 686a152fd9..f1860ee3e4 100644
--- a/arch/arm/dts/am335x-pdu001-u-boot.dtsi
+++ b/arch/arm/dts/am335x-pdu001-u-boot.dtsi
@@ -5,17 +5,25 @@
 
 #include "am33xx-u-boot.dtsi"
 
-/ {
-   ocp {
-   u-boot,dm-pre-reloc;
-   };
-};
-
 &l4_wkup {
u-boot,dm-pre-reloc;
+   segment@20 {
+
+   target-module@1 {
+   u-boot,dm-pre-reloc;
+   };
+   };
 };
 
 &l4_per {
+   u-boot,dm-pre-reloc;
+   segment@10 {
+   u-boot,dm-pre-reloc;
+
+   target-module@a6000 {
+   u-boot,dm-pre-reloc;
+   };
+   };
 
segment@30 {
 
diff --git a/configs/am335x_pdu001_defconfig b/configs/am335x_pdu001_defconfig
index 1c4c711858..1381cc7f9c 100644
--- a/configs/am335x_pdu001_defconfig
+++ b/configs/am335x_pdu001_defconfig
@@ -35,8 +35,10 @@ CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SYS_MALLOC_F_LEN=0x1200
 # CONFIG_NET is not set
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
@@ -45,6 +47,8 @@ CONFIG_MMC_OMAP_HS=y
 CONFIG_MMC_SDHCI=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_SINGLE=y
+CONFIG_CLK=y
+CONFIG_CLK_TI_CTRL=y
 CONFIG_DM_PMIC=y
 CONFIG_DM_PMIC_TPS65910=y
 CONFIG_DM_REGULATOR=y
-- 
2.25.1

Re: [PATCH v4 07/11] FWU: Add boot time checks as highlighted by the FWU specification

[Michal Simek]

po 7. 2. 2022 v 19:22 odesílatel Sughosh Ganu  napsal:
>
> The FWU Multi Bank Update specification requires the Update Agent to
> carry out certain checks at the time of platform boot. The Update
> Agent is the component which is responsible for updating the firmware
> components and maintaining and keeping the metadata in sync.
>
> The spec requires that the Update Agent perform the following checks
> at the time of boot
> * Sanity check of both the metadata copies maintained by the platform.
> * Get the boot index passed to U-Boot by the prior stage bootloader
>   and use this value for metadata bookkeeping.
> * Check if the system is booting in Trial State. If the system boots
>   in the Trial State for more than a specified number of boot counts,
>   change the Active Bank to be booting the platform from.
>
> Add these checks in the board initialisation sequence, invoked after
> relocation.
>
> Signed-off-by: Sughosh Ganu 
> ---
>
> Changes since V3:
> * Change the TrialStateCtr efi variable attribute to remove the
>   runtime attribute
>
>  common/board_r.c  |   6 ++
>  include/fwu.h |   3 +
>  lib/fwu_updates/fwu.c | 178 ++
>  3 files changed, 187 insertions(+)
>  create mode 100644 lib/fwu_updates/fwu.c
>
> diff --git a/common/board_r.c b/common/board_r.c
> index 31a59c585a..81678870b9 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -78,6 +78,9 @@
>  #ifdef CONFIG_EFI_SETUP_EARLY
>  #include 
>  #endif
> +#ifdef CONFIG_FWU_MULTI_BANK_UPDATE
> +#include 
> +#endif
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> @@ -805,6 +808,9 @@ static init_fnc_t init_sequence_r[] = {
>  #endif
>  #ifdef CONFIG_EFI_SETUP_EARLY
> (init_fnc_t)efi_init_obj_list,
> +#endif
> +#ifdef CONFIG_FWU_MULTI_BANK_UPDATE
> +   fwu_boottime_checks,
>  #endif
> run_main_loop,
>  };
> diff --git a/include/fwu.h b/include/fwu.h
> index 90b8cd41e5..5a329d9ef7 100644
> --- a/include/fwu.h
> +++ b/include/fwu.h
> @@ -37,6 +37,9 @@ struct fwu_mdata_ops {
> EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
>  0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
>
> +int fwu_boottime_checks(void);
> +u8 fwu_update_checks_pass(void);
> +
>  int fwu_get_mdata(struct fwu_mdata **mdata);
>  int fwu_update_mdata(struct fwu_mdata *mdata);
>  int fwu_get_active_index(u32 *active_idx);
> diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
> new file mode 100644
> index 00..86933123e7
> --- /dev/null
> +++ b/lib/fwu_updates/fwu.c
> @@ -0,0 +1,178 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2021, Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static u8 trial_state = 0;
> +static u8 boottime_check = 0;

you don't need to initialize them to 0. They are in bss which is setup
to 0 already.

> +
> +static int fwu_trial_state_check(void)
> +{
> +   int ret, i;
> +   efi_status_t status;
> +   efi_uintn_t var_size;
> +   u16 trial_state_ctr;
> +   u32 nimages, active_bank, var_attributes, active_idx;
> +   struct fwu_mdata *mdata = NULL;
> +   struct fwu_image_entry *img_entry;
> +   struct fwu_image_bank_info *img_bank_info;
> +
> +   ret = fwu_get_mdata(&mdata);
> +   if (ret < 0)

Isn't it easier to have if (ret) here?

> +   return ret;
> +
> +   ret = 0;

Then you can remove this and the whole ret handling below is weird.


> +   nimages = CONFIG_FWU_NUM_IMAGES_PER_BANK;
> +   active_bank = mdata->active_index;
> +   img_entry = &mdata->img_entry[0];
> +   for (i = 0; i < nimages; i++) {
> +   img_bank_info = &img_entry[i].img_bank_info[active_bank];
> +   if (!img_bank_info->accepted) {
> +   trial_state = 1;
> +   break;
> +   }
> +   }
> +
> +   if (trial_state) {
> +   var_size = (efi_uintn_t)sizeof(trial_state_ctr);
> +   log_info("System booting in Trial State\n");
> +   var_attributes = EFI_VARIABLE_NON_VOLATILE |
> +   EFI_VARIABLE_BOOTSERVICE_ACCESS;
> +   status = efi_get_variable_int(L"TrialStateCtr",
> + &efi_global_variable_guid,
> + &var_attributes,
> + &var_size, &trial_state_ctr,
> + NULL);
> +   if (status != EFI_SUCCESS) {
> +   log_err("Unable to read TrialStateCtr variable\n");
> +   ret = -1;

Any reason not to use standard return macros? The same I see below too.

> +   goto out;
> +   }
> +
> +   ++trial_state_ctr;
> +   if (trial_state_ctr > CONFIG_FWU_TRIAL_STATE_CNT) {
> +   log_info(

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Michal Simek]

po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  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 
> ---
>
> 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 00..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.

> +
> +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

Re: [PATCH v4 00/11] FWU: Add support for FWU Multi Bank Update feature

[Michal Simek]

po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  napsal:
>
>
>
> The patchset adds support for the FWU Multi Bank Update[1]
> feature. Certain aspects of the Dependable Boot[2] specification have
> also been implemented.
>
> The FWU multi bank update feature is used for supporting multiple
> sets(also called banks) of firmware image(s), allowing the platform to
> boot from a different bank, in case it fails to boot from the active
> bank. This functionality is supported by keeping the relevant
> information in a structure called metadata, which provides information
> on the images. Among other parameters, the metadata structure contains
> information on the currect active bank that is being used to boot
> image(s).
>
> Functionality is being added to work with the UEFI capsule driver in
> u-boot. The metadata is read to gather information on the update bank,
> which is the bank to which the firmware images would be flashed to. On
> a successful completion of the update of all components, the active
> bank field in the metadata is updated, to reflect the bank from which
> the platform will boot on the subsequent boots.
>
> Currently, the feature is being enabled on the STM32MP157C-DK2
> board which boots a FIP image from a uSD card partitioned with the GPT
> partioning scheme. This also requires changes in the previous stage of
> bootloader, which parses the metadata and selects the bank to boot the
> image(s) from. Support is being added in tf-a(BL2 stage) for the
> STM32MP157C-DK2 board to boot the active bank images. These changes
> have been merged to the upstream tf-a's integration branch[3].
>
> These patches are based on top of the series from Takahiro to add
> Authentication support to mkeficapsule utility[4] and a couple of
> other patches[5][6]
>
> TODO's
> --
> * Add a unit test case for the newly added FWU_MDATA uclass. Some
>   involved effort is needed on this since the host device interface on
>   sandbox cannot be used with the UT framework.
> * Add test case for the feature with the python test suite, along the
>   lines of capsule update testing.
>
> [1] - https://developer.arm.com/documentation/den0118/a
> [2] - 
> https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf
> [3] - 
> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/log/?h=integration
> [4] - https://patchwork.ozlabs.org/project/uboot/list/?series=281549
> [5] - 
> https://patchwork.ozlabs.org/project/uboot/patch/164388019634.446835.18271480521485569016.stgit@localhost/
> [6] - 
> https://patchwork.ozlabs.org/project/uboot/patch/20220129192108.6618-1-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
> * Move the metadata access driver for GPT partitioned block devices
>   under drivers/fwu-mdata/ directory, complying with driver model.
> * Move functionality to get the active index under the common function
>   instead of the GPT block device specific driver.
> * Remove function for getting the storage device containing the
>   metadata as the information is now obtained from the device tree.
> * Define a weak function fill_image_type_guid_array for populating the
>   image descriptor array with u-boot's raw and fit image GUIDs
> * Define the function fill_image_type_guid_array for the ST DK2 board
>   for GPT partitioned devices.
> * Change the TrialStateCtr efi variable attribute to remove the
>   runtime attribute
> * Rebase the change on top of the patch from Masami to call
>   efi_capsule_update_firmware directly.
> * Put the FWU related checks which were earlier in efi_update_capsule
>   function to separate functions fwu_empty_capsule and
>   fwu_empty_capsule_process.
> * Use the device model api uclass_get_device to probe and get the FWU
>   Metadata device.
> * Add related documentation for empty capsules in the mkeficapsule man
>   page.
> * Add separate usage for empty capsules, with corresponding valid
>   options.
> * Use ternary operators where possible.
> * Put a exclusivity check for the empty capsule options.
>
>
> Sughosh Ganu (11):
>   FWU: Add FWU metadata structure and driver for accessing metadata
>   FWU: Add FWU metadata access driver for GPT partitioned block devices
>   FWU: stm32mp1: Add helper functions for accessing FWU metadata
>   FWU: STM32MP1: Add support to read boot index from backup register
>   EFI: FMP: Add provision to update image's ImageTypeId in image
> descriptor
>   stm32mp1: Populate ImageTypeId values in EFI_FIRMWARE_IMAGE_DESCRIPTOR
> array
>   FWU: Add boot time checks as highlighted by the FWU specification
>   FWU: Add support for FWU Multi Bank Update feature
>   FWU: cmd: Add a command to read FWU metadata
>   mkeficapsule: Add support for generating empty capsules
>   FWU: doc: Add documentation for the FWU feature
>
>  arch/arm/dts/stm32

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Masami Hiramatsu]

Hi Sughosh,

2022年2月8日(火) 19:24 Sughosh Ganu :
>
> hi Masami,
>
> On Tue, 8 Feb 2022 at 15:04, Masami Hiramatsu
>  wrote:
> >
> > Hi Sughosh,
> >
> > Thanks for updating the series. I have some comment on this patch.
> >
> > 2022年2月8日(火) 3:21 Sughosh Ganu :
> > [snip]
> > > +
> > > +/**
> > > + * fwu_get_active_index() - Get active_index from the FWU metadata
> > > + * @active_idx: active_index value to be read
> > > + *
> > > + * Read the active_index field from the FWU metadata and place it in
> > > + * the variable pointed to be the function argument.
> > > + *
> > > + * Return: 0 if OK, -ve on error
> > > + *
> > > + */
> > > +int fwu_get_active_index(u32 *active_idx)
> > > +{
> > > +   int ret;
> > > +   struct fwu_mdata *mdata = NULL;
> > > +
> > > +   ret = fwu_get_mdata(&mdata);
> > > +   if (ret < 0) {
> > > +   log_err("Unable to get valid FWU metadata\n");
> > > +   goto out;
> >
> > Again, as we discussed previous series, please don't return unused
> > allocated memory if the function returns an error.
> > That is something like putting a burden on the callers. They always
> > needs to initialize the pointer before call and free it even if the
> > function is failed.
>
> I would like to keep the convention consistent. The function that
> declares the pointer will also be responsible for free'ing it up. I
> find the alternative to be more confusing, where in some instances the
> callee frees up the memory, while in some cases it is the caller that
> frees it up. If there is no stated convention in u-boot which forbids
> this style of memory handling, I would like to keep this as is. I
> would say that this makes the implementation easier for the callee,
> since it is the responsibility of the caller to free up the memory.

Hmm, ... I'm not convinced yet. Please give me the last chance to argue.
I think the pointer is the pointer, that is not the resource itself.

Please see `man asprintf` for example.
Usually, if the function, which allocates any resource including
memory, returns an error, the resource pointer is undefined.
Of course, there is no need to unallocate the memory for
undefined address.
That is I think the standard way to handle the resource
allocation.

And actually, the callee implementation isn't simplified. In my
case, it forces me to re-initialize the pointer to NULL if an error
occurs. additional 1-line is needed :-) (maybe I need more
comment lines to explain why this NULL setting is required)

BTW, I attached a patch to change this code. You can see
the gpt_get_mdata() is refined into 2 gpt_get_mdata_part()
and many gotos are removed.
This shows how both of callee and caller can be simplified
with the convention which I suggested.

Thank you,

-- 
Masami Hiramatsu
From 695b4276283654bcf0440889cf214b887174345d Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu 
Date: Thu, 20 Jan 2022 15:41:49 +0900
Subject: [PATCH] FWU: Free metadata copy if gpt_get_mdata() failed

It is better if a function which returns an error then release
all allocated memory resources. This simplifies the mind model
and less chance to forgot to free memory and double free.

Signed-off-by: Masami Hiramatsu 
---
 drivers/fwu-mdata/fwu-mdata-uclass.c  | 24 +
 drivers/fwu-mdata/fwu_mdata_gpt_blk.c | 49 +++
 2 files changed, 36 insertions(+), 37 deletions(-)

diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c b/drivers/fwu-mdata/fwu-mdata-uclass.c
index fad44b25d1..512ce157e9 100644
--- a/drivers/fwu-mdata/fwu-mdata-uclass.c
+++ b/drivers/fwu-mdata/fwu-mdata-uclass.c
@@ -79,12 +79,12 @@ int fwu_verify_mdata(struct fwu_mdata *mdata, bool pri_part)
 int fwu_get_active_index(u32 *active_idx)
 {
 	int ret;
-	struct fwu_mdata *mdata = NULL;
+	struct fwu_mdata *mdata;
 
 	ret = fwu_get_mdata(&mdata);
 	if (ret < 0) {
 		log_err("Unable to get valid FWU metadata\n");
-		goto out;
+		return ret;
 	}
 
 	/*
@@ -96,8 +96,6 @@ int fwu_get_active_index(u32 *active_idx)
 		log_err("Active index value read is incorrect\n");
 		ret = -EINVAL;
 	}
-
-out:
 	free(mdata);
 
 	return ret;
@@ -115,17 +113,17 @@ out:
 int fwu_update_active_index(u32 active_idx)
 {
 	int ret;
-	struct fwu_mdata *mdata = NULL;
+	struct fwu_mdata *mdata;
 
 	if (active_idx > CONFIG_FWU_NUM_BANKS - 1) {
 		log_err("Active index value to be updated is incorrect\n");
-		return -1;
+		return -EINVAL;
 	}
 
 	ret = fwu_get_mdata(&mdata);
 	if (ret < 0) {
 		log_err("Unable to get valid FWU metadata\n");
-		goto out;
+		return ret;
 	}
 
 	/*
@@ -144,8 +142,6 @@ int fwu_update_active_index(u32 active_idx)
 		log_err("Failed to update FWU metadata partitions\n");
 		ret = -EIO;
 	}
-
-out:
 	free(mdata);
 
 	return ret;
@@ -225,12 +221,12 @@ int fwu_revert_boot_index(void)
 {
 	int ret;
 	u32 cur_active_index;
-	struct fwu_mdata *mdata = NULL;
+	struct fwu_mdata *mdata;
 
 	ret = fwu_get_mdata(&mdata);
 	if (ret < 0) {
 		log_err("Unable to get valid FWU metadata\n");
-		goto out;
+		

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Michal Simek]

po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  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 
> ---
>
> 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 00..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.
> +
> +Example :
> +   fwu-mdata {
> +   compatible = "u-boot,fwu-mdata";
> +   fwu-mdata-store = <&sdmmc1>;
> +   };
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index b26ca8cf70..adc6079ecf 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -42,6 +42,8 @@ source "drivers/firmware/Kconfig"
>
>  source "drivers/fpga/Kconfig"
>
> +source "drivers/fwu-mdata/Kconfig"
> +
>  source "drivers/gpio/Kconfig"
>
>  source "drivers/hwspinlock/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 4e7cf28440..56f0f04874 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -81,6 +81,7 @@ obj-y += cache/
>  obj-$(CONFIG_CPU) += cpu/
>  obj-y += crypto/
>  obj-$(CONFIG_FASTBOOT) += fastboot/
> +obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata/
>  obj-y += misc/
>  obj-$(CONFIG_MMC) += mmc/
>  obj-$(CONFIG_NVME) += nvme/
> diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
> new file mode 100644
> index 00..d6a21c8e19
> --- /dev/null
> +++ b/drivers/fwu-mdata/Kconfig
> @@ -0,0 +1,7 @@
> +config DM_FWU_MDATA
> +   bool "Driver support for accessing FWU Metadata"
> +   depends on DM
> +   help
> + Enable support for accessing FWU Metadata partitions. The
> + FWU Metadata partitions reside on the same storage device
> + which contains the other FWU updatable firmware images.
> diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
> new file mode 100644
> index 00..7fec7171f4
> --- /dev/null
> +++ b/drivers/fwu-mdata/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (c) 2022, Linaro Limited
> +#
> +
> +obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o
> diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c 
> b/drivers/fwu-mdata/fwu-mdata-uclass.c
> new file mode 100644
> index 00..64b3051ecf

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Sughosh Ganu]

On Tue, 8 Feb 2022 at 16:26, Michal Simek  wrote:
>
> po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  
> 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 
> > ---
> >
> > 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 00..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 
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

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Sughosh Ganu]

On Tue, 8 Feb 2022 at 17:01, Michal Simek  wrote:
>
> po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  
> 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 
> > ---
> >
> > 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 00..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.
> > +
> > +Example :
> > +   fwu-mdata {
> > +   compatible = "u-boot,fwu-mdata";
> > +   fwu-mdata-store = <&sdmmc1>;
> > +   };
> > diff --git a/drivers/Kconfig b/drivers/Kconfig
> > index b26ca8cf70..adc6079ecf 100644
> > --- a/drivers/Kconfig
> > +++ b/drivers/Kconfig
> > @@ -42,6 +42,8 @@ source "drivers/firmware/Kconfig"
> >
> >  source "drivers/fpga/Kconfig"
> >
> > +source "drivers/fwu-mdata/Kconfig"
> > +
> >  source "drivers/gpio/Kconfig"
> >
> >  source "drivers/hwspinlock/Kconfig"
> > diff --git a/drivers/Makefile b/drivers/Makefile
> > index 4e7cf28440..56f0f04874 100644
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -81,6 +81,7 @@ obj-y += cache/
> >  obj-$(CONFIG_CPU) += cpu/
> >  obj-y += crypto/
> >  obj-$(CONFIG_FASTBOOT) += fastboot/
> > +obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata/
> >  obj-y += misc/
> >  obj-$(CONFIG_MMC) += mmc/
> >  obj-$(CONFIG_NVME) += nvme/
> > diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
> > new file mode 100644
> > index 00..d6a21c8e19
> > --- /dev/null
> > +++ b/drivers/fwu-mdata/Kconfig
> > @@ -0,0 +1,7 @@
> > +config DM_FWU_MDATA
> > +   bool "Driver support for accessing FWU Metadata"
> > +   depends on DM
> > +   help
> > + Enable support for accessing FWU Metadata partitions. The
> > + FWU Metadata partitions reside on the same storage device
> > + which contains the other FWU updatable firmware images.
> > diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
> > new file mode 100644
> > index 00..7fec7171f4
> > --- /dev/null
> > +++ b/drivers/fwu-mdata/Makefile
> > @

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Michal Simek]

On 2/8/22 12:35, Sughosh Ganu wrote:

On Tue, 8 Feb 2022 at 16:26, Michal Simek  wrote:


po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  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 
---

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 00..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 
tuples which can then list the device and partition number of the
metadata partitions.


I think you should list all possible devices which can be used to have generic 
description for it. It is sort of the same list of devices which could be used 
for storing u-boot internal variables.

That's why the same description can be used for it too.

Thanks,
Michal

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Michal Simek]

On 2/8/22 12:38, Sughosh Ganu wrote:

On Tue, 8 Feb 2022 at 17:01, Michal Simek  wrote:


po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  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 
---

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 00..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.
+
+Example :
+   fwu-mdata {
+   compatible = "u-boot,fwu-mdata";
+   fwu-mdata-store = <&sdmmc1>;
+   };
diff --git a/drivers/Kconfig b/drivers/Kconfig
index b26ca8cf70..adc6079ecf 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -42,6 +42,8 @@ source "drivers/firmware/Kconfig"

  source "drivers/fpga/Kconfig"

+source "drivers/fwu-mdata/Kconfig"
+
  source "drivers/gpio/Kconfig"

  source "drivers/hwspinlock/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 4e7cf28440..56f0f04874 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -81,6 +81,7 @@ obj-y += cache/
  obj-$(CONFIG_CPU) += cpu/
  obj-y += crypto/
  obj-$(CONFIG_FASTBOOT) += fastboot/
+obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata/
  obj-y += misc/
  obj-$(CONFIG_MMC) += mmc/
  obj-$(CONFIG_NVME) += nvme/
diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
new file mode 100644
index 00..d6a21c8e19
--- /dev/null
+++ b/drivers/fwu-mdata/Kconfig
@@ -0,0 +1,7 @@
+config DM_FWU_MDATA
+   bool "Driver support for accessing FWU Metadata"
+   depends on DM
+   help
+ Enable support for accessing FWU Metadata partitions. The
+ FWU Metadata partitions reside on the same storage device
+ which contains the other FWU updatable firmware images.
diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
new file mode 100644
index 00..7fec7171f4
--- /dev/null
+++ b/drivers/fwu-mdata/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2022, Linaro Limited
+#
+
+obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o
diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c 
b/drivers/fwu-mdata/fwu-mdata-uclass.c
new file mode 100644
index 00..64b3051ecf
--- /dev/null
+++ b/drivers/fwu-mdata/fwu-mdata-uclass.c
@@ -0,0 +1,434 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Sughosh Ganu]

On Tue, 8 Feb 2022 at 17:15, Michal Simek  wrote:
>
>
>
> On 2/8/22 12:38, Sughosh Ganu wrote:
> > On Tue, 8 Feb 2022 at 17:01, Michal Simek  wrote:
> >>
> >> po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  
> >> 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 
> >>> ---
> >>>
> >>> 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 00..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.
> >>> +
> >>> +Example :
> >>> +   fwu-mdata {
> >>> +   compatible = "u-boot,fwu-mdata";
> >>> +   fwu-mdata-store = <&sdmmc1>;
> >>> +   };
> >>> diff --git a/drivers/Kconfig b/drivers/Kconfig
> >>> index b26ca8cf70..adc6079ecf 100644
> >>> --- a/drivers/Kconfig
> >>> +++ b/drivers/Kconfig
> >>> @@ -42,6 +42,8 @@ source "drivers/firmware/Kconfig"
> >>>
> >>>   source "drivers/fpga/Kconfig"
> >>>
> >>> +source "drivers/fwu-mdata/Kconfig"
> >>> +
> >>>   source "drivers/gpio/Kconfig"
> >>>
> >>>   source "drivers/hwspinlock/Kconfig"
> >>> diff --git a/drivers/Makefile b/drivers/Makefile
> >>> index 4e7cf28440..56f0f04874 100644
> >>> --- a/drivers/Makefile
> >>> +++ b/drivers/Makefile
> >>> @@ -81,6 +81,7 @@ obj-y += cache/
> >>>   obj-$(CONFIG_CPU) += cpu/
> >>>   obj-y += crypto/
> >>>   obj-$(CONFIG_FASTBOOT) += fastboot/
> >>> +obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata/
> >>>   obj-y += misc/
> >>>   obj-$(CONFIG_MMC) += mmc/
> >>>   obj-$(CONFIG_NVME) += nvme/
> >>> diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
> >>> new file mode 100644
> >>> index 00..d6a21c8e19
> >>> --- /dev/null
> >>> +++ b/drivers/fwu-mdata/Kconfig
> >>> @@ -0,0 +1,7 @@
> >>> +config DM_FWU_MDATA
> >>> +   bool "Driver support for accessing FWU Metadata"
> >>> +   depends on DM
> >>> +   help
> >>> + Enable support for a

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Michal Simek]

On 2/8/22 12:54, Sughosh Ganu wrote:

On Tue, 8 Feb 2022 at 17:15, Michal Simek  wrote:




On 2/8/22 12:38, Sughosh Ganu wrote:

On Tue, 8 Feb 2022 at 17:01, Michal Simek  wrote:


po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  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 
---

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 00..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.
+
+Example :
+   fwu-mdata {
+   compatible = "u-boot,fwu-mdata";
+   fwu-mdata-store = <&sdmmc1>;
+   };
diff --git a/drivers/Kconfig b/drivers/Kconfig
index b26ca8cf70..adc6079ecf 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -42,6 +42,8 @@ source "drivers/firmware/Kconfig"

   source "drivers/fpga/Kconfig"

+source "drivers/fwu-mdata/Kconfig"
+
   source "drivers/gpio/Kconfig"

   source "drivers/hwspinlock/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 4e7cf28440..56f0f04874 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -81,6 +81,7 @@ obj-y += cache/
   obj-$(CONFIG_CPU) += cpu/
   obj-y += crypto/
   obj-$(CONFIG_FASTBOOT) += fastboot/
+obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata/
   obj-y += misc/
   obj-$(CONFIG_MMC) += mmc/
   obj-$(CONFIG_NVME) += nvme/
diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
new file mode 100644
index 00..d6a21c8e19
--- /dev/null
+++ b/drivers/fwu-mdata/Kconfig
@@ -0,0 +1,7 @@
+config DM_FWU_MDATA
+   bool "Driver support for accessing FWU Metadata"
+   depends on DM
+   help
+ Enable support for accessing FWU Metadata partitions. The
+ FWU Metadata partitions reside on the same storage device
+ which contains the other FWU updatable firmware images.
diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
new file mode 100644
index 00..7fec7171f4
--- /dev/null
+++ b/drivers/fwu-mdata/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2022, Linaro Limited
+#
+
+obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o
diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c 
b/drivers/fwu-mdata/fwu-mdata-uclass.c
new file mode 100644
index 00..64b3051ecf
--- /dev/null

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Sughosh Ganu]

On Tue, 8 Feb 2022 at 17:29, Michal Simek  wrote:
>
>
>
> On 2/8/22 12:54, Sughosh Ganu wrote:
> > On Tue, 8 Feb 2022 at 17:15, Michal Simek  wrote:
> >>
> >>
> >>
> >> On 2/8/22 12:38, Sughosh Ganu wrote:
> >>> On Tue, 8 Feb 2022 at 17:01, Michal Simek  wrote:
> 
>  po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  
>  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 
> > ---
> >
> > 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 00..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.
> > +
> > +Example :
> > +   fwu-mdata {
> > +   compatible = "u-boot,fwu-mdata";
> > +   fwu-mdata-store = <&sdmmc1>;
> > +   };
> > diff --git a/drivers/Kconfig b/drivers/Kconfig
> > index b26ca8cf70..adc6079ecf 100644
> > --- a/drivers/Kconfig
> > +++ b/drivers/Kconfig
> > @@ -42,6 +42,8 @@ source "drivers/firmware/Kconfig"
> >
> >source "drivers/fpga/Kconfig"
> >
> > +source "drivers/fwu-mdata/Kconfig"
> > +
> >source "drivers/gpio/Kconfig"
> >
> >source "drivers/hwspinlock/Kconfig"
> > diff --git a/drivers/Makefile b/drivers/Makefile
> > index 4e7cf28440..56f0f04874 100644
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -81,6 +81,7 @@ obj-y += cache/
> >obj-$(CONFIG_CPU) += cpu/
> >obj-y += crypto/
> >obj-$(CONFIG_FASTBOOT) += fastboot/
> > +obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata/
> >obj-y += misc/
> >obj-$(CONFIG_MMC) += mmc/
> >obj-$(CONFIG_NVME) += nvme/
> > diff --git 

Re: [PATCH v4 00/11] FWU: Add support for FWU Multi Bank Update feature

[Sughosh Ganu]

On Tue, 8 Feb 2022 at 16:36, Michal Simek  wrote:
>
> po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  
> napsal:
> >
> >
> >
> > The patchset adds support for the FWU Multi Bank Update[1]
> > feature. Certain aspects of the Dependable Boot[2] specification have
> > also been implemented.
> >
> > The FWU multi bank update feature is used for supporting multiple
> > sets(also called banks) of firmware image(s), allowing the platform to
> > boot from a different bank, in case it fails to boot from the active
> > bank. This functionality is supported by keeping the relevant
> > information in a structure called metadata, which provides information
> > on the images. Among other parameters, the metadata structure contains
> > information on the currect active bank that is being used to boot
> > image(s).
> >
> > Functionality is being added to work with the UEFI capsule driver in
> > u-boot. The metadata is read to gather information on the update bank,
> > which is the bank to which the firmware images would be flashed to. On
> > a successful completion of the update of all components, the active
> > bank field in the metadata is updated, to reflect the bank from which
> > the platform will boot on the subsequent boots.
> >
> > Currently, the feature is being enabled on the STM32MP157C-DK2
> > board which boots a FIP image from a uSD card partitioned with the GPT
> > partioning scheme. This also requires changes in the previous stage of
> > bootloader, which parses the metadata and selects the bank to boot the
> > image(s) from. Support is being added in tf-a(BL2 stage) for the
> > STM32MP157C-DK2 board to boot the active bank images. These changes
> > have been merged to the upstream tf-a's integration branch[3].
> >
> > These patches are based on top of the series from Takahiro to add
> > Authentication support to mkeficapsule utility[4] and a couple of
> > other patches[5][6]
> >
> > TODO's
> > --
> > * Add a unit test case for the newly added FWU_MDATA uclass. Some
> >   involved effort is needed on this since the host device interface on
> >   sandbox cannot be used with the UT framework.
> > * Add test case for the feature with the python test suite, along the
> >   lines of capsule update testing.
> >
> > [1] - https://developer.arm.com/documentation/den0118/a
> > [2] - 
> > https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf
> > [3] - 
> > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/log/?h=integration
> > [4] - https://patchwork.ozlabs.org/project/uboot/list/?series=281549
> > [5] - 
> > https://patchwork.ozlabs.org/project/uboot/patch/164388019634.446835.18271480521485569016.stgit@localhost/
> > [6] - 
> > https://patchwork.ozlabs.org/project/uboot/patch/20220129192108.6618-1-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
> > * Move the metadata access driver for GPT partitioned block devices
> >   under drivers/fwu-mdata/ directory, complying with driver model.
> > * Move functionality to get the active index under the common function
> >   instead of the GPT block device specific driver.
> > * Remove function for getting the storage device containing the
> >   metadata as the information is now obtained from the device tree.
> > * Define a weak function fill_image_type_guid_array for populating the
> >   image descriptor array with u-boot's raw and fit image GUIDs
> > * Define the function fill_image_type_guid_array for the ST DK2 board
> >   for GPT partitioned devices.
> > * Change the TrialStateCtr efi variable attribute to remove the
> >   runtime attribute
> > * Rebase the change on top of the patch from Masami to call
> >   efi_capsule_update_firmware directly.
> > * Put the FWU related checks which were earlier in efi_update_capsule
> >   function to separate functions fwu_empty_capsule and
> >   fwu_empty_capsule_process.
> > * Use the device model api uclass_get_device to probe and get the FWU
> >   Metadata device.
> > * Add related documentation for empty capsules in the mkeficapsule man
> >   page.
> > * Add separate usage for empty capsules, with corresponding valid
> >   options.
> > * Use ternary operators where possible.
> > * Put a exclusivity check for the empty capsule options.
> >
> >
> > Sughosh Ganu (11):
> >   FWU: Add FWU metadata structure and driver for accessing metadata
> >   FWU: Add FWU metadata access driver for GPT partitioned block devices
> >   FWU: stm32mp1: Add helper functions for accessing FWU metadata
> >   FWU: STM32MP1: Add support to read boot index from backup register
> >   EFI: FMP: Add provision to update image's ImageTypeId in image
> > descriptor
> >   stm32mp1: Populate ImageTypeId values in EFI_FIRMWARE_IMAGE_DESCRIPTOR
> > array
> >   FWU: Add boot time checks as highlighted by the FWU spec

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Michal Simek]

On 2/8/22 13:07, Sughosh Ganu wrote:

On Tue, 8 Feb 2022 at 17:29, Michal Simek  wrote:




On 2/8/22 12:54, Sughosh Ganu wrote:

On Tue, 8 Feb 2022 at 17:15, Michal Simek  wrote:




On 2/8/22 12:38, Sughosh Ganu wrote:

On Tue, 8 Feb 2022 at 17:01, Michal Simek  wrote:


po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  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 
---

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 00..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.
+
+Example :
+   fwu-mdata {
+   compatible = "u-boot,fwu-mdata";
+   fwu-mdata-store = <&sdmmc1>;
+   };
diff --git a/drivers/Kconfig b/drivers/Kconfig
index b26ca8cf70..adc6079ecf 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -42,6 +42,8 @@ source "drivers/firmware/Kconfig"

source "drivers/fpga/Kconfig"

+source "drivers/fwu-mdata/Kconfig"
+
source "drivers/gpio/Kconfig"

source "drivers/hwspinlock/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 4e7cf28440..56f0f04874 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -81,6 +81,7 @@ obj-y += cache/
obj-$(CONFIG_CPU) += cpu/
obj-y += crypto/
obj-$(CONFIG_FASTBOOT) += fastboot/
+obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata/
obj-y += misc/
obj-$(CONFIG_MMC) += mmc/
obj-$(CONFIG_NVME) += nvme/
diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
new file mode 100644
index 00..d6a21c8e19
--- /dev/null
+++ b/drivers/fwu-mdata/Kconfig
@@ -0,0 +1,7 @@
+config DM_FWU_MDATA
+   bool "Driver support for accessing FWU Metadata"
+   depends on DM
+   help
+ Enable support for accessing FWU Metadata partitions. The
+ FWU Metadata partitions reside on the same storage device
+ which contains the other FWU updatable firmware images.
diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
new file mode 100644
index 00..7fec7171f4
--- /dev/null
+++ b/drivers/fwu-mdata/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2022, Linaro Limited
+#
+
+obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o
diff --git a/drivers/fwu-mdata/fw

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Sughosh Ganu]

On Tue, 8 Feb 2022 at 17:44, Michal Simek  wrote:
>
>
>
> On 2/8/22 13:07, Sughosh Ganu wrote:
> > On Tue, 8 Feb 2022 at 17:29, Michal Simek  wrote:
> >>
> >>
> >>
> >> On 2/8/22 12:54, Sughosh Ganu wrote:
> >>> On Tue, 8 Feb 2022 at 17:15, Michal Simek  wrote:
> 
> 
> 
>  On 2/8/22 12:38, Sughosh Ganu wrote:
> > On Tue, 8 Feb 2022 at 17:01, Michal Simek  wrote:
> >>
> >> po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu 
> >>  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 
> >>> ---
> >>>
> >>> 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 00..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.
> >>> +
> >>> +Example :
> >>> +   fwu-mdata {
> >>> +   compatible = "u-boot,fwu-mdata";
> >>> +   fwu-mdata-store = <&sdmmc1>;
> >>> +   };
> >>> diff --git a/drivers/Kconfig b/drivers/Kconfig
> >>> index b26ca8cf70..adc6079ecf 100644
> >>> --- a/drivers/Kconfig
> >>> +++ b/drivers/Kconfig
> >>> @@ -42,6 +42,8 @@ source "drivers/firmware/Kconfig"
> >>>
> >>> source "drivers/fpga/Kconfig"
> >>>
> >>> +source "drivers/fwu-mdata/Kconfig"
> >>> +
> >>> source "drivers/gpio/Kconfig"
> >>>
> >>> source "drivers/hwspinlock/Kconfig"
> >>> diff --git a/drivers/Makefile b/drivers/Makefile
> >>> index 4e7cf28440..56f0f04874 100644
> >>> --- a/drivers/Makefi

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Masami Hiramatsu]

2022年2月8日(火) 20:35 Sughosh Ganu :
>
> On Tue, 8 Feb 2022 at 16:26, Michal Simek  wrote:
> >
> > po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  
> > 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 
> > > ---
> > >
> > > 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 00..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 
> tuples which can then list the device and partition number of the
> metadata partitions.

Yes, I would like to define new compatible for sf backend, e.g.
"u-boot,fwu-mdata-sf".
It will have the fwu-mdata-store to point the SPI flash device, and
will have a list of offset information for the metadata.

Thank you,



>
> -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



--
Masami Hiramatsu

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Michal Simek]

On 2/8/22 14:36, Masami Hiramatsu wrote:

2022年2月8日(火) 20:35 Sughosh Ganu :


On Tue, 8 Feb 2022 at 16:26, Michal Simek  wrote:


po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  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 
---

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 00..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 
tuples which can then list the device and partition number of the
metadata partitions.


Yes, I would like to define new compatible for sf backend, e.g.
"u-boot,fwu-mdata-sf".


backend is fine. What does this compatible string have to do with it?
I didn't see any fwu-mdata-gpt in this series.


It will have the fwu-mdata-store to point the SPI flash device, and
will have a list of offset information for the metadata.


Can you describe it?

Something like for raw accesses?
fwu-mdta-store = <&qspi 0 >;

Thanks,
Michal

[PATCH v3 0/5] fs/erofs: new filesystem

[Huang Jianan]

Changes since v2:
 - sync up with erofs-utils 1.4;
 - update lib/lz4 to v1.8.3;
 - add test for filesystem functions;

Changes since v1:
 - fix the inconsistency between From and SoB;
 - add missing license header;

Huang Jianan (5):
  fs/erofs: add erofs filesystem support
  lib/lz4: update LZ4 decompressor module
  fs/erofs: add lz4 decompression support
  fs/erofs: add filesystem commands
  test/py: Add tests for the erofs

 MAINTAINERS |   9 +
 cmd/Kconfig |   6 +
 cmd/Makefile|   1 +
 cmd/erofs.c |  42 ++
 configs/sandbox_defconfig   |   1 +
 fs/Kconfig  |   2 +
 fs/Makefile |   1 +
 fs/erofs/Kconfig|  21 +
 fs/erofs/Makefile   |   9 +
 fs/erofs/data.c | 311 +
 fs/erofs/decompress.c   |  78 
 fs/erofs/decompress.h   |  24 +
 fs/erofs/erofs_fs.h | 436 ++
 fs/erofs/fs.c   | 267 +++
 fs/erofs/internal.h | 313 +
 fs/erofs/namei.c| 252 +++
 fs/erofs/super.c| 105 +
 fs/erofs/zmap.c | 601 
 fs/fs.c |  22 +
 include/erofs.h |  19 +
 include/fs.h|   1 +
 include/u-boot/lz4.h|  49 ++
 lib/lz4.c   | 679 
 lib/lz4_wrapper.c   |  23 +-
 test/py/tests/test_fs/test_erofs.py | 211 +
 25 files changed, 3268 insertions(+), 215 deletions(-)
 create mode 100644 cmd/erofs.c
 create mode 100644 fs/erofs/Kconfig
 create mode 100644 fs/erofs/Makefile
 create mode 100644 fs/erofs/data.c
 create mode 100644 fs/erofs/decompress.c
 create mode 100644 fs/erofs/decompress.h
 create mode 100644 fs/erofs/erofs_fs.h
 create mode 100644 fs/erofs/fs.c
 create mode 100644 fs/erofs/internal.h
 create mode 100644 fs/erofs/namei.c
 create mode 100644 fs/erofs/super.c
 create mode 100644 fs/erofs/zmap.c
 create mode 100644 include/erofs.h
 create mode 100644 test/py/tests/test_fs/test_erofs.py

-- 
2.25.1

[PATCH v3 1/5] fs/erofs: add erofs filesystem support

[Huang Jianan]

This patch mainly deals with uncompressed files.

Signed-off-by: Huang Jianan 
---
 MAINTAINERS |   7 +
 fs/Kconfig  |   2 +
 fs/Makefile |   1 +
 fs/erofs/Kconfig|  12 ++
 fs/erofs/Makefile   |   7 +
 fs/erofs/data.c | 223 ++
 fs/erofs/erofs_fs.h | 436 
 fs/erofs/fs.c   | 267 +++
 fs/erofs/internal.h | 313 +++
 fs/erofs/namei.c| 252 +
 fs/erofs/super.c| 105 +++
 fs/fs.c |  22 +++
 include/erofs.h |  19 ++
 include/fs.h|   1 +
 14 files changed, 1667 insertions(+)
 create mode 100644 fs/erofs/Kconfig
 create mode 100644 fs/erofs/Makefile
 create mode 100644 fs/erofs/data.c
 create mode 100644 fs/erofs/erofs_fs.h
 create mode 100644 fs/erofs/fs.c
 create mode 100644 fs/erofs/internal.h
 create mode 100644 fs/erofs/namei.c
 create mode 100644 fs/erofs/super.c
 create mode 100644 include/erofs.h

diff --git a/MAINTAINERS b/MAINTAINERS
index dcdd99e368..571a64bf7e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -794,6 +794,13 @@ S: Maintained
 F: doc/usage/environment.rst
 F: scripts/env2string.awk
 
+EROFS
+M: Huang Jianan 
+L: linux-er...@lists.ozlabs.org
+S: Maintained
+F: fs/erofs/
+F: include/erofs.h
+
 FASTBOOT
 S: Orphaned
 F: cmd/fastboot.c
diff --git a/fs/Kconfig b/fs/Kconfig
index 620af7f044..cda9f66cc9 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -24,4 +24,6 @@ source "fs/yaffs2/Kconfig"
 
 source "fs/squashfs/Kconfig"
 
+source "fs/erofs/Kconfig"
+
 endmenu
diff --git a/fs/Makefile b/fs/Makefile
index 937cbcf6e8..f05a21c9e6 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -25,5 +25,6 @@ obj-$(CONFIG_CMD_UBIFS) += ubifs/
 obj-$(CONFIG_YAFFS2) += yaffs2/
 obj-$(CONFIG_CMD_ZFS) += zfs/
 obj-$(CONFIG_FS_SQUASHFS) += squashfs/
+obj-$(CONFIG_FS_EROFS) += erofs/
 endif
 obj-y += fs_internal.o
diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig
new file mode 100644
index 00..f4b2d51a23
--- /dev/null
+++ b/fs/erofs/Kconfig
@@ -0,0 +1,12 @@
+config FS_EROFS
+   bool "Enable EROFS filesystem support"
+   help
+ This provides support for reading images from EROFS filesystem.
+ EROFS (Enhanced Read-Only File System) is a lightweight read-only
+ file system for scenarios which need high-performance read-only
+ requirements.
+
+ It also provides fixed-sized output compression support, which
+ improves storage density, keeps relatively higher compression
+ ratios, which is more useful to achieve high performance for
+ embedded devices with limited memory.
diff --git a/fs/erofs/Makefile b/fs/erofs/Makefile
new file mode 100644
index 00..7398ab7a36
--- /dev/null
+++ b/fs/erofs/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-$(CONFIG_$(SPL_)FS_EROFS) = fs.o \
+   super.o \
+   namei.o \
+   data.o
diff --git a/fs/erofs/data.c b/fs/erofs/data.c
new file mode 100644
index 00..699975c1be
--- /dev/null
+++ b/fs/erofs/data.c
@@ -0,0 +1,223 @@
+// SPDX-License-Identifier: GPL-2.0+
+#include "internal.h"
+
+static int erofs_map_blocks_flatmode(struct erofs_inode *inode,
+struct erofs_map_blocks *map,
+int flags)
+{
+   int err = 0;
+   erofs_blk_t nblocks, lastblk;
+   u64 offset = map->m_la;
+   struct erofs_inode *vi = inode;
+   bool tailendpacking = (vi->datalayout == EROFS_INODE_FLAT_INLINE);
+
+   nblocks = DIV_ROUND_UP(inode->i_size, EROFS_BLKSIZ);
+   lastblk = nblocks - tailendpacking;
+
+   /* there is no hole in flatmode */
+   map->m_flags = EROFS_MAP_MAPPED;
+
+   if (offset < blknr_to_addr(lastblk)) {
+   map->m_pa = blknr_to_addr(vi->u.i_blkaddr) + map->m_la;
+   map->m_plen = blknr_to_addr(lastblk) - offset;
+   } else if (tailendpacking) {
+   /* 2 - inode inline B: inode, [xattrs], inline last blk... */
+   map->m_pa = iloc(vi->nid) + vi->inode_isize +
+   vi->xattr_isize + erofs_blkoff(map->m_la);
+   map->m_plen = inode->i_size - offset;
+
+   /* inline data should be located in one meta block */
+   if (erofs_blkoff(map->m_pa) + map->m_plen > PAGE_SIZE) {
+   erofs_err("inline data cross block boundary @ nid %" 
PRIu64,
+ vi->nid);
+   DBG_BUGON(1);
+   err = -EFSCORRUPTED;
+   goto err_out;
+   }
+
+   map->m_flags |= EROFS_MAP_META;
+   } else {
+   erofs_err("internal error @ nid: %" PRIu64 " (size %llu), m_la 
0x%" PRIx64,
+ vi->nid, (unsigned long long)inode->i_size, 
map

[PATCH v3 2/5] lib/lz4: update LZ4 decompressor module

[Huang Jianan]

Update the LZ4 compression module based on LZ4 v1.8.3 in order to
use the newest LZ4_decompress_safe_partial() which can now decode
exactly the nb of bytes requested.

Signed-off-by: Huang Jianan 
---
 include/u-boot/lz4.h |  49 
 lib/lz4.c| 679 +++
 lib/lz4_wrapper.c|  23 +-
 3 files changed, 536 insertions(+), 215 deletions(-)

diff --git a/include/u-boot/lz4.h b/include/u-boot/lz4.h
index e18b39a5dc..655adbfcd1 100644
--- a/include/u-boot/lz4.h
+++ b/include/u-boot/lz4.h
@@ -21,4 +21,53 @@
  */
 int ulz4fn(const void *src, size_t srcn, void *dst, size_t *dstn);
 
+/**
+ * LZ4_decompress_safe() - Decompression protected against buffer overflow
+ * @source: source address of the compressed data
+ * @dest: output buffer address of the uncompressed data
+ * which must be already allocated
+ * @compressedSize: is the precise full size of the compressed block
+ * @maxDecompressedSize: is the size of 'dest' buffer
+ *
+ * Decompresses data from 'source' into 'dest'.
+ * If the source stream is detected malformed, the function will
+ * stop decoding and return a negative result.
+ * This function is protected against buffer overflow exploits,
+ * including malicious data packets. It never writes outside output buffer,
+ * nor reads outside input buffer.
+ *
+ * Return: number of bytes decompressed into destination buffer
+ * (necessarily <= maxDecompressedSize)
+ * or a negative result in case of error
+ */
+int LZ4_decompress_safe(const char *source, char *dest,
+   int compressedSize, int maxDecompressedSize);
+
+/**
+ * LZ4_decompress_safe_partial() - Decompress a block of size 'compressedSize'
+ * at position 'source' into buffer 'dest'
+ * @source: source address of the compressed data
+ * @dest: output buffer address of the decompressed data which must be
+ * already allocated
+ * @compressedSize: is the precise full size of the compressed block.
+ * @targetOutputSize: the decompression operation will try
+ * to stop as soon as 'targetOutputSize' has been reached
+ * @maxDecompressedSize: is the size of destination buffer
+ *
+ * This function decompresses a compressed block of size 'compressedSize'
+ * at position 'source' into destination buffer 'dest'
+ * of size 'maxDecompressedSize'.
+ * The function tries to stop decompressing operation as soon as
+ * 'targetOutputSize' has been reached, reducing decompression time.
+ * This function never writes outside of output buffer,
+ * and never reads outside of input buffer.
+ * It is therefore protected against malicious data packets.
+ *
+ * Return: the number of bytes decoded in the destination buffer
+ * (necessarily <= maxDecompressedSize)
+ * or a negative result in case of error
+ *
+ */
+int LZ4_decompress_safe_partial(const char *src, char *dst,
+   int compressedSize, int targetOutputSize, int dstCapacity);
 #endif
diff --git a/lib/lz4.c b/lib/lz4.c
index 046c34e390..5337842126 100644
--- a/lib/lz4.c
+++ b/lib/lz4.c
@@ -1,13 +1,63 @@
-// SPDX-License-Identifier: BSD-2-Clause
+// SPDX-License-Identifier: GPL 2.0+ OR BSD-2-Clause
 /*
-   LZ4 - Fast LZ compression algorithm
-   Copyright (C) 2011-2015, Yann Collet.
+ * LZ4 - Fast LZ compression algorithm
+ * Copyright (C) 2011 - 2016, Yann Collet.
+ * BSD 2 - Clause License (http://www.opensource.org/licenses/bsd - 
license.php)
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following disclaimer
+ * in the documentation and/or other materials provided with the
+ * distribution.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ * You can contact the author at :
+ * - LZ4 homepage : http://www.lz4.org
+ * - LZ4 source repository : https://github.com/lz4/lz4
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define FORCE_INLINE inline __attribute__((always_inlin

[PATCH v3 4/5] fs/erofs: add filesystem commands

[Huang Jianan]

Add 'ls' and 'load' commands.

Signed-off-by: Huang Jianan 
---
 MAINTAINERS  |  1 +
 cmd/Kconfig  |  6 ++
 cmd/Makefile |  1 +
 cmd/erofs.c  | 42 ++
 4 files changed, 50 insertions(+)
 create mode 100644 cmd/erofs.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 571a64bf7e..aa417bc44f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -798,6 +798,7 @@ EROFS
 M: Huang Jianan 
 L: linux-er...@lists.ozlabs.org
 S: Maintained
+F: cmd/erofs.c
 F: fs/erofs/
 F: include/erofs.h
 
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 5e25e45fd2..50b8f33434 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2176,6 +2176,12 @@ config CMD_CRAMFS
 cramfsls   - lists files in a cramfs image
 cramfsload - loads a file from a cramfs image
 
+config CMD_EROFS
+   bool "EROFS command support"
+   select FS_EROFS
+   help
+ Support for the EROFS fs
+
 config CMD_EXT2
bool "ext2 command support"
select FS_EXT4
diff --git a/cmd/Makefile b/cmd/Makefile
index 166c652d98..d668b3c62d 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_CMD_EEPROM) += eeprom.o
 obj-$(CONFIG_EFI) += efi.o
 obj-$(CONFIG_CMD_EFIDEBUG) += efidebug.o
 obj-$(CONFIG_CMD_ELF) += elf.o
+obj-$(CONFIG_CMD_EROFS) += erofs.o
 obj-$(CONFIG_HUSH_PARSER) += exit.o
 obj-$(CONFIG_CMD_EXT4) += ext4.o
 obj-$(CONFIG_CMD_EXT2) += ext2.o
diff --git a/cmd/erofs.c b/cmd/erofs.c
new file mode 100644
index 00..add80b8b59
--- /dev/null
+++ b/cmd/erofs.c
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022 Huang Jianan 
+ *
+ * Author: Huang Jianan 
+ *
+ * erofs.c:implements EROFS related commands
+ */
+
+#include 
+#include 
+#include 
+
+static int do_erofs_ls(struct cmd_tbl *cmdtp, int flag, int argc, char * const 
argv[])
+{
+   return do_ls(cmdtp, flag, argc, argv, FS_TYPE_EROFS);
+}
+
+U_BOOT_CMD(erofsls, 4, 1, do_erofs_ls,
+  "List files in directory. Default: root (/).",
+  " [] [directory]\n"
+  "- list files from 'dev' on 'interface' in 'directory'\n"
+);
+
+static int do_erofs_load(struct cmd_tbl *cmdtp, int flag, int argc, char * 
const argv[])
+{
+   return do_load(cmdtp, flag, argc, argv, FS_TYPE_EROFS);
+}
+
+U_BOOT_CMD(erofsload, 7, 0, do_erofs_load,
+  "load binary file from a EROFS filesystem",
+  " [ [ [ [bytes [pos]\n"
+  "- Load binary file 'filename' from 'dev' on 'interface'\n"
+  "  to address 'addr' from EROFS filesystem.\n"
+  "  'pos' gives the file position to start loading from.\n"
+  "  If 'pos' is omitted, 0 is used. 'pos' requires 'bytes'.\n"
+  "  'bytes' gives the size to load. If 'bytes' is 0 or omitted,\n"
+  "  the load stops on end of file.\n"
+  "  If either 'pos' or 'bytes' are not aligned to\n"
+  "  ARCH_DMA_MINALIGN then a misaligned buffer warning will\n"
+  "  be printed and performance will suffer for the load."
+);
-- 
2.25.1

[PATCH v3 3/5] fs/erofs: add lz4 decompression support

[Huang Jianan]

Support EROFS lz4 compressed files.

Signed-off-by: Huang Jianan 
---
 fs/erofs/Kconfig  |   9 +
 fs/erofs/Makefile |   4 +-
 fs/erofs/data.c   |  90 ++-
 fs/erofs/decompress.c |  78 ++
 fs/erofs/decompress.h |  24 ++
 fs/erofs/namei.c  |   2 +-
 fs/erofs/zmap.c   | 601 ++
 7 files changed, 805 insertions(+), 3 deletions(-)
 create mode 100644 fs/erofs/decompress.c
 create mode 100644 fs/erofs/decompress.h
 create mode 100644 fs/erofs/zmap.c

diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig
index f4b2d51a23..ee4e777c5c 100644
--- a/fs/erofs/Kconfig
+++ b/fs/erofs/Kconfig
@@ -10,3 +10,12 @@ config FS_EROFS
  improves storage density, keeps relatively higher compression
  ratios, which is more useful to achieve high performance for
  embedded devices with limited memory.
+
+config FS_EROFS_ZIP
+   bool "EROFS Data Compression Support"
+   depends on FS_EROFS
+   select LZ4
+   default y
+   help
+ Enable fixed-sized output compression for EROFS.
+ If you don't want to enable compression feature, say N.
diff --git a/fs/erofs/Makefile b/fs/erofs/Makefile
index 7398ab7a36..58af6a68e4 100644
--- a/fs/erofs/Makefile
+++ b/fs/erofs/Makefile
@@ -4,4 +4,6 @@
 obj-$(CONFIG_$(SPL_)FS_EROFS) = fs.o \
super.o \
namei.o \
-   data.o
+   data.o \
+   decompress.o \
+   zmap.o
diff --git a/fs/erofs/data.c b/fs/erofs/data.c
index 699975c1be..761896054c 100644
--- a/fs/erofs/data.c
+++ b/fs/erofs/data.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 #include "internal.h"
+#include "decompress.h"
 
 static int erofs_map_blocks_flatmode(struct erofs_inode *inode,
 struct erofs_map_blocks *map,
@@ -205,6 +206,93 @@ static int erofs_read_raw_data(struct erofs_inode *inode, 
char *buffer,
return 0;
 }
 
+static int z_erofs_read_data(struct erofs_inode *inode, char *buffer,
+erofs_off_t size, erofs_off_t offset)
+{
+   erofs_off_t end, length, skip;
+   struct erofs_map_blocks map = {
+   .index = UINT_MAX,
+   };
+   struct erofs_map_dev mdev;
+   bool partial;
+   unsigned int bufsize = 0;
+   char *raw = NULL;
+   int ret = 0;
+
+   end = offset + size;
+   while (end > offset) {
+   map.m_la = end - 1;
+
+   ret = z_erofs_map_blocks_iter(inode, &map, 0);
+   if (ret)
+   break;
+
+   /* no device id here, thus it will always succeed */
+   mdev = (struct erofs_map_dev) {
+   .m_pa = map.m_pa,
+   };
+   ret = erofs_map_dev(&sbi, &mdev);
+   if (ret) {
+   DBG_BUGON(1);
+   break;
+   }
+
+   /*
+* trim to the needed size if the returned extent is quite
+* larger than requested, and set up partial flag as well.
+*/
+   if (end < map.m_la + map.m_llen) {
+   length = end - map.m_la;
+   partial = true;
+   } else {
+   DBG_BUGON(end != map.m_la + map.m_llen);
+   length = map.m_llen;
+   partial = !(map.m_flags & EROFS_MAP_FULL_MAPPED);
+   }
+
+   if (map.m_la < offset) {
+   skip = offset - map.m_la;
+   end = offset;
+   } else {
+   skip = 0;
+   end = map.m_la;
+   }
+
+   if (!(map.m_flags & EROFS_MAP_MAPPED)) {
+   memset(buffer + end - offset, 0, length);
+   end = map.m_la;
+   continue;
+   }
+
+   if (map.m_plen > bufsize) {
+   bufsize = map.m_plen;
+   raw = realloc(raw, bufsize);
+   if (!raw) {
+   ret = -ENOMEM;
+   break;
+   }
+   }
+   ret = erofs_dev_read(mdev.m_deviceid, raw, mdev.m_pa, 
map.m_plen);
+   if (ret < 0)
+   break;
+
+   ret = z_erofs_decompress(&(struct z_erofs_decompress_req) {
+   .in = raw,
+   .out = buffer + end - offset,
+   .decodedskip = skip,
+   .inputsize = map.m_plen,
+   .decodedlength = length,
+   .alg = map.m_algorithmformat,
+

[PATCH v3 5/5] test/py: Add tests for the erofs

[Huang Jianan]

Add Python scripts to test 'ls' and 'load' commands, as well as
test related filesystem functions.

Signed-off-by: Huang Jianan 
---
 MAINTAINERS |   1 +
 configs/sandbox_defconfig   |   1 +
 test/py/tests/test_fs/test_erofs.py | 211 
 3 files changed, 213 insertions(+)
 create mode 100644 test/py/tests/test_fs/test_erofs.py

diff --git a/MAINTAINERS b/MAINTAINERS
index aa417bc44f..23ffdbc488 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -801,6 +801,7 @@ S:  Maintained
 F: cmd/erofs.c
 F: fs/erofs/
 F: include/erofs.h
+F: test/py/tests/test_fs/test_erofs.py
 
 FASTBOOT
 S: Orphaned
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index f85274353d..78962ab4c8 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -105,6 +105,7 @@ CONFIG_CMD_TPM_TEST=y
 CONFIG_CMD_BTRFS=y
 CONFIG_CMD_CBFS=y
 CONFIG_CMD_CRAMFS=y
+CONFIG_CMD_EROFS=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_SQUASHFS=y
 CONFIG_CMD_MTDPARTS=y
diff --git a/test/py/tests/test_fs/test_erofs.py 
b/test/py/tests/test_fs/test_erofs.py
new file mode 100644
index 00..27d3ccdf4e
--- /dev/null
+++ b/test/py/tests/test_fs/test_erofs.py
@@ -0,0 +1,211 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Huang Jianan 
+# Author: Huang Jianan 
+
+import os
+import pytest
+import shutil
+import subprocess
+
+EROFS_SRC_DIR = 'erofs_src_dir'
+EROFS_IMAGE_NAME = 'erofs.img'
+
+def generate_file(name, size):
+"""
+Generates a file filled with 'x'.
+"""
+content = 'x' * size
+file = open(name, 'w')
+file.write(content)
+file.close()
+
+def make_erofs_image(build_dir):
+"""
+Makes the EROFS images used for the test.
+
+The image is generated at build_dir with the following structure:
+erofs_src_dir/
+├── f4096
+├── f7812
+├── subdir/
+│   └── subdir-file
+├── symdir -> subdir
+└── symfile -> f5096
+"""
+root = os.path.join(build_dir, EROFS_SRC_DIR)
+os.makedirs(root)
+
+# 4096: uncompressed file
+generate_file(os.path.join(root, 'f4096'), 4096)
+
+# 7812: Compressed file
+generate_file(os.path.join(root, 'f7812'), 7812)
+
+# sub-directory with a single file inside
+subdir_path = os.path.join(root, 'subdir')
+os.makedirs(subdir_path)
+generate_file(os.path.join(subdir_path, 'subdir-file'), 100)
+
+# symlink
+os.symlink('subdir', os.path.join(root, 'symdir'))
+os.symlink('f7812', os.path.join(root, 'symfile'))
+
+input_path = os.path.join(build_dir, EROFS_SRC_DIR)
+output_path = os.path.join(build_dir, EROFS_IMAGE_NAME)
+args = ' '.join([output_path, input_path])
+subprocess.run(['mkfs.erofs -zlz4hc ' + args], shell=True, check=True,
+   stdout=subprocess.DEVNULL)
+
+def clean_erofs_image(build_dir):
+"""
+Deletes the image and src_dir at build_dir.
+"""
+path = os.path.join(build_dir, EROFS_SRC_DIR)
+shutil.rmtree(path)
+image_path = os.path.join(build_dir, EROFS_IMAGE_NAME)
+os.remove(image_path)
+
+def erofs_ls_at_root(u_boot_console):
+"""
+Test if all the present files and directories were listed.
+"""
+no_slash = u_boot_console.run_command('erofsls host 0')
+slash = u_boot_console.run_command('erofsls host 0 /')
+assert no_slash == slash
+
+expected_lines = ['./', '../', '4096   f4096', '7812   f7812', 'subdir/',
+  '   symdir', '   symfile', '4 file(s), 3 
dir(s)']
+
+output = u_boot_console.run_command('erofsls host 0')
+for line in expected_lines:
+assert line in output
+
+def erofs_ls_at_subdir(u_boot_console):
+"""
+Test if the path resolution works.
+"""
+expected_lines = ['./', '../', '100   subdir-file', '1 file(s), 2 dir(s)']
+output = u_boot_console.run_command('erofsls host 0 subdir')
+for line in expected_lines:
+assert line in output
+
+def erofs_ls_at_symlink(u_boot_console):
+"""
+Test if the symbolic link's target resolution works.
+"""
+output = u_boot_console.run_command('erofsls host 0 symdir')
+output_subdir = u_boot_console.run_command('erofsls host 0 subdir')
+assert output == output_subdir
+
+expected_lines = ['./', '../', '100   subdir-file', '1 file(s), 2 dir(s)']
+for line in expected_lines:
+assert line in output
+
+def erofs_ls_at_non_existent_dir(u_boot_console):
+"""
+Test if the EROFS support will crash when get a nonexistent directory.
+"""
+out_non_existent = u_boot_console.run_command('erofsls host 0 fff')
+out_not_dir = u_boot_console.run_command('erofsls host 0 f1000')
+assert out_non_existent == out_not_dir
+assert '' in out_non_existent
+
+def erofs_load_files(u_boot_console, files, sizes, address):
+"""
+Loads files and asserts their checksums.
+"""
+build_dir = u_boot_console.config.build_dir
+for (file, size) in zip(files, sizes):
+  

[RESEND PATCH v7 1/1] arm: imx8m: add support for Advantech RSB-3720

[Ying-Chun Liu]

From: "Ying-Chun Liu (PaulLiu)" 

Add initial support for Advantech RSB-3720 board.
The initial support includes:
 - MMC
 - eMMC
 - I2C
 - FEC
 - Serial console

Signed-off-by: Darren Huang 
Signed-off-by: Kevin12.Chen 
Signed-off-by: Phill.Liu 
Signed-off-by: Tim Liang 
Signed-off-by: wei.zeng 
Signed-off-by: Ying-Chun Liu (PaulLiu) 
Cc: uboot-imx 
Cc: Peng Fan (OSS) 
---
v3: remove unnecessary code. move board code to board/advantech
v4: rebase to latest master branch
v7: remove redefined configs for latest master branch.
---
 arch/arm/dts/Makefile |4 +
 arch/arm/mach-imx/imx8m/Kconfig   |   15 +
 board/advantech/imx8mp_rsb3720a1/Kconfig  |   14 +
 board/advantech/imx8mp_rsb3720a1/MAINTAINERS  |7 +
 board/advantech/imx8mp_rsb3720a1/Makefile |   24 +
 .../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c   |  213 ++
 .../imx8mp_rsb3720a1/imximage-8mp-lpddr4.cfg  |   11 +
 .../lpddr4_timing_rsb3720a1_4G.c  | 1848 
 .../lpddr4_timing_rsb3720a1_6G.c  | 1875 +
 board/advantech/imx8mp_rsb3720a1/spl.c|  260 +++
 configs/imx8mp_rsb3720a1_4G_defconfig |  167 ++
 configs/imx8mp_rsb3720a1_6G_defconfig |  168 ++
 include/configs/imx8mp_rsb3720.h  |  223 ++
 13 files changed, 4829 insertions(+)
 create mode 100644 board/advantech/imx8mp_rsb3720a1/Kconfig
 create mode 100644 board/advantech/imx8mp_rsb3720a1/MAINTAINERS
 create mode 100644 board/advantech/imx8mp_rsb3720a1/Makefile
 create mode 100644 board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c
 create mode 100644 board/advantech/imx8mp_rsb3720a1/imximage-8mp-lpddr4.cfg
 create mode 100644 
board/advantech/imx8mp_rsb3720a1/lpddr4_timing_rsb3720a1_4G.c
 create mode 100644 
board/advantech/imx8mp_rsb3720a1/lpddr4_timing_rsb3720a1_6G.c
 create mode 100644 board/advantech/imx8mp_rsb3720a1/spl.c
 create mode 100644 configs/imx8mp_rsb3720a1_4G_defconfig
 create mode 100644 configs/imx8mp_rsb3720a1_6G_defconfig
 create mode 100644 include/configs/imx8mp_rsb3720.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e51e875079..db0fa7755b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1199,6 +1199,10 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) += 
imx8mm-cl-iot-gate-optee.dtb \
imx8mm-cl-iot-gate-ied-tpm0.dtbo \
imx8mm-cl-iot-gate-ied-tpm1.dtbo
 
+ifneq 
($(CONFIG_TARGET_IMX8MP_RSB3720A1_4G)$(CONFIG_TARGET_IMX8MP_RSB3720A1_6G),)
+dtb-y += imx8mp-rsb3720-a1.dtb
+endif
+
 dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
 
 dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb qemu-arm64.dtb
diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
index 73bc9b34f3..cc2975b84a 100644
--- a/arch/arm/mach-imx/imx8m/Kconfig
+++ b/arch/arm/mach-imx/imx8m/Kconfig
@@ -182,8 +182,23 @@ config TARGET_IMX8MM_CL_IOT_GATE_OPTEE
select SUPPORT_SPL
select IMX8M_LPDDR4
select SUPPORT_EXTENSION_SCAN
+
+config TARGET_IMX8MP_RSB3720A1_4G
+   bool "Support i.MX8MP RSB3720A1 4G"
+   select BINMAN
+   select IMX8MP
+   select SUPPORT_SPL
+   select IMX8M_LPDDR4
+
+config TARGET_IMX8MP_RSB3720A1_6G
+   bool "Support i.MX8MP RSB3720A1 6G"
+   select BINMAN
+   select IMX8MP
+   select SUPPORT_SPL
+   select IMX8M_LPDDR4
 endchoice
 
+source "board/advantech/imx8mp_rsb3720a1/Kconfig"
 source "board/beacon/imx8mm/Kconfig"
 source "board/beacon/imx8mn/Kconfig"
 source "board/compulab/imx8mm-cl-iot-gate/Kconfig"
diff --git a/board/advantech/imx8mp_rsb3720a1/Kconfig 
b/board/advantech/imx8mp_rsb3720a1/Kconfig
new file mode 100644
index 00..4486ed6d33
--- /dev/null
+++ b/board/advantech/imx8mp_rsb3720a1/Kconfig
@@ -0,0 +1,14 @@
+if TARGET_IMX8MP_RSB3720A1_4G || TARGET_IMX8MP_RSB3720A1_6G
+
+config SYS_BOARD
+   default "imx8mp_rsb3720a1"
+
+config SYS_VENDOR
+   default "advantech"
+
+config SYS_CONFIG_NAME
+   default "imx8mp_rsb3720"
+
+source "board/freescale/common/Kconfig"
+
+endif
diff --git a/board/advantech/imx8mp_rsb3720a1/MAINTAINERS 
b/board/advantech/imx8mp_rsb3720a1/MAINTAINERS
new file mode 100644
index 00..bc967af4f5
--- /dev/null
+++ b/board/advantech/imx8mp_rsb3720a1/MAINTAINERS
@@ -0,0 +1,7 @@
+i.MX8MP RSB3720 BOARD
+M: Ying-Chun Liu (PaulLiu) 
+S: Maintained
+F: board/advantech/imx8mp_rsb3720a1/
+F: include/configs/imx8mp_rsb3720a1.h
+F: configs/imx8mp_rsb3720a1_4G_defconfig
+F: configs/imx8mp_rsb3720a1_6G_defconfig
diff --git a/board/advantech/imx8mp_rsb3720a1/Makefile 
b/board/advantech/imx8mp_rsb3720a1/Makefile
new file mode 100644
index 00..eb6b18b04a
--- /dev/null
+++ b/board/advantech/imx8mp_rsb3720a1/Makefile
@@ -0,0 +1,24 @@
+#
+# Copyright 2019 NXP
+# Copyright 2022 Linaro
+#
+# SPDX-License-Identifier:  GPL-2.0+
+#
+
+ifdef CONFIG_TARGET_IMX8MP_RSB3720A1_6G
+obj-y += imx8mp_rsb37

[PATCH v2] scripts: setlocalversion: remove quotes around localversion from config

[Nikita Maslov]

From: Nikita Maslov 
Date: Fri, 14 Jan 2022 00:13:39 +0300
Subject: [PATCH v2] scripts: setlocalversion: remove quotes around localversion 
from config

After replacing of include/config/auto.conf sourcing with
extraction of CONFIG_LOCALVERSION, resulting version string
contains quotes around localversion part which are always
present in auto.conf (even if localversion is empty).

This patch fixes this script to remove quotes.

Signed-off-by: Nikita Maslov 
Cc: Philipp Tomsich 
Cc: Tom Rini 
Reviewed-by: Simon Glass 
---
Changes for v2:
   - re-post because of messed up word wrapping


 scripts/setlocalversion | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index c1c0435267..4a63143706 100755
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -153,8 +153,9 @@ if test -e include/config/auto.conf; then
# We are interested only in CONFIG_LOCALVERSION and
# CONFIG_LOCALVERSION_AUTO, so extract these in a safe
# way (i.e. w/o sourcing auto.conf)
-   CONFIG_LOCALVERSION=`cat include/config/auto.conf | awk -F '=' 
'/^CONFIG_LOCALVERSION=/ {print $2}'`
-   CONFIG_LOCALVERSION_AUTO=`cat include/config/auto.conf | awk -F '=' 
'/^CONFIG_LOCALVERSION_AUTO=/ {print $2}'`
+   # xargs echo removes quotes
+   CONFIG_LOCALVERSION=`cat include/config/auto.conf | awk -F '=' 
'/^CONFIG_LOCALVERSION=/ {print $2}' | xargs echo`
+   CONFIG_LOCALVERSION_AUTO=`cat include/config/auto.conf | awk -F '=' 
'/^CONFIG_LOCALVERSION_AUTO=/ {print $2}' | xargs echo`
 else
echo "Error: kernelrelease not valid - run 'make prepare' to update it" 
>&2
exit 1
--

Re: [EXT] [PATCH] crypto/fsl: Fallback to SW sha1/256 is misaligned buffers

[Philip Oberfichtner]

Hi everybody,

On Mon, 2021-12-06 at 08:22 +, Ye Li wrote:
> On Fri, 2021-11-05 at 10:42 +0100, Christian Sørensen wrote:
> > Caution: EXT Email
> > 
> > Problem:
> > With U-Boot 2021.10, we currently cannot load a fitImage on our
> > imx7d
> > board, due to misaligned buffers.
> > 
> > Reason:
> > Commit 92055e138f28 ("image: Drop if/elseif hash selection in
> > calculate_hash()")
> > changed the way the FIT were verified. Previously, SW sha1/256 were
> > always
> > used. Due to that commit, that can now be done in hardware.
> > caam_hash requires both the input, pbuf, and output buffer, pout,
> > to
> > be
> > aligned. E.g. for the kernel data, pbuf will be the data start
> > address
> > for the kernel. The data start address is dependent on how the FIT
> > is
> > constructed and what address the FIT is loaded to. I.e.; it is
> > fairly
> > likely that we have a case of pbuf to not be aligned. pout is even
> > more
> > likely to not be aligned since it is simply a stack variable
> > declared
> > in
> > fit_image_check_hash in common/image-fit.c.
> > So to rely upon both of these buffers to be aligned, makes errors
> > fairly
> > likely.
> > 
> > Solution:
> > I wont propose copying the entire input buffer due to its size, so
> > instead
> > just fallback to use the sw sha1/sha256 if buffers is misaligned.
> > 

I have the same problem on my imx6d. This patch works fine for me.


> > Signed-off-by: Christian Sørensen 
> > ---
> > 
> >  drivers/crypto/fsl/fsl_hash.c | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/crypto/fsl/fsl_hash.c
> > b/drivers/crypto/fsl/fsl_hash.c
> > index 8b5c26db07..48dd10883e 100644
> > --- a/drivers/crypto/fsl/fsl_hash.c
> > +++ b/drivers/crypto/fsl/fsl_hash.c
> > @@ -16,6 +16,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > 
> >  #define CRYPTO_MAX_ALG_NAME80
> >  #define SHA1_DIGEST_SIZE20
> > @@ -176,8 +179,12 @@ int caam_hash(const unsigned char *pbuf,
> > unsigned int buf_len,
> > 
> > if (!IS_ALIGNED((uintptr_t)pbuf, ARCH_DMA_MINALIGN) ||
> > !IS_ALIGNED((uintptr_t)pout, ARCH_DMA_MINALIGN)) {
> > -   puts("Error: Address arguments are not aligned\n");
> > -   return -EINVAL;
> > +   printf("Fallback to SW hash due to misaligned
> > buffers\n");
> > +   if (algo == SHA1)
> > +   sha1_csum_wd(pbuf, buf_len, pout,
> > CHUNKSZ_SHA1);
> > +   else
> > +   sha256_csum_wd(pbuf, buf_len, pout,
> > CHUNKSZ_SHA256);
> > +   return 0;
> 
> How about adding “#ifdef CONFIG_SHA1” and “#ifdef CONFIG_SHA256” here
> ?  Then it can depend on users’ selection to determine the fallback
> 
> Best regards,
> Ye Li
> 
> > }
> > 
> > size = ALIGN(buf_len, ARCH_DMA_MINALIGN);
> > --
> > 2.25.1

Is this patch still active? The change request is already two months
old. If the original patch request is abandoned, should I contribute a
[PATCH v2]?

Best Regards,
Philip Oberfichtner

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Masami Hiramatsu]

2022年2月8日(火) 22:45 Michal Simek :
>
>
>
> On 2/8/22 14:36, Masami Hiramatsu wrote:
> > 2022年2月8日(火) 20:35 Sughosh Ganu :
> >>
> >> On Tue, 8 Feb 2022 at 16:26, Michal Simek  wrote:
> >>>
> >>> po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  
> >>> 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 
>  ---
> 
>  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 00..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 
> >> tuples which can then list the device and partition number of the
> >> metadata partitions.
> >
> > Yes, I would like to define new compatible for sf backend, e.g.
> > "u-boot,fwu-mdata-sf".
>
> backend is fine. What does this compatible string have to do with it?
> I didn't see any fwu-mdata-gpt in this series.

Sughosh made it "fwu-mdata" but I think it should be "fwu-mdata-gpt"
if the required parameters are different.

>
> > It will have the fwu-mdata-store to point the SPI flash device, and
> > will have a list of offset information for the metadata.
>
> Can you describe it?
>
> Something like for raw accesses?
> fw

Re: i.MX8M Mini Hangs at ATF when booting from USB

[Tom Rini]

On Tue, Feb 08, 2022 at 11:58:50AM +0800, Peng Fan (OSS) wrote:
> 
> 
> On 2022/2/3 2:42, Tom Rini wrote:
> > On Wed, Feb 02, 2022 at 02:45:44PM -0300, Fabio Estevam wrote:
> > > Hi Marcel,
> > > 
> > > [Adding Tom and Marek]
> > > 
> > > On Wed, Feb 2, 2022 at 2:40 PM Marcel Ziswiler
> > >  wrote:
> > > 
> > > > > The blocker to getting non-dm-spl-usb support for IMX8M appears to be
> > > > > the base addresses and instead of adding more of them to imx-regs.h we
> > > > > need to get them from DT via of_platdata which nobody has had time to
> > > > > dig into yet.
> > > > 
> > > > I was also a little hesitant due to not using DM in SPL might no longer 
> > > > be accepted upstream. What is the
> > > > stance on this?
> > > 
> > > My understanding is that there is no requirement to use DM in SPL.
> > 
> > DM isn't required in SPL, no.  Are we running in to some size limit
> > here?  I see SPL_DM being set in a number of imx8m* platforms is why I
> > ask.
> 
> I still see this as maintainence effort. And mix DM & non-DM code in one
> driver is pain. Should we split non-DM code out to a new folder, such as
> drivers/non-dm/[usb,mmc,...]/

No, I don't think splitting it in to a new root subfolder will help
at least in part because I'm not sure it will go away long term, but
we'll see where some of the platdata work leads.  Splitting the existing
files more may make the code easier to maintain and would have to be
done to move to a new root subfolder as well?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 01/11] FWU: Add FWU metadata structure and driver for accessing metadata

[Michal Simek]

On 2/8/22 15:14, Masami Hiramatsu wrote:

2022年2月8日(火) 22:45 Michal Simek :




On 2/8/22 14:36, Masami Hiramatsu wrote:

2022年2月8日(火) 20:35 Sughosh Ganu :


On Tue, 8 Feb 2022 at 16:26, Michal Simek  wrote:


po 7. 2. 2022 v 19:21 odesílatel Sughosh Ganu  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 
---

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 00..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 
tuples which can then list the device and partition number of the
metadata partitions.


Yes, I would like to define new compatible for sf backend, e.g.
"u-boot,fwu-mdata-sf".


backend is fine. What does this compatible string have to do with it?
I didn't see any fwu-mdata-gpt in this series.


Sughosh made it "fwu-mdata" but I think it should be "fwu-mdata-gpt"
if the required parameters are different.




It will have the fwu-mdata-store to point the SPI flash device, and
will have a list of offset information for the metadata.


Can you describe it?

Something like for raw accesses?
fwu-mdta-store = <&qspi 0 >;


I'm still not sure what is the best way. What I thought was,

fwu-mdata-store = <&spi-flash>;
fwu-mdata-offsets = <50, 52>;


as I said. Before this is applied I think we should work on generic proposal how 
to describe it. Because the same way can be used for u-boot variables and maybe 
others.
Definitely I would prefer to ask Rob for helping with this and get this to yaml 
to be able to use the whole infrastructure to check it.


Thanks,
Michal

Re: [PATCH v1 0/5] Move board specific files to board directory

[Tom Rini]

On Fri, Jan 07, 2022 at 10:33:34AM -0800, Troy Kisky wrote:
> On 1/7/2022 7:12 AM, Tom Rini wrote:
> > On Thu, Jan 06, 2022 at 01:14:40PM -0800, Troy Kisky wrote:
> >> On 12/28/2021 5:11 AM, Tom Rini wrote:
> >>> On Tue, Dec 28, 2021 at 01:33:05AM -0700, Simon Glass wrote:
>  Hi Troy,
> 
>  On Fri, 17 Dec 2021 at 16:02, Troy Kisky 
>   wrote:
> >
> > This series intends to let board specific files live in the boards
> > directory. The last patch moves files for nitrogen6x.
> > I have tested it with buildman
> >
> > ./tools/buildman/buildman boundary -b denx_master
> >
> > But it is likely the more scripts then just tools/genboardscfg.py would
> > need to be updated.
> >
> > Troy Kisky (5):
> >   kconfig: allow defconfigs to live in board directory
> >   dts: allow dts files in board directory
> >   scripts: Makefile.autoconf: allow CONFIG_SYS_CONFIG_NAME file to live
> > in board directory
> >   genboardcfg: allow defconfigs in board directory
> >   nitrogen6x: move board specific files to nitrogen6x directory
> >
> >  arch/arm/dts/Makefile |  3 --
> >  board/boundary/nitrogen6x/MAINTAINERS | 13 ---
> >  board/boundary/nitrogen6x/Makefile| 13 +++
> >  .../nitrogen6x}/imx6dl-nitrogen6x.dts |  0
> >  .../boundary/nitrogen6x}/imx6q-nitrogen6x.dts |  0
> >  .../boundary/nitrogen6x}/imx6q-sabrelite.dts  |  0
> >  .../nitrogen6x}/imx6qdl-nitrogen6x.dtsi   |  0
> >  .../nitrogen6x}/imx6qdl-sabrelite.dtsi|  0
> >  .../nitrogen6x}/mx6qsabrelite_defconfig   |  0
> >  .../nitrogen6x}/nitrogen6dl2g_defconfig   |  0
> >  .../nitrogen6x}/nitrogen6dl_defconfig |  0
> >  .../nitrogen6x}/nitrogen6q2g_defconfig|  0
> >  .../boundary/nitrogen6x}/nitrogen6q_defconfig |  0
> >  .../nitrogen6x}/nitrogen6s1g_defconfig|  0
> >  .../boundary/nitrogen6x}/nitrogen6s_defconfig |  0
> >  .../boundary/nitrogen6x}/nitrogen6x.h |  2 +-
> >  dts/Makefile  | 11 +-
> >  scripts/Makefile.autoconf |  9 -
> >  scripts/Makefile.lib  |  1 +
> >  scripts/kconfig/Makefile  |  9 -
> >  tools/genboardscfg.py | 37 ++-
> >  21 files changed, 75 insertions(+), 23 deletions(-)
> >  rename {arch/arm/dts => 
> > board/boundary/nitrogen6x}/imx6dl-nitrogen6x.dts (100%)
> >  rename {arch/arm/dts => 
> > board/boundary/nitrogen6x}/imx6q-nitrogen6x.dts (100%)
> >  rename {arch/arm/dts => board/boundary/nitrogen6x}/imx6q-sabrelite.dts 
> > (100%)
> >  rename {arch/arm/dts => 
> > board/boundary/nitrogen6x}/imx6qdl-nitrogen6x.dtsi (100%)
> >  rename {arch/arm/dts => 
> > board/boundary/nitrogen6x}/imx6qdl-sabrelite.dtsi (100%)
> >  rename {configs => board/boundary/nitrogen6x}/mx6qsabrelite_defconfig 
> > (100%)
> >  rename {configs => board/boundary/nitrogen6x}/nitrogen6dl2g_defconfig 
> > (100%)
> >  rename {configs => board/boundary/nitrogen6x}/nitrogen6dl_defconfig 
> > (100%)
> >  rename {configs => board/boundary/nitrogen6x}/nitrogen6q2g_defconfig 
> > (100%)
> >  rename {configs => board/boundary/nitrogen6x}/nitrogen6q_defconfig 
> > (100%)
> >  rename {configs => board/boundary/nitrogen6x}/nitrogen6s1g_defconfig 
> > (100%)
> >  rename {configs => board/boundary/nitrogen6x}/nitrogen6s_defconfig 
> > (100%)
> >  rename {include/configs => board/boundary/nitrogen6x}/nitrogen6x.h 
> > (98%) I'm not about the goal.
> 
>  Can you please add a few notes about the motivation for this change?
> >>>
> >>> Sorry for the delayed reply here.  I'm also not entirely sure this is a
> >>> good idea.  Moving the defconfig files?  Maybe.  It does make checking
> >>> all configs a bit more tricky, but indeed the configs directory is
> >>> unwieldy.  Moving the dts files?  Those should be a direct cp from the
> >>> kernel, so that makes things less clear to me.  Especially since it will
> >>> need other common files that will still be elsewhere.
> >>>
> >>
> >> They will still be a direct copy. Notice the 100% rename. Common files 
> >> still living in the dts
> >> directory is less clear. I can try to address the "piecemeal building of 
> >> .dts files" if this
> >> still has a chance of being accepted.
> > 
> > So, here's my worry.  Today, in an ideal world that we're not yet at, I
> > could do:
> > 1. cd ~/src/linux; git checkout v5.16
> > 2. cd ~/src/u-boot; for DTS in arch/arm/dts/*.dts*; do \
> > [ -f ~/src/linux/$DTS ] && cp ~/src/linux/$DTS $DTS; done
> > 
> 
> Still, a script could easily check that a dts file exists before overwriting 
> it
> and find the correct directory to put it in. A little more complicated, but 

Re: Running qemu tests on RISC-V

[Simon Glass]

Hi Heinrich,

On Tue, 8 Feb 2022 at 01:21, Heinrich Schuchardt  wrote:
>
> On 2/7/22 19:19, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 7 Feb 2022 at 09:49, Tom Rini  wrote:
> >>
> >> On Mon, Feb 07, 2022 at 11:34:17AM -0500, Sean Anderson wrote:
> >>>
> >>>
> >>> On 2/7/22 10:53 AM, Heinrich Schuchardt wrote:
>  On 2/7/22 16:38, Simon Glass wrote:
> > Hi,
> >
> > I am trying to run the SPL tests for riscv32 but it dies with an
> > illegal instruction. I have tried building qemu 4.2 but it seems to
> > happen on various versions. Has anyone seen this?
> 
>  Did you try to run qemu-riscv32_spl_defconfig in the Docker container we
>  are using for Gitlab?
> >
> > No, I want to run it outside docker. I can see that it works in the
> > docker container, but not sure why it fails for me.
> >
> 
>  We are using QEMU v6.1.0 according to tools/docker/Dockerfile.
> 
>  With all that duplicate output below it is hard to understand what is
>  going. Why is each byte written twice to the serial?
> >>>
> >>> If I had to guess there are 2 harts, and they both trigger an illegal
> >>> instruction. In situations like these, I have added a spinlock around 
> >>> puts.
> >
> > There are 4 CPUs I think.
> >
> >>
> >> It might also be worth asking why such an old QEMU?  I know my
> >> host-provided QEMU is 4.2.1 but I just don't use it since it's too old
> >> for everything we do, especially on something as fast moving as RISC-V.
> >
> > I tried 6.x and went back to 4.2.1 because I thought that might be the 
> > problem.
> >
> >>
> >> And as an aside, if anyone has tips on changes that would need to be
> >> made to our Dockerfile so that some of those tools that let you run app
> >> from a container "normally" would work with our container, that'd be
> >> handy and appreciated.
> >
> > I'm not sure what that means, probably because I am not an expert in that 
> > area.
> >
> > Regards,
> > Simon
>
> Hello Simon,
>
> The qemu-riscv32_spl_defconfig image built inside Docker with
>
> wget -O -
> https://github.com/riscv/opensbi/releases/download/v0.9/opensbi-0.9-rv-bin.tar.xz
> export
> OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin
> tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl
>
> runs flawlessly on Ubuntu Jammy with:
>
> qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \
>  -device loader,file=u-boot.itb,addr=0x8020 -smp cpus=4
>
> This is a QEMU 6.0
>
> Please, provide a reproducible instruction for your problem.

I wonder if the problem is the OPENSBI thing. I am not providing that,
nor am I seeing a warning about it.

+Alper Nebi Yasak did a series that makes Fit a subclass of Section
but even that does not help with the missing warning. Has anyone else
noticed it?

Regards,
Simon

Re: [PATCH 00/14] Add support for NVMEM API

[Michael Walle]

Hi Sean,

> Should this be implemented on top of/as part of syscon/regmap? In Linux,
> all nvmem devices must also implement regmap support, making nvmem a
> subset of regmap drivers. There are certainly similarities, but I don't
> know if we want to make this depend on regmap.

What do you mean by that? I assume with "nvmem devices" you mean the
nvmem providers. I've implemented the nvmem provider for MTD OTP devices
in linux and there is no regmap support.

-michael

Re: [PATCH v2 1/5] binman: Fix subentry expansion for FIT entry type

[Simon Glass]

On Mon, 7 Feb 2022 at 15:08, Alper Nebi Yasak  wrote:
>
> Binman tries to expand some entries into parts that make it up, e.g.
> 'u-boot' into a 'u-boot-expanded' section that contains 'u-boot-nodtb'
> and 'u-boot-dtb'. Entries with child entries must call ExpandEntries()
> on them to build a correct image, as it's possible that unexpanded child
> entries have no data of their own. The FIT entry type doesn't currently
> do this, which means putting a "u-boot" entry inside it doesn't work as
> expected.
>
> Implement ExpandEntries() for FIT and add a copy of a simple FIT image
> test that checks subentry expansion in FIT entries.
>
> Signed-off-by: Alper Nebi Yasak 
> ---
>
> Changes in v2:
> - Split reused testSimpleFit code into a helper function
>
>  tools/binman/etype/fit.py |  5 +
>  tools/binman/ftest.py | 33 -
>  2 files changed, 29 insertions(+), 9 deletions(-)

Reviewed-by: Simon Glass 

I missed the duplicate number on the dts, but will fix that when applying.

>
> diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py
> index 6ad4a686df55..38bc2a2d784e 100644
> --- a/tools/binman/etype/fit.py
> +++ b/tools/binman/etype/fit.py
> @@ -237,6 +237,11 @@ def _AddNode(base_node, depth, node):
>  self._fdt = Fdt.FromData(fdt.as_bytearray())
>  self._fdt.Scan()
>
> +def ExpandEntries(self):
> +super().ExpandEntries()
> +for section in self._fit_sections.values():
> +section.ExpandEntries()
> +
>  def ObtainContents(self):
>  """Obtain the contents of the FIT
>
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 5400f76c676a..626df786c8c9 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -61,6 +61,9 @@
>  U_BOOT_NODTB_DATA = b'nodtb with microcode pointer somewhere in here'
>  U_BOOT_SPL_NODTB_DATA = b'splnodtb with microcode pointer somewhere in here'
>  U_BOOT_TPL_NODTB_DATA = b'tplnodtb with microcode pointer somewhere in here'
> +U_BOOT_EXP_DATA   = U_BOOT_NODTB_DATA + U_BOOT_DTB_DATA
> +U_BOOT_SPL_EXP_DATA   = U_BOOT_SPL_NODTB_DATA + U_BOOT_SPL_DTB_DATA
> +U_BOOT_TPL_EXP_DATA   = U_BOOT_TPL_NODTB_DATA + U_BOOT_TPL_DTB_DATA
>  FSP_DATA  = b'fsp'
>  CMC_DATA  = b'cmc'
>  VBT_DATA  = b'vbt'
> @@ -3713,13 +3716,7 @@ def testPackOverlap(self):
>  """Test that zero-size overlapping regions are ignored"""
>  self._DoTestFile('160_pack_overlap_zero.dts')
>
> -def testSimpleFit(self):
> -"""Test an image with a FIT inside"""
> -data = self._DoReadFile('161_fit.dts')
> -self.assertEqual(U_BOOT_DATA, data[:len(U_BOOT_DATA)])
> -self.assertEqual(U_BOOT_NODTB_DATA, data[-len(U_BOOT_NODTB_DATA):])
> -fit_data = data[len(U_BOOT_DATA):-len(U_BOOT_NODTB_DATA)]
> -
> +def _CheckSimpleFitData(self, fit_data, kernel_data, fdt1_data):
>  # The data should be inside the FIT
>  dtb = fdt.Fdt.FromData(fit_data)
>  dtb.Scan()
> @@ -3752,8 +3749,26 @@ def testSimpleFit(self):
>  self.assertIsNotNone(data_sizes)
>  self.assertEqual(2, len(data_sizes))
>  # Format is "4 Bytes = 0.00 KiB = 0.00 MiB" so take the first word
> -self.assertEqual(len(U_BOOT_DATA), int(data_sizes[0].split()[0]))
> -self.assertEqual(len(U_BOOT_SPL_DTB_DATA), 
> int(data_sizes[1].split()[0]))
> +self.assertEqual(len(kernel_data), int(data_sizes[0].split()[0]))
> +self.assertEqual(len(fdt1_data), int(data_sizes[1].split()[0]))
> +
> +def testSimpleFit(self):
> +"""Test an image with a FIT inside"""
> +data = self._DoReadFile('161_fit.dts')
> +self.assertEqual(U_BOOT_DATA, data[:len(U_BOOT_DATA)])
> +self.assertEqual(U_BOOT_NODTB_DATA, data[-len(U_BOOT_NODTB_DATA):])
> +fit_data = data[len(U_BOOT_DATA):-len(U_BOOT_NODTB_DATA)]
> +
> +self._CheckSimpleFitData(fit_data, U_BOOT_DATA, U_BOOT_SPL_DTB_DATA)
> +
> +def testSimpleFitExpandsSubentries(self):
> +"""Test that FIT images expand their subentries"""
> +data = self._DoReadFileDtb('161_fit.dts', use_expanded=True)[0]
> +self.assertEqual(U_BOOT_EXP_DATA, data[:len(U_BOOT_EXP_DATA)])
> +self.assertEqual(U_BOOT_NODTB_DATA, data[-len(U_BOOT_NODTB_DATA):])
> +fit_data = data[len(U_BOOT_EXP_DATA):-len(U_BOOT_NODTB_DATA)]
> +
> +self._CheckSimpleFitData(fit_data, U_BOOT_EXP_DATA, 
> U_BOOT_SPL_DTB_DATA)
>
>  def testFitExternal(self):
>  """Test an image with an FIT with external images"""
> --
> 2.34.1
>

Re: [PATCH 2/2] acpi: Move MCFG implementation to common lib

[Simon Glass]

Hi Moritz,

On Mon, 7 Feb 2022 at 13:49, Moritz Fischer  wrote:
>
> Hi Simon,
>
> On Mon, Feb 7, 2022 at 12:22 PM Simon Glass  wrote:
> >
> > Hi Moritz,
> >
> > On Sat, 5 Feb 2022 at 13:17, Moritz Fischer  wrote:
> > >
> > > MCFG tables are used on multiple arches. Move to common ACPI lib.
> > >
> > > Cc: Simon Glass 
> > > Signed-off-by: Moritz Fischer 
> > > ---
> > >
> > >  arch/x86/cpu/intel_common/acpi.c  | 15 +---
> > >  arch/x86/cpu/tangier/acpi.c   | 11 --
> > >  arch/x86/include/asm/acpi_table.h |  1 -
> > >  arch/x86/lib/acpi_table.c | 54 --
> > >  lib/acpi/Makefile |  1 +
> > >  lib/acpi/mcfg.c   | 64 +++
> > >  6 files changed, 81 insertions(+), 65 deletions(-)
> > >  create mode 100644 lib/acpi/mcfg.c
> > >
> > > diff --git a/arch/x86/cpu/intel_common/acpi.c 
> > > b/arch/x86/cpu/intel_common/acpi.c
> > > index 15f19da206..d94ec208f6 100644
> > > --- a/arch/x86/cpu/intel_common/acpi.c
> > > +++ b/arch/x86/cpu/intel_common/acpi.c
> > > @@ -31,14 +31,17 @@
> > >  #include 
> > >  #include 
> > >
> > > -u32 acpi_fill_mcfg(u32 current)
> > > +int acpi_fill_mcfg(struct acpi_ctx *ctx)
> > >  {
> > > +   size_t size;
> > > +
> > > /* PCI Segment Group 0, Start Bus Number 0, End Bus Number is 255 
> > > */
> > > -   current += acpi_create_mcfg_mmconfig((void *)current,
> > > -CONFIG_MMCONF_BASE_ADDRESS, 
> > > 0, 0,
> > > -(CONFIG_SA_PCIEX_LENGTH >> 
> > > 20)
> > > -- 1);
> > > -   return current;
> > > +   size = acpi_create_mcfg_mmconfig((void *)ctx->current,
> > > +CONFIG_MMCONF_BASE_ADDRESS, 0, 0,
> > > +(CONFIG_SA_PCIEX_LENGTH >> 20) - 
> > > 1);
> > > +   acpi_inc(ctx, size);
> > > +
> > > +   return 0;
> > >  }
> > >
> > >  static int acpi_sci_irq(void)
> > > diff --git a/arch/x86/cpu/tangier/acpi.c b/arch/x86/cpu/tangier/acpi.c
> > > index 12f9289612..e3a2fcea76 100644
> > > --- a/arch/x86/cpu/tangier/acpi.c
> > > +++ b/arch/x86/cpu/tangier/acpi.c
> > > @@ -68,14 +68,17 @@ u32 acpi_fill_madt(u32 current)
> > > return current;
> > >  }
> > >
> > > -u32 acpi_fill_mcfg(u32 current)
> > > +int acpi_fill_mcfg(struct acpi_ctx *ctx)
> > >  {
> > > +   size_t size;
> > > +
> > > /* TODO: Derive parameters from SFI MCFG table */
> > > -   current += acpi_create_mcfg_mmconfig
> > > -   ((struct acpi_mcfg_mmconfig *)current,
> > > +   size = acpi_create_mcfg_mmconfig
> > > +   ((struct acpi_mcfg_mmconfig *)ctx->current,
> > > MCFG_BASE_ADDRESS, 0x0, 0x0, 0x0);
> > > +   acpi_inc(ctx, size);
> > >
> > > -   return current;
> > > +   return 0;
> > >  }
> > >
> > >  static u32 acpi_fill_csrt_dma(struct acpi_csrt_group *grp)
> > > diff --git a/arch/x86/include/asm/acpi_table.h 
> > > b/arch/x86/include/asm/acpi_table.h
> > > index 0d07f7cad8..39547de0d4 100644
> > > --- a/arch/x86/include/asm/acpi_table.h
> > > +++ b/arch/x86/include/asm/acpi_table.h
> > > @@ -34,7 +34,6 @@ int acpi_create_madt_lapic_nmi(struct 
> > > acpi_madt_lapic_nmi *lapic_nmi,
> > >  u32 acpi_fill_madt(u32 current);
> > >  int acpi_create_mcfg_mmconfig(struct acpi_mcfg_mmconfig *mmconfig, u32 
> > > base,
> > >   u16 seg_nr, u8 start, u8 end);
> > > -u32 acpi_fill_mcfg(u32 current);
> > >
> > >  /**
> > >   * acpi_write_hpet() - Write out a HPET table
> > > diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
> > > index 753bf39619..c5b33dc65d 100644
> > > --- a/arch/x86/lib/acpi_table.c
> > > +++ b/arch/x86/lib/acpi_table.c
> > > @@ -161,28 +161,6 @@ int acpi_write_madt(struct acpi_ctx *ctx, const 
> > > struct acpi_writer *entry)
> > >  }
> > >  ACPI_WRITER(5x86, NULL, acpi_write_madt, 0);
> > >
> > > -int acpi_create_mcfg_mmconfig(struct acpi_mcfg_mmconfig *mmconfig, u32 
> > > base,
> > > - u16 seg_nr, u8 start, u8 end)
> > > -{
> > > -   memset(mmconfig, 0, sizeof(*mmconfig));
> > > -   mmconfig->base_address_l = base;
> > > -   mmconfig->base_address_h = 0;
> > > -   mmconfig->pci_segment_group_number = seg_nr;
> > > -   mmconfig->start_bus_number = start;
> > > -   mmconfig->end_bus_number = end;
> > > -
> > > -   return sizeof(struct acpi_mcfg_mmconfig);
> > > -}
> > > -
> > > -__weak u32 acpi_fill_mcfg(u32 current)
> > > -{
> > > -   current += acpi_create_mcfg_mmconfig
> > > -   ((struct acpi_mcfg_mmconfig *)current,
> > > -   CONFIG_PCIE_ECAM_BASE, 0x0, 0x0, 255);
> > > -
> > > -   return current;
> > > -}
> > > -
> > >  /**
> > >   * acpi_create_tcpa() - Create a TCPA table
> > >   *
> > > @@ -480,38 +458,6 @@ int acpi_write_gnvs(struct acpi_ctx *ctx, const 
> > > struct acpi

Re: [PATCH] boot: Update default on USE_SPL_FIT_GENERATOR

[Simon Glass]

Hi Tom,

On Mon, 31 Jan 2022 at 17:03, Tom Rini  wrote:
>
> The use of CONFIG_SPL_FIT_GENERATOR is deprecated and should not be
> used.  Start by changing the current default option from enabled to only
> enabled for the platforms still using it.
>
> Cc: Simon Glass 
> Signed-off-by: Tom Rini 
> ---
> This change completes the migration for a number of platforms that were
> tripping the warning before but not actually using a generator.
> ---
>  boot/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

This landed in spam so I missed it. I have a similar patch in my
series if I ever get time to finish it. But we can deal with any
conflict later.

Regards,
Simon

Re: [PATCH] serial: remove nulldev_serial_input

[Simon Glass]

On Wed, 2 Feb 2022 at 05:53, Heiko Schocher  wrote:
>
> nulldev_serial_input is static and not used in this file,
> so remove it.
>
> Signed-off-by: Heiko Schocher 
> ---
> azure build is clean
> https://dev.azure.com/hs0298/hs/_build/results?buildId=78&view=results
>
>  drivers/serial/serial_nulldev.c | 5 -
>  1 file changed, 5 deletions(-)

Reviewed-by: Simon Glass 

Re: [RFC PATCH] dts: automatically build necessary .dtb files

[Simon Glass]

On Mon, 24 Jan 2022 at 14:15, Rasmus Villemoes
 wrote:
>
> On 24/01/2022 18.57, Simon Glass wrote:
> > Hi,
> >
> > On Mon, 24 Jan 2022 at 09:02, Tom Rini  wrote:
> >>
> >> On Mon, Jan 10, 2022 at 02:34:41PM +0100, Rasmus Villemoes wrote:
> >>
> >>> When building for a custom board, it is quite common to maintain a
> >>> private branch which include some defconfig and .dts files. But to
> >>> hook up those .dts files requires modifying a file "belonging" to
> >>> upstream U-Boot, the arch/*/dts/Makefile. Forward-porting that branch
> >>> to a newer upstream then often results in a conflict which, while it
> >>> is trivial to resolve by hand, makes it harder to have a CI do "try to
> >>> build our board against latest upstream".
> >>>
> >>> The .config usually includes information on precisely what .dtb(s) are
> >>> needed, so to avoid having to modify the Makefile, simply add the
> >>> files in (SPL_)OF_LIST to dtb-y.
> >>>
> >>> A technicality is that (SPL_)OF_LIST is not always defined, so rework
> >>> the Kconfig symbols so that (SPL_)OF_LIST is always defined (when
> >>> (SPL_)OF_CONTROL), but only prompted for in the cases which used to be
> >>> their "depends on".
> >>>
> >>> nios2 and microblaze already have something like this in their
> >>> dts/Makefile, and the rationale in commit 41f59f68539 is similar to
> >>> the above. So this simply generalizes existing practice. Followup
> >>> patches could remove the logic in those two makefiles, just as there's
> >>> potential for moving some common boilerplate from all the
> >>> arch/*/dts/Makefile files to the new scripts/Makefile.dts.
> >>>
> >>> Signed-off-by: Rasmus Villemoes 
> >>> ---
> >>>  arch/arc/dts/Makefile| 2 ++
> >>>  arch/arm/dts/Makefile| 2 ++
> >>>  arch/m68k/dts/Makefile   | 2 ++
> >>>  arch/microblaze/dts/Makefile | 2 ++
> >>>  arch/mips/dts/Makefile   | 2 ++
> >>>  arch/nds32/dts/Makefile  | 2 ++
> >>>  arch/nios2/dts/Makefile  | 2 ++
> >>>  arch/powerpc/dts/Makefile| 2 ++
> >>>  arch/riscv/dts/Makefile  | 2 ++
> >>>  arch/sandbox/dts/Makefile| 2 ++
> >>>  arch/sh/dts/Makefile | 2 ++
> >>>  arch/x86/dts/Makefile| 2 ++
> >>>  arch/xtensa/dts/Makefile | 2 ++
> >>>  dts/Kconfig  | 8 
> >>>  scripts/Makefile.dts | 3 +++
> >>>  15 files changed, 33 insertions(+), 4 deletions(-)
> >>>  create mode 100644 scripts/Makefile.dts

Reviewed-by: Simon Glass 

Re: [PATCH v2 1/1] sandbox: fix build failure with musl and SDL

[Simon Glass]

On Sat, 29 Jan 2022 at 07:17, Heinrich Schuchardt
 wrote:
>
>
>
> On 1/28/22 10:08, Heinrich Schuchardt wrote:
> > sdl.c is compiled against the SDL library.
> >
> > Trying to redefine wchar_t with -fshort-wchar is not necessary
> > and leads to build failures when compiling against musl.
> >
> > Cc: Milan P. Stanić 
> > Signed-off-by: Heinrich Schuchardt 
> > ---

Reviewed-by: Simon Glass 

How do I compile against musl?

Regards,
Simon

> > v2:
> >   fix a build error with clang by adding -fno-lto for building sdl.o
> >
> > A better longterm solution will be to eliminate -fshort-wchar completely.
> > This will require replacing %ls printf() codes by something that gcc does
> > not check, e.g. %pS. Further all L"" strings must be replaced by u""
> > strings.
>
> %p will not work as a replacement for %ls:
>
> warning: precision used with ‘%p’ gnu_printf format [-Wformat=]
>298 | s += sprintf(s, "%-.*ps", slen, fp->str);
>|  ^
>
> Best regards
>
> Heinrich

Re: [PATCH] boot: Update default on USE_SPL_FIT_GENERATOR

[Tom Rini]

On Tue, Feb 08, 2022 at 08:13:33AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 31 Jan 2022 at 17:03, Tom Rini  wrote:
> >
> > The use of CONFIG_SPL_FIT_GENERATOR is deprecated and should not be
> > used.  Start by changing the current default option from enabled to only
> > enabled for the platforms still using it.
> >
> > Cc: Simon Glass 
> > Signed-off-by: Tom Rini 
> > ---
> > This change completes the migration for a number of platforms that were
> > tripping the warning before but not actually using a generator.
> > ---
> >  boot/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Reviewed-by: Simon Glass 
> 
> This landed in spam so I missed it. I have a similar patch in my
> series if I ever get time to finish it. But we can deal with any
> conflict later.

OK.  Now that the first iMX PR has come through I _think_ the implicitly
depended on binman patches there have come in and so this patch won't
break anything.  I'll pick this up soon along with other Kconfig
migration/etc patches in the next day or two.

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC PATCH v2 00/21] Modernize U-Boot shell

[Tom Rini]

On Sun, Feb 06, 2022 at 07:54:26PM +0100, Heinrich Schuchardt wrote:
> On 2/6/22 19:36, Francis Laniel wrote:
> > Hi.
> > 
> > First I hope you are fine and the same for your relatives.
> > 
> > During 2021 summer, Sean Anderson wrote a contribution to add a new shell, 
> > based
> > on LIL, to U-Boot [1][2].
> > While one of the goals of this contribution was to address the fact actual
> > U-Boot shell, which is based on Busybox hush, is old there was a discussion
> > about adding a new shell versus updating the actual one [3][4].
> > 
> > So, in this series, with Harald Seiler, we updated the actual U-Boot shell 
> > to
> > reflect what is currently in Busybox source code.
> > Basically, this contribution is about taking a snapshot of Busybox 
> > shell/hush.c
> > file (as it exists in commit 37460f5da) and adapt it to suit U-Boot needs.
> > 
> > This contribution was written to be as backward-compatible as possible to 
> > avoid
> > breaking the existing.
> > So, the 2021 hush flavor offers the same as the actual, that is to say:
> > 1. Variable expansion.
> > 2. Instruction lists (;, && and ||).
> > 3. If, then and else.
> > 4. Loops (for, while and until).
> > No new features offered by Busybox hush were implemented (e.g. functions).
> 
> If no new features are added relative to what we have, why should we add
> 12000 lines of code? Please, describe the benefit of the series.

Please see the referenced threads for a longer discussion of why this is
being looked at.

> Is there a repo with your patches?

Note that "b4 am -o - 
20220206183717.57446-1-francis.lan...@amarulasolutions.com | git am -3"
applies cleanly.

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC PATCH v2 00/21] Modernize U-Boot shell

[Simon Glass]

Hi,

On Tue, 8 Feb 2022 at 08:28, Tom Rini  wrote:
>
> On Sun, Feb 06, 2022 at 07:54:26PM +0100, Heinrich Schuchardt wrote:
> > On 2/6/22 19:36, Francis Laniel wrote:
> > > Hi.
> > >
> > > First I hope you are fine and the same for your relatives.
> > >
> > > During 2021 summer, Sean Anderson wrote a contribution to add a new 
> > > shell, based
> > > on LIL, to U-Boot [1][2].
> > > While one of the goals of this contribution was to address the fact actual
> > > U-Boot shell, which is based on Busybox hush, is old there was a 
> > > discussion
> > > about adding a new shell versus updating the actual one [3][4].
> > >
> > > So, in this series, with Harald Seiler, we updated the actual U-Boot 
> > > shell to
> > > reflect what is currently in Busybox source code.
> > > Basically, this contribution is about taking a snapshot of Busybox 
> > > shell/hush.c
> > > file (as it exists in commit 37460f5da) and adapt it to suit U-Boot needs.
> > >
> > > This contribution was written to be as backward-compatible as possible to 
> > > avoid
> > > breaking the existing.
> > > So, the 2021 hush flavor offers the same as the actual, that is to say:
> > > 1. Variable expansion.
> > > 2. Instruction lists (;, && and ||).
> > > 3. If, then and else.
> > > 4. Loops (for, while and until).
> > > No new features offered by Busybox hush were implemented (e.g. functions).
> >
> > If no new features are added relative to what we have, why should we add
> > 12000 lines of code? Please, describe the benefit of the series.
>
> Please see the referenced threads for a longer discussion of why this is
> being looked at.

It was also discussed at length in a U-Boot contributor call.

https://docs.google.com/document/d/1YBOMsbM19uSFyoJWnt7-PsOLBaevzQUgV-hiR88a5-o/edit#bookmark=id.j6h2xzste5sy

I know you cannot attend the meetings, but it is a good idea to check
the notes every now and then :-)

>
> > Is there a repo with your patches?
>
> Note that "b4 am -o - 
> 20220206183717.57446-1-francis.lan...@amarulasolutions.com | git am -3"
> applies cleanly.

Regards,
Simon

Re: Running qemu tests on RISC-V

[Heinrich Schuchardt]

On 2/8/22 15:52, Simon Glass wrote:

Hi Heinrich,

On Tue, 8 Feb 2022 at 01:21, Heinrich Schuchardt  wrote:


On 2/7/22 19:19, Simon Glass wrote:

Hi Tom,

On Mon, 7 Feb 2022 at 09:49, Tom Rini  wrote:


On Mon, Feb 07, 2022 at 11:34:17AM -0500, Sean Anderson wrote:



On 2/7/22 10:53 AM, Heinrich Schuchardt wrote:

On 2/7/22 16:38, Simon Glass wrote:

Hi,

I am trying to run the SPL tests for riscv32 but it dies with an
illegal instruction. I have tried building qemu 4.2 but it seems to
happen on various versions. Has anyone seen this?


Did you try to run qemu-riscv32_spl_defconfig in the Docker container we
are using for Gitlab?


No, I want to run it outside docker. I can see that it works in the
docker container, but not sure why it fails for me.



We are using QEMU v6.1.0 according to tools/docker/Dockerfile.

With all that duplicate output below it is hard to understand what is
going. Why is each byte written twice to the serial?


If I had to guess there are 2 harts, and they both trigger an illegal
instruction. In situations like these, I have added a spinlock around puts.


There are 4 CPUs I think.



It might also be worth asking why such an old QEMU?  I know my
host-provided QEMU is 4.2.1 but I just don't use it since it's too old
for everything we do, especially on something as fast moving as RISC-V.


I tried 6.x and went back to 4.2.1 because I thought that might be the problem.



And as an aside, if anyone has tips on changes that would need to be
made to our Dockerfile so that some of those tools that let you run app
from a container "normally" would work with our container, that'd be
handy and appreciated.


I'm not sure what that means, probably because I am not an expert in that area.

Regards,
Simon


Hello Simon,

The qemu-riscv32_spl_defconfig image built inside Docker with

wget -O -
https://github.com/riscv/opensbi/releases/download/v0.9/opensbi-0.9-rv-bin.tar.xz
export
OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin
tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl

runs flawlessly on Ubuntu Jammy with:

qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \
  -device loader,file=u-boot.itb,addr=0x8020 -smp cpus=4

This is a QEMU 6.0

Please, provide a reproducible instruction for your problem.


I wonder if the problem is the OPENSBI thing. I am not providing that,
nor am I seeing a warning about it.


OpenSBI is needed to emulate unaligned access, access to CSR registers
and so forth. I assume you cannot run qemu-riscv32_spl_defconfig.

A build warning if CONFIG_SPL_OPENSBI=y and OPENSBI is not defined might
make sense.

Best regards

Heinrich



+Alper Nebi Yasak did a series that makes Fit a subclass of Section
but even that does not help with the missing warning. Has anyone else
noticed it?

Regards,
Simon

Re: [PATCH 00/14] Add support for NVMEM API

[Sean Anderson]

Hi Michael,

On 2/8/22 10:00 AM, Michael Walle wrote:
> Hi Sean,
> 
>> Should this be implemented on top of/as part of syscon/regmap? In Linux,
>> all nvmem devices must also implement regmap support, making nvmem a
>> subset of regmap drivers. There are certainly similarities, but I don't
>> know if we want to make this depend on regmap.
> 
> What do you mean by that? I assume with "nvmem devices" you mean the
> nvmem providers. I've implemented the nvmem provider for MTD OTP devices
> in linux and there is no regmap support.

According to [1],

> [The NVMEM] framework is based on regmap, so that most of the
> abstraction available in regmap can be reused, across multiple types
> of buses.

and

> It is mandatory that the NVMEM provider has a regmap associated with
> its struct device. Failure to do would return error code from
> nvmem_register().

which seems to imply that NVMEM devices should also be regmaps.

--Sean

[1] https://www.kernel.org/doc/html/latest/driver-api/nvmem.html

Re: [PATCH 00/14] Add support for NVMEM API

[Michael Walle]

Hi Sean,

Am 2022-02-08 17:02, schrieb Sean Anderson:
Should this be implemented on top of/as part of syscon/regmap? In 
Linux,

all nvmem devices must also implement regmap support, making nvmem a
subset of regmap drivers. There are certainly similarities, but I 
don't

know if we want to make this depend on regmap.


What do you mean by that? I assume with "nvmem devices" you mean the
nvmem providers. I've implemented the nvmem provider for MTD OTP 
devices

in linux and there is no regmap support.


According to [1],


[The NVMEM] framework is based on regmap, so that most of the
abstraction available in regmap can be reused, across multiple types
of buses.


and


It is mandatory that the NVMEM provider has a regmap associated with
its struct device. Failure to do would return error code from
nvmem_register().


which seems to imply that NVMEM devices should also be regmaps.


Ahh I see. That seems to be outdated, see commit
795ddd18d38f9762fbfefceab9aa16caef0cf431 ("nvmem: core: remove
regmap dependency").

-michael

Re: [PATCH v2 1/1] sandbox: fix build failure with musl and SDL

[Heinrich Schuchardt]

On 2/8/22 16:16, Simon Glass wrote:

On Sat, 29 Jan 2022 at 07:17, Heinrich Schuchardt
 wrote:




On 1/28/22 10:08, Heinrich Schuchardt wrote:

sdl.c is compiled against the SDL library.

Trying to redefine wchar_t with -fshort-wchar is not necessary
and leads to build failures when compiling against musl.

Cc: Milan P. Stanić 
Signed-off-by: Heinrich Schuchardt 
---


Reviewed-by: Simon Glass 

How do I compile against musl?


On Ubuntu install the musl-tools package and use musl-gcc as your compiler.

You can add a new alternative for cc with

sudo update-alternatives --install /usr/bin/cc cc 
/usr/bin/x86_64-linux-musl-gcc 10


and choose the active alternative with

sudo update-alternatives --config cc

But this will give you problems with the include paths for libraries 
like openssl.


A better choice is using a distro like Alpine which defaults to musl. 
You can easily test it in docker.


Best regards

Heinrich



Regards,
Simon


v2:
   fix a build error with clang by adding -fno-lto for building sdl.o

A better longterm solution will be to eliminate -fshort-wchar completely.
This will require replacing %ls printf() codes by something that gcc does
not check, e.g. %pS. Further all L"" strings must be replaced by u""
strings.


%p will not work as a replacement for %ls:

warning: precision used with ‘%p’ gnu_printf format [-Wformat=]
298 | s += sprintf(s, "%-.*ps", slen, fp->str);
|  ^

Best regards

Heinrich

Compile error with SPL_FIT_FULL_CHECK and SPL_LOAD_FIT_FULL enabled

[Johann Neuhauser]

Dear developers and Simon,

we wanna run secure boot with U-Boot's SPL_FIT_SIGNATURE and FIT_SIGNATURE on 
our STM32MP1 boards and discovered the CVE-2021-27097.
To mitigate this vulnerability we wanna enable SPL_LOAD_FIT_FULL and 
SPL_FIT_FULL_CHECK.
If I compile any U-Boot SPL with the mentioned config symbols after commit 
6f3c2d8a, it fails always with the following error message:

Used defconfig: stm32mp15_dhcom_basic_defconfig (+ mentioned configs enabled)
```
...
  LD  spl/lib/built-in.o
  LD  spl/u-boot-spl
/usr/bin/arm-linux-gnueabihf-ld.bfd: common/built-in.o: in function 
`fit_check_format':
/mnt/work/dev/u-boot/common/image-fit.c:1591: undefined reference to 
`fdt_check_full'
make[1]: *** [scripts/Makefile.spl:432: spl/u-boot-spl] Error 1
make: *** [Makefile:1941: spl/u-boot-spl] Error 2
```
After diging around to find the cause, we're out of ideas.
Does anyone have a clue why the needed function is not compiled in libfdt for 
the spl build?

Many thanks in advance.

Best regards,

Johann Neuhauser

DH electronics GmbH | Am Anger 8 | 83346 Bergen | Germany | Fon: +49 8662 4882 0
Board of Management: Stefan Daxenberger, Helmut Henschke | HRB Traunstein 9602

Re: Compile error with SPL_FIT_FULL_CHECK and SPL_LOAD_FIT_FULL enabled

[Philippe REYNES]

Hi Johann,

Le 08/02/2022 à 16:43, Johann Neuhauser a écrit :

Dear developers and Simon,

we wanna run secure boot with U-Boot's SPL_FIT_SIGNATURE and FIT_SIGNATURE on 
our STM32MP1 boards and discovered the CVE-2021-27097.
To mitigate this vulnerability we wanna enable SPL_LOAD_FIT_FULL and 
SPL_FIT_FULL_CHECK.
If I compile any U-Boot SPL with the mentioned config symbols after commit 
6f3c2d8a, it fails always with the following error message:

Used defconfig: stm32mp15_dhcom_basic_defconfig (+ mentioned configs enabled)
```
...
   LD  spl/lib/built-in.o
   LD  spl/u-boot-spl
/usr/bin/arm-linux-gnueabihf-ld.bfd: common/built-in.o: in function 
`fit_check_format':
/mnt/work/dev/u-boot/common/image-fit.c:1591: undefined reference to 
`fdt_check_full'
make[1]: *** [scripts/Makefile.spl:432: spl/u-boot-spl] Error 1
make: *** [Makefile:1941: spl/u-boot-spl] Error 2
```
After diging around to find the cause, we're out of ideas.
Does anyone have a clue why the needed function is not compiled in libfdt for 
the spl build?
I have reproduced this issue with this config 
(stm32mp15_dhcom_basic_defconfig (+ mentioned configs enabled)).

The function fdt_check_full is build conditionnaly:

#if !defined(FDT_ASSUME_MASK) || FDT_ASSUME_MASK != 0xff
int fdt_check_full(const void *fdt, size_t bufsize)

{

...

}

In this config FDT_ASSUME_MASK is 0xff, so the function fdt_check_full 
is not compiled.

I succeed to build (not tested) with this patch:

--- a/scripts/dtc/libfdt/fdt_ro.c
+++ b/scripts/dtc/libfdt/fdt_ro.c
@@ -937,4 +937,9 @@ int fdt_check_full(const void *fdt, size_t bufsize)
    }
    }
 }
+#else
+int fdt_check_full(const void *fdt, size_t bufsize)
+{
+   return 0;
+}
 #endif


If simon agrees with this fix, I may sent a patch.



Many thanks in advance.

Best regards,

Johann Neuhauser

DH electronics GmbH | Am Anger 8 | 83346 Bergen | Germany | Fon: +49 8662 4882 0
Board of Management: Stefan Daxenberger, Helmut Henschke | HRB Traunstein 9602



Regards,
Philippe

Re: Compile error with SPL_FIT_FULL_CHECK and SPL_LOAD_FIT_FULL enabled

[Simon Glass]

Hi Johann,

On Tue, 8 Feb 2022 at 08:44, Johann Neuhauser
 wrote:
>
> Dear developers and Simon,
>
> we wanna run secure boot with U-Boot's SPL_FIT_SIGNATURE and FIT_SIGNATURE on 
> our STM32MP1 boards and discovered the CVE-2021-27097.

That is already fixed in 2021.04 so you can just use a mainline U-Boot
to avoid it.

> To mitigate this vulnerability we wanna enable SPL_LOAD_FIT_FULL and 
> SPL_FIT_FULL_CHECK.
> If I compile any U-Boot SPL with the mentioned config symbols after commit 
> 6f3c2d8a, it fails always with the following error message:
>
> Used defconfig: stm32mp15_dhcom_basic_defconfig (+ mentioned configs enabled)
> ```
> ...
>   LD  spl/lib/built-in.o
>   LD  spl/u-boot-spl
> /usr/bin/arm-linux-gnueabihf-ld.bfd: common/built-in.o: in function 
> `fit_check_format':
> /mnt/work/dev/u-boot/common/image-fit.c:1591: undefined reference to 
> `fdt_check_full'
> make[1]: *** [scripts/Makefile.spl:432: spl/u-boot-spl] Error 1
> make: *** [Makefile:1941: spl/u-boot-spl] Error 2
> ```
> After diging around to find the cause, we're out of ideas.
> Does anyone have a clue why the needed function is not compiled in libfdt for 
> the spl build?

SPL_OF_LIBFDT_ASSUME_MASK is set to 0xff so this check is not enabled.
I suspect that the value of that setting should change to 0 or 1 if
the full check is enabled.

Regards,
Simon

Re: Running qemu tests on RISC-V

[Simon Glass]

Hi Heinrich,

On Tue, 8 Feb 2022 at 08:34, Heinrich Schuchardt  wrote:
>
> On 2/8/22 15:52, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Tue, 8 Feb 2022 at 01:21, Heinrich Schuchardt  wrote:
> >>
> >> On 2/7/22 19:19, Simon Glass wrote:
> >>> Hi Tom,
> >>>
> >>> On Mon, 7 Feb 2022 at 09:49, Tom Rini  wrote:
> 
>  On Mon, Feb 07, 2022 at 11:34:17AM -0500, Sean Anderson wrote:
> >
> >
> > On 2/7/22 10:53 AM, Heinrich Schuchardt wrote:
> >> On 2/7/22 16:38, Simon Glass wrote:
> >>> Hi,
> >>>
> >>> I am trying to run the SPL tests for riscv32 but it dies with an
> >>> illegal instruction. I have tried building qemu 4.2 but it seems to
> >>> happen on various versions. Has anyone seen this?
> >>
> >> Did you try to run qemu-riscv32_spl_defconfig in the Docker container 
> >> we
> >> are using for Gitlab?
> >>>
> >>> No, I want to run it outside docker. I can see that it works in the
> >>> docker container, but not sure why it fails for me.
> >>>
> >>
> >> We are using QEMU v6.1.0 according to tools/docker/Dockerfile.
> >>
> >> With all that duplicate output below it is hard to understand what is
> >> going. Why is each byte written twice to the serial?
> >
> > If I had to guess there are 2 harts, and they both trigger an illegal
> > instruction. In situations like these, I have added a spinlock around 
> > puts.
> >>>
> >>> There are 4 CPUs I think.
> >>>
> 
>  It might also be worth asking why such an old QEMU?  I know my
>  host-provided QEMU is 4.2.1 but I just don't use it since it's too old
>  for everything we do, especially on something as fast moving as RISC-V.
> >>>
> >>> I tried 6.x and went back to 4.2.1 because I thought that might be the 
> >>> problem.
> >>>
> 
>  And as an aside, if anyone has tips on changes that would need to be
>  made to our Dockerfile so that some of those tools that let you run app
>  from a container "normally" would work with our container, that'd be
>  handy and appreciated.
> >>>
> >>> I'm not sure what that means, probably because I am not an expert in that 
> >>> area.
> >>>
> >>> Regards,
> >>> Simon
> >>
> >> Hello Simon,
> >>
> >> The qemu-riscv32_spl_defconfig image built inside Docker with
> >>
> >> wget -O -
> >> https://github.com/riscv/opensbi/releases/download/v0.9/opensbi-0.9-rv-bin.tar.xz
> >> export
> >> OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin
> >> tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl
> >>
> >> runs flawlessly on Ubuntu Jammy with:
> >>
> >> qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \
> >>   -device loader,file=u-boot.itb,addr=0x8020 -smp cpus=4
> >>
> >> This is a QEMU 6.0
> >>
> >> Please, provide a reproducible instruction for your problem.
> >
> > I wonder if the problem is the OPENSBI thing. I am not providing that,
> > nor am I seeing a warning about it.
>
> OpenSBI is needed to emulate unaligned access, access to CSR registers
> and so forth. I assume you cannot run qemu-riscv32_spl_defconfig.
>
> A build warning if CONFIG_SPL_OPENSBI=y and OPENSBI is not defined might
> make sense.

OK, it seems we need a binman test that we warn on external blobs that
are embedded in a FIT.


> >
> > +Alper Nebi Yasak did a series that makes Fit a subclass of Section
> > but even that does not help with the missing warning. Has anyone else
> > noticed it?

Regards,
Simon

Re: [PATCH v4 01/20] remoteproc: k3_system_controller: Support optional boot_notification channel

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:27PM +0530, Aswath Govindraju wrote:

> From: Nishanth Menon 
> 
> If there is an optional boot notification channel that an SoC uses
> separate from the rx path, use the same.
> 
> Signed-off-by: Nishanth Menon 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 02/20] ram: k3-ddrss: lpddr4_structs_if.h: Add a pointer to ddr instance

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:28PM +0530, Aswath Govindraju wrote:

> Add a pointer to ddr instance int the lpddr4_privatedata_s structure for
> supporting mutliple instances of DDR in the drivers.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 03/20] ram: k3-ddrss: Add support for multiple instances of DDR subsystems

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:29PM +0530, Aswath Govindraju wrote:

> The current driver only supports single instance of DRR subsystem. Add
> support for probing multiple instances of DDR subsystem.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 04/20] ram: k3-ddrss: Add support for configuring MSMC subsystem in case of Multiple DDR subsystems

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:30PM +0530, Aswath Govindraju wrote:

> In Multi DDR subystems with interleaving support, the following needs to
> configured,
> 
> - interleaving granular size and region
> - EMIFs to be enabled
> - EMIFs with ecc to be enabled
> - EMIF separated or interleaved
> - number of cycles of unsuccessful EMIF arbitration to wait before
>   arbitrating for a different EMIF port, by default set to 3
> 
> Add support for configuring all the above by using a MSMC device
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 05/20] arm: K3: Add basic support for J721S2 SoC definition

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:31PM +0530, Aswath Govindraju wrote:

> From: David Huang 
> 
> Add basic support for J721S2 SoC definition
> 
> Signed-off-by: David Huang 
> Signed-off-by: Aswath Govindraju 
> Signed-off-by: Dave Gerlach 
> Signed-off-by: Nishanth Menon 
> Signed-off-by: Hari Nagalla 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 06/20] drivers: dma: Add support for J721S2

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:32PM +0530, Aswath Govindraju wrote:

> From: David Huang 
> 
> Add support for DMA in J721S2 SoC.
> 
> Signed-off-by: David Huang 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 07/20] clk: clk-k3: Add support for J721S2 SoC

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:33PM +0530, Aswath Govindraju wrote:

> From: David Huang 
> 
> Add support for J721S2 SoC.
> 
> Signed-off-by: David Huang 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 08/20] power: domain: ti: Add support for J721S2 SoC

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:34PM +0530, Aswath Govindraju wrote:

> From: David Huang 
> 
> Add support for J721S2 SoC.
> 
> Signed-off-by: David Huang 
> Signed-off-by: Aswath Govindraju 
> Reviewed-by: Jaehoon Chung 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 09/20] ram: k3-ddrss: Add support for J721S2 SoC

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:35PM +0530, Aswath Govindraju wrote:

> From: David Huang 
> 
> Add support for DDR subsystem in J721S2 SoC.
> 
> Signed-off-by: David Huang 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 10/20] soc: ti: k3-socinfo: Add entry for J721S2 SoC

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:36PM +0530, Aswath Govindraju wrote:

> From: David Huang 
> 
> Add support for J721S2 SoC identification.
> 
> Signed-off-by: David Huang 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 11/20] board: ti: j721s2: Add board support for J721S2

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:37PM +0530, Aswath Govindraju wrote:

> From: David Huang 
> 
> Add board support for J721S2 SoC.
> 
> Signed-off-by: David Huang 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 12/20] dt-bindings: ti-serdes-mux: Add defines for J721S2 SoC

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:38PM +0530, Aswath Govindraju wrote:

> There are 4 lanes in the single instance of J721S2 SERDES. Each SERDES
> lane mux can select upto 4 different IPs. Define all the possible
> functions.
> 
> Signed-off-by: Aswath Govindraju 

First, this is now applied to u-boot/master.  Second, to follow up on
some of my previous feedback, there is for example now:
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/options/u-boot.yaml
and I expect that this binding, and other relevant "the SoC needs these,
but the Linux kernel does not" will be submitted upstream to dt-schema
and then synced back to U-Boot (and then yes, we don't _yet_ support the
yaml checking in U-Boot natively, but, that's something else to solve).
Thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 13/20] dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721S2

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:39PM +0530, Aswath Govindraju wrote:

> Add pinctrl macros for J721S2 SoC. These macro definitions are
> similar to that of J721E, but adding new definitions to avoid
> any naming confusions in the soc dts files.
> 
> checkpatch insists the following error exists:
> ERROR: Macros with complex values should be enclosed in parentheses
> 
> However, we do not need parentheses enclosing the values for this
> macro as we do intend it to generate two separate values as has been
> done for other similar platforms.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 14/20] arm: dts: Add initial support for J721S2 SoC

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:40PM +0530, Aswath Govindraju wrote:

> The J721S2 SoC belongs to the K3 Multicore SoC architecture platform,
> providing advanced system integration in automotive ADAS applications and
> industrial applications requiring AI at the network edge. This SoC extends
> the Jacinto 7 family of SoCs with focus on lowering system costs and power
> while providing interfaces, memory architecture and compute performance for
> single and multi-sensor applications.
> 
> Some highlights of this SoC are:
> 
> * Dual Cortex-A72s in a single cluster, three clusters of lockstep capable
> dual Cortex-R5F MCUs, Deep-learning Matrix Multiply Accelerator(MMA), C7x
> floating point Vector DSP.
> * 3D GPU: Automotive grade IMG BXS-4-64
> * Vision Processing Accelerator (VPAC) with image signal processor and
> Depth and Motion Processing Accelerator (DMPAC)
> * Two CSI2.0 4L RX plus one eDP/DP, two DSI Tx, and one DPI interface.
> * Two Ethernet ports with RGMII support.
> * Single 4 lane PCIe-GEN3 controllers, USB3.0 Dual-role device subsystems,
> * Up to 20 MCANs, 5 McASP, eMMC and SD, OSPI/HyperBus memory controller,
> QSPI, I3C and I2C, eCAP/eQEP, eHRPWM, MLB among other peripherals.
> * Hardware accelerator blocks containing AES/DES/SHA/MD5 called SA2UL
> management.
> 
> See J721S2 Technical Reference Manual (SPRUJ28 – NOVEMBER 2021)
> for further details: http://www.ti.com/lit/pdf/spruj28
> 
> Introduce basic support for the J721S2 SoC.
> 
> Signed-off-by: Aswath Govindraju 
> Signed-off-by: Vignesh Raghavendra 
> Signed-off-by: Nishanth Menon 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 15/20] arm: dts: Add initial support for J721S2 System on Module

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:41PM +0530, Aswath Govindraju wrote:

> A System on Module (SoM) contains the SoC, PMIC, DDR and basic high speed
> components necessary for functionality. Therefore, add support for the
> components present on the SoM.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 16/20] arm: dts: Add support for A72 specific J721S2 Common Processor Board

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:42PM +0530, Aswath Govindraju wrote:

> The EVM architecture for J721S2 is similar to that of J721E and J7200. It
> is as follows,
> 
> +--+
> |   +---+  |
> |   |   |  |
> |   |Add-on Card 1 Options  |  |
> |   |   |  |
> |   +---+  |
> |  |
> |  |
> | +---+|
> | |   ||
> | |   SOM ||
> |  +--+   |   ||
> |  |  |   |   ||
> |  |  Add-on  |   +---+|
> |  |  Card 2  ||Power Supply
> |  |  Options |||
> |  |  |||
> |  +--+| <---
> +--+
>  Common Processor Board
> 
> Common Processor board is the baseboard that contains most of the actual
> connectors, power supply etc. The System on Module (SoM) is plugged on to
> the common processor baord. Therefore, add support for peripherals brought
> out in the common processor board.
> 
> Link to Common Processor Board: https://www.ti.com/lit/zip/sprr439
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 17/20] arm: dts: k3-j721s2: Add r5 specific dt support

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:43PM +0530, Aswath Govindraju wrote:

> Add initial support for device tree that runs on R5.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 18/20] arm: dts: k3-j721s2-ddr: Add DDR support

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:44PM +0530, Aswath Govindraju wrote:

> J721S2 can support two instances for DDR. Therefore, add the device support
> for the same and use 4266MT/s as DDR frequency.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 19/20] configs: j721s2_evm_r5_defconfig: Add R5 SPL specific defconfig

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:45PM +0530, Aswath Govindraju wrote:

> From: David Huang 
> 
> Enable R5 SPL specific configs for J721S2.
> 
> Signed-off-by: David Huang 
> Signed-off-by: Aswath Govindraju 
> Signed-off-by: Vignesh Raghavendra 
> Signed-off-by: Hari Nagalla 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] soc: soc_ti_k3: update j721e revision numbering

[Tom Rini]

On Wed, Jan 26, 2022 at 04:07:33PM -0600, Bryan Brattlof wrote:

> There is a 4 bit VARIANT number inside the JTAGID register that TI
> increments any time a new variant for a chip is produced. Each
> family of TI's SoCs uses a different versioning scheme based off
> that VARIANT number.
> 
> CC: Dave Gerlach 
> Signed-off-by: Bryan Brattlof 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 20/20] configs: j721s2_evm_a72_defconfig: Add A72 specific defconfig

[Tom Rini]

On Tue, Jan 25, 2022 at 08:56:46PM +0530, Aswath Govindraju wrote:

> From: David Huang 
> 
> Enable A72 specific configs for J721S2
> 
> Signed-off-by: David Huang 
> Signed-off-by: Aswath Govindraju 
> Signed-off-by: Vignesh Raghavendra 
> Signed-off-by: Hari Nagalla 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 01/11] configs: dra7xx_evm: Increase the size of SPL_MULTI_DTB_FIT

[Tom Rini]

On Thu, Jan 27, 2022 at 01:16:50PM +0100, Amjad Ouled-Ameur wrote:

> Expand SPL_MULTI_DTB_FIT to accommodate new SPL IPU nodes.
> 
> Signed-off-by: Amjad Ouled-Ameur 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 02/11] reset: dra7: Add a reset driver

[Tom Rini]

On Thu, Jan 27, 2022 at 01:16:51PM +0100, Amjad Ouled-Ameur wrote:

> From: Keerthy 
> 
> Add a reset driver to bring IPs out of reset.
> 
> Signed-off-by: Keerthy 
> [Amjad: reset_ops structure member "free" has been renamed to "rfree",
> use the latter instead]
> Signed-off-by: Amjad Ouled-Ameur 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 03/11] arm: mach-omap2: load/start remoteproc IPU1/IPU2

[Tom Rini]

On Thu, Jan 27, 2022 at 01:16:52PM +0100, Amjad Ouled-Ameur wrote:

> From: Keerthy 
> 
> First check the presence of the ipu firmware in the boot partition.
> If present enable the ipu and the related clocks & then move
> on to load the firmware and eventually start remoteproc IPU1/IPU2.
> 
> do_enable_clocks by default puts the clock domains into auto
> which does not work well with reset. Hence adding do_enable_ipu_clocks
> function.
> 
> Signed-off-by: Keerthy 
> [Amjad: fix IPU1_LOAD_ADDR and compile warnings]
> Signed-off-by: Amjad Ouled-Ameur 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 04/11] drivers: misc: Makefile: Enable fs_loader compilation at SPL Level

[Tom Rini]

On Thu, Jan 27, 2022 at 01:16:53PM +0100, Amjad Ouled-Ameur wrote:

> From: Keerthy 
> 
> Enable fs_loader compilation at SPL Level.
> 
> Signed-off-by: Keerthy 
> [Amjad: fix compilation failures for J721e platform]
> Signed-off-by: Amjad Ouled-Ameur 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 05/11] linux: bitmap.h: Add find_next_zero_area function

[Tom Rini]

On Thu, Jan 27, 2022 at 01:16:54PM +0100, Amjad Ouled-Ameur wrote:

> From: Keerthy 
> 
> Add find_next_zero_area to fetch the next zero area in the map.
> 
> Signed-off-by: Keerthy 
> Signed-off-by: Amjad Ouled-Ameur 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 06/11] remoteproc: uclass: Add remoteproc resource handling helpers

[Tom Rini]

On Thu, Jan 27, 2022 at 01:16:55PM +0100, Amjad Ouled-Ameur wrote:

> From: Keerthy 
> 
> Add remoteproc resource handling helpers. These functions
> are primarily to parse the resource table and to handle
> different types of resources. Carveout, devmem, trace &
> vring resources are handled.
> 
> Signed-off-by: Keerthy 
> [Amjad: fix redefinition of "struct resource_table" and compile warnings ]
> Signed-off-by: Amjad Ouled-Ameur 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 07/11] remoteproc: ipu: Add driver to bring up ipu

[Tom Rini]

On Thu, Jan 27, 2022 at 01:16:56PM +0100, Amjad Ouled-Ameur wrote:

> From: Keerthy 
> 
> The driver enables IPU support. Basically enables the clocks,
> timers, watchdog timers and bare minimal MMU and supports
> loading the firmware from mmc.
> 
> Signed-off-by: Keerthy 
> [Amjad: fix compile warnings]
> Signed-off-by: Amjad Ouled-Ameur 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 08/11] dts: dra7-ipu-common-early-boot.dtsi: Add all the ipu early boot related nodes

[Tom Rini]

On Thu, Jan 27, 2022 at 01:16:57PM +0100, Amjad Ouled-Ameur wrote:

> From: Keerthy 
> 
> Add all the ipu early boot related nodes
> 
> Signed-off-by: Keerthy 
> Signed-off-by: Amjad Ouled-Ameur 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 09/11] arm: dts: dra7: Add ipu and related nodes

[Tom Rini]

On Thu, Jan 27, 2022 at 01:16:58PM +0100, Amjad Ouled-Ameur wrote:

> From: Keerthy 
> 
> Add ipu and the associated nodes.
> 
> Signed-off-by: Keerthy 
> Signed-off-by: Amjad Ouled-Ameur 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 10/11] arm: dts: dra7*/am57xx-idk-evm-u-boot: Add ipu early boot DT changes

[Tom Rini]

On Thu, Jan 27, 2022 at 01:16:59PM +0100, Amjad Ouled-Ameur wrote:

> From: Keerthy 
> 
> Add support for ipu early boot.
> 
> Signed-off-by: Keerthy 
> Signed-off-by: Amjad Ouled-Ameur 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 11/11] dts: am57xx*: Add ipu early boot DT changes

[Tom Rini]

On Thu, Jan 27, 2022 at 01:17:00PM +0100, Amjad Ouled-Ameur wrote:

> From: Keerthy 
> 
> Add support for ipu early boot.
> 
> Signed-off-by: Keerthy 
> Signed-off-by: Amjad Ouled-Ameur 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 01/25] phy: cadence: sierra: Fix for USB3 U1/U2 state

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:28PM +0530, Aswath Govindraju wrote:

> From: Sanket Parmar 
> 
> Updated values of USB3 related Sierra PHY registers.
> This change fixes USB3 device disconnect issue observed
> while enternig U1/U2 state.
> 
> Signed-off-by: Sanket Parmar 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 02/25] phy: cadence: Sierra: Fix PHY power_on sequence

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:29PM +0530, Aswath Govindraju wrote:

> From: Kishon Vijay Abraham I 
> 
> Commit 39b823381d9d ("phy: cadence: Add driver for Sierra PHY")
> de-asserts PHY_RESET even before the configurations are loaded in
> phy_init(). However PHY_RESET should be de-asserted only after
> all the configurations has been initialized, instead of de-asserting
> in probe. Fix it here.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 03/25] phy: cadence: Sierra: Create PHY only for "phy" or "link" sub-nodes

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:30PM +0530, Aswath Govindraju wrote:

> From: Kishon Vijay Abraham I 
> 
> Cadence Sierra PHY driver registers PHY using devm_phy_create()
> for all sub-nodes of Sierra device tree node. However Sierra device
> tree node can have sub-nodes for the various clocks in addtion to the
> PHY. Use devm_phy_create() only for nodes with name "phy" (or "link"
> for old device tree) which represent the actual PHY.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 04/25] phy: cadence: Sierra: Move all clk_get_*() to a separate function

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:31PM +0530, Aswath Govindraju wrote:

> From: Kishon Vijay Abraham I 
> 
> No functional change. Group all devm_clk_get_optional() to a
> separate function.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 05/25] phy: cadence: Sierra: Move all reset_control_get*() to a separate function

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:32PM +0530, Aswath Govindraju wrote:

> From: Kishon Vijay Abraham I 
> 
> No functional change. Group devm_reset_control_get() and
> devm_reset_control_get_optional() to a separate function.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 07/25] phy: cadence: Sierra: Add missing clk_disable_unprepare() in .remove callback

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:34PM +0530, Aswath Govindraju wrote:

> From: Kishon Vijay Abraham I 
> 
> Add missing clk_disable_unprepare() in cdns_sierra_phy_remove().
> 
> Signed-off-by: Kishon Vijay Abraham I 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 08/25] phy: cadence: Sierra: Add a UCLASS_PHY device for links

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:35PM +0530, Aswath Govindraju wrote:

> Add a driver of type UCLASS_PHY for each of the link nodes in the serdes
> instance.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 09/25] phy: cadence: Sierra: Model PLL_CMNLC and PLL_CMNLC1 as a clock

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:36PM +0530, Aswath Govindraju wrote:

> Sierra has two PLLs, PLL_CMNLC and PLL_CMNLC1 and each of these PLLs has
> two inputs, plllc_refclk (input from pll0_refclk) and refrcv (input from
> pll1_refclk). Model PLL_CMNLC and PLL_CMNLC1 as a clock so that it's
> possible to select one of these two inputs from device tree.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 10/25] phy: ti: phy-j721e-wiz.c: Fix the condition for setting P_ENABLE_FORCE

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:37PM +0530, Aswath Govindraju wrote:

> Fix the condition for setting P_ENABLE_FORCE bit, by syncing with the
> driver in kernel.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 11/25] board: ti: j721e: evm.c: Add support for probing SerDes0

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:38PM +0530, Aswath Govindraju wrote:

> Add support for probing, initializing and powering, SerDes0 instance.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 12/25] arm: dts: k3-j721e: Add support for PLL_CMNLC clocks in SerDes0

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:39PM +0530, Aswath Govindraju wrote:

> The PLL_CMNLC clocks are modelled as a child clock device of seirra. In the
> function device_probe, the corresponding clocks are probed before calling
> the device's probe. The PLL_CMNLC mux clock can only be created after the
> device's probe. Therefore, move assigned-clocks and assigned-clock-parents
> to the link nodes in U-Boot device tree file.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 13/25] phy: cadence: Sierra: Prepare driver to add support for multilink configurations

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:40PM +0530, Aswath Govindraju wrote:

> From: Swapnil Jakhade 
> 
> Sierra driver currently supports single link configurations only. Prepare
> driver to support multilink multiprotocol configurations along with
> different SSC modes.
> 
> Signed-off-by: Swapnil Jakhade 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 14/25] dt-bindings: phy: cadence-sierra: Add binding to specify SSC mode

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:41PM +0530, Aswath Govindraju wrote:

> From: Swapnil Jakhade 
> 
> Add binding to specify Spread Spectrum Clocking mode used
> 
> Signed-off-by: Swapnil Jakhade 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 15/25] phy: cadence: Sierra: Add support to get SSC type from device tree.

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:42PM +0530, Aswath Govindraju wrote:

> From: Swapnil Jakhade 
> 
> Add support to get SSC type from DT.
> 
> Signed-off-by: Swapnil Jakhade 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 17/25] phy: cadence: Sierra: Add PHY PCS common register configurations

[Tom Rini]

On Fri, Jan 28, 2022 at 01:41:44PM +0530, Aswath Govindraju wrote:

> From: Swapnil Jakhade 
> 
> Add PHY PCS common register configuration sequences for single link.
> Update single link PCIe register sequence accordingly.
> 
> Signed-off-by: Swapnil Jakhade 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature