OpenWrt Forum Archive

Topic: Support for Marvell 88F5xx81 based routers

The content of this topic has been archived between 18 Jan 2014 and 6 May 2018. Unfortunately there are posts – most likely complete pages – missing.

Ah that's great news!

Is the image builder somewhere available and where can I find the SVN server?
I have some embedded Linux expirience, and I'll try to help with the port to the WRT350N.

What problems did you hit? It should work without problems (although we still have to fixup the mach id for the kernel).

I didn't had any problems, as I don't know where to download...

Is 802.11n working?

@lexi
kaloz was referring to strikers previous post I guess.
No n support so far.

*update (forgot about the imagebuilder)
It's ready, I'll set it up somewhere this weekend
We're using the Git repos with some patches, as described by StrikerNL in an earlier post.
I guess you can also use the repos from Openwrt since Kaloz has integrated most of the patches in the latest svn.


@kaloz

we did see the missing machID but that was easily fixed. But there are some other issues.

The openwrt repos uses a different version of squashfs (3.0), our development kernel has got 3.3 support. So for starters the rootfs isn't transparent. But then again in the end it's the idea to build a fully working image with the openwrt builder, so we started using that kernel as well.

The openwrt kernel does boot, but fails to map it's flash. I'm writing this off the top of head, but I think it failed to find the entire flashdevice. After that I recall alot of errors about the /proc not being found, but that's to blame to the flash device not being found.

I'm planning to give it another look this weekend, so I'll keep you posted

(Last edited by dirkNL on 13 Jun 2008, 01:12)

@lexi: check https://dev.openwrt.org

@dirk: sounds good. if you give me a dmesg, I can tell more.. I think I've forgot the CFI patch, I'll add that when I woke up, it's late here.. smile

I also try to look into this during the weekend.. if you send me the image builder and stuff, I integrate those as well.

Dirk forgot some points. This is also from memory, but I recall /dev being empty. I had to create /dev/console (and some other devices) myself to get the output of the device booting.

I'll post a dmesg later today.

(Last edited by StrikerNL on 13 Jun 2008, 11:59)

As promised, this weekend’s update:

"Short version"

-Openwrt rootfs is able to boot, but some modifications are needed
-Somehow wifi isn't able to scan for wireless networks
-imagebuilder problems


"The long version"

It took a while to get there, but now I know what was missing/or wrong in the openwrt tree.

Mach-ID:
I noticed the mach-id patch was somehow integrated in svn. But it is applied to the uImage of the kernel whereas our patch is applied to the zImage of the kernel before the kernel itself generates the uImage. Because I don't know the details on how the uImage and zImage are generated I also tested "the openwrt" way. When trying to boot such a kernel (via tftp 0x40000) the bootloader protests with the following message:

Marvell>> bootm 0x40000
## Booting image at 00040000 ...
Bad Magic Number
Marvell>>

To fix this problem I applied our own mach-id patch to the arch/arm/boot/Makefile again, after that the arch/arm/boot/uImage is a proper kernel.

MTD/Flashmap:
The next thing not properly configured was the flashmap, because the .config for the kernel is generated from the openwrt menu I changed it after I ran "make" for the first time and then ran "make" again.
For the wrt350n to work these options need to be set: (kernel config available @ link)

Device drivers->MTD->
[*]   MTD partitioning support
[ ]     Automatically set 'rootfs' partition to be root filesystem
[ ]     Automatically split 'rootfs' partition for squashfs
< >     RedBoot partition table parsing
[ ]     Command line partition table parsing
< >     ARM Firmware Suite partition parsing
< >     TI AR7 partitioning support
    *** User Modules And Translation Layers ***
<*>   Direct char device access to MTD devices
-*-   Common interface to block layer for MTD 'translation layers'
<*>   Caching block device access to MTD devices

Yes to Device drivers->MTD->ROM/RAM/Flash chip drivers->Support for AMD/Fujitsu flash chips   (intel support can be turned off)

Device drivers->MTD->Mapping drivers for chip access->
    <*> CFI Flash device in physical memory map
    (0xf0000000) Physical start address of flash mapping
    (0x0) Physical length of flash mapping
    (1)   Bank width in octets

