Topic: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

I tried a 96358 image on a WAG160Nv2. The first few images linux said that the board wasn't supported on boot, but now it doesn't get that far and the bootloader says something like (yes, the spelling and grammer is exactly as printed on the serial console):

no pid2
FIRMWARE HAD BEEN DESTORYED!!

Without prompting to press a key to drop into CFE.

The IP address 192.168.1.1 is pingable at this point but a TCP and UDP scan shows nothing is opened. The router does not send any packets either.

If i hold in the reset button on boot I get:

get pid at0xbfc0ff80
SerialNumber53534831304b34303031333600
Language:1000
PinCode:3333363832323335
bffe1000:a55a
Download mode1111 ... press enter to stop

I'm wondering if 'Download mode1111' might mean I have an opportunity to load a new firmware via the serial port. I've tried xmodem and a few other protocols but it never handshakes. Is JTAG (if it exists on this model) my only remaining option? I did take copies of the mtd images before I flashed anything.

thanks

James

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

Full output on boot:

CFE version 1.0.37-5.4 for BCM96358 (32bit,SP,BE)
Build Date: 2009å¹´ 03æ 31æ¥ ææäº 17:07:55 CST (root@localhost.localdomain)
Copyright (C) 2000-2005 Broadcom Corporation.

Boot Address 0xbfc00000

Initializing Arena.
Initializing Devices.
Parallel flash device: name MX29LV320AB, id 0x22a8, size 4096KB
798
875
0x6:0x11f
0x6:0x108
0x6:0x108
CPU type 0x2A010: 300MHz, Bus: 133MHz, Ref: 64MHz
Total memory: 33554432 bytes (32MB)

Total memory used by CFE:  0x80401000 - 0x80533000 (1253376)
Initialized Data:          0x8041C0E0 - 0x8041CDD0 (3312)
BSS Area:                  0x8041CDD0 - 0x80431000 (82480)
Local Heap:                0x80431000 - 0x80531000 (1048576)
Stack Area:                0x80531000 - 0x80533000 (8192)
Text (code) segment:       0x80401000 - 0x8041C0D8 (110808)
Boot area (physical):      0x00533000 - 0x00573000
Relocation Factor:         I:00000000 - D:00000000

Board IP address                  : 192.168.1.1
Host IP address                   : 192.168.1.253
Gateway IP address                :
Run from flash/host (f/h)         : f
Default host run file name        : vmlinux.lzma.cfe
Default host flash file name      : bcm963xx_fs_kernel
Boot delay (0-9 seconds)          : 1
Board Id Name                     : 96358GW
Psi size in KB                    : 24
Number of MAC Addresses (1-32)    : 10
Base MAC Address                  : 00:22:6b:ff:8c:f1
Ethernet PHY Type                 : Internal
Memory size in MB                 : 32
CMT Thread Number                 : 0

no pid2
WARNING!! - FIRMWARE HAD BEEN DESTORYED!!
            YOU NEED RE-DOWNLOAD FIRMWARE!!

and when I hold down the reset button on boot:

CFE version 1.0.37-5.4 for BCM96358 (32bit,SP,BE)
Build Date: 2009å¹´ 03æ 31æ¥ ææäº 17:07:55 CST (root@localhost.localdomain)
Copyright (C) 2000-2005 Broadcom Corporation.

Boot Address 0xbfc00000

Initializing Arena.
Initializing Devices.
Parallel flash device: name MX29LV320AB, id 0x22a8, size 4096KB
798
875
0x6:0x11f
0x6:0x108
0x6:0x108
CPU type 0x2A010: 300MHz, Bus: 133MHz, Ref: 64MHz
Total memory: 33554432 bytes (32MB)

Total memory used by CFE:  0x80401000 - 0x80533000 (1253376)
Initialized Data:          0x8041C0E0 - 0x8041CDD0 (3312)
BSS Area:                  0x8041CDD0 - 0x80431000 (82480)
Local Heap:                0x80431000 - 0x80531000 (1048576)
Stack Area:                0x80531000 - 0x80533000 (8192)
Text (code) segment:       0x80401000 - 0x8041C0D8 (110808)
Boot area (physical):      0x00533000 - 0x00573000
Relocation Factor:         I:00000000 - D:00000000

