OpenWrt Forum Archive

Topic: Buffalo WHR-G54S beyond bricked?

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

I just got two new Buffalo WHR-G54S units and installed RC5.  Boot_wait is on by default, so tftp'ing the openwrt-brcm-2.4-jffs2-4MB.trx file was not a problem.

The first unit went fine, and I got everything set up without incident.  The second unit was not so good. :-(

The image transferred fine, I telneted in after the transfer and got the usual OpenWRT "first time" screen.  I gave it a "reboot" command to finish off the jffs setup (since it mounts read-only on the first time), and it never rebooted.  After a few minutes (around 5?) I pulled the power and plugged it back in, but it never came back up.

Here's the symptoms:

1)  All the led's light up and stay light.   For reference, on the other unit they go off when the bootloader starts.
2)  No response from the tftp server (i.e.  either boot_wait isn't working or the CFE is never starting the tftp server)
3)  I soldered on a JTAG header and tried to debrick, but the latest version of hairydairymaid's tool (v4.5) returns all 0's for the chip-id and says it's unknown.  (FYI - I was using the cheap xilinx style cable that I've used on Linksys models previously).  I did notice that the flash chip that's on the board isn't in the list of chips the debrick tool supports with the /fc option.  I don't have the unit in front of me, but I'll post the chip part number in a follow-on post later today for reference.
4)  I even resorted to trying the crude pin-shorting in a last ditch effort, with no success.

I'm confused why the initial flash worked (I logged in!), and why it then completely crapped out on reboot since I've never seen that behaviour before.  I'll settle for just recovering it though :-)

Anyone have any other experience debricking one of these or know of any other tools/methods to try?  I'm really comfortable with OpenWRT and flashing units, and I've run out of ideas on this one.



Greg

I would be willing to bet the serial number on the one that died starts with 7407 and the one that didnt starts with 3407.

Buffalo changed some stuff on the board... looking into it as we speak.

We have figured out console on the devices... next is jtag.  Have you found any resources that have info on these devices?  We had to figure out the pin-outs for serial on our own.

Tim

liquid wrote:

I would be willing to bet the serial number on the one that died starts with 7407 and the one that didnt starts with 3407.

Interesting data point.  I'll check when I get home and let you know.

liquid wrote:

Have you found any resources that have info on these devices?  We had to figure out the pin-outs for serial on our own.

No, I just got these, and hadn't used this brand before, so I hadn't really looked into it.  Guess I need to start researching it now :-)


Greg

I will post the pinouts and some various other information to the wiki later today.

pinouts for serial:

1 is TX 7 is Rx
2 is PWR 3 is GND

bluesguy: see this changeset... https://dev.openwrt.org/changeset/4585

you will need a jtag (erase:nvram) or to short pin 10 (i think) to resolve your issue.

jtag is flipped as if you were coming from the back side.  i will post that stuff to the wiki later

liquid wrote:

I would be willing to bet the serial number on the one that died starts with 7407 and the one that didnt starts with 3407.

Ok, this is interesting.  Both of my units start with 7407, and yet the first one worked fine, the second one didn't.  The *only* thing I can think of that I did different was that I booted the first one all the way up into the Buffalo GUI, because I wanted to see what it looked like and what their stock configuration looked like.  I can't imagine this would have made a difference unless they do some kind of initial configuration during the bootup (e.g. something that modifies the flash or sets up the nvram).  The second one (broken one) I flashed immediately on first power up as soon as the boot_wait kicked in.

liquid wrote:

bluesguy: see this changeset... https://dev.openwrt.org/changeset/4585

you will need a jtag (erase:nvram) or to short pin 10 (i think) to resolve your issue.

Ok, but this raises a couple questions:

1)  The wiki says it's not safe to erase the nvram on this unit.  Are you suggesting that I read the nvram off the one that's working and write it back to the broken one?  Cause I could certainly do that.  Or are you saying the wiki is wrong and deleting NVRAM is ok?
2)  Are you saying it's just an NVRAM problem then, because the changset looks like it's just nvram variables.   
3)  If it is just a matter of OpenWRT incorrectly setting NVRAM then I still can't reconcile why I have one working unit, unless, as I'm guessing above, Buffalo does something during that initial bootup.

liquid wrote:

jtag is flipped as if you were coming from the back side.  i will post that stuff to the wiki later

So it's a mirror image of what it should be on the long axis?  As in, pin 1 marked on the board is really pin 2?