All other options in the MTD menus can be turned off

Along with the kernel options I changed the partitioning of the wrt350n-v2-setup.c file back to its original state, being:

static struct mtd_partition wrt350n_v2_nor_flash_partitions[] = {
        {
                .name           = "kernel",
                .offset         = 0x00000000,
                .size           = 0x00760000,
        }, {
                .name           = "rootfs",
                .offset         = 0x001a0000,
                .size           = 0x005c0000,
        }, {
                .name           = "lang",
                .offset         = 0x00760000,
                .size           = 0x00040000,
        }, {
                .name           = "nvram",
                .offset         = 0x007a0000,
                .size           = 0x00020000,
        }, {
                .name           = "u-boot",
                .offset         = 0x007c0000,
                .size           = 0x00040000,
        },
};

I only did this to be able to switch back to linksys sources whenever necessary. Once fully supported by openwrt I also want proper partitioning. Still for every first flash of the wrt350n you will always need an initial flash image. This has to be build the same way linksys builds its images, once openwrt is running you can easily upgrade with the openwrt generated images.

Because I used the original mappings, I also changed the boot settings to boot from root=/dev/mtdblock1 instead of root=/dev/mtdblock2

Network (eth0) support:
I noticed we completely forgot to mention anything about the modifications needed for eth0 support in our previous posts, so here it is.
First use the latest mv643xx_eth sources or patches from http://marc.info/?l=linux-netdev&m=121325378302191&w=2 / http://git.marvell.com/?p=mv643xx_eth.git;a=shortlog
Then change this rule in your wrt350n-v2-setup.c

static struct mv643xx_eth_platform_data wrt350n_v2_eth_data = {
        .phy_addr       = -1,
};

becomes

static struct mv643xx_eth_platform_data wrt350n_v2_eth_data = {
        .phy_addr       = MV643XX_ETH_PHY_NONE,
};

Wifi problem:
I don't know why, but with the openwrt kernel and rootfs we're unable to scan for wireless networks. dmesg and iwconfig show the wifi0 device, also the kernel modules for madwifi scanning seem to be loaded. The only difference I can see is that we had to build madwifi using gcc 3, and openwrt tree uses gcc 4 per default. Maybe this is something to look into.

Image builder:
We're having some issues with our own imagebuilder at the moment. The images build by it are not identical to those build by linksyss imagebuilder. So for now it's best to stick with their way of creating images to flash from the webinterface. source available here look in the WRT350N-EU_V2.00.19/source_code/binfile directory

*update about imagebuilder:
It seems we can’t even build an image from our openwrt uImage and root.squashfs using the Linksys tools. If we try to load such an image into the webinterface it throws an error about "wrong format image" . If we replace the openwrt rootfs with the Linksys rootfs tough, we can upload the image through the webinterface. It’ll fail to boot because of incompatible squashfs version but it loads…

On a sidenote, the patches about the eth interface will probably be included in the 2.6.27 stock kernel, so we only need those patches now, but not in the future.

(Last edited by dirkNL on 16 Jun 2008, 00:53)

Thanks for the heads up, I merge these tomorrow. smile

Some updates. It seems we have built a working image!

The mksquashfs-lzma needs to be called with these additional arguments: -noI -no-fragments, so in include/image.mk this line

$(STAGING_DIR_HOST)/bin/mksquashfs-lzma $(TARGET_DIR) $(KDIR)/root.squashfs -nopad -noappend -root-owned $(SQUASHFS_OPTS)

Becomes

$(STAGING_DIR_HOST)/bin/mksquashfs-lzma $(TARGET_DIR) $(KDIR)/root.squashfs -nopad -noappend -root-owned -noI -no-fragments $(SQUASHFS_OPTS)

Without this, the Linksys firmware will not accept the image.

