I'll propably buy one from U.S. by using ebay when openwrt is up and running on this hardware, some dealers there seem to be shipping worldwide, although, then it's version 1.0 - btw. what kind of power currency is used in U.S. ? In Finland we have 230 volts..

if you know someone in France, just know that every "Fnac" reseller where i went still sell the box...
(you have to know that the WT350n have been only put on the french market on november 2007...)

http://micro-informatique.fnac.com/a216 … 1&Fr=0

but in france it's very expansive, due to taxe

(Last edited by neb on 13 Oct 2008, 16:14)

I know exactly how you feel - just found out today that probably noone in Slovakia sells them anymore and it's just a little over 2 months as I bought the first one.
But that's not why I'm writing here, again. I found out that JTAG communication with an ARM processor is "just a little bit" different than with MIPS. I'll have to study it a bit. For now I've managed to get OpenOCD to detect the Marvell processor and initialize successfully, but I'm stuck again on the "halt" command - it times out every time. My modified openocd.cfg:

telnet_port 4444
gdb_port 3333

# interface
interface ft2232
ft2232_layout oocdlink
ft2232_vid_pid 0x0403 0x6010
ft2232_device_desc "Dual RS232 A"

jtag_speed 0x3E8
jtag_nsrst_delay 200
jtag_ntrst_delay 200

reset_config trst_and_srst separate trst_push_pull srst_push_pull

jtag_device 4 0x1 0xffffffff 0x07926041

#target feroceon little 0
target create 88f5181 feroceon -endian little
targets

flash bank cfi 0xff800000 0x00800000 1 1 0

init

Output with no debug after initialization:

NightWolf@toaster-m4/c/Installs/Hardware/JTAG/openocd/1041/src$ ./openocd
Open On-Chip Debugger 1.0 (2008-10-13-14:41) svn:1041M


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
jtag_speed: 1000
    CmdName    Type       Endian     ChainPos State
--  ---------- ---------- ---------- -------- ----------
 0: 88f5181    feroceon   little            0 unknown
Info:   JTAG device found: 0x07926041 (Manufacturer: 0x020, Part: 0x7926, Version: 0x0)
Error:  unknown EmbeddedICE version (comms ctrl: 0x00000018)
Warning:no tcl port specified, using default port 6666

- I have no idea what the EmbeddedICE version error means.
Output from following halt command:

Info:   accepting 'telnet' connection from 0
Error:  timed out while waiting for target halted
Runtime error, file "command.c", line 436:

If I turn on debug mode and don't call "poll off" right after the "init" command I get a neverending loop:

Debug:   167 733 jtag.c:1117 jtag_build_buffer(): fields[0].out_value: 0x00000004
Debug:   168 736 jtag.c:1117 jtag_build_buffer(): fields[1].out_value: 0x01
Debug:   169 739 jtag.c:1117 jtag_build_buffer(): fields[2].out_value: 0x00
Debug:   170 741 ft2232.c:1347 ft2232_execute_queue(): DR scan, 38 bit, end in 8
Debug:   171 744 jtag.c:1117 jtag_build_buffer(): fields[0].out_value: 0x00000004
Debug:   172 747 jtag.c:1117 jtag_build_buffer(): fields[1].out_value: 0x04
Debug:   173 749 jtag.c:1117 jtag_build_buffer(): fields[2].out_value: 0x00
Debug:   174 752 ft2232.c:1347 ft2232_execute_queue(): DR scan, 38 bit, end in 8
Debug:   175 773 jtag.c:1151 jtag_read_buffer(): fields[0].in_value: 0x00000004

And then something very similar after "halt":

