The Huawei EchoLife HG553 practical manual

Flashing new CFE bootloader from CFE itself

This can be done via the w command:

CFE> w cfe.bin

inside the CFE shell that can be accessed via TTL UART pins.

However, the bin file needs proper CRC signing before it is accepted. This is not necessarily already done with the .bin files that can be found online.

Also please note that flashing a new CFE might switch off the serial terminal in the early boot stages, so this method will avoid you the JTAG soldering and flashing... but probably only once. Once the system boots, you should be able to use the terminal again.

For reference, this happens with a non correctly signed image:

	CFE> w [address]:[cfe image path]
	Loading [address]:[cfe image path] ...
	Finished loading [n] bytes
	Illegal whole flash image
	Finished flashing image.
	*** command status = -1
	

Signing, method 1

This manual method makes use of a hex editor and quite some patience. An accurate description can be found in the [2] link. The idea is to edit the .bin image so that it includes a proper CRC32 signature of the NVRAM portion of image, which is calculated taking the algorithm from the CFE sources. This algorithm is the same as the linux kernel one. This is the equivalent C function you can compile and run:

 uint32_t crc32_le(uint32_t crc, unsigned char const *p, size_t len)
{ 
  int i;
        while (len--) {
                crc ^= *p++;
                for (i = 0; i < 8; i++)
                        crc = (crc >> 1) ^ ((crc & 1) ? 0xedb88320 : 0);
        }
        return crc;  
}
 

 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 48 57 35 35 33 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06
 00 24 D2 1A 5F 81 00 00 33 30 31 33 33 38 4B 39
 31 30 36 31 37 36 37 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 88 9E 0D C5
 

• 48 57 35 35 33 is "HW553";
• 00 24 D2 1A 5F 81 is the base mac address;
• 33 30 31 33 33 38 4B 39 31 30 36 31 37 36 37 is the board serial number;
• and finally 88 9E 0D C5 is the CRC32 (underlined).

There is no actual need to edit this data, as the system will work anyways. And, by the way, if the CFE you are flashing provides serial access, you can edit these options with the CLI and have the NVRAM automatically hashed and flashed correctly.

Just make sure that the CRC32 is correct.

Note: as link points out there are CFE files in the Internet which have some lines offset due to presence of a header.

Signing, method 2 (currently not tested)

As in [1] link...

Some general Broadcom CFE heads-up

1. CFE is not exactly user-friendly and many error messages could be inexplicative at best. But keep in mind that source is available. For example, if you get an unhelpful "error 21" you can look it up in the repo and, given some C knowledge, understand what it actually means and when it is raised.