public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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