[SOLVED] U-boot CRC warning at boot

[vinczo]

Hi,

I sometimes see this weird message
.*** Warning - bad CRC, using default environment
instead of
.raspi_read: from:30000 len:1000
appearing at boot (9th line).

What could cause this to happen? Is it an error ?
I've seen it on working devices and that doesn't seem to cause a problem.
For example, https://openwrt.org/toh/asus/rt-g32 section "OEM bootlog"

---

This is a full extract of the output while the device boots :

U-Boot 1.1.3 (Apr 20 2015 - 13:25:55)

Board: RT5350F-OLinuXino DRAM:  32 MB
relocate_code Pointer at: 81fb4000
spi_wait_nsec: 42 
spi device id: ef 40 17 0 0 (40170000)
find flash: W25Q64BV
raspi_read: from:30000 len:1000 
.*** Warning - bad CRC, using default environment

============================================================= 
RT5350F-OLinuXino UBoot Version: 4.0.0.0
--------------------------------------------------------------
ASIC 5350_MP (Port5<->None)
DRAM_CONF_FROM: Boot-Strapping 
DRAM_TYPE: SDRAM 
DRAM_SIZE: 256 Mbits
DRAM_WIDTH: 16 bits
DRAM_TOTAL_WIDTH: 16 bits
TOTAL_MEMORY_SIZE: 32 MBytes
Flash component: SPI Flash
Date:Apr 20 2015  Time:13:25:55
============================================ 
icache: sets:256, ways:4, linesz:32 ,total:32768
dcache: sets:128, ways:4, linesz:32 ,total:16384 

 ##### The CPU freq = 360 MHZ #### 
 estimate memory size =32 Mbytes

Please choose the operation: 
   1: Load system code to SDRAM via TFTP. 
   2: Load system code then write to Flash via TFTP. 
   3: Boot system code via Flash (default).
   4: Entr boot command line interface.
   7: Load Boot Loader code then write to Flash via Serial. 
   9: Load Boot Loader code then write to Flash via TFTP.

Many thanks !

[jeff]

U-Boot environment is preserved on flash so it can be changed, if needed. It has a checksum to determine if it is likely valid or not. If it doesn’t match, it is ignored and rewritten with default values. Could be bad flash or something writing to that area of flash. Does it happen every boot?

[vinczo]

Hi jeff,

Yes it happens on every boot.
I've seen this on devices with "apparently" no side effects.
But I have also seen this on devices with this issue : Flashing OpenWrt-18.06 to device loses wifi functionality (no SSID broadcast) even after reboot
Could it be related ?

Thanks

[mk24]

That is normal for hacked up u-boots that work entirely from the hard-coded environment, or if the manufacturer never saved an environment in the flash block. In some cases that flash block is used for other purposes, and trying a saveenv will overwrite that data and break the system.

If it only happens sometimes though that could mean there is a flash error reading the environment (from block 3 in this case).

[vinczo]

Thanks mk24,

That looks interesting but I don't seem to understand everything. Could you please give some more explanation ? What do you call "work entirely from the hard-coded environment", "never saving environment", what king of environment can be saved ? what could the flash block be used for?

Also, could it cause wifi dysfunction as stated in Flashing OpenWrt-18.06 to device loses wifi functionality (no SSID broadcast) even after reboot ?

Thanks.

[jeff]

In a typical embedded boot process, at power-on, the device runs "built-in" code to determine which type of "acceptable" flash are connected (if there is a choice at all) and "picks the right one" and starts executing code from a pre-defined location. In some cases this is simple code that then starts a "fancy" boot loader like U-Boot, or it might be U-Boot itself, or the like. U-Boot's "job" is to be able to load the kernel to memory, set up any information it might need to run, then transfer control to the kernel. For simple devices, it might not have to do anything more than load the kernel and jump to the kernel's entry point. On many devices, additional information is passed, such as the kernel command line, and/or information about how the board is "wired up" and how the flash is partitioned. Since the OEM typically builds a device-specific version of U-Boot, the default parameters are often compiled into the U-Boot binary.

There are cases where the defaults aren't "right" for the task at hand. Many units are run tested and calibrated using different firmware than that on flash. A special U-Boot command or variable can be used to, for example, load a kernel and firmware over TFTP directly to RAM and ignore the on-board flash. Another time that changing the U-Boot environment may happen is with dual-firmware units. For example, a U-Boot variable called boot_part is used in some units to select between firmware A and firmware B to be able to save that decision over a power-off period or reboot.

I would be surprised if the U-Boot environment is at the core of the problems described in the other thread. Typically wireless "cal" data and MAC addresses are stored in other portions of the flash and are read at run time by OpenWrt to configure the devices.

[mk24]

U-boot really doesn't have anything to do with wifi, so not likely to cause that problem. Important wifi parameters are stored in a "factory" or "ART" partition depending on the system chip type. U-boot is usually not even aware of the location of that partition.

If you type printenv at the U-boot prompt it will show the "environment" settings which affect how U-boot operates. The most important one is "bootcmd" which tells it where to find the operating system kernel in flash. Also there are settings for TFTP transfer. There is a "default" copy of the environment settings compiled into U-boot itself. Or, in some cases they are loaded from a separate area of flash. If that load fails, the defaults will be copied to RAM and used instead.