Also, it seems the image needs to be padded to be a certain size for the Linksys firmware to accept the image. The 'original' openwrt img that we built was 1.7 MB. The Linksys rejects this straight away (very quick, so it's almost definitely a simple filesize check on the uploaded image). We padded the rootfs.squash to be almost as large as the stock rootfs.squash. This was achieved like so:

In image.mk, just before mksquashfs-lzma is called, I inserted these lines:

                dd if=/dev/urandom of=$(TARGET_DIR)/bin/aaa bs=1000000 count=1
                dd if=/dev/urandom of=$(TARGET_DIR)/bin/bbb bs=1000000 count=1
                dd if=/dev/urandom of=$(TARGET_DIR)/bin/ccc bs=1000000 count=1

3 MB seemed to do it, maybe less is also OK, I haven't experimented with this.

In any case, this leads to an image that's flashable from the stock firmware. This leaves you with 3 MB of garbage data on the root.squashfs though, so maybe this should just be an initial flashing method. Maybe Kaloz has a better idea about this.

Finally, as Dirk said, our own imagebuilder has some problems still, one part of it anyway. So we're using Linksys's binaries which we don't have the source of, but work. Of course we'd like to have this replaced my image builder to which we'd have the source, but it's not quite there yet. There's something with regard to a checksum being put in that I haven't quite figured out yet. I'll go into more detail if anyone's interested and can help (that would be great!)

I've fixed the machid setup, added amd flash support and physmap, also backported the ethernet driver changes from git.. It seems however that

static struct mv643xx_eth_platform_data wrt350n_v2_eth_data = {
        .phy_addr       = -1,
};

is correct, still.

Wifi: I guess this can be related to the fact that we are using a different HAL now.

squashfs: seems to be weird, I try to find why it even cares about the content..

image genertion: I think the utility should do the padding.. it's not problematic, on first boot the space after squashfs will be erased anyways.. also, if you could upload/send me your image generation utility, maybe we can spot the bug sooner

I recall lennert saying something about the phy_addr to be set to none because there is a switch attached to the chip. But it's probably best to wait for full chip/switch support before jumping to conclusions.

(Last edited by dirkNL on 16 Jun 2008, 16:58)

Kaloz wrote:

squashfs: seems to be weird, I try to find why it even cares about the content..

It's the Linksys firmware, for some reason it does check the content of the rootfs (and the size of the image itself).

Kaloz wrote:

image genertion: I think the utility should do the padding.. it's not problematic, on first boot the space after squashfs will be erased anyways..

I imagine you mean the padding that I did with the dd /dev/urandom line? I guess that'd be possible. It's now zero padded, could easily be changed by changing /dev/zero to /dev/urandom padded in makebin.sh

Kaloz wrote:

also, if you could upload/send me your image generation utility, maybe we can spot the bug sooner

Sure, here it is: http://ddcrew.com/wrt350n/imagebuilder.tar.gz

I'll explain the important bits. Unpack this somewhere and insert the uImage as 'uImage' and the root.squashfs as 'rootfs.squash'.

There's three steps to building an image.

1) The uImage, root.squashfs and u-boot.bin get concatenated together with some bytes in between (a checksum of sorts) as a .bin file.
2) This .bin is then zipped, and some bytes from wrt350n.pid and some static bytes get appended & prepended
3) Finally the contents of the output of step 2 are used to get an md5 sum (with a salt appended) and this md5 sum is put into the file from step 2 at a static address (0x1E0)

Now the image is ready for flashing.

These are the interesting files in the .tar.gz

buildimage.sh
Used to create an image using the linksys tools only. The old way.

newbuildimage.sh
Used to create an image using my tools only. The new way.

comparetest.sh
Uses both ways, first creates one with the linksys tool, then with my tool, then compares the .bin (after step 1), and gives a warning if they don't match (this warning happens a lot now, which is the problem).

Then there are these scripts/programs

makebin.sh and linksys's equivalent mipsBind
This does step 1. Mine almost seems to work, except I print the bytes statically and a few seem to change between every .bin. This is most likely the checksum being referred to, however I have not figured out what this checksum is or how it is calculated. This is our problem. The rest works, only a few bytes that I have in makebin.sh are incorrect, they need to be calculated, but how?

makeimg.sh and linksys's equivalent scimg
This does step 2. Seems to work just fine.

md5hash.sh and linksys's equivalent md5encrypt
This does step 3. Seems to work just fine.

Finally there are

