Here's a quick hack that will give you a booting OpenWrt Backfire on the Bifferboard, compiled from source. It ain't pretty, but it seems to work. For now. This worked as of evening
14th Jul 2010. Tested with an 8MB device, but I've reason to believe it should work with 4MB ones too.
1) Download the script attached below (mkbiffer.py).
2) Obtain OpenWrt Backfire sources:
$> svn co svn://svn.openwrt.org/openwrt/branches/backfire
First you have to edit files in backfire/target/linux/rdc/
4) Open the Makefile and change
5) Open config-2.6.32 and change the line CONFIG_CMDLINE from:
In other words remove the bit about setting the console=tty0,38400
6) Run 'make menuconfig', select the RDC321x target system.
7) Select target profile, "Devices from Sitecom (WL-153, DC-230)"
8) Run 'make' and wait a while.
9) Run the mkbiffer.py script to combine the built kernel and JFFS images.
This should create 'biff-firmware.img'
10) Don't flash it to the board yet! First you have to change Biffboot config.
At the Biffboot prompt, lower the kernel_max value to 0x0010, instead of the
11) Flash the file to the Bifferboard as you would a normal kernel, either with
the serial cable or via Ethernet. You may have to wait some time for the first
boot, due to JFFS erasing trailing blocks.
By making the above changes, the Bifferboard most closely resembles a ZyXEL
flash configuration, which, as luck would have it is the default fallback for
this board profile when no other magic numbers are detected.
It's possible (although unlikely) that this won't work depending on what
junk may be lying around your flash device, however, if you have one of the
Bifferboards with the flash erase and/or flash test feature, then running that
before flashing should correct any issues. You could instead just write a
large file of 0xFFs to it.
Note that by using this profile you waste blocks at the end of the device.
This can be corrected by adjusting the ZyXEL values in platform.c.