Open DavidAntliff opened 1 year ago
Ah, it turns out that I had CONFIG_SYS_REDUNDAND_ENVIRONMENT enabled in the langdale project (an upstream default changed, maybe? I did not have this set in gatesgarth), which puts U-Boot into a mode where it maintains two instances of the environment. The structures in libubootenv
source, struct uboot_env_noredund
and struct uboot_env_redund
, differ in the bytes that are included in the CRC. Because my fw_env.config
only had one entry, this put fw_printenv
into "noredund" mode, and it used the wrong data structure to calculate the CRC, which resulted in a mismatch (error).
There are two possible fixes for my situation:
fw_env.config
to supply the two environment sections:
/dev/mtd0 0x2e00000 0x40000 0x40000 0 1
/dev/mtd0 0x1e00000 0x40000 0x40000 0 1
May I suggest a minor improvement where, if the CRC fails in libuboot_load()
and copies == 1
, it might be helpful to others to include in the error message something along the lines of "Environment CRC failed. Your config file only has one entry - check that U-Boot is not configured to use a redundant environment."
Happy for this issue to be closed if you prefer to leave it as-is. Will leave that up to you. If you approve output similar to above (or suggest something else), let me know here and I can submit a patch via the mailing list to help out.
I originally posted this as a comment to issue #20, however it's probably easier to manage if I move it into a new issue here.
I have a similar issue to #20 after updating from gatesgarth to langdale - with both libubootenv 0.3.2 and 0.3.3.
Note: this was working for 0.3.2 in gatesgarth but has broken for me in langdale with both 0.3.2 and 0.3.3.
The U-Boot config is stored in SPI Flash, and U-Boot reports this when booting:
fw_printenv
andfw_setenv
were working in gatesgarth with the config:U-Boot config:
But with langdale, and no changes to U-Boot's config, I now see:
I understand that the second line is due to a missing
u-boot-initial-env
file. It's the first line I'm concerned about.Also, with
strace
, I can see that the environment is actually read from the Flash (I have a variable 'altbootcmd', which appears below), but it is then discarded for some reason and the error emitted instead:The first bytes of the relevant section of Flash look like this:
U-Boot does not report a corrupted environment, and in the course of this testing I have done
env default -f -a ; saveenv
several times to make sure it is valid.I'll dig into the source code next, and try to figure out why the 262144 (0x40000) bytes are not processed as a valid environment.