All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jassi Brar <jaswinder.singh@linaro.org>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jassi Brar <jassisinghbrar@gmail.com>,
	u-boot@lists.denx.de,  etienne.carriere@linaro.org,
	trini@konsulko.com, sjg@chromium.org,  sughosh.ganu@linaro.org,
	xypron.glpk@gmx.de, patrick.delaunay@foss.st.com,
	 patrice.chotard@foss.st.com
Subject: Re: [PATCHv3 2/5] fwu: move meta-data management in core
Date: Sat, 4 Feb 2023 20:44:46 -0600	[thread overview]
Message-ID: <CAJe_Zhez1FDSh_Yum-Sz3ZqdEs3duAtcX54PaMpUEi02uJq2DA@mail.gmail.com> (raw)
In-Reply-To: <Y7wOg+wmR2jMR9bM@hades>

On Mon, 9 Jan 2023 at 06:54, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Jassi,
>
> On Mon, Jan 02, 2023 at 12:26:40PM -0600, Jassi Brar wrote:
> > Instead of each i/f having to implement their own meta-data verification
> > and storage, move the logic in common code. This simplifies the i/f code
> > much simpler and compact.
> >
> > Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> > ---
> >  drivers/fwu-mdata/fwu-mdata-uclass.c |  34 +++++++
> >  include/fwu.h                        |  41 ++++++++
> >  lib/fwu_updates/fwu.c                | 142 ++++++++++++++++++++++++++-
> >  3 files changed, 213 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c b/drivers/fwu-mdata/fwu-mdata-uclass.c
> > index b477e9603f..e03773c584 100644
> > --- a/drivers/fwu-mdata/fwu-mdata-uclass.c
> > +++ b/drivers/fwu-mdata/fwu-mdata-uclass.c
.....
> > + */
> > +static int fwu_sync_mdata(struct fwu_mdata *mdata, int part)
> > +{
> > +     void *buf = &mdata->version;
> > +     int err = 0;
> > +
> > +     /*
> > +      * Calculate the crc32 for the updated FWU metadata
> > +      * and put the updated value in the FWU metadata crc32
> > +      * field
> > +      */
> > +     mdata->crc32 = crc32(0, buf, sizeof(*mdata) - sizeof(u32));
> > +
> > +     if (part & PRIMARY_PART)
> > +             err = fwu_write_mdata(g_dev, mdata, true);
> > +
> > +     if (err) {
> > +             log_err("Unable to write primary mdata\n");
> > +             return err;
> > +     }
> > +
> > +     if (part & SECONDARY_PART)
> > +             err = fwu_write_mdata(g_dev, mdata, false);
> > +
> > +     if (err) {
> > +             log_err("Unable to write secondary mdata\n");
> > +             return err;
> > +     }
>
> Can we write this
> err = fwu_write_mdata(g_dev, mdata, part & PRIMARY_PART ? true: false);
> if (err)
>     log_err("Unable to write %s partition\n", part & PRIMARY_PART ?  "primary": "secondary" );
>     ....
>
of course :)


