Unbricking the Belkin F5L049

In my last post I found out how to enter the bootloader, and execute some debugging commands through a serial console. However, it appears that the only way to write to the flash with the bootloader is with a proprietary protocol over raw ethernet with an unknown ethertype (0x8813). I have reverse-engineered it and written a flasher utility: sxflash (in their quest to make the bootloader as minimal as possible they decided not to simply go with TFTP over IP like most routers)...

Now that it is possible to flash new firmware I could try to debug the 'boot hang' problem. My first assumption was that the squashfs was incompatible (I built and installed my own as there is none with the toolchain). But when I checked it was 3.4 big-endian just like the kernel. Also, the initialisation sequence mentioned that kernel modules were being loaded. So the first thing I tried is to change the kernel command line in an attempt to launch a console at boot.

... init=/bin/sh

Which didn't help at all:

Kernel panic - not syncing: Attempted to kill init!?

Other tries to launch a serial console at boot-up (via inittab and rc.S) also failed. Then I noticed a small, seemingly innocent message in the boot log:

Warning: unable to open an initial console.

After googling this message it turned out to show the cause of all evil: /dev/console cannot be opened by the kernel. Why not? Well, a look in the firmware build process made it clear that the devices were never made. A ready-made base file system including /dev is initialized from a directory, /preinstall/

Eek! it seems that archives MUST be unpacked as root. If you don't, it can't extract the device nodes. /dev/console was dis-functional, just like /dev/ttyS0.

When I discovered this, fixed it and flashed the new firmware, it was solved! It was great to see the full boot sequence again, now I can finally do the customizations I wanted in the first place... see also the hardware specs of this neat device.

Written on June 4, 2010