Re: Support for Marvell 88F5xx81 based routers

mpu: Not sure if this is the same issue you're having, but when I tried with revision 14171 make failed after the wrt350nv2-builder returned '164'.After enabling the debugging text in tools/wrt350nv2-builder/src/wrt350nv2-builder.c, it seemed that the image was indeed created, but the non-zero return value caused make to fail.

Simply adding 'return 0;' at the end of main() allowed make to continue. I haven't tried the resulting image yet though, so I don't know whether it works or not.

Re: Support for Marvell 88F5xx81 based routers

dcf: Yeah, that was it! Thanks.

I had a linksys fw 2.00.19 and flashed it with my own image. The flashing seem to went fine (waited long enough) and port lights do blink but I can't telnet to it (brick'em all(tm)?) Well, there's always JTAG. :-I

Re: Support for Marvell 88F5xx81 based routers

mpu wrote:

dcf: Yeah, that was it! Thanks.

I had a linksys fw 2.00.19 and flashed it with my own image. The flashing seem to went fine (waited long enough) and port lights do blink but I can't telnet to it (brick'em all(tm)?) Well, there's always JTAG. :-I

Re: Support for Marvell 88F5xx81 based routers

I have had no succes with my jtag yet. If you manage to get it working i am very interested in how.

Openocd connects to the device fine, however for some strange reason my router wont go into a halt state at all.

I remember some similar problems, what kind of jtag are you using? if you're using one with rst pins, please disable those (openocd.conf) and try again by shorting pin 1 and 3 yourself. That's the "manual" reset state. Good luck with it, if you find yourself around eindhoven someday I maybe able to help you.

Re: Support for Marvell 88F5xx81 based routers

I'm using a DLC5 cable with a jumper on pins 1 and 3. The chip identifies in openocd but it times out when i try to halt it.

I also discovered that connecting a 3v ttl cable causes the chip at U9 (near the jtag connector) to go extremely hot. I had this on 2 wrt350n's. I'd suggest using the dc adapter with the device to power it and leave the 3v line of your serial disconnected.

Re: Support for Marvell 88F5xx81 based routers

dirkNL wrote:

Did you wait for the second reboot as suggested?

Yes, I _think_ so. Waited for over 20 minutes.... Didn't actually check how many times device booted. Noticed one boot because browser refreshed the usual "network not found" message and checked on panel.

Is there a time window that you have to try telnet on when the wrt350n is booting? I'll try today yet again (unfortunately don't have much time to play around with this).

Re: Support for Marvell 88F5xx81 based routers

Hi there,

I tried to flash via serial and tftpboot the mtd0.orig.img like DirkNL described below:

dirkNL wrote:

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.

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.

And also lots of self generated imgaes from trunk with no success.

Most of the images have bad magic numbers or crc failures !?The device does not work with recovery mode, even with ip like in uboot env.Can someone explain to me what Iá¸¿ doing wrong ?Is there any Howto or Wiki for Jtag or and serial flash for doing step by step?

Re: Support for Marvell 88F5xx81 based routers

cmoegele,

in your state you will need to boot uImage kernel with NFS or ramfs support, most likely NFS is the easyist way. From inside the booted uImage with NFS it's possible to flash back the original contents for mt0. Read back a few pages about how we restored my brick, aside from the kernel booting with JTAG the procedure with booting a tftp kernel is very similar.

You'll be able to find those files after you've build for the orion target with OpenWRT trunk in the build_dir/linux-orion/ directory.

It's all from the top of my head so double check everything before you start flashing Just one last tip: stay away from the u-boot mtd space at any time! It'll be alot more difficult to restore once you've screwed that up...

Re: Support for Marvell 88F5xx81 based routers

generate image with this option and tftpboot 0x40000 as you have already done.

Once the router is running from ram you can write a squashfs image to flash.

(You'll be able to find those files ( 2 ) after you've build for the orion target with OpenWRT trunk in the build_dir/linux-orion/ directory.dd if=wrt350nv2-uImage of=/dev/mtdblock0 dd if=root.squashfs of=/dev/mtdblock1 as dirNLk wrote)

Re: Support for Marvell 88F5xx81 based routers

cmoegele wrote:

<SNIP>And then you will be happy with a very fast router

br

cm

Hey, just wondering, how is the WiFi working out? I cant stand the stock linksys firmware. Have you checked out the throughput of LAN-LAN file transfers through gigabit? Is it atleast as quick as the linksys firmware?

Also, anyone wanna help a dude out and upload an image I can flash with the Linksys web config? Do I have to bribe someone with Paypal? I'd do almost anything for a version of WRT that has a web interface and is precompiled for this router...

Re: Support for Marvell 88F5xx81 based routers

Hello everyone It's been a while since the last time I joined this discussion... Meanwhile I've managed to screw my first device up quite thoroughly, doing a few nasty hardware experiments. Recently I've got a brand new working one, and I'm doing my best to keep it working (at least to get to u-boot prompt). I hope it will survive the 128mb upgrade I'm gonna do sometime next week )I've noticed there seems to be a bit of confusion about flashing images into the device, so - at least for those with working serial connection and u-boot prompt access - here's quite a safe way to flash anything you want, it's really just a few simple u-boot commands:

This little code will burn any file you want directly to the flash, starting from address 0. In u-boot the flash is mapped to 0xff800000 address, so using correct offset you can boot things elsewhere as well. There are just a few things to watch out for:- you should never EVER write anything above 0x7fc000 even if you by any chance need to overwrite u-boot - this area contains u-boot configuration and some signatures, if you corrupt this area u-boot will get stuck in the mac-address communication mode and you won't get access to prompt (not a complete disaster yet, it's still possible to recover without jtag from this)- you should almost never write anything above 0x7c0000 address in flash either - that's u-boot code area and you don't need to rewrite this unless you want to upgrade/hack u-boot (for example to get rid of the annoying "ercomm" signature check at the end of rootfs which is actually quite simple)- you should be VERY careful while erasing or overwriting the 64k sector starting at 0x750000 (hence the 0xfff4ffff boundary in the erase above) - u-boot considers this to be the last sector of kernel/rootfs partitions, and checks the end of this sector for 'eRcOmM' signature. If it's not there, again you will get stuck before u-boot prompt and the only way to recover without jtag is a special software communicating with router directly over low-level ethernet (mac addresses and other nasty stuff). I've managed to get it working once, in a very hardcoded and limited way, if someone's interested (or desperate enough), I can supply the source code for further refinement.Other than the 3 points above, there's really not much to screw up. If you stay inside flash address range 0 to 0x74ffff, you will always be able to get to u-boot prompt and reflash your device again.Another little feature I found quite helpful was removing the kamikaze/target/linux/orion/patches/010-ignore-atag-cmdline.patch - this patch prevents kernel from accepting custom parameters from u-boot, so it will always start with the compiled-in command line regardless of the value of u-boot's 'bootargs' variable. If you remove it, you can control kernel startup with this variable, making it for example capable to mount rootfs directly from usb drive. This is actually a nice little trick, as you can load the kernel over tftp each time, mounting USB root, and you can experiment without reflashing anything at all. And when playing with patches, it's also nice to reconfigure default openwrt mtd table to something like:

- this way you will have a little more place for root (0x1a0000 gives you about 1.7mb for kernel, which I personally never managed to overrun), and you can be sure that even by direct /dev/mtdblock1 or 2 rewriting from linux you won't screw up the rootfs signature.If you want to gain additional space for root, you can patch uboot to ignore the signature (I can supply a do-it-yourself-no-guarantee-at-all patch if someone feels brave enough) and get additional 3x64k sectors, and even use the nvram space (which you don't need in openwrt anyway) and gain another 2x64k... not much, but it's nice if you want to squeeze a lot of packages inside without USB drive, or if you need larger jffs partition.Well, that was quite enough for one post I believe, now it's time for lunch I'm experiencing some problems with wifi network in 14384 svn checkout, but I'll get to that later.Regards,