wrt350n.pid
This file only seems to get injected in the image in step 2, no need to change it.

wrt350n.par
Seems to be used to define where the root.squashfs, uImage and u-boot.bin go in the img, no need to change it.

Would be nice to figure the makebin.sh problem out, because then we can throw the linksys binaries out.

(Last edited by StrikerNL on 16 Jun 2008, 17:38)

Another update. Imagebuilder (seems) done.

Kaloz and someone I don't know the name of yet have figured out what mipsBind does and I have written a tool together with Dirk to replace it. That means we now have our own working (or at least it seems to...) imagebuilder. No more Linksys binaries! smile

These are the new files that can be added to the imagebuilder.tar.gz in the previous post:

http://ddcrew.com/wrt350n/calcsum.c (compile it as calcsum)

http://ddcrew.com/wrt350n/makebin.sh (replace the old one with this new one)

juhosg is the one who figured it out, I was only the proxy on this one smile

I rewrote the buildimg shellscripts from StrikerNL into c, available here

See the readme for details

The code can use some optimization, but it gets the work done. If anyone is interested in doing the optimization, be my guest and post it back here when you're done.

Hello,

I've just ordered a wrt350n (should be v2) and plan to put openwrt on it. I've never done that before, but I'm not afraid as I have a pretty good knowledge of the GNU/Linux world and some basics in electronics (but I'd rather not use it wink). I've checked out the svn trunk and successfully built an orion image, which gets nicely packaged with dirkNL's buildimg from the post above.

Now the big question: can I go ahead and flash it (once I get my router, which should be today)? I mean, has the openwrt svn everything that has been discussed in this thread or do I need to apply some more patches or make some manual manipulations? In other words, can the work on this model be considered "done" wrt the latest svn revision?

Also, are there any special options absolutely needed in the kernel config (apart from the obvious)? For example, I've removed ipw2100 and ipw2200, as my thought is that we'll use madwifi. Any reason it was enabled by default?

BTW, thanks for all the work done! cool

I *think* all the important patches are in there now, however, the two important things that I know of that are missing/non-functional are:

- Support for the switch (i.e. you'll end up with an AP instead of a router for now)
- The wifi didn't seem to work yet when we last tried

Other than that, pretty much everything seems to work. Good luck!

Hi zorglab,

Welcome to the club ;]

Aside from what striker points out I should warn you about flashing the openwrt image. Because we have a serial console attached to the device we are able to restore or set anything we like, including its ip address. I don't remember if the stock flash sets up an ip address straight away. It should as its included in the openwrt image builder, but I just can’t remember.

We’re going to test this and let you know if you’re good to go.

Thanks for the replies. So my first objective would be to investigate how to easily go back to an official firmware. This is what's written in the troubleshooting section of the manual:

13. The firmware upgrade failed, and/or the Power LED is flashing.
    The upgrade could have failed for a number of reasons. Follow these steps to upgrade the firmware and/or
    make the Power LED stop flashing:
    • If the firmware upgrade failed, use the TFTP program (it was downloaded along with the firmware). Open
       the pdf that was downloaded along with the firmware and TFTP program, and follow the pdf’s
       instructions.
    • Set a static IP address on the PC; refer to "Problem #2, I need to set a static IP address."  Use the following
       IP address settings for the computer you are using:
       IP Address: 192.168.1.50
       Subnet Mask: 255.255.255.0
       Gateway: 192.168.1.1
    • Perform the upgrade using the TFTP program or the Administration tab of the Router’s web-based utility.

Is it correct to assume the router will set its ip address to 192.168.1.1 on reset and wait for a tftp connection for some time? Anyway, this is the first thing I'll try.

As for the switch, this is indeed annoying. In the linksys sources, there seems to be some kind of "driver" handling the 88E6131 (according to the README), lying in the source_code/src/kernel/linux-88fxx81L-1_8_5/arch/arm/mach-mv88fxx81/Board/QD-DSDT_2.5 directory. Could we do something with that?

dirkNL: thanks for testing. I'll wait for your advice before trying to brick my device smile.

Some bad news I guess