Info:    171 8703 server.c:84 add_connection(): accepting 'telnet' connection from 0
Debug:   173 10195 command.c:82 script_command(): script_command - halt
Debug:   174 10197 command.c:99 script_command(): script_command - halt, argv[0]=ocd_halt
Debug:   175 10199 target.c:1789 handle_halt_command(): -
Debug:   176 10201 arm7_9_common.c:979 arm7_9_halt(): target->state: running
Debug:   177 10203 embeddedice.c:403 embeddedice_write_reg(): 0: 0x00000002
Debug:   178 10204 jtag.c:1117 jtag_build_buffer(): fields[0].out_value: 0x00000002
Debug:   179 10206 jtag.c:1117 jtag_build_buffer(): fields[1].out_value: 0x00
Debug:   180 10208 jtag.c:1117 jtag_build_buffer(): fields[2].out_value: 0x01
Debug:   181 10210 ft2232.c:1347 ft2232_execute_queue(): DR scan, 38 bit, end in 8
Debug:   182 10211 jtag.c:1117 jtag_build_buffer(): fields[0].out_value: 0x00000004
Debug:   183 10213 jtag.c:1117 jtag_build_buffer(): fields[1].out_value: 0x01
Debug:   184 10215 jtag.c:1117 jtag_build_buffer(): fields[2].out_value: 0x00
Debug:   185 10217 ft2232.c:1347 ft2232_execute_queue(): DR scan, 38 bit, end in 8
Debug:   186 10219 jtag.c:1117 jtag_build_buffer(): fields[0].out_value: 0x00000004
Debug:   187 10220 jtag.c:1117 jtag_build_buffer(): fields[1].out_value: 0x04
Debug:   188 10222 jtag.c:1117 jtag_build_buffer(): fields[2].out_value: 0x00
Debug:   189 10225 ft2232.c:1347 ft2232_execute_queue(): DR scan, 38 bit, end in 8
Debug:   190 10253 jtag.c:1151 jtag_read_buffer(): fields[0].in_value: 0x00000004
Debug:   191 10255 target.c:1769 target_wait_state(): waiting for target halted...
Debug:   192 10257 jtag.c:1117 jtag_build_buffer(): fields[0].out_value: 0x00000004
Debug:   193 10259 jtag.c:1117 jtag_build_buffer(): fields[1].out_value: 0x01
Debug:   194 10261 jtag.c:1117 jtag_build_buffer(): fields[2].out_value: 0x00
Debug:   195 10263 ft2232.c:1347 ft2232_execute_queue(): DR scan, 38 bit, end in 8
Debug:   196 10265 jtag.c:1117 jtag_build_buffer(): fields[0].out_value: 0x00000004
Debug:   197 10267 jtag.c:1117 jtag_build_buffer(): fields[1].out_value: 0x04
Debug:   198 10268 jtag.c:1117 jtag_build_buffer(): fields[2].out_value: 0x00
Debug:   199 10270 ft2232.c:1347 ft2232_execute_queue(): DR scan, 38 bit, end in 8
Debug:   200 10291 jtag.c:1151 jtag_read_buffer(): fields[0].in_value: 0x00000004
...............
Error:   1506 15220 target.c:1776 target_wait_state(): timed out while waiting for target halted
Debug:   1507 15222 command.c:407 run_command(): Command failed with error code -4
User:    1508 15225 command.c:607 openocd_jim_vfprintf(): Runtime error, file "command.c", line 436:
User:    1509 15227 command.c:607 openocd_jim_vfprintf():

I'll have to study the ARM JTAG specification a lot deeper to understand this... Meanwhile, any help would be welcome
I'm going back to documentation, good night everyone.

Rel

(Last edited by relghuar on 13 Oct 2008, 20:49)

relghuar, have you read buytenh's post about the jtag port on the wrt350n? This might save you a lot of time.

Of course I have read his posts - I'm watching this thread very closely Only with his help have I been able to make the JTAG work. The architecture is a lot different from MIPS jtag I'm used to from broadcom chips, so I made a few mistakes in the beginning, but I'm slowly getting through. I'm already talking to the chip, as can be seen from the openocd logs I've sent here. TMS/TDI are swapped, TRST/SRST are set correctly, processor is providing it's IDCODE (even after instruction scan - the IDCODE for ARM is 0x0e instead of MIPS 0x01 ). Now the only problem is to talk to it in the right way, or perhaps just to configure the openocd correctly. I have to find out what all the values from my debug logs actually mean. With a little help from http://infocenter.arm.com/help/index.js … 42747.html it should be just a matter of time. Of course if someone would recognize the problem right away and point me in the right direction, the time could be considerably shorter ;-) That's why I'm posting my progress here along the way...

Aside from the swapped TDI and TMS pins we didn’t have any trouble halting the target. I tried to connect it with an ft2232 device but without any luck. I ran into similar problems with that. The simple parallel DLC5 JTAG cable solved this problem but I don’t think that’s any good to you.

I thought of something that might just work, if you setup OpenOCD to use _no_ reset function of the JTAG key whatsoever and pull the TRST pin high.

See, that was exactly what I meant The ft2232 OOCDLink is the only JTAG adapter I have, and without a parallel port I couldn't really test a dlc5 cable.
With "reset_config none" and a simple short between pins 1 and 3 the adapter works like a charm! Thanks a lot for the advice - processor halted OK, I've just dumped a few leading words from flash memory (0xff800000) in gdb, and they're exactly what they should be... Tomorrow I'll try to put the kernel into RAM.
Now I only have to find out why the router won't boot with fully programmed flash

glad I could help.

I would suggest to do the same as I and dump the current contents of your flash, to do that:

halt
arm7_9 fast_memory_access enable
dump_image currentflash.img 0xff800000 0x00800000

If you find those nasty eRcOmM bits missing in the dump you'll know why it stopped working if you managed to break your u-boot you'll have to do some more work. You need to do all sorts of settings on the target before being able to run u-boot, RAM settings and such sort.

OK, I think I found my problem each X..X+0x7f block contains the same data as X+0x80..X+0xff - address pin A6 on the flash must have gone bad by soldering. Hopefully nothing permanent, I'll look into it tomorrow.
Thanks again for the help with JTAG, dirk

I don't believe the content of flash chip is damaged - I have programmed it myself and verified many times. Problem is that with A6 pin always set to 0 processor simply can't access every second block of 0x80 bytes of flash memory (just duplicates the previous one instead), which certainly doesn't make him happy

My router boots from flash!!!
Well, almost... Actually it freezes in U-Boot, but it's quite a progress since I soldered it off the board.
Serial console shows some nvram problems:

         __  __                      _ _
        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ V /  __/ | |
        |_|  |_|\__,_|_|    \_/ \___|_|_|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__|  ** LOADER **
 ** MARVELL BOARD: RD-88F5181L-VOIP-GE LE

U-Boot 1.1.1 (Dec 12 2006 - 16:12:22) Marvell version: 1.7.3

DRAM CS[0] base 0x00000000   size  32MB
DRAM Total size  32MB
Flash: mvFlashInit base 0xff800000 devW 1 busW 1
Flash: flashStructGet manu 0xec id 0xe0
Flash: flashStructGet flash is supported.
FLASH: initFlashSecs TOP Sector Type
Flash: flashSecsInit main sector loop 0 - 127
[8192kB@ff800000] Flash:  8 MB
Addresses 20M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (20M - 16M): Done
*** Warning - bad CRC, using default environment


Soc: MV88F5181 Rev 9
CPU: ARM926 (Rev 0) running @ 500Mhz
SysClock = 166Mhz , TClock = 166Mhz


USB 0: host mode
PCI 0: PCI Express Root Complex Interface
PCI 1: Conventional PCI, speed = 33000000
Net:   mvEgigaLoad: egiga0 load ok
egiga0 [PRIME]

***************DRIVER INFO*****************

DRIVER BUILD DATA: Jan  9 2007 at 18:25:44
DRIVER VERSION 1.06

*******************************************
dbSign is:65:52:63:4f:6d:4d
mac address in flash is:00:00:00:00:00:00
have eRcOmM
no node address

mvEgigaInit: egiga0 init - mvBoardPhyAddrGet()=0x0 , priv->port =0x0
ring full
mvEgigaInit: egiga0 complete ok
In Assign function

Apparently he can't get MAC address, though it really puzzles me as the flash image is fully identical with original Linksys WRT350Nv2-ETSI-2.00.17 firmware - I dumped whole 8MB through JTAG/gdb chain and it's perfect match, just as I expected.
I tried to check the freezing code in linksys sources, but the Assign function is stored in board/mv88fxx81/sercomm/upgrade.o file, and there's no source for it. I'm really not looking forward to disassembling it
I've also tried to boot kernel from RAM over JTAG, but the original Linksys kernel won't come up, it didn't even write anything to the console. I'll try it one more time, and then I'll compile a new one from kernel.org, hopefully I'll have more luck with that.
Does anyone know how the original flashing procedure actually works? Linksys firmware is simply a compressed full 8MB flash image, I thought it would be enough to overwrite whole flash with it. Obviously that's not enough to get U-Boot to start...

I've uploaded the stock flash contents for you, so not build from Linksys sources but really stock from the flash. It's the same dump I used to bring back my WRT to life. I only used the mtd0 part because I knew my u-boot wasn't screwed, but I've uploaded all other partitions as well. Maybe it'll help.

mtd0.img (kernel+rootfs)
mtd1.img (rootfs)
mtd2.img (lang)
mtd3.img (nvram)
mtd4.img (u-boot)

Because of the overlapping mtd0 and mtd1 you only need to use the contents of mtd0 and mtd2 through mtd4.

If you could post your image contents I can have a look and maybe find out what's missing, but I doubt you can't fix it with the images provided here.

Hello Dirk
Thanks for the images. I've also used the stock firmware - 2.00.17 to be precise (the same you've posted from what I can tell). Your kernel+rootfs and lang images are exactly the same as mine full-image.bin, the only difference in u-boot is some kind of checksum at the end. Main difference is the nvram segment - in the stock image it's completely blank (all 0), while yours contains quite a lot of settings. I suppose the original flashing routine either does not overwrite that part, or generates new data after the stock image is flashed.
I have some problems writing to flash from openocd (flash probe always tries to access it in word mode?? probably wrong openocd.cfg). If I set "flash bank cfi 0xff800000 0x00800000 1 1 0", the "flash probe 0" always fails. On the other hand, with "flash bank cfi 0xff800000 0x00800000 1 2 0" the memory is detected with 128k/16k sectors and addresses up to 16MB There's probably nothing wrong with the flash itself, as calling the right mwb/mdb sequences manually behaves correctly - I've even managed to erase both nvram sectors... I'll get back to it tomorrow, now I really need some sleep.
Good night.

You're getting quiet a lot more out of flash/openocd as we did, but after being able to boot a kernel with openocd we figured it wasn't going to be much of help anyway. The next time I'm gonna play around with the device I will try some more in OpenOCD and post back my findings. This could take a while as I'm now just waiting for openwrt to have full wrt350n support in their trunk.

I'M IN!!! Router booted fully, web interface works, wifi works. Serial console's not reacting to input, but I suppose that's a serial adapter/cable issue rather than router itself.
Problems with OpenOCD and flash unfortunately remained, I suppose they're caused by the 8bit flash access used on the board. Based on source code and debug outputs I assume OOCD is not quite ready to deal with 8bit CFI memories, as the 16bit access addresses are hardcoded in the flash/cfi.c module. The only way to get correct addresses is configuring the bus width 2 - unfortunately that corrupts cfi-autodetected block addresses/sizes, and probably also screws up following flash chip control sequences.
In the end I decided to have a little fun and write my own little flash programmer (thanks to Yagarto arm-toolchain), loaded it to ram over jtag, loaded necessary images into ram as well, and let processor do the dirty work It was quite interesting, and it's also pretty fast. I expect I could get a whole 8MB image into RAM in under 5 minutes and then write it to flash in about a minute - not bad for a pure JTAG connection (I needed more time just to get 128k bootloader into the broadcom MIPS system).
I'll put the box back together, get the serial connection fully working and hopefully I can start playing with openwrt by weekend.
Thanks again to everyone here - mainly dirk, striker and buytenh for help with jtag and firmware images

Rel

(Last edited by relghuar on 15 Oct 2008, 20:12)

Excellent work Rel! Actually show far it has been a pleasure to follow this thread as web is full of threads where people have similar problems - but so rarely things end up with any good Indeed it seems that you've really put a really lot on this.

Good luck.

hi
i previously flashed my wrt350n v2.1 with linksys firmware 2.00.19 and bricked it.
can someone explain how to burn stock firmware or openwrt image via u-boot and tftp from ram to flash?

regards

(Last edited by pregi on 16 Oct 2008, 19:25)

If you're 100% sure you've bricked it you'll need at least a serial connection to your device, possibly a JTAG connection as well. If this at all sounds difficult to you, you're in for a rough ride...