That would mean it looks like this (where \/ is the pin 1 marking that's on the board):

12 10 8   6   4   2
                       \/
o   o   o   o   o   o
o   o   o   o   o   o
11 9   7   5   3   1

Is this what you mean?  Or do you mean switched on the short axis as in pin 1 and pin 11 are swapped (along with all the others)?

Thanks for the update and all the info!!

G

Oh yeah, and for the record the flash chip on this unit is an MX 29LV320CBTC (emphasis mine) which isn't in the list of supported chips using the /fc flag of HairyDairyMaids v4.5 util.

G

flipped on the long axis.  we used the linux wrt54g.c jtag app and it worked fine for us (keep in mind the timings are very short.. like 1/2 second or so from initial power on).

the sdram_config on this board is different than the linksys wrt54g v2.2 (which is what that hack was in place for).  openwrt shouldnt have been messing with that flag anyway, since it wasnt necessary.

doing so will result in a bootable system.

as for buffalo... they do some initial set up in the bootloader.

if you power on a brand new device, you will see it reboot once before coming up.  that is a result of the device setting some defaults.

you can also watch that in console.

hope that helps.

liquid wrote:

flipped on the long axis.  we used the linux wrt54g.c jtag app and it worked fine for us (keep in mind the timings are very short.. like 1/2 second or so from initial power on).

Ok, so re-soldering the header on the back side of the board should do it then.  I'll give it a whirl.

liquid wrote:

the sdram_config on this board is different than the linksys wrt54g v2.2 (which is what that hack was in place for).  openwrt shouldnt have been messing with that flag anyway, since it wasnt necessary.

Gotcha.

So is it safe to just erase the nvram on these guys, or should I grab the nvram off the other unit and load it over the b0rked one?



G

i just erased it... but you can always grab the nvram from a fresh one if you are paranoid. smile

Thanks.  And it automatically rebuilt the default values, or did you have to enter them through the serial console?

And the serial on these units is 115,200 N,8,1, no flow control?

G

(Last edited by bluesguy on 18 Aug 2006, 14:16)

yeah, it built what it needed.. if it needed anything.

and yes, that's right on serial.

Hi liquid,

does it means that the 7407 units are supported on RC5 as well by just changing S05nvram as described on
https://dev.openwrt.org/changeset/4585
after initial setup, but before rebooting ?

I have an order of 4 of this units on the way, and now I'm afraid that they might be 7407's ! :-(

Well I'm not convinced the 7407 serial number is accurate to catch the root source of the problem.  I have two 7407 units, one's fine, the other's dead.

I've tried everything I could think of, including liquid's suggestion of trying the JTAG from the backside of the board, and still nothing.  (From the back I get all F's, unknown chipid)  To make sure I hadn't screwed something up, I also tried the JTAG on the working unit, and I still get nothing.   FYI - The two units are identical.  I know my JTAG setup is working because it works flawlessly on my old wrt54gs.  I still suspect the flash chip, since it's not on the list of supported chips in HairyDairyMaid's v4.5 debrick tool.

Here's a couple pictures of my board, and I suspect liquid and I must have different units, since his worked with the JTAG debrick tool.

Top left corner markings

http://blues.gotdns.org/buffalo-whr-g54s/top-left.jpg

The flash chip

http://blues.gotdns.org/buffalo-whr-g54s/flash-chip.jpg

I've got shots of the front and back as well, but they'll take a while to download, if you're interested.

I've got nothing to left to try, so maybe someone else will have a break though?  I'll gladly post or e-mail other (higher resolution) shots if someone's interested in something specific about this unit.


G

FWIW, I ordered another unit.  This one also has the 7407 serial number.  I followed exactly the same procedure as I did the first successful unit, and...... it worked.  So now I have three units with the 7407 serial, two good, one bad.

So either letting the WHR-G54S go through it's startup routine does something, or I just had bad luck that the other unit really is defective. 

In either case the 7407 serial doesn't seem to be an issue, so we can probably update the wiki, but I won't know for sure until I can get a JTAG setup that works for these units.  (see previous posts)

Liquid, do you have any more insight into how the JTAG works on these guys?  I can't get it to work on any of these units (the two good one's or the bad one), but it works fine for my older Linksys models.  If I could prove that I can talk to the good unit, but not to the bad unit, that would be a clincher.  The sledgehammer patiently awaits...:-)


G

I just flashed a WHR-G54S with serial number beginning with 7407, and it worked. I booted up into the default Buffalo GUI first, the followed procedure as indicated above and on WHR-G54S wiki page for the older serial number.

I've successfully installed the openwrt-brcm-2.4-squashfs.trx on my Buffalo WHR-G54S and then soldered the serial connector where I follow the schematic found on http://www.k9spud.com/whr-g54s/

I've also installed microcom to check the serial communication.

My problem is, I cannot connect to my serial device using /dev/ttyS0 .... Can anybody help me?

The Buffalo serial number starts with 3407.

The discussion might have continued from here.