I tried to flash an image generated from openwrt with my buildimg tool, but the GUI from linksys doesn't accept it.
I compared the output from my tool and linksys's tool, but they were identical.

So we have to dig into this before you can have a go. I'm a little shy on spare time but we'll do what we can.

Figured it's worth posting an update after 9 days...

Apparently the imagebuilder is fine, well, the mechanics of it anyway. The problem is in the minizip implementation that is used in Dirk's c image builder. It doesn't seem to create compatible zip files. It did once or a few times in the past during tests, however it's clearly not working as well as it should be. For now it's probably easiest to use my older shell script imagebuilder since that simply relies on the zip binary being available on the system. Using that always builds correct images.

Having built a root.squashfs and uImage using the latest openwrt svn, I found out you need to adjust the .par to conform to the flashmap as defined in the openwrt sources by Kaloz. Use this:

:uImage      &000000
:rootfs.squash   &0ffff0
:u-boot.bin  &7bfff0
%wrt350n.pid &7fffff &75ffe0
$SIZE        &2000

This should leave you with a working flashable image.

Word of warning: while attempting to figure out a way to return to original linksys firmware without using the serial console, we semi-bricked the wrt350n, probably by overwriting something that u-boot needs. We no longer have a working u-boot, so now Dirk is attempting to fix this using JTAG. The thing to take away from this is, do not expect to be able to return to linksys firmware for now without having access to the serial console!

(Last edited by StrikerNL on 14 Jul 2008, 00:31)

Ok, thanks to both.

