Bricked NAS200 for anyone willing to pay shipping

Discussion in 'Cisco/Linksys Network Storage Devices' started by leitec, Feb 14, 2008.

  1. leitec

    leitec LI Guru Member

    Sorry, I short-circuited it trying to fix it, and it's now in the trash.

    So, I totally bricked this thing within two hours of arrival. I intended on adding a serial port and trying to compile a custom kernel so that it'd boot Debian or another distribution from one of the hard drives. Unfortunately I messed up adding the serial port when I accidentally removed the point of contact on the RxD pin. I then messed it up further trying to fix it, so the serial port is a goner unless you know some sort of PCB magic.

    The thing still worked, so I thought I could work it through the RedBoot telnet interface and load kernels using TFTP before I flashed anything. Of course curiosity kicked in and I wondered what the 'flash' command did, hoping it'd produce usage information, but instead it seems to have overwritten at least part of the flash so that the unit no longer boots, not even into RedBoot.

    I don't think I really have the patience to deal with yet another bricked device, and the use I had for this thing was superfluous at best so I think it's best for me to part with it and not waste any more of my time trying to fix it. If you want to mess with it, try to fix it with JTAG or otherwise do something with it, please let me know and I will send it to you for the cost of shipping.
  2. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    I'd be happy to help you JTAG it back to life again. Except for the part about frying the board, what you did is pretty much exactly what I did.

    I posted a long message on page 3 of the NAS200 telnetd thread ( about jtagging; Depending on how much you know about electronics and PC's, you may be able to do it yourself: the NAS200 is just a headless 486 compatible PC and you will only need about $10 in parts to build a JTAG cable [edit: never mind I see in one of your other posts that you already have JTAG experience]. Just be careful not to fry the JTAG connector :)

    Send me a private message or email me (put behind my linksysinfo user ID) and I'll help you. I already have a NAS200 and the offer of getting another one for shipping costs is tempting, but I don't need it and I would rather make you another happy NAS200 user by getting your box working again.


    (Of course, if someone else wants to take Leitec up on his offer, I'll be happy to help them too!)
  3. Toxic

    Toxic Administrator Staff Member

    why dont you just contact linksys and say it failed and get a replacement?
  4. leitec

    leitec LI Guru Member

    I very clearly voided the warranty.
  5. mstombs

    mstombs Network Guru Member

    I already have the bits for a "wiggler" JTAG cable, not used because a HairyDairyMaid one worked- but guess its not worth shipping across the Atlantic ocean and buying a new power supply in UK - but the NAS200 over here is still 100 pounds/ 200 dollars!
  6. leitec

    leitec LI Guru Member

    I think I'm going to be a little less hasty and try to resurrect it. If I decide against it, I'll put up the offer again.

    I read jac's long post and it looks like I'll be building a buffered cable sometime soon. mstombs, did your unbuffered cable work for your NAS200, or for another device?
  7. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    Leitec, I thought I saw in one of your other posts that you already JTAGged your WRT54G(?). If you still have that JTAG cable, it might work for this too. You may need a different connector but that should be trivial. Make sure the wiring matches the Xilinx schematics (pin numbers on NAS200 side start at the pin farthest from the speaker):
    • Parallel port pin 2 -> TDI (pin 5)
    • Parallel port pin 3 -> TCK (pin 3)
    • Parallel port pin 4 -> TMS (pin 6)
    • Parallel port pin 5 -> OE* of line driver/latch (HIGH=tri-state)
    • Parallel port pin 13 <- TDO (pin 4)
    • Parallel port pins 18-25 -> GND (pin 2)
    • Line driver VCC <- VCC (pin 1)
    You don't need the transistor and surrounding components from the top of the schematics, just leave parallel port pin 15 disconnected. You can also leave parallel port pin 6 disconnected, the pulldown circuitry for TDO (made with the bottom two line drivers) is not needed. Instead of the 74HC367 you can also use 74HC244 or 74HC573.

    To use JTAG, you will need to pull pin 40 of the CPU HIGH for a short time while you switch the unit on. There's no way that a mere mortal can solder a wire to that pin but fortunately it's connected to pins elsewhere too. The easiest place I found to attach a wire was pin 35 of the unused U26 RAM chip. I simply soldered a short piece of thin stiff wire flat on the board at U26 pin 35 and attached another wire to the VCC pin of my JTAG plug. When I want to JTAG the box, I plug in my JTAG connector and hold the VCC wire against the little piece of wire soldered onto the board while I power up.

    You will need the RDC Loader program from here. Other JTAG tools that I tried, didn't work because they didn't recognize the CPU. Fortunately RDC Loader is a nice tool that's able to do pretty much anything you will want to do.

    Unfortunately there's something funky about the board or about the processor; while it's in real mode, it's executing different instructions than the ones you'll be seeing in the debugger. My initial hypothesis was that it uses the GDT while it's in real mode, but I'm not so sure about that now. There are some unused source files in the Redboot source code that might indicate that there is (or was) a hardware bug involving the CS0 and CS1 chip select lines. Let us know about your progress and I'll see if I can find out more.

    Good luck!


    (who's thinking of maybe purposely re-bricking his box in order to write a JTAG page :) )
  8. mstombs

    mstombs Network Guru Member

    I used a HairyDairyMaid passive cable with an ADSL2MUE which used the WRT54G program in a special mode for Ti AR7 routers. I bought a cheap bufferred JTAG converter from ebay - see item 120222416702 - you can see the 74HC244 in the picture. Circuit I think it could be converted to a wiggler ?, various diy designs here

    But I've never used it!
  9. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    Here's my cable modified from the Xilinx. I actually used a 74HC244 or 74HC573.


    Mstombs, thanks for the links but RDC Loader expects to find the pins of the printer port connected like the Xilinx cable. I would be very surprised if a Wiggler would work.

  10. mstombs

    mstombs Network Guru Member

    Sure - the only significance on Wiggler is that is uses the buffer interface chip - I believe I had the option to use this with the HDM cable (which is a subset of the Xilinx standard), but other JTAG tools for my modem such as Ciclamab needed the Wiggler.

    I'm not too sure what the JTAG standard is - it appears it is only the names of the JTAG pins at the device end - you must use the parallel computer port end that is supported by the software. A pretty definitive guide here
  11. leitec

    leitec LI Guru Member

    Thanks, jac, for the simplified schematic and your sleuthing efforts. Knowing the correct addresses sure helps in recovery! I couldn't find a suitable buffer chip among the ones I have or that stores around me sell, so they're on order off the internet. I'll report back when I put together the adapter.

    As for upgrade mode, I wonder if the upslug2 tool used could be modified to recognize the NAS200. Perhaps I will play with that once I get my NAS200 back to life.

    It sounds like it'll be really easy to come up with alternative firmware for this thing.
  12. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    I think I already mentioned, it's unfortunately really easy to brick your NAS200 from Redboot by typing the Flash command. But the good news is that "flash" only overwrites the Redboot section of the flash ROM. On the NAS200, Redboot doesn't offer any easy way to overwrite the Linux part of your ROM so your Linux is probably okay and you won't need the ugutil or upslug2 tool; once you restore Redboot your box will probably boot fine.

    I definitely think that the NAS200 Redboot has some severe design flaws. In a sensible boot loader, it should be EASY to overwrite everything EXCEPT the boot loader. Instead, this one can ONLY overwrite itself and poses some barriers to overwriting Linux.

  13. leitec

    leitec LI Guru Member

    Oh, that's not the issue; I'm sure the rest of the firmware is intact. I actually would just love a tool like upslug2 to test new firmware and backup good working firmware. It's quite useful to have something that automatically ignores the Redboot part of the flash.

    I really bought the NAS200 with the sole intention of modifying it, not running it for any of its original purposes--similar to my reasoning with my NSLU2. I'm thinking of how to put together a working Debian system, for example, or creating something small and expandable like Unslung based on the original firmware. Hopefully I can get this back to life soon so that I can start development.
  14. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    It sounds like what you want to do is frighteningly close to what I want to do... :rolleyes:

    Hopefully you'll get your system up and running again soon. Like I said, if you need any help let me know.

  15. leitec

    leitec LI Guru Member

    Congrats on the new firmware, Jac. Beat me to it! :) In any case, I got the latch IC in the mail yesterday and put the circuit together on a breadboard; tonight I'll solder the the connectors and hopefully can get RDC loader to work. Thanks again.
  16. leitec

    leitec LI Guru Member

    Hrm. RDC Loader detects the correct CPU, the PCI bus listing lists what I believe are the correct ID's (among them 1095/3512 of the SATA controller) and it looks as though if I set a register it stores the correct value, yet when I try to load a file into memory, every single byte fails the verification. I'm assuming this is a cable issue, so I'll perhaps shorten both ends of the cable. This is on a breadboard, so all sorts of things could be going wrong.

    In any case, I presume a way to recovery is to load redboot.bin, tell the board to execute it, telnet into it, load redboot.bin into the address that the 'flash' command reads from and run it, correct?

    Now if I can just wrap my head around this addressing mess...
  17. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    If RDC loader starts and recognizes the CPU, it works!

    RDC Loader was written for the evaluation board (see Ivan Kuten's website for a picture). Unfortunately the Linksys engineers used different flash ROMs that are not compatible with the RDC loader so you can't flash anything directly to ROM. Sucks huh :frown:

    What you can do however is download a file into RAM by opening a memory window (be careful that you don't close the disassembly window - as far as I can tell there's no way to reopen it :rolleyes:) and right-clicking on it. In the popup menu there's an option to load a file to RAM (sorry I don't know the exact locations and wordings, I'm at work right now). Indeed you will need the redboot.bin which is part of the source tarball if I'm not mistaken. If not, you can use dd to snip the last 128K off a .bin file.

    As far as I can tell, the file is loaded to RAM perfectly fine and the memory and disassembly windows will show you what's there. Of course after the reset you will be in Real mode which means real-mode addressing: physical address = (segment << 4) + offset. The easiest way to keep your brain from exploding is to use segment values that end in three zeroes. 0000:0000=00000 1000:0000=10000 etc.

    Loading registers with values also works great and I believe there too the program does what it's supposed to do.

    The problem is that when you start executing instructions, sometimes the processor executes something completely different from what you see in the disassembly window. I couldn't put my finger on the problem and I never figured out what it was. Basically what I did was single step through the code for a while until I knew that what I was seeing in the disassembly window was actually what the CPU was executing (by checking what was happening to the registers). The CPU starts at F000:FFF0 and there were some random instructions there in my bricked box, but eventually when single-stepping, I ended up in a code segment that was working. I then downloaded the initialization part of Redboot.bin (which is normally stored at F000:FB00) at a known working location in that code segment and single-stepped into it. I eventually was able to get the CPU into protected mode, and then it was just a matter of downloading the 128K of redboot.bin and jumping into the start of it.

  18. leitec

    leitec LI Guru Member

    Unfortunately I actually killed it this time :-/ I thought I'd made a mistake soldering pin 35 of the second memory pads, and I must have shorted something when I tried to resolder. It doesn't power on anymore, so I pitched it.

    At least I tried everything to get it back first! Thanks again for your help.
  19. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member


  20. beatgr

    beatgr Network Guru Member

    IF you still have it, I will pay postage for everything you have, NAS200, power supply, etc.

    beatgr --
  21. Disman_ca

    Disman_ca Super Moderator Staff Member Member

    He already said he pitched it too late.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice