Error "Cannot read environment, using default" - after upgrade from Yocto gatesgarth to langdale - 0.3.2 and 0.3.3 #25
Description
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:
Loading Environment from SPIFlash... SF: Detected mt25qu02g with page size 512 Bytes, erase size 128 KiB, total 512 MiB
fw_printenv and fw_setenv were working in gatesgarth with the config:
/dev/mtd0 0x2e00000 0x40000 0x40000 0 1
U-Boot config:
CONFIG_ENV_OFFSET=0x2E00000
CONFIG_ENV_OFFSET_REDUND=0x1E80000
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_ENV_SIZE=0x40000
CONFIG_ENV_SECT_SIZE=0x40000
But with langdale, and no changes to U-Boot's config, I now see:
# fw_printenv -c fw_env.config bootcmd
Cannot read environment, using default
Cannot read default environment from file
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:
# strace fw_printenv -c fw_env.config bootcmd
...
openat(AT_FDCWD, "/dev/mtd0", O_RDONLY) = 4
lseek(4, 48234496, SEEK_SET) = 48234496
read(4, "\245a\30\0\0altbootcmd=run sqc_boot_alt"..., 262144) = 262144
close(4) = 0
munmap(0xffffba48f000, 266240) = 0
write(2, "Cannot read environment, using d"..., 39Cannot read environment, using default
) = 39
...
The first bytes of the relevant section of Flash look like this:
# hexdump -C -s 0x2E00000 -n 64 /dev/mtd0
02e00000 a5 61 18 00 00 61 6c 74 62 6f 6f 74 63 6d 64 3d |.a...altbootcmd=|
02e00010 72 75 6e 20 73 71 63 5f 62 6f 6f 74 5f 61 6c 74 |run sqc_boot_alt|
02e00020 00 61 72 63 68 3d 61 72 6d 00 62 61 75 64 72 61 |.arch=arm.baudra|
02e00030 74 65 3d 31 31 35 32 30 30 00 62 6f 61 72 64 3d |te=115200.board=|
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.