hi Simon,
On Thu, 18 Aug 2022 at 23:19, Simon Glass <s...@chromium.org> wrote:
>
> 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;
> }
Fair enough. Based on your comment in the other patch, I will look at
the code to see where I can use the stack instead of allocating memory
for the metadata.
>
> [..]
>
> > >
> > > > + 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.
Okay. I will change log_err to log_debug in the driver code.
-sughosh
>
> >
> > >
> > > > +}
> > > > +
> > > > +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