Please PM me if you can provide additional information, so I can update this post.

Attention! It is NOT recommended to do this stuff without having a serial connection or JTAG connection to the router! Do flashing at your own risk!

To build OpenWRT just login with root and a normal user in parallel into the build environment, then follow the instructions of the Building OpenWrt HowTo (or here in the old wiki).For older revisions you can add webupgrade image (before r18761 plus fix from r18794) and sysupgrade support (before r19166).Place the patch files directly in the normal user's home directory (~).The property changes have to be applied manually, maybe you have to apply some code changes manually too (the code is always under development).

--> "make menuconfig" will tell if more packages have to be installed via APT by the root user (parallel login).--> Change the target to "Marvell Orion", for temporary testing set the target image to "ramdisk".--> Add the modules to the image (="*") that are required to access the internet, so OpenWrt can retrieve further packages. Be careful, do not make your package too big, only the essentials are necessary, all other stuff can be added later.--> If you don't use a 192.16.1.0/24 net, then you may change the configuration of the image to fit your network.--> If for any reason you want to compile everything again, then run "make distclean" to compile from scratch

After compilation the build can be found in the bin folder.

Loading the build into the router via serial console and TFTP--> Download the build from the virtual machine to the real computer (e.g. via WinSCP).--> Setup the serial connection to the router, start the console (115200,8,N,1; e.g. via Putty) to listen on the serial port, power up the router and interrupt the boot process by pressing enter in the console.--> Temporary change the envvars with setenv to fit your network. You can apply the changes permanently with saveenv (not recommended).

setenv ipaddr 10.0.0.99
setenv serverip 10.0.0.1

--> Start a tftp server on your computer (e.g. tftpd32 on windows) and point it to your copy of the bin folder.

In the console you can now load and start the ramdisk image with

tftpboot "openwrt-wrt350nv2-uImage"
bootm

After booting you can telnet to 192.168.1.1 (e.g via Putty).Setup a password for root to enable SSH access. This also disables telnet.

[s]Remember the caveats mentioned by DirkNL.[/s] (Wifi/W-LAN, LAN port #4, USB is working; please do stability and performance tests before using it in a production environment).Several people report instabilities for wireless/WLAN/Wifi after running it for several days. These can normally be avoided by a daily restart as described in post #751.

For a web interface install the package "webif", or "luci-admin-mini" plus "luci-admin-full" with "luci-theme-openwrt".

For getting back to the stock firmware check out DirkNL's posting here and here plus Pregi's posting here.

There's even a recovery method for the WRT350Nv2 without any gadgets: 'download mode'.The update via download mode was described by drizzt81 in post #436 and DaBigMac created a HowTo for setting the router into download mode in post #524.

Hope these guides will help to get more people into testing.Maddes

Changelog:* 2009-02-26: webupgrade image build working, repositories, luci information* 2009-02-28: bigger HD needed for all packages, added DirkNL's warnings* 2009-03-01: temporary change the U-Boot config to fit the network, how to get back to stock firmware* 2009-03-05: updated Building Kamikaze HowTo with a bell/beep/alert, when make finishes* 2009-03-23: splitted the webupgrade patch into a general part and an often changed part (tools/Makefile)* 2009-03-31: adjusted wiki links to server change* 2009-07-04: corrected links, added info about kernel size issue* 2009-08-03: kernel is now below 1MB, [s]mtd patch is just for a nicer mtd map[/s]* 2009-08-31: updated instructions to most current sysupgrade support and webupgrade mtd patch is necessary for sysupgrade support* 2009-11-29: added links to 'download mode' recovery method* 2009-12-13: webupgrade image is now in trunk (added in r18761, fixed in r18794)* 2010-01-16: sysupgrade support is now in trunk (added in r19166)* 2010-01-17: package "luci-theme-openwrt" was not mentioned for luci* 2010-02-02: package "luci-admin-mini" was not mentioned for luci* 2010-04-05: added info about wireless instabilities after several days plus link to solution* 2010-06-13: fixed wiki links for HowTos