I would suggest to read this thread thoroughly, mainly the posts from striker, buytenh and myself, the path relghuar had chosen to fix his device is a bit more hardcore and most likely not necessary for you.

To give you some kind of information to start with:
-Device uses a 3.3v TTL Serial connection (see openwrt wiki for pinout)
-Device uses a std ARM JTAG 20p connection, with the TDI and TMS pins swapped
-OpenOCD currently doesn't support the flashchip in u-boot

Some starting points:
-Create serial link
-Try to boot a kernel in u-boot with root-nfs support
-flash your device inside of this nfs root

hi
i got working serial connection and ethernet, also jtag if i need it
but i need more info about booting kernel images from ram to flash the device
there are just a few sites on the net about this device :-(

regards

(Last edited by pregi on 16 Oct 2008, 22:40)

please read at least the last 3-4 pages

Try to figure out what's wrong with you device, begin with posting your serial output, we'll build up from there on...

         __  __                      _ _
        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ V /  __/ | |
        |_|  |_|\__,_|_|    \_/ \___|_|_|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__|  ** LOADER **
 ** MARVELL BOARD: RD-88F5181L-VOIP-GE LE

U-Boot 1.1.1 (Dec 12 2006 - 16:12:22) Marvell version: 1.7.3

DRAM CS[0] base 0x00000000   size  32MB
DRAM Total size  32MB
Flash: mvFlashInit base 0xff800000 devW 1 busW 1
Flash: flashStructGet manu 0xec id 0xe0
Flash: flashStructGet flash is supported.
FLASH: initFlashSecs TOP Sector Type
Flash: flashSecsInit main sector loop 0 - 127
[8192kB@ff800000] Flash:  8 MB
Addresses 20M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (20M - 16M): Done
*** Warning - bad CRC, using default environment


Soc: MV88F5181 Rev 9
CPU: ARM926 (Rev 0) running @ 500Mhz
SysClock = 166Mhz , TClock = 166Mhz


USB 0: host mode
PCI 0: PCI Express Root Complex Interface
PCI 1: Conventional PCI, speed = 33000000
Net:   mvEgigaLoad: egiga0 load ok
egiga0 [PRIME]

***************DRIVER INFO*****************

DRIVER BUILD DATA: Jan  9 2007 at 18:25:44
DRIVER VERSION 1.06

*******************************************
dbSign is:65:52:63:4f:6d:4d
mac address in flash is:00:1d:7e:ad:37:dc
have eRcOmM
Hit ENTER to stop autoboot:  0
copy kernel from 0xff800000 to 0x400000 with size 0x200000
## Booting image at 00400000 ...
   Image Name:   Linux-2.6.12-arm1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1510872 Bytes =  1.4 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
Marvell>>

kernel image has bad crc so it refuses to boot :-/

EDIT:
ok got it working again
booted your mtd0 image kernel from 0x400000 and flashed again via linksys webinterface
got this error

CodeReal: invalid data
SQUASHFS error: lzma_fs error while decompressing!
SQUASHFS error: Unable to read page, block 60d70, size 3d1c

but it works from flash :-D

(Last edited by pregi on 16 Oct 2008, 23:49)

My path was extremely hardcore, and is definitely not necessary for anyone anymore since buytenh got the JTAG working on wrt350n-v2 - though I might have to do it again soon on a friend's asus wl500g premium v1, as it doesn't seem to have jtag pins at all...

People, the Orion chips require "reset_config srst_only" in OpenOCD!!! I know, because I'm the one who submitted the patch to it (r950) that made it work.

Hi all, great work!

Where can I find the WRT350Nv2 support? Is it everything included in the openwrt trunk svn tree?
Or do I have to follow StrikerNL's steps as described in http://forum.openwrt.org/viewtopic.php?pid=68981#p68981 ?

A lot of questions, but I'm willing to give it a try (and have a serial and jtag cable ready just in case ;-)

Not yet, it's close though.

2.6.27 is not in the trunk yet so some support is missing. As soon as this is done (which is not up to me and DirkNL), you can give it a shot. We just replaced the kernel with 2.6.27 ourselves.

The latest status:

- wifi is not completely working yet (AP mode, as someone pointed out, does not seem to work yet)
- there are some problems with the switch driver, it works, but performance is not up to par yet

Other than that, everything is done.