Board IP address                  : 192.168.1.1
Host IP address                   : 192.168.1.253
Gateway IP address                :
Run from flash/host (f/h)         : f
Default host run file name        : vmlinux.lzma.cfe
Default host flash file name      : bcm963xx_fs_kernel
Boot delay (0-9 seconds)          : 1
Board Id Name                     : 96358GW
Psi size in KB                    : 24
Number of MAC Addresses (1-32)    : 10
Base MAC Address                  : 00:22:6b:ff:8c:f1
Ethernet PHY Type                 : Internal
Memory size in MB                 : 32
CMT Thread Number                 : 0

get pid at0xbfc0ff80
SerialNumber53534831304b34303031333600
Language:1000
PinCode:3333363832323335
bffe1000:a55a
Download mode1111 ... press enter to stop

Any suggestions?? Is this CFE giving me this or something else?

thanks

James

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

james.harper wrote:

Any suggestions?? Is this CFE giving me this or something else?

I'd guess this is the CFE. I doubt that the download mode refers to some protocol on the serial line,
it's rather tftp over ethernet. Have you tried to upload a firmware using tftp?

tftp -i 192.168.1.1 put firmware.bin

You might have to set your host's IP address to 192.168.1.253 before. If this doesn't work,
sniff the ethernet on the LAN ports during power up. If you see any tftp requests from the device,
you must run a tftp server on the host and provide the firmware in the requested filename.

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

Run a tftp server at 192.168.1.253. File name should be bcm963xx_fs_kernel. As its name implies, it contains only kernel and rootfs (and a 256-byte header). In order to strip off the necessary part from the Linksys firmware, you need to understand the firmware format.

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

fyi wrote:

Run a tftp server at 192.168.1.253. File name should be bcm963xx_fs_kernel. As its name implies, it contains only kernel and rootfs (and a 256-byte header). In order to strip off the necessary part from the Linksys firmware, you need to understand the firmware format.

I had  a look into a annex.a firmware for the EU. Seems like it starts with the loader and the header described in the link above is located at offset 0x10000. Do you really need to strip anything off?

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

Once in that crashed state it responds to pings but nothing else. Not tftp or anything else.

I have obtained the WRT54G DeBrick software (HairyDairyMaid) tool and have added 6358 to the list and it probes correctly about 80% of the time and I just get a garbled dump. I'm using an unbuffered cable though and the docs do say that while it works on the WRT54G it is unknown if it could work on anything else.

I'm going to tinker with the timings and hopefully will have something working before bedtime smile

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

james.harper wrote:

Once in that crashed state it responds to pings but nothing else. Not tftp or anything else.

I have obtained the WRT54G DeBrick software (HairyDairyMaid) tool and have added 6358 to the list and it probes correctly about 80% of the time and I just get a garbled dump. I'm using an unbuffered cable though and the docs do say that while it works on the WRT54G it is unknown if it could work on anything else.

I'm going to tinker with the timings and hopefully will have something working before bedtime smile

I recently used tjtag 3.0.1 with the DG834ND (BCM6358 inside), but with a wiggler clone. Tjtag supports the 6358 out of the box.
IMHO cable lengths are critical with the unbuffered adapter. Keep them as short as possible.

Have you sniffed the ethernet traffic from the board during power up?

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

jal2 wrote:

I recently used tjtag 3.0.1 with the DG834ND (BCM6358 inside), but with a wiggler clone. Tjtag supports the 6358 out of the box.
IMHO cable lengths are critical with the unbuffered adapter. Keep them as short as possible.

Yeah I think mine might be too long. The openwrt docs suggest 15cm as a maximum and i'm probably over that.

jal2 wrote:

Have you sniffed the ethernet traffic from the board during power up?

Yes. Wireshark with the device plugged into my laptop. Nothing. It's really screwed now though since I flashed it with my dodgy jtag cable!

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

james.harper wrote:

It's really screwed now though since I flashed it with my dodgy jtag cable!

Any output on the serial port?
If you want to stick to the unbuffered cable, use the shortest cable possible - on both sides of the adapter, i.e. to the parallel port as well.
Try to use another PC to run the JTAG tool, if possible. Use another power supply for the target.
You may also try tjtag.

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

