From: Pierre AUBERT <p.aubert@staubli.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] env export fix: compute the CRC on the real lenght of the exported variables.
Date: Mon, 03 Mar 2014 18:14:16 +0100 [thread overview]
Message-ID: <5314B868.2000407@staubli.com> (raw)
In-Reply-To: <20140226200247.GE16805@bill-the-cat>
Dear Tom Rini
Le 26/02/2014 21:02, Tom Rini a ?crit :
> [ Catching up on some old emails ]
>
> On Fri, Nov 15, 2013 at 08:20:09AM +0100, Pierre AUBERT wrote:
>> Dear Wolfgang Denk,
>>
>> Le 14/11/2013 18:24, Wolfgang Denk a ?crit :
>>> Dear Pierre Aubert,
>>>
>>> In message <1384434720-11214-3-git-send-email-p.aubert@staubli.com> you wrote:
>>>> Signed-off-by: Pierre Aubert <p.aubert@staubli.com>
>>>> ---
>>>> common/cmd_nvedit.c | 5 +++--
>>>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
>>>> index 5bcc324..c32a932 100644
>>>> --- a/common/cmd_nvedit.c
>>>> +++ b/common/cmd_nvedit.c
>>>> @@ -922,14 +922,15 @@ NXTARG: ;
>>>> len = hexport_r(&env_htab, '\0',
>>>> H_MATCH_KEY | H_MATCH_IDENT,
>>>> - &res, ENV_SIZE, argc, argv);
>>>> + &res, size, argc, argv);
>>>> +
>>>> if (len < 0) {
>>>> error("Cannot export environment: errno = %d\n", errno);
>>>> return 1;
>>>> }
>>>> if (chk) {
>>>> - envp->crc = crc32(0, envp->data, ENV_SIZE);
>>>> + envp->crc = crc32(0, envp->data, len);
>>> This is not correct. When exporting with CRC, then the CRC
>>> computation should be the same as is done with the persistently
>>> stored environment, i. e. it should be taken over ENV_SIZE bytes.
>> In this case, there's an inconstisency between the export and the
>> import. It isn't possible to export some variables and the reimport
>> them:
>> U-Boot > env export -c <addr>
>> U-Boot > env import -c <same addr> fails with a CRC error.
>> The import computes the CRC on the real lenght of the environment
>> variables. IMO, as the import and the export are done to work
>> together, it seems to me that the export should compute its CRC on
>> the real lenght.
> But env import -c <same addr> $filesize does work as the export sets
> filesize.
>
You're right, but my purpose wasn't to export and reimport immediatly
the same environment.
I thought it was more logical to have the same behaviour between
"sister" functions.
Best regards
next prev parent reply other threads:[~2014-03-03 17:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 13:11 [U-Boot] [PATCH 0/2] env export fixes Pierre Aubert
2013-11-14 13:11 ` [U-Boot] [PATCH 1/2] hashtable: fix the export lenght computation Pierre Aubert
2013-11-14 17:25 ` Wolfgang Denk
2013-11-15 7:09 ` Pierre AUBERT
2013-11-14 13:12 ` [U-Boot] [PATCH 2/2] env export fix: compute the CRC on the real lenght of the exported variables Pierre Aubert
2013-11-14 17:24 ` Wolfgang Denk
2013-11-15 7:20 ` Pierre AUBERT
2014-02-26 20:02 ` Tom Rini
2014-03-03 17:14 ` Pierre AUBERT [this message]
2014-03-03 17:33 ` 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=5314B868.2000407@staubli.com \
--to=p.aubert@staubli.com \
--cc=u-boot@lists.denx.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.