Flashing firmware

From Embedded Xinu
Revision as of 16:19, 21 June 2011 by Kpersohn (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Normally, we dynamically load Xinu from an elf image over the network. In some cases, you may want your kernel to persist when you power-cycle the platform. For this, we write the kernel to flash memory instead of just loading the kernel into RAM at boot time. You may also want to replace the default firmware with another version of embedded Linux or perhaps restore the factory firmware should your router become corrupted somehow. Below we detail a variety of methods which should accomplish any of the aforementioned tasks.

Contents

Kernel Image Formats

You will commonly see firmware images intended for flashing in two formats: BIN and TRX. For the precise differences, see this OpenWrt article and our TRX header page. Essentially, a TRX header provides the loader with some basic layout information and the BIN format extends this by adding some platform specific tags. Some of the flashing mechanisms check for the BIN information so you don't accidentally flash a kernel that won't run on a platform it wasn't designed for. In these cases, you want to find a BIN image specific to your platform. Otherwise, some methods trust you to pick the correct TRX image and don't require the extra header. When using these methods, do ensure your kernel is compatible before proceeding.

Web GUI

Linksys Factory Firmware

dd-wrt

OpenWrt

TFTP

CFE Tricks

Bootloader with TFTP

CFE

U-Boot

Linux MTD

Xinu

TODO: Figure out if this works now that we are confident we can revive routers. Intel style flash only???

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox