OpenWrt Forum Archive

Topic: BCM6348 - DLink 2460B - B2 CFE or Full Flash

The content of this topic has been archived on 25 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hello,

I need a dump from the flash memory for this modem. I'll re-flash in a flash programmer outside the board. if anyone can send me the dump would be great wink

thanks and best regards,

Thanks wink

maybe it's only the endian my problem, i tried to flash about 5 times, soldered the memory on the board, and removed, flashed again... hmm

well, i'll try again tomorrow with reverse endian

-- any hint in how to reverse the endian? maybe dd?

thanks

-- edit--

found a tool to convert to little endian in the link-> http://wiki.openwrt.org/toh/davolink/dv-2020

(Last edited by gmtandi on 8 May 2013, 04:16)

I'm trying with the original firmware from d-link, i think it does have a full flash, it is: CFE, FS, and Kernel... just the begin of the flash that is making me go crazy, it's different,

the firmware i dumped from the memory before writing is:

0000000 1000 0279 0000 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000


the one from dlink firmware:
0000000 0036 0000 7242 616f 6364 6d6f 4320 726f
0000020 6f70 6172 6974 006f 6576 2e72 3220 302e
(a lot of things here...)
0000400 0010 7902 0000 0000 0000 0000 0000 0000

maybe i must to cut that header and make it little endian?

-- i'm trying to re-flash because there is no data from serial port, i think CFE is not working anymore, it occurred after flashing with wrong firmware(for BCM6338, the device is BCM6348), the  modem had frozen in the upgrade process i think the power supply was damaged, a few capacitor inside, that i replaced --

thanks

(Last edited by gmtandi on 8 May 2013, 11:47)

Yes, you need to cut the header to get CFE from the OEM firmware, probably at offset 0x100. The size of CFE in these boards usually is 64KB. Then it's easy to extract.

About the endianess it depends on how you'll write the CFE on the flash. With hairydairy, it maybe needed some flag in the command for flashing, or byte reordering before flashing. With Urjtag there is no need to do byte reordering if you issue "endian big" in the Urjtag CLI. And with a flash programmer no idea about endianness.

Is your flash 4 or 8MB size?. if 8MB size the bootloader should be flashed in the offset at the middle of the flash.

the flash size is 4MB (29lv320cbtc-90g), it's being a little hard to calculate te right position for the CFE begin,  i'm reading the address on the flash programmer software, and with hexdump / od, the values are different(od/hexdump address are each 0x0, 0x10, 0x20, 0x30, and in the flash programmer software is 0x0, 0x08, 0x10, 0x18, 0x20; comparing the positions 0x10 = 0x08; 0x20 = 0x10)...   i'll keep trying

OEM Firmware:


# od -A x -x GE_DSL-2640B_306041G00_cfe_fs_kernel  | head -n 10
000000 0036 0000 7242 616f 6364 6d6f 4320 726f
000010 6f70 6172 6974 006f 6576 2e72 3220 302e
000020 0000 0000 0000 3336 3834 0000 2d44 5034
000030 572d 0000 0000 0000 0000 0000 0031 3133
000040 3339 3536 0031 0000 3233 3731 3330 3131

od -A x -x GE_DSL-2640B_306041G00_cfe_fs_kernel  | grep "0010 7902"
000100 0010 7902 0000 0000 0000 0000 0000 0000

Dumped from the flash before writing:

# od -A x -x modemdump2.BIN  | head -n 10
000000 1000 0279 0000 0000 0000 0000 0000 0000
000010 0000 0000 0000 0000 0000 0000 0000 0000
*
000200 1000 0361 0000 0000 0000 0000 0000 0000
000210 0000 0000 0000 0000 0000 0000 0000 0000
*
000280 1000 034c 241a 0010 0000 0000 0000 0000
000290 0000 0000 0000 0000 0000 0000 0000 0000


# od -A x -x modemdump2.BIN  | grep "3600 0000"
010000 3600 0000 4453 4c2d 3236 3430 4200 0000


(remember: oem: big endian, dump: little endian)

so in the OEM the CFE is after the (kernel?) i must to re-order all, or just burn the CFE and flash via jtag? in the past i tried to flash via jtag with no success, the jtag could'nt write to the bcm, maybe due to the CFE corrupted?


// edit //

i'll flash just the CFE and then try to load the firmware by serial/jtag wink it'll be easier

(Last edited by gmtandi on 8 May 2013, 13:46)

A bad CFE may lock the CPU causing a non working JTAG. If this is the case you first need to erase the bootloader, which can ve very difficult using JTAG because you need to catch the CPU before swalowing the bytes causing the lock, maybe miliseconds after powering on the board..

If you flash a bad CFE with endianess mismatch, it won't cause this lock for sure, allowing you to use JTAG later for flashing a sane one.

great wink so i'm in the right way... i removed the flash from the board, and i'm programming directly to the memory... just the CFE(64KB from the OEM firmware, begining with "0279 1000"

that is?

thanks

(Last edited by gmtandi on 8 May 2013, 14:48)

Well most bcm6348 CFEs, extracted from OEM firmwares, without any change:

10 00 02 79

And If I do the byte reordering with redim tool (this is for straight flashing with HairyDairyMaid without any endian flag)

00 10 79 02

With a flash programmer, as I said before, no idea about if any byte reordering is needed.

Hello,

well, i think i got a good result, before, without a flash memory on the board or with an corrupted data in the memory, the ethernet leds only blinks and the red light stays;

now with the CFE(64 Kbytes), all the ethernet leds stays on,  but no data is received on the rs232 port...


//// found that the "switchend" was switching 4 bytes, i think that this bcm is only 2 bytes, the dump from the memory was 1000 0279, switchend was doing 0279 1000, so i modified the source of switchend, now programming again and let's test ;D

now i got the cfe from the gpl firmware

/// edit

It's being impossible to get it running, the flash is fully erased  with only the CFE begining at the start of the memory... it's not running :\ maybe i need a full dump of the flash, now i'll close the modem and try to find someone who have one like this one damaged to dump the flash and try again :\

thanks

(Last edited by gmtandi on 8 May 2013, 18:02)

The discussion might have continued from here.