No output from the serial port. Flash is completely scambled.

I cut off the cable to shorten it and found that the ground wire had come loose (or more likely, i'd forgotten to attach it). Surprising it worked at all smile

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

It's amazing how much better it works with the ground wire attached smile

I have reflashed CFE with the original image but i'm back to getting "WARNING!! - FIRMWARE HAD BEEN DESTORYED!!" messages and cannot see a way to break into CFE. I thought I was getting this because I'd wiped CFE but now that CFE is back and I'm getting the same thing I guess that's not the case. Any suggestions? It would suck to have to flash with JTAG every time!

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

I am now of the opinion that there is a bug in my CFE that causes it to crash when the rest of the firmware isn't entirely perfect. How can I get a later version than "CFE version 1.0.37-5.4 for BCM96358 (32bit,SP,BE)"?

I assume that the regular openwrt images don't include a CFE image.

thanks

James

13

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

jal2 wrote:
fyi wrote:

Run a tftp server at 192.168.1.253. File name should be bcm963xx_fs_kernel. As its name implies, it contains only kernel and rootfs (and a 256-byte header). In order to strip off the necessary part from the Linksys firmware, you need to understand the firmware format.

I had  a look into a annex.a firmware for the EU. Seems like it starts with the loader and the header described in the link above is located at offset 0x10000. Do you really need to strip anything off?

Yes. I suppose you can verify it by dumping the first 256 bytes of mtd "kernel".

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

fyi wrote:
jal2 wrote:
fyi wrote:

Run a tftp server at 192.168.1.253. File name should be bcm963xx_fs_kernel. As its name implies, it contains only kernel and rootfs (and a 256-byte header). In order to strip off the necessary part from the Linksys firmware, you need to understand the firmware format.

I had  a look into a annex.a firmware for the EU. Seems like it starts with the loader and the header described in the link above is located at offset 0x10000. Do you really need to strip anything off?

Yes. I suppose you can verify it by dumping the first 256 bytes of mtd "kernel".

Sure, but my question was if the tftp server in the bootloader of a WAG160N can handle the vendor firmware format (without any stripping needed), which starts with the CFE itself and contains the header at offset 0x10000? This looks like a plain copy of the complete flash.

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

james.harper wrote:

I am now of the opinion that there is a bug in my CFE that causes it to crash when the rest of the firmware isn't entirely perfect. How can I get a later version than "CFE version 1.0.37-5.4 for BCM96358 (32bit,SP,BE)"?

I assume that the regular openwrt images don't include a CFE image.

The vendor firmware (link above) seems to contain a CFE in the first 64KB. Difficult to tell the version, as it is compressed. You may run a binary diff to your CFE dump from the JTAG, which is probably in little endian, i.e. need to be swapped. I doubt that it is a new version.

I'd rather prefer to find out where pid2 is located and which value it should have in order to fix the openwrt images.
From your posting the first pid is at 0xbfc0ff80, i.e. at the end of the CFE. I'd guess pid2 is located in the header, i.e. the first 256 byte of the
openwrt images. Which openwrt image did you try last time?

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

I'd rather prefer to find out where pid2 is located and which value it should have in order to fix the openwrt images.
From your posting the first pid is at 0xbfc0ff80, i.e. at the end of the CFE. I'd guess pid2 is located in the header, i.e. the first 256 byte of the
openwrt images. Which openwrt image did you try last time?

Stupidly, I didn't take note which was the image that broke it. It *might* have been openwrt-DSL2740B-squashfs-cfe.bin (DSL2740B appears to be a 96358 build) but i'm not sure.

I left it flashing the original image back again (i copied all the /dev/mtdblockX images), so hopefully i'll at least have CFE working again.

I don't know what a pid2 is, nor why it would stop CFE from working. Can you explain or is there a doc somewhere?

thanks

James

17 (edited by jal2 2010-12-23 12:45:22)

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

james.harper wrote:

Stupidly, I didn't take note which was the image that broke it. It *might* have been openwrt-DSL2740B-squashfs-cfe.bin (DSL2740B appears to be a 96358 build) but i'm not sure.

I left it flashing the original image back again (i copied all the /dev/mtdblockX images), so hopefully i'll at least have CFE working again.

I don't know what a pid2 is, nor why it would stop CFE from working. Can you explain or is there a doc somewhere?

I assume that pid and pid2 are magic numbers in the flash at defined locations.
pid is located at the end of the bootloader at offset 0xff80, where the CFE from the vendor firmware contains the string "sErCoMm". Both serve to detect invalid flash content, however I wonder what the bootloader will do if pid was changed.
pid2 may be located in the 256 byte header following the bootloader. I've compared the first 62 bytes of the header from openwrt-DSL2740B-squashfs-cfe.bin and from the vendor firmware, they appear to be the same. So you either flashed a different image or the header got changed during the firmware update.

I'd love to look at the 256 byte header at 0xbfc10000 in both the working and non-working case.
You may also try to flash openwrt-DSL2740B-squashfs-cfe.bin to this address via JTAG, after your CFE was restored.

I don't know how much time you want to spend on this issue, I'll get a WAG160N during the next weeks and could try this myself.

I'm really surprised that you don't run into endian problems, thought that the HairyDairyMaid tool stores the binaries in little endian mode (tjtag 3.0.1 does for sure), while the mtdblock images are in big endian.

18

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

jal2 wrote:

I'm really surprised that you don't run into endian problems, thought that the HairyDairyMaid tool stores the binaries in little endian mode (tjtag 3.0.1 does for sure), while the mtdblock images are in big endian.

Install Python and run "python rvs-dword.py [file_to_reverse]".

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

jal2 wrote:

You may also try to flash openwrt-DSL2740B-squashfs-cfe.bin to this address via JTAG, after your CFE was restored.

I'm pretty sure I tried DSL2740B. CFE still worked but linux complained that it couldn't find the board.

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

JTAG flash finally completed and it's booting again. I think I need to put the nvram and ath_data partitions back still.

21 (edited by jal2 2010-12-24 00:44:16)

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

james.harper wrote:
jal2 wrote:

You may also try to flash openwrt-DSL2740B-squashfs-cfe.bin to this address via JTAG, after your CFE was restored.

I'm pretty sure I tried DSL2740B. CFE still worked but linux complained that it couldn't find the board.

So the DSL2740B wasn't the last image flashed, i.e. the one which let the CFE fail? You flashed some other images afterwards?
Then the pid2 could well be the board id or the router model in the header at flash offset 0x10000. They are at
offset 0x10026 (board id, 6 bytes, string "6358" in the vendor firmware) and offset 0x1002c (router model, 16 byte, string "96358GW").

With the DSL2740B image you got an error during boot from the Linux kernel?

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

I just flashed openwrt-96358GW-squashfs-bc310-cfe.bin that I found from this thread https://forum.openwrt.org/viewtopic.php?id=19601 and it booted up just fine, but then on the next reboot I'm right back where I started with:

no pid2
WARNING!! - FIRMWARE HAD BEEN DESTORYED!!
            YOU NEED RE-DOWNLOAD FIRMWARE!!

So i'm wondering now if I did actually find a bootable image last time and wasn't watching the serial port when it booted up, and that when it formats jffs2 it wipes the pid area?

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

james.harper wrote:

I just flashed openwrt-96358GW-squashfs-bc310-cfe.bin that I found from this thread https://forum.openwrt.org/viewtopic.php?id=19601 and it booted up just fine, but then on the next reboot I'm right back where I started with:

no pid2
WARNING!! - FIRMWARE HAD BEEN DESTORYED!!
            YOU NEED RE-DOWNLOAD FIRMWARE!!

So i'm wondering now if I did actually find a bootable image last time and wasn't watching the serial port when it booted up, and that when it formats jffs2 it wipes the pid area?

This may be the case. Do you have a log of the first boot of this firmware?

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

jal2 wrote:

This may be the case. Do you have a log of the first boot of this firmware?

CFE> f
Loading 192.168.1.100:bcm963xx_fs_kernel ...
Finished loading 2686980 bytes

Flashing root file system and kernel at 0xbfc10000: ..........................................

.
*** Image flash done *** !
Resetting board...

CFE version 1.0.37-5.4 for BCM96358 (32bit,SP,BE)
Build Date: 2009å¹´ 03æ 31æ¥ ææäº 17:07:55 CST (root@localhost.localdomain)
Copyright (C) 2000-2005 Broadcom Corporation.

Boot Address 0xbfc00000

Initializing Arena.
Initializing Devices.
Parallel flash device: name MX29LV320AB, id 0x22a8, size 4096KB
798
875
0x6:0x11f
0x6:0x108
0x6:0x108
CPU type 0x2A010: 300MHz, Bus: 133MHz, Ref: 64MHz
Total memory: 33554432 bytes (32MB)

Total memory used by CFE:  0x80401000 - 0x80533000 (1253376)
Initialized Data:          0x8041C0E0 - 0x8041CDD0 (3312)
BSS Area:                  0x8041CDD0 - 0x80431000 (82480)
Local Heap:                0x80431000 - 0x80531000 (1048576)
Stack Area:                0x80531000 - 0x80533000 (8192)
Text (code) segment:       0x80401000 - 0x8041C0D8 (110808)
Boot area (physical):      0x00533000 - 0x00573000
Relocation Factor:         I:00000000 - D:00000000

Board IP address                  : 192.168.1.1
Host IP address                   : 192.168.1.100
Gateway IP address                :
Run from flash/host (f/h)         : f
Default host run file name        : vmlinux
Default host flash file name      : bcm963xx_fs_kernel
Boot delay (0-9 seconds)          : 9
Board Id Name                     : 96358GW
Psi size in KB                    : 24
Number of MAC Addresses (1-32)    : 10
Base MAC Address                  : 00:22:6b:ff:8c:f1
Ethernet PHY Type                 : Internal
Memory size in MB                 : 32
CMT Thread Number                 : 0

get pid2 at0xbffbd00b
pid checked!
*** Press any key to stop auto run (9 seconds) ***
Auto run second count down: 0
Code Address: 0x80010000, Entry Address: 0x80010000
Decompression OK!
Entry at 0x80010000
Closing network.
Starting program at 0x80010000
Linux version 2.6.32.9 (virus@Virion) (gcc version 4.3.3 (GCC) ) #18 Mon Mar 15 16:16:55 CET 2010
Detected Broadcom 0x6358 CPU revision a1
CPU frequency is 300 MHz
32MB of RAM installed
registering 40 GPIOs
board_bcm963xx: CFE version: 1.0.37-5.4
bootconsole [early0] enabled
CPU revision is: 0002a010 (Broadcom BCM6358)
board_bcm963xx: board name: 96358GW
Determined physical RAM map:
 memory: 02000000 @ 00000000 (usable)
Initrd not found or empty - disabling initrd
Zone PFN ranges:
  Normal   0x00000000 -> 0x00002000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0: 0x00000000 -> 0x00002000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128
Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Primary instruction cache 32kB, VIPT, 2-way, linesize 16 bytes.
Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16 bytes
Memory: 29724k/32768k available (2050k kernel code, 3044k reserved, 363k data, 136k init, 0k highmem)
Hierarchical RCU implementation.
NR_IRQS:128
Calibrating delay loop... 299.00 BogoMIPS (lpj=598016)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
ath: Register ath_data_device at address 0x1ffe1000
registering PCI controller with io_map_base unset
bio: create slab <bio-0> at 0
Switching to clocksource MIPS
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
NET: Registered protocol family 1
audit: initializing netlink socket (disabled)
type=2000 audit(0.197:1): initialized
squashfs: version 4.0 (2009/01/31) Phillip Lougher
Registering mini_fo version $Id$
JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
msgmni has been set to 58
io scheduler noop registered
io scheduler deadline registered (default)
gpiodev: gpio device registered with major 254
gpiodev: gpio platform device registered with access mask FFFFFFFF
bcm63xx_uart.0: ttyS0 at MMIO 0xfffe0100 (irq = 10) is a bcm63xx_uart
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
bcm963xx_flash: 0x00400000 at 0x1fc00000
bcm963xx: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
bcm963xx_flash: Read Signature value of CFE1CFE1
bcm963xx_flash: CFE bootloader detected
bcm963xx_flash: CFE boot tag found with version 6, board type 96358GW, and tagid bc310.
bcm963xx_flash: Partition 0 is CFE offset 81ce1e48 and length 0
bcm963xx_flash: Partition 1 is kernel offset d2b and length 0
bcm963xx_flash: Partition 2 is rootfs offset d6c and length 0
bcm963xx_flash: Partition 3 is ath_data offset dad and length 0
bcm963xx_flash: Partition 4 is nvram offset df0 and length 0
bcm963xx_flash: Spare partition is 2a0000 offset and length 150000
Creating 5 MTD partitions on "bcm963xx":
0x000000000000-0x000000010000 : "CFE"
0x000000010100-0x0000000f0000 : "kernel"
mtd: partition "kernel" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
0x0000000f0000-0x0000003e0000 : "rootfs"
mtd: partition "rootfs" set to be root filesystem
mtd: partition "rootfs_data" created automatically, ofs=2A0000, len=140000
0x0000002a0000-0x0000003e0000 : "rootfs_data"
0x0000003e0000-0x0000003f0000 : "ath_data"
0x0000003f0000-0x000000400000 : "nvram"
bcm63xx_enet MII bus: probed
bcm63xx_wdt started, timer margin: 30 sec
TCP westwood registered
NET: Registered protocol family 17
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
VFS: Mounted root (squashfs filesystem) readonly on device 31:2.
Freeing unused kernel memory: 136k freed
Please be patient, while OpenWrt loads ...
- preinit -
Press f<ENTER> to enter failsafe mode
- regular preinit -
jffs2 not ready yet; using ramdisk
mini_fo: using base directory: /
mini_fo: using storage directory: /tmp/root
- init -

Please press Enter to activate this console. bcm63xx_enet bcm63xx_enet.0: attached PHY at address 1 [Broadcom BCM63XX (2)]
eth1: link forced UP - 100/full - flow control off/off
device eth1 entered promiscuous mode
br-lan: port 1(eth1) entering forwarding state
Generic kernel compatibility enabled based on linux-next next-20100113
cfg80211: Calling CRDA to update world regulatory domain
roboswitch: Probing device eth0: Failed to enable switch
roboswitch: Probing device eth1: found a 5325! It's a 5350.
cfg80211: World regulatory domain updated:
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
PCI: Enabling device 0000:00:01.0 (0000 -> 0002)
 # reading ath_data
ath9k 0000:00:01.0: Failed to initialize device
ath9k: probe of 0000:00:01.0 failed with error -22
PPP generic driver version 2.4.2
ip_tables: (C) 2000-2006 Netfilter Core Team
NET: Registered protocol family 24
nf_conntrack version 0.5.0 (466 buckets, 1864 max)
ath_hal: module license 'Proprietary' taints kernel.
Disabling lock debugging due to kernel taint
ath_hal: 2009-05-08 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, REGOPS_FUNC, XR)
ath_pci: trunk
wlan: trunk
wlan: mac acl policy registered
ath_rate_minstrel: Minstrel automatic rate control algorithm 1.2 (trunk)
ath_rate_minstrel: look around rate set to 10%
ath_rate_minstrel: EWMA rolloff level set to 75%
ath_rate_minstrel: max segment size in the mrr set to 6000 us
jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
jffs2_build_filesystem(): unlocking the mtd device... done.
jffs2_build_filesystem(): erasing all blocks after the end marker... done.
mini_fo: using base directory: /
mini_fo: using storage directory: /jffs



