From: Marek Vasut <marek.vasut@mailbox.org>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Jerome Forissier <jerome.forissier@linaro.org>,
Simon Glass <sjg@chromium.org>, Tom Rini <trini@konsulko.com>,
u-boot@lists.denx.de
Subject: Re: [PATCH v2 2/3] env: Add single to redundant environment upgrade path
Date: Tue, 23 Dec 2025 19:53:29 +0100 [thread overview]
Message-ID: <6230abdb-0e9a-4a27-90e3-34a8a8fee8fe@mailbox.org> (raw)
In-Reply-To: <ac80d9cd-4890-4382-9ce6-2f237933d32c@gmx.de>
On 12/23/25 6:43 PM, Heinrich Schuchardt wrote:
> On 12/23/25 15:31, Marek Vasut wrote:
>> Add support for converting single-copy environment to redundant
>> environment.
>> In case CRC checks on both redundant environment copies fail, try one
>> more
>> CRC check on the primary environment copy and treat it as single
>> environment.
>
> Why would a CRC check suddenly succeed if it has failed before?
The previous CRC check was for redundant env configuration, the follow
up test is for a single-copy environment. This is used for single-copy
env to redundant env upgrade path.
> This needs some more explanation.
Please read the full commit message, I hope the rest of it clarifies
what is going on here.
>> If that check does pass, rewrite the single-copy environment into
>> redundant
>> environment format, indicate the environment is valid, and import that as
>> usual primary copy of redundant environment. Follow up 'env save' will
>> then
>> store two environment copies and the system will continue to operate as
>> regular redundant environment system.
>>
>> Add test which validates this upgrade path. The test starts with spi.bin
>> which is pre-populated as single-copy environment and then upgrades that
>> environment to dual-copy environment.
[...]
>> +++ b/env/common.c
>> @@ -473,14 +473,24 @@ int env_import(const char *buf, int check, int
>> flags)
>> #ifdef CONFIG_ENV_REDUNDANT
>> static unsigned char env_flags;
>> +#define ENV_SINGLE_HEADER_SIZE (sizeof(uint32_t))
>> +#define ENV_SINGLE_SIZE (CONFIG_ENV_SIZE -
>> ENV_SINGLE_HEADER_SIZE)
>> +
>> +typedef struct {
>> + uint32_t crc; /* CRC32 over data bytes */
>> + unsigned char data[ENV_SINGLE_SIZE]; /* Environment data */
>> +} env_single_t;
>> +
>> int env_check_redund(const char *buf1, int buf1_read_fail,
>> const char *buf2, int buf2_read_fail)
>> {
>> - int crc1_ok = 0, crc2_ok = 0;
>> + int crc1_ok = 0, crc2_ok = 0, i;
>> env_t *tmp_env1, *tmp_env2;
>> + env_single_t *tmp_envs;
>> tmp_env1 = (env_t *)buf1;
>> tmp_env2 = (env_t *)buf2;
>> + tmp_envs = (env_single_t *)buf1;
>> if (buf1_read_fail && buf2_read_fail) {
>> puts("*** Error - No Valid Environment Area found\n");
>> @@ -498,6 +508,25 @@ int env_check_redund(const char *buf1, int
>> buf1_read_fail,
>> tmp_env2->crc;
>> if (!crc1_ok && !crc2_ok) {
>
> Do we really have a third location to copy from when both store 1 and
> store 2 are defective? I would have expected that if a vendor provides a
> single copy then exactly one of crc1_ok or crc2_ok is true and the other
> is false.
>
> Please, provide a documentation update explaining how this all works.
This implements upgrade path from single-copy env to redundant env, see
also what Tom wrote. So no, there is no third copy, there is only
primary copy which is single-copy env, and that primary copy is upgraded
to redundant (dual-copy) env.
next prev parent reply other threads:[~2025-12-23 18:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-23 14:31 [PATCH v2 1/3] test: env: Add test for environment storage in SPI NOR Marek Vasut
2025-12-23 14:31 ` [PATCH v2 2/3] env: Add single to redundant environment upgrade path Marek Vasut
2025-12-23 17:43 ` Heinrich Schuchardt
2025-12-23 18:04 ` Tom Rini
2025-12-23 18:53 ` Marek Vasut [this message]
2025-12-23 14:31 ` [PATCH v2 3/3] configs: sandbox: Enable environment in SPI NOR support Marek Vasut
2025-12-23 17:58 ` Heinrich Schuchardt
2025-12-23 18:07 ` Tom Rini
2025-12-23 17:32 ` [PATCH v2 1/3] test: env: Add test for environment storage in SPI NOR Heinrich Schuchardt
2025-12-23 18:55 ` Marek Vasut
2025-12-23 23:32 ` Tom Rini
2025-12-31 16:07 ` Marek Vasut
2025-12-31 16:11 ` Tom Rini
2025-12-31 16:50 ` Marek Vasut
2025-12-31 17:18 ` Tom Rini
2025-12-31 17:46 ` Marek Vasut
2025-12-24 3:18 ` Heinrich Schuchardt
2026-01-07 21:06 ` Tom Rini
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=6230abdb-0e9a-4a27-90e3-34a8a8fee8fe@mailbox.org \
--to=marek.vasut@mailbox.org \
--cc=jerome.forissier@linaro.org \
--cc=sjg@chromium.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.