CFE on bcm47xx devices allows running/installing firmware using a lot of different methods. Usually only few of them are available, depending on the choice of manufacturer who compiled and installed CFE. Most of the methods require access to the CFE console which means you need to attach a serial console. To get a prompt just keep CTRL+C pressed (or ESC for some models) while powering the device up.
Below is the (hopefully) completed list of methods. The best idea is to find a one looking the best/easiest and check if it works on your device.
Some CFEs start TFTP server for few seconds right after hardware initialization. This is probably the only method of installing firmware with CFE that doesn't require serial console. You simply have to give CFE 1-3 seconds to initialize the switch and then set your IP and start sending the firmware. If you have a serial console, you can identify TFTP server running with the following messages:
_tftpd_open(): retries=0/3 _tftpd_open(): retries=1/3 _tftpd_open(): retries=2/3
Unfortunately even if this method is available for you, it may not work. For example on Linksys E900 it fails after uploading firmware with the:
CMD: [boot -raw -z -addr=0x80001000 -max=0x1851e50 -fs=memory :0x807ae1b0] Loader:raw Filesys:memory Dev:eth0 File::0x807ae1b0 Options:(null) Loading: PANIC: out of memory!
Please not that CFE may require a valid firmware image (with a valid header), otherwise it may fail with the:
CMD: [flash -ctheader -mem -size=0x4c1000 0x807ae1b0 flash1.trx] Reading from 0x807ae1b0: CODE Pattern is incorrect! (E900) The file transferred is not a valid firmware image.
CFE almost always contains
flash command that may behave like both: TFTP client and server. The generic usage is following:
flash [options] source-file [destination-device]
This is very important to pass
[destination-device] argument or CFE will write to the
flash0 device overwriting the CFE! To see a list of available devices try
show devices command.
[options] there is one important one called
-noheader and if you happen to be Linksys owner, there is also
-noheader Override header verification, flash binary without checking -ctheader Check header of CyberTANBy default CFE validates received firmwares checking if they contain a device-specific header. That won't allow installing firmware created for a different device. If you want to install
trxfirmware directly (image without an extra device-specific header), you may use
In this scenario we will tell CFE to connect to the remote TFTP server, download firmware and install it on the flash. This means that
source-file should be set to
host:path/firmware.bin format. Example usage:
flash -noheader 192.168.1.2:bin/brcm47xx/openwrt-brcm47xx-squashfs.trx flash0.trx flash -ctheader 192.168.1.2:bin/brcm47xx/openwrt-e900_v1-squashfs.bin flash0.trx
Unfortunately on some devices this method makes CFE hang right after downloading the firmware and it gets never written to the flash.
It's also possible to make
flash start a TFTP server that will accept firmware for few seconds. The trick is to put
: as a
source-file. Example usage:
Example file to send: flash -noheader : flash0.trx openwrt-brcm47xx-squashfs.trx flash -ctheader : flash0.trx openwrt-e900_v1-squashfs.bin
Some manufacturers provide an
upgrade command that is usually just an alias to the parametrized
flash executed in a loop. Of course it's much less flexible that the
flash command, but also has some advantages like:
- Setting parameters automatically
- Running in a loop, so you have much more time to start sending the firmware (not only few seconds)
The most common (and probably safe) usage is to call it with
CFE> upgrade code.bin CMD: [upgrade code.bin] CMD: [flash -ctheader : flash1.trx] Reading :: _tftpd_open(): retries=0/3
Another possible parameters:
boot.bin Usually works the same way as code.bin linux.bin Doesn't always work ("flash0.0: Device not found") cfe.bin WARNING! Writes to the flash1.boot, you don't want to use it!
Unfortunately only few manufacturers decide to enable it, but it's probably the most user friendly way of installing firmware.
Every bcm47xx CFE has a small NVRAM backup that is used to restore the main NVRAM when it gets deleted or corrupted. If you want to modify that backup NVRAM, see changing defaults page.
CFE for bcm63xx boards have a different structure. At the begining of CFE, outside the NVRAM area there exist two interesting parameters:
|0x010-0x013||BpGetSdramSize||8MB 1 CHIP
16MB 1 CHIP
32MB 1 CHIP
64MB 2 CHIP
32MB 2 CHIP
16MB 2 CHIP
64MB 1 CHIP
The NVRAM is located between offsets 0x580 to 0x97F. The size is 1KB (1024 bytes).
|0x580-0x583||NVRAM DATA ID||4 bytes|
|0x584-0x683||BOOT LINE||e=192.168.1.1 (Board IP)
h=192.168.1.100 (Host IP)
g= (Gateway IP)
r=f/h (run from flash/host)
f=vmlinux (if r=h)
d=3 (delay, 0=forever prompt)
p=0 (boot image, 0=latest, 1=previous)
|0x684-0x693||Board ID||16 bytes|
|0x69C-0x69F||Number MAC Addresses||4 bytes|
|0x6A0-0x6A5||Base MAC Address||6 bytes|
|0x6AC-0x97F||— EMPTY —||724 bytes|
At the end of the flash, there exists a PSI partition (Profile Storage Information), about 16KB size.
doc/techref/bootloader/cfe.txt · Last modified: 2013/10/07 07:47 by zajec