Playing around with Siemens CL-040-I, a Broadcom BCM6338 based ADSL Modem with a couple of days now.
I know the ADSL part is closed source and will not work but I'm interested mainly in a network capable GPIO device.
After patching boardid (to RTA1320_16M), building trunk r35205 and flashing, the systems boots and is accessible by network (after configuring IP) as well on serial console.
The preinit scripts however tries to initialize the rootfs_data partition with some errors(?) and after a reset the cfe won't find a flash image (see http://pastebin.com/ApP1ebxf )
I was able to reflash and entered failsafe mode. The mdt3 contains the "deadC0de" marker. I can successfully erase the nvram partion (mtd4) or write anything to it, but if I write to mtd3 (the rootfs_data -- just to just remove the marker) and reboot, the cfe just answers "Flash image not found."
Is there a problem with the flash layout or the checksum?
This seems to be the flash layout from other similar devices (also see http://wiki.openwrt.org/doc/techref/flash.layout)
<--- CFE --->|<--- linux --->|<--- nvram --->
|<-- 256b header -->|<-- kernel -->|<-- rootfs -->|
|<-- rootfs_data -->|
I've tried to issue an "mtd fixtrx linux" manually:
Trying to fix trx header in linux at 0x0...
Verifying we actually have an imagetag.
Checking current fixed status.
Setting root length to 0.
Erasing imagetag block
New image crc32: 0xe26731ac, rewriting block
New header crc32: 0x925bf34b, rewriting block
But this seems to currupt the kernel with lines of 0xFF, I verified which hexdump/md5sum.
The mtd3 partion looks real strange after normal init, the 0x1985 magic seems mirrored every 0x10000 bytes... (see pastebin)
I ended up by renaming /sbin/firstboot for now...
This seems to be another warrior on this paticular platform.