Hello all,

I was wondering if someone could kindly provide or point me to a basic explanation on what is the specific hardware on the board that allows for a router like the Linksys to reflash, how this works, and how does it start tfp if the flash is corrupted.

The question is hardware related, what part of the hardware allows the unit to accept new images and burn the flash again. If a bad image was uploaded and the flash was erased (i.e., there is no more Linux or OS running), how is the router still capable of accepting new images via tftp? Where is this tftp code stored and how does it even run upon boot? Is there a 2nd flash chip and the CPU looks at this before going to a normal boot? Is a 'bootloader' stored on this chip, or could it be in a reserved area if the big flash?

2nd, what circuitry on the board is responsible for controlling writing on the flash? If we do a web upgrade, then something on the board controles and rewrites the flash.

I'd greatly appreviate a response or pointers. I am just trying to understand how this works.

Thank you.

The Linksys CFE/PMON area, the boot code area, has its own stand-alone tftp feature to flash *the rest* of flash.  The same boot code will restore (not flash an image) the nvram area to defaults, too - at least in all recent stuff I've used.

The image flashed by tftp must have the proper Linksys header (usually called a *.bin file) for the hardware.  This is the main reason you see all those different bin files for the different models (like G vs GS) - that only differs by header content for particular hardware.  Most all these are simply that header tacked onto the *.trx file which is a simple flash image.

So if the CFE area is trashed you cannot tftp either and JTAG is called for.  It's certainly not impossible to trash the CFE area but since it's (never?) not a part of any firmware I know of it's a lot less likely.

Being an old hardware guy, I'm familiar with protected boot areas in hardware flash.  To tell you the truth, I don't think that that's the case here but I could be wrong.  I do know you have a lot of hoops to jump over to flash the CFE area with OpenWrt so it's not common.

The firmware itself can flash, too.  The mtd routine in OpenWrt does an excellent job.  Different animal than CFE but the result is the same.  When firmware flashes this is their own routines, not CFE.

HTH.  All corrections appreciated.

EDIT: Found this golden reference from Mike Baker himself: http://downloads.openwrt.org/people/mbm/openwrt.html  Old but still good info.

(Last edited by Bill_MI on 27 Sep 2008, 21:15)

Bill, thanks a lot, much, much appreciated. I do have some other clarifications needed if you do not mind.

If I understand correctly, when the router is powered up, the processor will execute whatever is in the "protected" flash area, and that is what allows it to do tftp at boot time. You are not sure whether this area is really protected or not, sounds like it is not.

Re. "The same boot code will restore (not flash an image) the nvram area to defaults, too - at least in all recent stuff I've used.". This would only reset the router to its factory settings, but not restore any images. Correct? In theory, if the flash were big enough, could you not store a backup of the original flash image in the "protected area" and restore the whole thing?

Also if I get this right, using JTAG allows you to reflash the router. With JTAG, do you send instructions and data to the CPU so that it can burn the flash, or does it somehow allow you to write to the flash directly (how is this "somehow", does JTAG control the flash?).

Again, many thanks, that is awesome.

By any chance is there an schematic of an older Linksys somewhere?

A simple analogy for most people:

CFE = BIOS
firmware = OS

When you screw up your OS have you ruined the BIOS too?  Nope.
With serial console everything becomes clear.  The CFE bootloader
runs first and if you have boot_wait set it pauses an extra few seconds
during boot to give you a bigger window to TFTP in the firmware.

With JTAG you can reprogram the CFE.  I used it once just to update
a very old GS v1.0 with a newer CFE just to prove that I could do it.
JTAG does a lot of other things it really is a developers tool for
manufacturers.  But for hobbbyist purpose it's almost always used
for the purpose of getting direct access to the entire flash area when
you have messed up really badly.

Vast majority of "bad flash" are simple firmware problems and nothing
to do with CFE which is usally fine.  This becomes apparent when most
"bricked" routers you hook up a serial console and watch CFE messages
fly by as normal then it fails loading the firmware.

Thanks Vincent, excellent analogy. Is the CFE really a protected area of the flash or not (i.e, it can be easily overwritten by a bad image reflash? Does JTAG allow you to program the flash directly, position by position, without going through the CPU, or does JTAG simply command the CPU to do it?

I'd love to see a schematic of this if someone knows of one.

Again, thanks.

(Last edited by urso on 28 Sep 2008, 17:21)

JTAG doesn't involve the CPU - it's a hardware serial connection added to the board for such programmable devices like flash chips.

From my OpenWrt link collection: http://wiki.openwrt.org/OpenWrtDocs/Cus … JTAG_Cable