From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: 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,
Jassi Brar <jaswinder.singh@linaro.org>
Subject: Re: [PATCHv3 2/5] fwu: move meta-data management in core
Date: Mon, 9 Jan 2023 14:54:27 +0200 [thread overview]
Message-ID: <Y7wOg+wmR2jMR9bM@hades> (raw)
In-Reply-To: <20230102182640.2411224-1-jaswinder.singh@linaro.org>
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
> @@ -16,6 +16,40 @@
> #include <linux/types.h>
> #include <u-boot/crc.h>
[...]
> + * fwu_sync_mdata() - Update given meta-data partition(s) with the copy provided
> + * @mdata: FWU metadata structure
> + * @part: Bitmask of FWU metadata partitions to be written to
> + *
> + * Return: 0 if OK, -ve on error
> + */
> +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" );
....
> +
> + /* update the cached copy of meta-data */
> + memcpy(&g_mdata, mdata, sizeof(struct fwu_mdata));
> +
> + return 0;
> +}
> +
> +static inline int mdata_crc_check(struct fwu_mdata *mdata)
> +{
> + void *buf = &mdata->version;
> + u32 calc_crc32 = crc32(0, buf, sizeof(*mdata) - sizeof(u32));
> +
> + return calc_crc32 == mdata->crc32 ? 0 : -EINVAL;
> +}
> +
> +/**
> + * fwu_get_verified_mdata() - Read, verify and return the FWU metadata
> + *
> + * Read both the metadata copies from the storage media, verify their checksum,
> + * and ascertain that both copies match. If one of the copies has gone bad,
> + * restore it from the good copy.
> + *
> + * Return: 0 if OK, -ve on error
> + */
> +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?
> +
> + /* 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.
> + /* 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
> + }
> +
> + if (!sec_ok) {
> + memcpy(s_mdata, p_mdata, sizeof(struct fwu_mdata));
> + err = fwu_sync_mdata(s_mdata, SECONDARY_PART);
> + if (err)
> + goto ret_mdata;
> + }
> +
> +ret_mdata:
> + if (err)
> + log_debug("mdata : crc32 failed\n");
> + else if (mdata)
> + memcpy(mdata, p_mdata, sizeof(struct fwu_mdata));
> +
> + return err;
> +}
> +
> /**
> * fwu_verify_mdata() - Verify the FWU metadata
> * @mdata: FWU metadata structure
> --
> 2.34.1
>
Regards
/Ilias
next prev parent reply other threads:[~2023-01-09 12:54 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 [this message]
2023-02-05 2:44 ` Jassi Brar
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=Y7wOg+wmR2jMR9bM@hades \
--to=ilias.apalodimas@linaro.org \
--cc=etienne.carriere@linaro.org \
--cc=jassisinghbrar@gmail.com \
--cc=jaswinder.singh@linaro.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox