Posted: Sat May 15, 2010 19:07 Post subject: WZR-HP-G300NH bricked after a successful DD-WRT installation
Hi everyone,
I used to use my WZR-HP-G300NH with Japanese firmware until last week.
Then, tried the wzrg300nh-firmware_MULTI.bin to install ddwrt from web interface of stock firmware. It worked fine. I started to use it and tried for 1 week.
Yesterday, tried to revert the stock firmware (English one - Brainslayer's) from ddwrt web interface. After installation, router went into an infinite loop with "double blinking" red led (dunno the name, the one like a gear) on every 3 seconds. (not reboots itself, just led double blinks) I have checked other topics but those seem to me different.
It's not 'ping'able now.
I can reach the device over tftp and could install the below mentioned firmwares. But any of them differs.
What you have to be quick about is that when you have plugged in the power to the router, you need to run the arp command at the same time, so that the pc can find the router via mac address. This window is about 2-3 seconds by my estimates for the router to accept a tftp connection. BTW I have the A0 D0 revision of the Buffalo WZR-HP-300NH .
But the problem is I can do tftp and it works, but nothing was changed.
I did the procedures and catch the correct timing to tftp the firmware. it was ok, but then nothing happened. You can see the tftp log from the first post.
Do you still recommend me to do the same thing again and again?
But the problem is I can do tftp and it works, but nothing was changed.
The problem is that you have not connected a serial terminal to the router so you can see what happens on that side.
The long log you provided is basically worthless, it only shows that the file was transferred ok but you have no idea of what happened on the other side. _________________ Kernel panic: Aiee, killing interrupt handler!
Joined: 06 Feb 2010 Posts: 7401 Location: Little Rock
Posted: Sun May 23, 2010 10:20 Post subject:
you can keep trying again and again, but what LOM is saying is if you dont ttl to your unit and find out whats going on, you probably wasting your time, thus will end in the same result, however if you get a serial connection into your unit, then post that here, then maybe could better know whats up with it. _________________ Wireless N Config | Linking Routers | DD-WRT Wiki | DD-WRT Builds | Peacock - Broadcom FAQ
I don't think, by the look of your serial log, that the firmware you download by tftp gets written to the flash, it looks like it is booting the old corrupted firmware that it has in flash, the Linux kernel you have uploaded has a UTC time stamp but the kernel you are booting has JST time stamp.
There is normally, after a tftp transfer, a long row of symbols showing the write to the individual flash sectors, similar to the big block showing the tftp transfer.
Your U-Boot version is of an older kind which I don't have so I can not see if the tftp command was flawed in the old version or not implemented in the same way.
You can Ctrl-C at an earlier stage and get a U-Boot prompt, then type help to see the available boot and flash commands. _________________ Kernel panic: Aiee, killing interrupt handler!
One more question I have. Just out of curiosity.
This magic number sequence exists at the almost beginning of DD-WRT image. So I deleted the first part of the image. Otherwise UBoot does not allow it to boot.
But, the original image file from buffalo does not have this magic number at the beginning. Besides, I searched for it but it doesn't exist in the original image file. How come this could be? Because at first I tried to get the original buffalo firmware back. But didn't work. Still gave me the same error. (Bad Data CRC)
One more question I have. Just out of curiosity.
This magic number sequence exists at the almost beginning of DD-WRT image. So I deleted the first part of the image. Otherwise UBoot does not allow it to boot.
But, the original image file from buffalo does not have this magic number at the beginning. Besides, I searched for it but it doesn't exist in the original image file. How come this could be? Because at first I tried to get the original buffalo firmware back. But didn't work. Still gave me the same error. (Bad Data CRC)
The dd-wrt image is in Buffalo Open F/W format and later versions of the U-Boot understands that format, looks like your ver 1.02 does not have it implemented.
The header should be stripped off by the tftp client in U-Boot before the image is written to disk.
You have done that manually now.
Buffalo's original firmware is in encrypted format so you will not see the 27 05 19 56 until it has been decrypted and later U-Boot versions does also accept the encrypted format via tftp. _________________ Kernel panic: Aiee, killing interrupt handler!
hello every....I am new to this forum and I really liked this whole post..... the particpation of the experts is really great and awesome one..... keep it up gud work u all _________________ Test King , mcitp exam , mcpd dumps , mcp test
