Hi Sughosh, On Thu, 18 Aug 2022 at 05:39, Sughosh Ganu <sughosh.g...@linaro.org> wrote: > > hi Simon, > > On Thu, 18 Aug 2022 at 08:51, Simon Glass <s...@chromium.org> wrote: > > > > Hi Sughosh, > > > > On Wed, 17 Aug 2022 at 06:44, Sughosh Ganu <sughosh.g...@linaro.org> wrote: > > > > > > In the FWU Multi Bank Update feature, the information about the > > > updatable images is stored as part of the metadata, on a separate > > > partition. Add a driver for reading from and writing to the metadata > > > when the updatable images and the metadata are stored on a block > > > device which is formated with GPT based partition scheme. > > > > > > Signed-off-by: Sughosh Ganu <sughosh.g...@linaro.org> > > > Reviewed-by: Patrick Delaunay <patrick.delau...@foss.st.com> > > > --- > > > Changes since V7: None > > > > > > drivers/fwu-mdata/Kconfig | 9 + > > > drivers/fwu-mdata/Makefile | 1 + > > > drivers/fwu-mdata/fwu_mdata_gpt_blk.c | 410 ++++++++++++++++++++++++++ > > > include/fwu.h | 5 + > > > 4 files changed, 425 insertions(+) > > > create mode 100644 drivers/fwu-mdata/fwu_mdata_gpt_blk.c > > > > > > diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig > > > index d6a21c8e19..d5edef19d6 100644 > > > --- a/drivers/fwu-mdata/Kconfig > > > +++ b/drivers/fwu-mdata/Kconfig > > > @@ -5,3 +5,12 @@ config DM_FWU_MDATA > > > 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. > > > > Can we link to the docs here, or will it be easy for people to find in > > the U-Boot docs? > > The link to the spec is being provided in the documentation for the > feature. I guess that should suffice.
Yes it's the U-Boot documentation that I am referring to. I assume people can type 'FWU metadata' in the docs and it will come up. If so, that seems OK. > > > > > > + > > > +config FWU_MDATA_GPT_BLK > > > + bool "FWU Metadata access for GPT partitioned Block devices" > > > + select PARTITION_TYPE_GUID > > > + select PARTITION_UUIDS > > > + depends on DM && HAVE_BLOCK_DEVICE && EFI_PARTITION > > > + help > > > + Enable support for accessing FWU Metadata on GPT partitioned > > > + block devices. > > > > GPT-partitioned (I think) > > I see "GPT partition" being used elsewhere. I don't have a strong > opinion on this though. > > > > > > diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile > > > index e53a8c9983..313049f67a 100644 > > > --- a/drivers/fwu-mdata/Makefile > > > +++ b/drivers/fwu-mdata/Makefile > > > @@ -4,3 +4,4 @@ > > > # > > > > > > obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o > > > +obj-$(CONFIG_FWU_MDATA_GPT_BLK) += fwu_mdata_gpt_blk.o > > > diff --git a/drivers/fwu-mdata/fwu_mdata_gpt_blk.c b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c > > > > Perhaps just call it gpt_blk.c since it is in this directory > > Actually, there are both type of examples that can be seen under > drivers/. For e.g. the drivers/clk/ has all files starting with clk_*. > Similarly, under drivers/reset/. But there are other examples as well. > But this is not a big effort. I will change the name as per your > suggestion. > > > > > > new file mode 100644 > > > index 0000000000..f694c4369b > > > --- /dev/null > > > +++ b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c > > > @@ -0,0 +1,410 @@ > > > +// SPDX-License-Identifier: GPL-2.0-or-later > > > +/* > > > + * Copyright (c) 2022, Linaro Limited > > > + */ > > > + > > > +#define LOG_CATEGORY UCLASS_FWU_MDATA > > > + > > > +#include <blk.h> > > > +#include <dm.h> > > > +#include <efi_loader.h> > > > +#include <fwu.h> > > > +#include <fwu_mdata.h> > > > +#include <log.h> > > > +#include <malloc.h> > > > +#include <memalign.h> > > > +#include <part.h> > > > +#include <part_efi.h> > > > + > > > +#include <dm/device-internal.h> > > > +#include <linux/errno.h> > > > +#include <linux/types.h> > > > +#include <u-boot/crc.h> > > > + > > > +#define PRIMARY_PART BIT(0) > > > +#define SECONDARY_PART BIT(1) > > > +#define BOTH_PARTS (PRIMARY_PART | SECONDARY_PART) > > > + > > > +#define MDATA_READ BIT(0) > > > +#define MDATA_WRITE BIT(1) > > > + > > > > comment? > > Umm, is the macro name not descriptive enough? They are just being > used to select a read or write operation. I mean the function below > > > > > > +static int gpt_get_mdata_partitions(struct blk_desc *desc, > > > + u16 *primary_mpart, > > > + u16 *secondary_mpart) > > > > Should use uint, no need to select a 16-bit var so far as I can get > > Okay > [..] > > > +static int gpt_get_mdata(struct blk_desc *desc, struct fwu_mdata **mdata) > > > > mdatap > > Okay > > > > > > +{ > > > + int ret; > > > + u16 primary_mpart = 0, secondary_mpart = 0; > > > > uint > > Okay > > > > > Also do you need to set them to 0 > > > > Declare a locate mdata and use that here instead of *mdata, which is a pain. > > This function is copying the metadata into the callers copy. Unless I > don't understand your comment. I mean it is easier to do this (the pattern common in driver model); static int gpt_get_mdata(struct blk_desc *desc, struct fwu_mdata **mdatap) { struct fwu_mdata *mdata; mdata = malloc(sizeof(struct fwu_mdata)); ... (use mdata throughout function) *mdatap = mdata; return 0; } [..] > > > > > + ret = gpt_read_mdata(desc, *mdata, secondary_mpart); > > > + if (ret < 0) { > > > + log_err("Failed to read the FWU metadata from the device\n"); > > > + return -EIO; > > > + } > > > + > > > + ret = fwu_verify_mdata(*mdata, 0); > > > + if (!ret) > > > + return 0; > > > + > > > + /* Both the FWU metadata copies are corrupted. */ > > > + return -1; > > > > This is -EPERM > > > > Perhaps choose something else? > > Again, I am not sure what would be a suitable error to return in this case. Take a look at errno.h and pick one. Maybe -ELIBBAD ? It doesn't matter much, so long as your upper-level command code can decode the error and report it. > > > > > > +} > > > + > > > +static int gpt_check_mdata_validity(struct udevice *dev) > > > +{ > > > + int ret; > > > + struct blk_desc *desc; > > > + struct fwu_mdata pri_mdata; > > > + struct fwu_mdata secondary_mdata; > > > + u16 primary_mpart = 0, secondary_mpart = 0; > > > + u16 valid_partitions, invalid_partitions; > > > + struct fwu_mdata_gpt_blk_priv *priv = dev_get_priv(dev); > > > + > > > + desc = dev_get_uclass_plat(priv->blk_dev); > > > + if (!desc) { > > > + log_err("Block device not found\n"); > > > + return -ENODEV; > > > + } > > > + > > > + /* > > > + * Two FWU metadata partitions are expected. > > > + * If we don't have two, user needs to create > > > + * them first > > > + */ > > > + valid_partitions = 0; > > > + ret = gpt_get_mdata_partitions(desc, &primary_mpart, > > > + &secondary_mpart); > > > + > > > + if (ret < 0) { > > > + log_err("Error getting the FWU metadata partitions\n"); > > > + return -ENODEV; > > > + } > > > + > > > + ret = gpt_read_mdata(desc, &pri_mdata, primary_mpart); > > > + if (ret < 0) { > > > + log_err("Failed to read the FWU metadata from the device\n"); > > > + goto secondary_read; > > > + } > > > + > > > + ret = fwu_verify_mdata(&pri_mdata, 1); > > > + if (!ret) > > > + valid_partitions |= PRIMARY_PART; > > > + > > > +secondary_read: > > > + /* Now check the secondary partition */ > > > + ret = gpt_read_mdata(desc, &secondary_mdata, secondary_mpart); > > > + if (ret < 0) { > > > + log_err("Failed to read the FWU metadata from the device\n"); > > > + goto mdata_restore; > > > + } > > > + > > > + ret = fwu_verify_mdata(&secondary_mdata, 0); > > > + if (!ret) > > > + valid_partitions |= SECONDARY_PART; > > > + > > > +mdata_restore: > > > + if (valid_partitions == (PRIMARY_PART | SECONDARY_PART)) { > > > + ret = -1; > > > + /* > > > + * Before returning, check that both the > > > + * FWU metadata copies are the same. If not, > > > + * the FWU metadata copies need to be > > > + * re-populated. > > > + */ > > > + if (!memcmp(&pri_mdata, &secondary_mdata, > > > + sizeof(struct fwu_mdata))) { > > > + ret = 0; > > > + } else { > > > + log_err("Both FWU metadata copies are valid but do not match. Please check!\n"); > > > > Honestly the error handling needs a rethink IMO. You should try to > > return error codes that indicate what went wrong (you mostly do in > > this file) and then have the top-level code decode those errors and > > produce an error message. > > The code in efi_capsule.c which is calling the APIs is checking the > error codes and printing the error messages. log_err() prints a message, though. Change this to log_debug() and it won't appear unless specifically enabled. [..] Regards, Simon