Unfortunately, I was quite busy the last days and I will be away the following two weeks. But after that, I hope to be able to work more seriously on the matter.
I've looked a little bit for a RS232-TTL cable, but didn't find one (I don't like buying on the internet). I might try again when I'm back.

Status update, more of the bad news…

It’s not going to well with my JTAG recovery, I don’t seem to get it connected with openocd.
I began with trying to connect to the device using the unbuffered XilinX DC5 parallel JTAG. Openocd reports it cannot get the JTAG chain build, so I figured it was the lack of a proper JTAG cable.

I then got myself the JTAGkey-TINY from Amontec. I read about it on many howtos and figured it should work with this key. Unfortunately  I’m still not getting anywhere with my wrt350n.

This is the configuration I used for openocd:

# daemon config
telnet_port 4444
gdb_port 3333
#daemon_startup reset

# interface
jtag_speed 0
interface ft2232
ft2232_layout "jtagkey"
ft2232_vid_pid 0x0403 0xcff8
ft2232_device_desc "Amontec JTAGkey A"

# use combined on interfaces or targets that can't set TRST/SRST separately
reset_config srst_only
#reset_config trst_and_srst

# jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe

#jtag_nsrst_delay 500
#jtag_ntrst_delay 500

# target configuration
# target <type> <endianess> <reset_mode>
# if chain_pos is not zero it seg faults
#target arm926ejs little reset_init 0
target feroceon little reset_init 0
run_and_halt_time 0 30
#working_area 0 0xc8010000 0x400 nobackup

init

This is the config used with revision 838 and higher of openocd, notice the daemon_startup commented and the "init"  rule at the bottom. That’s about the only difference in config for the newer revision. I’ve tried revision 335 799 838 and 845 so far, but the all give me similar output.

Output:

skvalpe ~ # openocd -d 3
Open On-Chip Debugger 1.0 (2008-07-19-22:33) svn:838
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
Debug:   4 0 configuration.c:85 find_file(): found openocd.cfg
Debug:   6 0 command.c:72 script_command(): script_command - telnet_port
Debug:   7 0 command.c:85 script_command(): script_command - telnet_port, argv[0]=ocd_telnet_port
Debug:   8 0 command.c:85 script_command(): script_command - telnet_port, argv[1]=4444
Debug:   10 0 command.c:72 script_command(): script_command - gdb_port
Debug:   11 0 command.c:85 script_command(): script_command - gdb_port, argv[0]=ocd_gdb_port
Debug:   12 1 command.c:85 script_command(): script_command - gdb_port, argv[1]=3333
Debug:   14 1 command.c:72 script_command(): script_command - jtag_speed
Debug:   15 1 command.c:85 script_command(): script_command - jtag_speed, argv[0]=ocd_jtag_speed
Debug:   16 1 command.c:85 script_command(): script_command - jtag_speed, argv[1]=0
Debug:   17 1 jtag.c:1859 handle_jtag_speed_command(): handle jtag speed
User:    18 1 command.c:334 command_print(): jtag_speed: 0, 0
Debug:   20 1 command.c:72 script_command(): script_command - interface
Debug:   21 1 command.c:85 script_command(): script_command - interface, argv[0]=ocd_interface
Debug:   22 1 command.c:85 script_command(): script_command - interface, argv[1]=ft2232
Debug:   24 1 command.c:72 script_command(): script_command - ft2232_layout
Debug:   25 1 command.c:85 script_command(): script_command - ft2232_layout, argv[0]=ocd_ft2232_layout
Debug:   26 1 command.c:85 script_command(): script_command - ft2232_layout, argv[1]=jtagkey
Debug:   28 1 command.c:72 script_command(): script_command - ft2232_vid_pid
Debug:   29 1 command.c:85 script_command(): script_command - ft2232_vid_pid, argv[0]=ocd_ft2232_vid_pid
Debug:   30 1 command.c:85 script_command(): script_command - ft2232_vid_pid, argv[1]=0x0403
Debug:   31 1 command.c:85 script_command(): script_command - ft2232_vid_pid, argv[2]=0xcff8
Debug:   33 1 command.c:72 script_command(): script_command - ft2232_device_desc
Debug:   34 1 command.c:85 script_command(): script_command - ft2232_device_desc, argv[0]=ocd_ft2232_device_desc
Debug:   35 1 command.c:85 script_command(): script_command - ft2232_device_desc, argv[1]=Amontec JTAGkey A
Debug:   37 1 command.c:72 script_command(): script_command - reset_config
Debug:   38 1 command.c:85 script_command(): script_command - reset_config, argv[0]=ocd_reset_config
Debug:   39 1 command.c:85 script_command(): script_command - reset_config, argv[1]=srst_only
Debug:   41 1 command.c:72 script_command(): script_command - jtag_device
Debug:   42 1 command.c:85 script_command(): script_command - jtag_device, argv[0]=ocd_jtag_device
Debug:   43 1 command.c:85 script_command(): script_command - jtag_device, argv[1]=4
Debug:   44 1 command.c:85 script_command(): script_command - jtag_device, argv[2]=0x1
Debug:   45 1 command.c:85 script_command(): script_command - jtag_device, argv[3]=0xf
Debug:   46 1 command.c:85 script_command(): script_command - jtag_device, argv[4]=0xe
Debug:   48 1 command.c:72 script_command(): script_command - target
Debug:   49 1 command.c:85 script_command(): script_command - target, argv[0]=ocd_target
Debug:   50 1 command.c:85 script_command(): script_command - target, argv[1]=feroceon
Debug:   51 1 command.c:85 script_command(): script_command - target, argv[2]=little
Debug:   52 1 command.c:85 script_command(): script_command - target, argv[3]=reset_init
Debug:   53 1 command.c:85 script_command(): script_command - target, argv[4]=0
Warning: 54 2 target.c:1431 handle_target_command(): reset_mode argument is deprecated. reset_mode = reset_run
Debug:   55 2 feroceon.c:655 feroceon_target_command(): chain_pos: 0, variant: (null)
Debug:   57 2 command.c:72 script_command(): script_command - run_and_halt_time
Debug:   58 2 command.c:85 script_command(): script_command - run_and_halt_time, argv[0]=ocd_run_and_halt_time
Debug:   59 2 command.c:85 script_command(): script_command - run_and_halt_time, argv[1]=0
Debug:   60 2 command.c:85 script_command(): script_command - run_and_halt_time, argv[2]=30
Debug:   62 2 command.c:72 script_command(): script_command - init
Debug:   63 2 command.c:85 script_command(): script_command - init, argv[0]=ocd_init
Debug:   64 2 openocd.c:91 handle_init_command(): target init complete
Debug:   65 2 ft2232.c:1374 ft2232_init_ftd2xx(): 'ft2232' interface using FTD2XX with 'jtagkey' layout (0403:cff8)
Debug:   66 280 ft2232.c:1463 ft2232_init_ftd2xx(): current latency timer: 2
Debug:   67 281 ft2232.c:1729 jtagkey_init(): 80 08 1b
Debug:   68 282 ft2232.c:1787 jtagkey_init(): 82 09 0f
Debug:   69 283 ft2232.c:253 ft2232_speed(): 86 00 00
Debug:   70 292 openocd.c:98 handle_init_command(): jtag interface init complete
Debug:   71 292 jtag.c:1534 jtag_init_inner(): Init JTAG chain
Debug:   72 292 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   73 292 jtag.c:1293 jtag_reset_callback(): -
Debug:   74 293 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   75 293 jtag.c:1293 jtag_reset_callback(): -
Error:   76 295 jtag.c:1349 jtag_examine_chain(): JTAG communication failure, check connection, JTAG interface, tar                                          get power etc.
Error:   77 295 jtag.c:1553 jtag_init_inner(): trying to validate configured JTAG chain anyway...
Debug:   78 295 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   79 295 jtag.c:1293 jtag_reset_callback(): -
Error:   80 297 jtag.c:1442 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x3                                          f
Debug:   81 307 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   82 307 jtag.c:1293 jtag_reset_callback(): -
Error:   83 309 jtag.c:1442 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x3                                          f
Debug:   84 319 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   85 319 jtag.c:1293 jtag_reset_callback(): -
Error:   86 321 jtag.c:1442 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x3                                          f
Debug:   87 331 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   88 331 jtag.c:1293 jtag_reset_callback(): -
Error:   89 333 jtag.c:1442 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x3                                          f
Debug:   90 343 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   91 343 jtag.c:1293 jtag_reset_callback(): -
Error:   92 345 jtag.c:1442 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x3                                          f
Debug:   93 355 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   94 355 jtag.c:1293 jtag_reset_callback(): -
Error:   95 357 jtag.c:1442 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x3                                          f
Error:   96 357 jtag.c:1562 jtag_init_inner(): Could not validate JTAG chain, exit
Debug:   97 357 jtag.c:1578 jtag_init_reset(): Trying to bring the JTAG controller to life by asserting TRST / TLR
Debug:   98 357 jtag.c:995 jtag_add_reset(): SRST line released
Debug:   99 357 jtag.c:1002 jtag_add_reset(): JTAG reset with TLR instead of TRST
Debug:   100 357 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   101 357 jtag.c:1293 jtag_reset_callback(): -
Debug:   102 357 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   103 357 jtag.c:1293 jtag_reset_callback(): -
Debug:   104 357 jtag.c:991 jtag_add_reset(): SRST line asserted
Debug:   105 357 jtag.c:1002 jtag_add_reset(): JTAG reset with TLR instead of TRST
Debug:   106 358 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   107 358 jtag.c:1293 jtag_reset_callback(): -
Debug:   108 358 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   109 358 jtag.c:1293 jtag_reset_callback(): -
Debug:   110 358 jtag.c:991 jtag_add_reset(): SRST line asserted
Debug:   111 358 jtag.c:995 jtag_add_reset(): SRST line released
Debug:   112 358 ft2232.c:1004 jtagkey_reset(): trst: 0, srst: 0, high_output: 0x09, high_direction: 0x0f
Debug:   113 358 ft2232.c:1004 jtagkey_reset(): trst: 0, srst: 1, high_output: 0x01, high_direction: 0x0f
Debug:   114 358 ft2232.c:1004 jtagkey_reset(): trst: 0, srst: 1, high_output: 0x01, high_direction: 0x0f
Debug:   115 358 ft2232.c:1004 jtagkey_reset(): trst: 0, srst: 0, high_output: 0x09, high_direction: 0x0f
Debug:   116 358 jtag.c:1534 jtag_init_inner(): Init JTAG chain
Debug:   117 358 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   118 358 jtag.c:1293 jtag_reset_callback(): -
Debug:   119 359 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   120 359 jtag.c:1293 jtag_reset_callback(): -
Error:   121 361 jtag.c:1349 jtag_examine_chain(): JTAG communication failure, check connection, JTAG interface, ta                                          rget power etc.
Error:   122 361 jtag.c:1553 jtag_init_inner(): trying to validate configured JTAG chain anyway...
Debug:   123 361 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   124 361 jtag.c:1293 jtag_reset_callback(): -
Error:   125 363 jtag.c:1442 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x                                          3f
Debug:   126 373 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   127 373 jtag.c:1293 jtag_reset_callback(): -
Error:   128 375 jtag.c:1442 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x                                          3f
Debug:   129 385 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   130 385 jtag.c:1293 jtag_reset_callback(): -
Error:   131 387 jtag.c:1442 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x                                          3f
Debug:   132 397 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   133 397 jtag.c:1293 jtag_reset_callback(): -
Error:   134 399 jtag.c:1442 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x                                          3f
Debug:   135 409 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   136 409 jtag.c:1293 jtag_reset_callback(): -
Error:   137 411 jtag.c:1442 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x                                          3f
Debug:   138 421 jtag.c:324 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug:   139 421 jtag.c:1293 jtag_reset_callback(): -
Error:   140 423 jtag.c:1442 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x                                          3f
Error:   141 423 jtag.c:1562 jtag_init_inner(): Could not validate JTAG chain, exit
Debug:   142 423 openocd.c:113 handle_init_command(): flash init complete
Debug:   143 423 openocd.c:117 handle_init_command(): NAND init complete
Debug:   144 423 openocd.c:121 handle_init_command(): pld init complete
Debug:   145 423 gdb_server.c:2024 gdb_init(): gdb service for target feroceon at port 3333
Warning: 146 423 tcl_server.c:178 tcl_init(): no tcl port specified, using default port 6666
Debug:   148 424 command.c:72 script_command(): script_command - init
Debug:   149 424 command.c:85 script_command(): script_command - init, argv[0]=ocd_init

As this is the thread with more people owning a wrt350n I was hoping someone could try and set up a JTAG connection with his device. Be it with the amontec key or any other key, something to prove that I’m not wasting my time here…

Any help is much appreciated.

(Last edited by dirkNL on 22 Jul 2008, 14:13)

Hello, Im not an expert at this stuff. Actually I've never used JTAG ;-) Although when searching the internet I found these interesting pages:

* JTAG Adapter
* Tornado's JTAG router unbrick software

I hope this is usefull for unbricking the 350Nv2. I'm sorry if it is not usefull to your project. Keep up the good work!

I did some more research and it turns out Torando's EJTAG software would not help us because it doesn't support the Marvell CPU...

Sorry for that misleading information. When searching the internet I found some information at the Sparkfun forum. There seems to be someone who has the same system board as the one located in the WRT-350n V2. He tried flashing this board by using JTAG. It turns out he also got stuck in the beginning, but with some help he finally was able to connect to his system board. The link is: flashing marvell feroceon 88f5181

His configuration is as follows:

#daemon configuration 
telnet_port 4444 
gdb_port 3333 

#interface 
interface parport 
parport_port 0x378 
parport_cable wiggler 
#parport_cable old_amt_wiggler 
jtag_speed 1 

# use combined on interfaces or targets that can't set TRST/SRST separately 
reset_config srst_only 
#reset_config trst_and_srst 


# jtag scan chain 
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE) 
jtag_device 4 0x1 0xf 0xe 

#jtag_nsrst_delay 500 
#jtag_ntrst_delay 500 

# target configuration 
# target <type> <endianess> <reset_mode> 
# if chain_pos is not zero it seg faults 

#target arm926ejs little reset_init 0 
target feroceon little reset_init 0 
run_and_halt_time 0 30 

#working_area 0 0xc8010000 0x400 nobackup 

# flash configuration 
# flash bank <driver> <base> <size> <chip_width> <bus_width> [driver_options ...] 
flash bank cfi 0xff800000 0x800000 1 1 0 jedec_probe

But the flash chip still isn't corretly detected sad. I hope this helps. Good luck.

(Last edited by Briefcase on 26 Jul 2008, 02:40)

Sorry, posts 126 to 125 are missing from our archive.