BusyBox v1.15.3 (2010-03-13 12:19:49 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 KAMIKAZE (bleeding edge, r20018) ------------------
  * 10 oz Vodka       Shake well with ice and strain
  * 10 oz Triple sec  mixture into 10 shot glasses.
  * 10 oz lime juice  Salute!
 ---------------------------------------------------
root@OpenWrt:/# reboot
root@OpenWrt:/# br-lan: port 1(eth1) entering disabled state
device eth1 left promiscuous mode
br-lan: port 1(eth1) entering disabled state
bcm63xx_wdt: Unexpected close, not stopping watchdog!
Restarting system.
triggering watchdog soft-reset...


CFE version 1.0.37-5.4 for BCM96358 (32bit,SP,BE)
Build Date: 2009å¹´ 03æ 31æ¥ ææäº 17:07:55 CST (root@localhost.localdomain)
Copyright (C) 2000-2005 Broadcom Corporation.

Boot Address 0xbfc00000

Initializing Arena.
Initializing Devices.
Parallel flash device: name MX29LV320AB, id 0x22a8, size 4096KB
798
875
0x6:0x11f
0x6:0x108
0x6:0x108
CPU type 0x2A010: 300MHz, Bus: 133MHz, Ref: 64MHz
Total memory: 33554432 bytes (32MB)

Total memory used by CFE:  0x80401000 - 0x80533000 (1253376)
Initialized Data:          0x8041C0E0 - 0x8041CDD0 (3312)
BSS Area:                  0x8041CDD0 - 0x80431000 (82480)
Local Heap:                0x80431000 - 0x80531000 (1048576)
Stack Area:                0x80531000 - 0x80533000 (8192)
Text (code) segment:       0x80401000 - 0x8041C0D8 (110808)
Boot area (physical):      0x00533000 - 0x00573000
Relocation Factor:         I:00000000 - D:00000000

Board IP address                  : 192.168.1.1
Host IP address                   : 192.168.1.100
Gateway IP address                :
Run from flash/host (f/h)         : f
Default host run file name        : vmlinux
Default host flash file name      : bcm963xx_fs_kernel
Boot delay (0-9 seconds)          : 9
Board Id Name                     : 96358GW
Psi size in KB                    : 24
Number of MAC Addresses (1-32)    : 10
Base MAC Address                  : 00:22:6b:ff:8c:f1
Ethernet PHY Type                 : Internal
Memory size in MB                 : 32
CMT Thread Number                 : 0

no pid2
WARNING!! - FIRMWARE HAD BEEN DESTORYED!!
            YOU NEED RE-DOWNLOAD FIRMWARE!!

Some bytes in CFE were definitely changed but I don't know yet when that happened.

Re: Bricked WAG160Nv2 - bootloader says Download mode1111 ... press enter

If I flash the first 256 bytes at offset 0x10000 into the flash (eg the 'tag' area) with 0xff, then reboot, then re-read, it now contains:

# hd pid2.out
00000000  00 00 00 00 ff ff 00 00  00 00 ff ff 00 00 00 00  |....ÿÿ....ÿÿ....|
00000010  ff ff 00 00 ff ff ff ff  00 00 00 00 ff ff ff ff  |ÿÿ..ÿÿÿÿ....ÿÿÿÿ|
00000020  00 51 00 52 00 59 00 02  00 00 00 40 00 00 00 00  |.Q.R.Y.....@....|
00000030  00 00 00 00 00 00 00 27  00 36 00 00 00 00 00 04  |.......'.6......|
00000040  00 00 00 0a 00 00 00 05  00 00 00 04 00 00 00 16  |................|
00000050  00 02 00 00 00 00 00 00  00 02 00 07 00 00 00 20  |............... |
00000060  00 00 00 3e 00 00 00 00  00 01 00 00 00 00 00 00  |...>............|
00000070  00 00 00 00 00 00 00 00  00 00 ff ff ff ff ff ff  |..........ÿÿÿÿÿÿ|
00000080  00 50 00 52 00 49 00 31  00 31 00 00 00 02 00 04  |.P.R.I.1.1......|
00000090  00 01 00 04 00 00 00 00  00 00 00 a5 00 b5 00 02  |...........¥.µ..|
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ|
*
000000c0  ff ff ff ff ff ff ff 55  00 00 ff ff 00 00 00 00  |ÿÿÿÿÿÿÿU..ÿÿ....|
000000d0  ff ff 00 00 00 00 00 00  00 00 ff ff 00 00 00 00  |ÿÿ........ÿÿ....|
000000e0  00 00 00 00 00 00 00 00  00 00 ff ff 00 00 ff ff  |..........ÿÿ..ÿÿ|
000000f0  ff ff ff ff ff 55 ff 55  ff 55 ff ff ff ff ff 55  |ÿÿÿÿÿUÿUÿUÿÿÿÿÿU|

and even if I copy the first 8K back from the original mdtblock1 backup I took, some of that initial area still gets scrambled. It looks like it's rewriting a checksum or something and maybe corrupting itself?