Missing NVRAM on generic bcm47xx router (Top Global MB6800)

I’ve been playing with a no-name router i picked up for free from a friend. This router seems to run an OS very similar to OpenWRT (linux 2.4 kernel, busybox, dropbear), though with a few annoying proprietary modifications. I am attempting to make OpenWRT work on this router. It has the following specs:

• BCM947xx SoC
• 16 MB memory
• 8 MB flash
• ADM9669 switch
• Built-in RS-232 serial port
• PCMCIA slot
• USB Port

Manufacturer’s Spec Page

…Plus the usual assortment of LEDs and buttons (reset, ‘force reload’). I’ve asked the manufacturer for their modified GPL source, but have not yet received a response.

The problem I’m having with OpenWRT, is that I’m unable to get it to detect the switch, and therefore to initialise the PHY so that it can connect to the network, either on the WAN or LAN ports. This seems to be because the kernel cannot find the NVRAM to read the CFE parameters for these devices.

The first problem was that rather than having the 4 mtd ‘partitions’ we’re familiar with, it has *5* including a ‘backup’ copy of the NVRAM. this appears in the 128k before the NVRAM partition, and if an unmodified OpenWRT image is booted, is then misidentified as usable JFFS2 space. Upon rebooting, the CFE will then declare that the (perfectly fine!) NVRAM is ‘invalid’ and will overwrite it with the, now empty, contents of the ‘backup’! I resolved this issue with a quick & dirty hack to stop JFFS2 trampling on the backup:

Index: bcm47xx-flash.c
===================================================================
--- bcm47xx-flash.c (revision 20769)
+++ bcm47xx-flash.c (working copy)
@@ -353,7 +353,7 @@

/* find and size rootfs */
find_root(mtd,size,&bcm47xx_parts[2]);
- bcm47xx_parts[2].size = size - bcm47xx_parts[2].offset - bcm47xx_parts[3].size;
+ bcm47xx_parts[2].size = size - bcm47xx_parts[2].offset - (2 * bcm47xx_parts[3].size);

return bcm47xx_parts;
}
Thankfully CFE is smart enough to recognise this behaviour as wrong, and on the next reboot will replace the contents of NVRAM with an *absolutely* minimal set of parameters (basically, the sdram and cpu clock, and a couple other minor things). From here, I can rebuild the router’s initial config (including network & switch settings) using the output of ‘nvram show’, which I performed in CFE *before* starting to play around with various firmwares. Annoyingly though, the CFE on this device seems to be missing some of the commands mentioned on the Linux-mips Wiki

So, I guess I have several questions:

1. Why does the kernel not recognise the NVRAM when running ’strings /dev/mtd3′ works fine?
2. Do any other devices have a ‘flash0.backup’? if so, which ones?
3. Can a different CFE from another, similar, device be flashed in place of this one? This device’s CFE version is 1.0.5(build on May 6 2007 09:56:08)

I have attached various useful bits & bobs for comparison below.

Original firmware dmesg output showing the 5 mtd partitions:

Physically mapped flash: cramfs filesystem found at block 1336
Creating 5 MTD partitions on "Physically mapped flash":
0x00000000-0x00040000 : "boot"
0x00040000-0x007c0000 : "linux"
0x0014e144-0x007c0000 : "rootfs"
0x007c0000-0x007e0000 : "backup"
0x007e0000-0x00800000 : "nvram"

OpenWRT kernel 2.6 showing only 4:
Creating 4 MTD partitions on "Physically mapped flash":
0x000000000000-0x000000040000 : "cfe"
0x000000040000-0x0000007e0000 : "linux"
0x000000120000-0x0000007c0000 : "rootfs"
mtd: partition "rootfs" set to be root filesystem
split_squashfs: no squashfs found in "Physically mapped flash"
0x0000007e0000-0x000000800000 : "nvram"

…I’m slightly concerned about the squashfs message. The router boots fine, though.