> > +int fwu_get_verified_mdata(struct fwu_mdata *mdata)
> > +{
> > +     int err;
> > +     bool pri_ok, sec_ok;
> > +     struct fwu_mdata s, *p_mdata, *s_mdata;
> > +
> > +     p_mdata = &g_mdata;
> > +     s_mdata = &s;
>
> Why are we defining it like this? Readability to have pointers for primary
> and secondary metadata?
>
that's the idea.


> > +
> > +     /* if mdata already read and ready */
> > +     err = mdata_crc_check(p_mdata);
> > +     if (!err)
> > +             goto ret_mdata;
>
> Shouldn't we check the secondary metadata ? At least that's what the old
> fwu_check_mdata_validity() was doing.
>
During the first run after boot, both copies are checked. Also when we
update the mdata.
Othwise we have a good primary copy, even if the secondary is
corrupted for some mysterious (corrupted in readonly mode) reason
maybe we should let that be fixed after reboot and not add crc
checking cost to every call?


> > +     /* else read, verify and, if needed, fix mdata */
> > +
> > +     pri_ok = false;
> > +     err = fwu_read_mdata(g_dev, p_mdata, true);
> > +     if (!err) {
> > +             err = mdata_crc_check(p_mdata);
> > +             if (!err)
> > +                     pri_ok = true;
> > +             else
> > +                     log_debug("primary mdata: crc32 failed\n");
> > +     }
> > +
> > +     sec_ok = false;
> > +     err = fwu_read_mdata(g_dev, s_mdata, false);
> > +     if (!err) {
> > +             err = mdata_crc_check(s_mdata);
> > +             if (!err)
> > +                     sec_ok = true;
> > +             else
> > +                     log_debug("secondary mdata: crc32 failed\n");
> > +     }
> > +
> > +     if (pri_ok && sec_ok) {
> > +             /*
> > +              * Before returning, check that both the
> > +              * FWU metadata copies are the same.
> > +              */
> > +             err = memcmp(p_mdata, s_mdata, sizeof(struct fwu_mdata));
> > +             if (!err)
> > +                     goto ret_mdata;
> > +
> > +             /*
> > +              * If not, populate the secondary partition from the
> > +              * primary partition copy.
> > +              */
> > +             log_info("Both FWU metadata copies are valid but do not match.");
> > +             log_info(" Restoring the secondary partition from the primary\n");
> > +             sec_ok = false;
> > +     }
> > +
> > +     if (!pri_ok) {
> > +             memcpy(p_mdata, s_mdata, sizeof(struct fwu_mdata));
> > +             err = fwu_sync_mdata(p_mdata, PRIMARY_PART);
> > +             if (err)
> > +                     goto ret_mdata;
>
> The error print here is a bit misleading.  It's a failed write, not a crc32
> mismatch
>
Fixed.

Thanks.

  reply	other threads:[~2023-02-05  2:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-02 18:25 [PATCHv3 0/5] FWU: Handle meta-data in common code Jassi Brar
2023-01-02 18:26 ` [PATCHv3 1/5] fwu: gpt: use cached meta-data partition numbers Jassi Brar
2023-01-09  7:36   ` Ilias Apalodimas
2023-01-02 18:26 ` [PATCHv3 2/5] fwu: move meta-data management in core Jassi Brar
2023-01-09 12:54   ` Ilias Apalodimas
2023-02-05  2:44     ` Jassi Brar [this message]
2023-01-02 18:26 ` [PATCHv3 3/5] fwu: gpt: implement read_mdata and write_mdata callbacks Jassi Brar
2023-01-02 18:26 ` [PATCHv3 4/5] fwu: meta-data: switch to management by common code Jassi Brar
2023-01-02 18:27 ` [PATCHv3 5/5] fwu: rename fwu_get_verified_mdata to fwu_get_mdata Jassi Brar
2023-01-09  1:06 ` [PATCHv3 0/5] FWU: Add support for mtd backed feature on DeveloperBox Jassi Brar
2023-01-09  1:06   ` [PATCHv3 1/5] FWU: Add FWU metadata access driver for MTD storage regions Jassi Brar
2023-01-13 10:41     ` Sughosh Ganu
2023-01-18 14:24     ` Michal Simek
2023-02-05  4:09       ` Jassi Brar
2023-02-28  0:58         ` Jassi Brar
2023-01-09  1:06   ` [PATCHv3 2/5] FWU: mtd: Add helper functions for accessing FWU metadata Jassi Brar
2023-01-13 10:43     ` Sughosh Ganu
2023-01-09  1:07   ` [PATCHv3 3/5] dt: fwu: developerbox: enable fwu banks and mdata regions Jassi Brar
2023-01-18 13:24     ` Michal Simek
2023-01-09  1:07   ` [PATCHv3 4/5] fwu: DeveloperBox: add support for FWU Jassi Brar
2023-01-18 14:46     ` Michal Simek
2023-01-21 17:48       ` Jassi Brar
2023-01-09  1:07   ` [PATCHv3 5/5] tools: Add mkfwumdata tool for FWU metadata image Jassi Brar
2023-01-18 14:38     ` Michal Simek
2023-01-18 13:28 ` [PATCHv3 0/5] FWU: Handle meta-data in common code Michal Simek
2023-01-18 14:13   ` Jassi Brar
2023-01-18 14:18     ` Tom Rini
2023-01-18 14:27     ` Michal Simek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJe_Zhez1FDSh_Yum-Sz3ZqdEs3duAtcX54PaMpUEi02uJq2DA@mail.gmail.com \
    --to=jaswinder.singh@linaro.org \
    --cc=etienne.carriere@linaro.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=patrice.chotard@foss.st.com \
    --cc=patrick.delaunay@foss.st.com \
    --cc=sjg@chromium.org \
    --cc=sughosh.ganu@linaro.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.