Re: Support for Marvell 88F5xx81 based routers

if it fails with an error about staging_dir/host/etc "no such file or directory" do a 'mkdir staging_dir/host/etc'

the webupgrade should just be uploaded through the webupgrade utility (found under administration), see why it's called a webupgrade?!?

Still this upgrade can just fail or don't work at all. We've worked out all the errors the webinterface is throwing us. But sometimes it just looks as if it accepts the img, but doesn't flash it...

Due to lack of time I won't be looking into this issue shortly, but hey, it's opensource so anyone could try and figure it out.

277

Re: Support for Marvell 88F5xx81 based routers

dirkNL: Yes, figured 'etc' directory problem out myself=D. It fails in the final webimage generation right after make prints xx% deflated for the img file. Thanks anyway for the reply:]

278

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.

279

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 sad (brick'em all(tm)?) Well, there's always JTAG. :-I

280

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.

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 sad (brick'em all(tm)?) Well, there's always JTAG. :-I

Did you wait for the second reboot as suggested?

Re: Support for Marvell 88F5xx81 based routers

Mavy wrote:

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.

283

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

Mavy wrote:

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.

Could you try and connect openocd, don't halt it, but connect with gdb to the remote target? you need an arm-target based gdb build for that.

285

Re: Support for Marvell 88F5xx81 based routers

I'll try that tonight. But if i remember correctly connecting gdb caused openocd to spam not halted warnings and loading something to memory would just fail.

286

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

mpu wrote:

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).

No timewindow, but because of some flashcleaning up I let the router reboot itself after the cleaning process. So in all it should reboot twice, but without any assistence from your end.

When it's done you should be able to connect to it using telnet on the 192.168.1.1 address. If not I'm affraid you've got your first brick in the wall

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.

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.

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?

Or can someone do me a favour and flash my board ? I will pay for it.

Thx

Best regards

Best rtegards

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.

To boot a tftp kernel, go to the u-boot console "press enter to stop autoboot"
> tftp 0x400000 your.uImage.bin
> bootm 0x400000

Re: Support for Marvell 88F5xx81 based routers

Thx for help dirkNL!

My failure was the wrong tftp values, and wrong image.

Now with ramdisk compiled img, I could run openwrt from ram:

>tftpboot 0x400000 uImage.img
>bootm


But now I have problems to write any image to the flash :

> wget http://server-ip/squashfs
> mtd -r write squashfs kernel

brings always errors.

Can this problem be caused because of missing mtd?

> cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00010000 "kernel"
mtd1: 005c0000 00010000 "rootfs"
mtd4: 00040000 00010000 "u-boot"

everywhere in the post there are mtd0 - mtd4 described.

Re: Support for Marvell 88F5xx81 based routers

Seems to me your mtd map isn't correct. It might be easiest to use the values used by OpenWRT.

Look for the file

arch/arm/mach-orion/wrt350n_setup.c (something like that) in you kernel sources.

If you boot a kernel with those values, you'll be able to flash OpenWRT right away, no need to restore to stock or anything else. Unless ofcourse that's what you want to do right now...

I'm gonna asume you want to flash OpenWRT, if so, just use dd to flash your mtd.

dd if=wrt350nv2-uImage of=/dev/mtdblock0
dd if=root.squashfs of=/dev/mtdblock1

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 wink 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

Hi friends I must thank you all for your great help!

Especially DirkNL, your my hero!!!! big_smile

Once you will visit Germany, you can come to me and we will drink some beer or something else together, perhaps at Oktoberfest in Munich ;-)

After nearly 2 months, many very short nights, I have learned a lot linux basics and finally got openwrt to my router wink

Now its time to test performance and stability of this goodie!


Thx

cmoegele

293 (edited by heji 2009-02-09 16:35:30)

Re: Support for Marvell 88F5xx81 based routers

i tiy tftp my uImage. and bootm but get jffs error.

|  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ 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 128MB 
DRAM Total size 128MB 
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:cc:08
have eRcOmM 
Hit ENTER to stop autoboot:  0 
Marvell>> 
Marvell>> tftp 0x400000 openwrt-wrt350nv2-uImage
mvEgigaInit: egiga0 init - mvBoardPhyAddrGet()=0x0 , priv->port =0x0
ring full
mvEgigaInit: egiga0 complete ok
Using egiga0 device
TFTP from server 172.21.5.30; our IP address is 172.21.5.10
Filename 'openwrt-wrt350nv2-uImage'.
Load address: 0x400000
Loading: #################################################################
         #################################################################
         #################################################################
         #########
done
Bytes transferred = 1043236 (feb24 hex)
Marvell>> bootm
## Booting image at 00400000 ...
   Image Name:   Linux-2.6.28.4
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1043172 Bytes = 1018.7 kB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux..................................................................... done, booting the kernel.
Linux version 2.6.28.4 (heji@heji-desktop) (gcc version 4.1.2) #2 Mon Feb 9 19:23:52 CST 2009
CPU: Feroceon [41069260] revision 0 (ARMv5TEJ), cr=a0053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Linksys WRT350N v2
Clearing invalid memory bank 0KB@0xffffffff
Clearing invalid memory bank 0KB@0xffffffff
Clearing invalid memory bank 0KB@0xffffffff
Ignoring unrecognised tag 0x00000000
Ignoring unrecognised tag 0x00000000
Ignoring unrecognised tag 0x00000000
Ignoring unrecognised tag 0x41000403
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: root=/dev/mtdblock1 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 init=/etc/preinit
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 127600KB available (1928K code, 144K data, 96K init)
Calibrating delay loop... 332.59 BogoMIPS (lpj=1662976)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 476 bytes
NET: Registered protocol family 16
Orion ID: MV88F5181L-Rev-A1. TCLK=166666667.
Applying Orion-1/Orion-NAS PCIe config read transaction workaround
PCI: bus0: Fast back to back transfers disabled
pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot
pci 0000:01:00.0: PME# disabled
PCI: bus1: Fast back to back transfers enabled
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
squashfs: version 3.0 (2006/03/15) Phillip Lougher
Registering mini_fo version $Id$
JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
msgmni has been set to 249
io scheduler noop registered
io scheduler deadline registered (default)
Serial: 8250/16550 driver2 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 3) is a 16550A
console [ttyS0] enabled
MV-643xx 10/100/1000 ethernet driver version 1.4
mv643xx_eth smi: probed
net eth0: port 0 with MAC address 00:00:00:00:51:81
physmap platform flash device: 00800000 at f4000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
physmap-flash.0: Swapping erase regions for broken CFI table.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Using physmap partition information
Creating 3 MTD partitions on "physmap-flash.0":
0x00000000-0x00100000 : "kernel"
0x00100000-0x00750000 : "rootfs"
mtd: partition "rootfs" set to be root filesystem
split_squashfs: no squashfs found in "physmap-flash.0"
0x007c0000-0x00800000 : "u-boot"
i2c /dev entries driver
TCP westwood registered
NET: Registered protocol family 17
Distributed Switch Architecture driver version 0.1
eth0: detected a Marvell 88E6131 switch
dsa slave smi: probed
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0x9062 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004: 0x542b instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000008: 0x5663 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000000c: 0xce7e instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x52c1 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000014: 0x332c instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000018: 0x37c0 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000001c: 0x69e7 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000020: 0x3ce3 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000024: 0x45da instead
Further such events for this erase block will not be printed
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010000: 0x8379 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010004: 0xa513 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010008: 0x8e16 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001000c: 0x7df0 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010010: 0x43f6 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010014: 0x21b3 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010018: 0x1e17 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001001c: 0x441f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010020: 0x0e45 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010024: 0xfffb instead
Further such events for this erase block will not be printed
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020000: 0xa485 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020004: 0x37fe instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020008: 0x9bf9 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0002000c: 0xd4ef instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020010: 0xe5e5 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020014: 0xebbe instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020018: 0xcfd2 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0002001c: 0x7be9 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020020: 0xfa27 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020024: 0x77c2 instead
Further such events for this erase block will not be printed
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030000: 0x729c instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030004: 0x05bb instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030008: 0x9f81 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0003000c: 0x9d05 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030010: 0xaaca instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030014: 0x1026 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030018: 0xdab4 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0003001c: 0x23e7 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030020: 0x9816 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030024: 0x040d instead
Further such events for this erase block will not be printed
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040000: 0xfb8b instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040004: 0x5f89 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040008: 0xda89 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0004000c: 0x4e22 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040010: 0x036b instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040014: 0x5df1 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040018: 0x24da instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0004001c: 0x81fc instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040020: 0x662d instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040024: 0x2df7 instead
Further such events for this erase block will not be printed
Old JFFS2 bitmask found at 0x000453e0
You cannot use older JFFS2 filesystems with newer kernels
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050000: 0xea30 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050004: 0xea28 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050008: 0xca38 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0005000c: 0x7502 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050010: 0xe50a instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050014: 0x28ae instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050018: 0x4ea3 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0005001c: 0xcea0 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050020: 0x9455 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050024: 0x9454 instead
Further such events for this erase block will not be printed
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060000: 0x081a instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060004: 0xf117 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060008: 0x708d instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0006000c: 0x0dd1 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060010: 0x78ca instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060014: 0x395c instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060018: 0x7fec instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0006001c: 0x67e5 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060020: 0x714b instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060024: 0xbe51 instead
Further such events for this erase block will not be printed
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070000: 0x07ec instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070004: 0x2c03 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070008: 0xfd91 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0007000c: 0xc07e instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070010: 0x2b80 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070014: 0xec8f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070018: 0x07ec instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0007001c: 0x9407 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070020: 0xec94 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070024: 0x03f6 instead
Further such events for this erase block will not be printed
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0009fff0: 0x4900 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000a0000: 0x7368 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000a0004: 0x0269 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000a0008: 0x7357 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000a000c: 0x2ca0 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000a0010: 0xd4f8 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000a0014: 0xcfb4 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000a0018: 0xf1ac instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000a001c: 0x0003 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000a0020: 0x2d04 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000a0024: 0x0351 instead
Further such events for this erase block will not be printed
Empty flash at 0x000a0070 ends at 0x000a0074
Old JFFS2 bitmask found at 0x000aea74
You cannot use older JFFS2 filesystems with newer kernels
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000b0000: 0xcf3a instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000b0004: 0xde66 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000b0008: 0x16e4 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000b000c: 0xadd6 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000b0010: 0xaa5b instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000b0014: 0xb142 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000b0018: 0x68f0 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000b001c: 0x8f1f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000b0020: 0xaaaf instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000b0024: 0x471a instead
Further such events for this erase block will not be printed
Old JFFS2 bitmask found at 0x000bf818
Empty flash at 0x00536218 ends at 0x0053621c
Empty flash at 0x0053623c ends at 0x00536240
Empty flash at 0x00536260 ends at 0x00536264
Empty flash at 0x005362b4 ends at 0x005362b8
Empty flash at 0x005362d8 ends at 0x005362dc
Empty flash at 0x00536300 ends at 0x00536304
Empty flash at 0x00536324 ends at 0x00536328
Empty flash at 0x00536348 ends at 0x0053634c
Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes
empty_blocks 0, bad_blocks 0, c->nr_blocks 101
VFS: Cannot open root device "mtdblock1" or unknown-block(31,1)
Please append a correct "root=" boot option; here are the available partitions:
1f00            1024 mtdblock0 (driver?)
1f01            6464 mtdblock1 (driver?)
1f02             256 mtdblock2 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1)

Re: Support for Marvell 88F5xx81 based routers

hi heji,

make menuconfig and in target image select ramdisk

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)

And then you will be happy with a very fast router smile

br

cm

Re: Support for Marvell 88F5xx81 based routers

cmoegele wrote:

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

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

That's an interesting though actually, is the webif^2 package going to work? It should right, it's not a binary.. or is it?? hmm

I never really thought about it.. has anyone tried it?

Re: Support for Marvell 88F5xx81 based routers

Hello everyone smile
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 smile)
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:

tftpboot 0x400000 <filename>
erase 0xff800000 0xfff4ffff
protect off 0xff800000 0xfff4ffff
cp.b 0x400000 0xff800000 0x750000

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 wink 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:

0x00000000-0x00750000 : "kernel"
0x001a0000-0x00750000 : "rootfs"
0x00750000-0x007c0000 : "donttouch"
0x007c0000-0x00800000 : "u-boot"

- 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 smile I'm experiencing some problems with wifi network in 14384 svn checkout, but I'll get to that later.
Regards,

Rel

Re: Support for Marvell 88F5xx81 based routers

DaBigMac wrote:

That's an interesting though actually, is the webif^2 package going to work? It should right, it's not a binary.. or is it?? hmm

I never really thought about it.. has anyone tried it?

Yes Webif^2 (xwrt) and LUCI is working well I tried both images and my favorite is Luci, because its pretty fast.

Best regards

cm

299 (edited by heji 2009-02-23 12:03:32)

Re: Support for Marvell 88F5xx81 based routers

sata_via 0000:01:07.0: routed to hard irq line 4
Unable to handle kernel paging request at virtual address 0010042a
pgd = c6cf4000
[0010042a] *pgd=06d06031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1]
Modules linked in: sata_via(+) ipt_REJECT xt_TCPMSS ipt_LOG xt_multiport xt_mac xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables ppp_async ppp_generic slhc libata crc_ccitt
CPU: 0    Not tainted  (2.6.28.6 #3)
pc : [<bf013b70>]    lr : [<bf00f030>]    psr: 20000093
sp : c6d1fc2c  ip : c6d1fc40  fp : c6d1fc3c
r10: bf07e1b4  r9 : c6c95630  r8 : 00000000
r7 : 00000000  r6 : c6c9562c  r5 : 00000000  r4 : c7888000
r3 : 0000000a  r2 : 0010042a  r1 : c6d2a9e0  r0 : c7888000
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: a005317f  Table: 06cf4000  DAC: 00000015
Process insmod (pid: 2259, stack limit = 0xc6d1e260)
Stack: (0xc6d1fc2c to 0xc6d20000)
fc20:                            c7888000 c6d1fc50 c6d1fc40 bf00f030 bf013b54 
fc40: a0000013 c6d1fc64 c6d1fc54 bf00f074 bf00effc c7888000 c6d1fc94 c6d1fc68 
fc60: bf004734 bf00f058 c6d1fc90 c780e0e4 bf015e7c c6c9562c 00000024 00000080 
fc80: c6d1e000 bf07de3c c6d1fcc4 c6d1fc98 bf00a754 bf004524 c780e000 c780e058 
fca0: c780e0e4 c780e000 c780e058 00000004 c6c9562c 00001d1c c6d1fd0c c6d1fcc8 
fcc0: bf07d7d0 bf00a73c bf07de3c c6d1fcd8 c02eefdc c02efd2c bf07ded0 bf07ded0 
fce0: bf07deec c6d1fcf1 bf07de04 c780e000 c780e058 bf07ddd0 00000000 000615c7 
fd00: c6d1fd30 c6d1fd10 c0303548 bf07d2c8 c780e058 c780e104 c780e058 bf07de04 
fd20: c0406398 c6d1fd50 c6d1fd34 c031ad10 c03034f8 c780e058 c780e104 bf07de04 
fd40: c6d1fd70 c6d1fd6c c6d1fd54 c031ae4c c031ac48 00000000 c031ade4 bf07de04 
fd60: c6d1fd94 c6d1fd70 c031a594 c031adf4 c782c698 c780e0a0 00000000 bf07de04 
fd80: bf07de04 c6c42120 c6d1fda4 c6d1fd98 c031ab50 c031a550 c6d1fdcc c6d1fda8 
fda0: c0319e6c c031ab40 bf07dc6e bf07ddd0 bf07de04 bf07de04 00000000 c0210f24 
fdc0: c6d1fdf0 c6d1fdd0 c031b058 c0319dd4 bf07ddd0 bf07de04 bf081000 00000000 
fde0: c0210f24 c6d1fe0c c6d1fdf4 c03037bc c031afb8 00002740 bf07e380 bf081000 
fe00: c6d1fe1c c6d1fe10 bf08101c c0303780 c6d1ff80 c6d1fe20 c0210298 bf081010 
fe20: c782e400 00000000 00000001 00000001 00000010 00000000 00000010 00000000 
fe40: 00000005 c73b3000 c0507ae0 c040bf10 40000013 c6d1fe80 c6d1fe64 c024bac0 
fe60: c024a404 00000000 c88bd000 c6d2ad80 00000001 c6d1fe90 c6d1fe84 c024bb80 
fe80: c024b9a8 00000003 c88bd000 c6d2ad80 00000001 c88be7e4 c6d1fec4 c6d1fea8 
fea0: c025dcb8 c025fbfc 00000000 c6d1ff48 00000000 bf07e380 c6d1fed4 c6d1fec8 
fec0: c025dd48 c025dc08 c6d1ff80 c6d1fed8 c02415f4 c025dd1c 00000000 c6d1ff50 
fee0: c6d1ff3c c88be9ec 00000000 c88bd000 c88be740 c6d2aea0 c88bef34 00000012 
ff00: 00000013 0000000a c02fe27c 00000043 00000043 c6d1e000 bf01d244 bf07e3c8 
ff20: bf07e38c c88beadc c03bf324 c88beadc 00000000 00000000 00000000 00000000 
ff40: 00000000 00000000 00000000 00002740 bf07e380 00074038 00000000 c0210f24 
ff60: c6d1ff80 00002740 bf07e380 00074038 00000000 c6d1ffa4 c6d1ff84 c0241964 
ff80: c0210258 c6d1ff90 756e694c 00000078 00000000 00000080 00000000 c6d1ffa8 
ffa0: c0210d80 c02418dc 00000078 00000000 00900080 00074038 00002740 00074028 
ffc0: 756e694c 00000078 00000000 00074028 beea0e91 000612e2 000615c7 00000000 
ffe0: 400508f0 beea0b24 0001184c 40050900 20000010 00900080 00522031 00522431 
Backtrace: 
Function entered at [<bf013b44>] from [<bf00f030>]
 r4:c7888000
Function entered at [<bf00efec>] from [<bf00f074>]
 r4:a0000013
Function entered at [<bf00f048>] from [<bf004734>]
 r4:c7888000
Function entered at [<bf004514>] from [<bf00a754>]
Function entered at [<bf00a72c>] from [<bf07d7d0>]
Function entered at [<bf07d2b8>] from [<c0303548>]
Function entered at [<c03034e8>] from [<c031ad10>]
 r8:c0406398 r7:bf07de04 r6:c780e058 r5:c780e104 r4:c780e058
Function entered at [<c031ac38>] from [<c031ae4c>]
 r7:c6d1fd70 r6:bf07de04 r5:c780e104 r4:c780e058
Function entered at [<c031ade4>] from [<c031a594>]
 r6:bf07de04 r5:c031ade4 r4:00000000
Function entered at [<c031a540>] from [<c031ab50>]
 r7:c6c42120 r6:bf07de04 r5:bf07de04 r4:00000000
Function entered at [<c031ab30>] from [<c0319e6c>]
Function entered at [<c0319dc4>] from [<c031b058>]
 r8:c0210f24 r7:00000000 r6:bf07de04 r5:bf07de04 r4:bf07ddd0
Function entered at [<c031afa8>] from [<c03037bc>]
 r8:c0210f24 r7:00000000 r6:bf081000 r5:bf07de04 r4:bf07ddd0
Function entered at [<c0303770>] from [<bf08101c>]
 r6:bf081000 r5:bf07e380 r4:00002740
Function entered at [<bf081000>] from [<c0210298>]
Function entered at [<c0210248>] from [<c0241964>]
 r7:00000000 r6:00074038 r5:bf07e380 r4:00002740
Function entered at [<c02418cc>] from [<c0210d80>]
 r7:00000080 r6:00000000 r5:00000078 r4:756e694c
Code: e5c03061 e5c03060 15d03060 e1a04000 (15c23000) 
---[ end trace 3482ee2c85f43df7 ]---
nf_conntrack version 0.5.0 (2048 buckets, 8192 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.



BusyBox v1.11.3 (2009-02-22 12:13:27 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 KAMIKAZE (bleeding edge, r14586) -------------------
  * 10 oz Vodka       Shake well with ice and strain
  * 10 oz Triple sec  mixture into 10 shot glasses.
  * 10 oz lime juice  Salute!
 ---------------------------------------------------
root@OpenWrt:/#

I used via 6421a sata get error.

300 (edited by maddes.b 2010-06-13 16:52:40)

Re: Support for Marvell 88F5xx81 based routers

For all those eager to test WRT350N v2 support, but are not used to build OpenWRT, I wrote and enhanced some HowTos for setting up a virtual machine with Debian for building OpenWrt and for setting up the build environment and building OpenWrt on the wiki (or here and here in the old wiki) plus some additions in this post.
Thanks to Dirk, Striker, Kaloz, Lennert, Davidkra and all the others to make this possible.

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).

(as root user)
aptitude install zip

(as normal user)
mkdir -p ~/orion/trunk/
cd ~/orion/trunk/
... do all the checkout stuff from the HowTo ...
... Note: repository now at svn://svn.openwrt.org/openwrt/trunk (not https)...
# sysupgrade (only necessary before revision 19166)
patch -p0 < ~/orion_sysupgrade_mtd_wnr854t.r17264.patch
patch -p0 < ~/orion_sysupgrade_mtd_wrt350nv2.r17264.patch
patch -p0 < ~/orion_sysupgrade_platform_sh.r17264.patch
# webupgrade (only necessary before revision 18761/18794)
patch -p0 < ~/orion_webupgrade.builder_v21.patch
patch -p0 < ~/orion_webupgrade.tools_makefile.r17264.patch
patch -p0 < ~/orion_webupgrade.image_makefile_wrt350nv2.r17264.patch

--> "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 flashing (at your own risk!) see the next two pages of this thread (especially #375 and #341) plus the instructions of this post by relghuar.
Also read the wiki page about TFTP (or here).
If there's no /jffs after flashing, then check out this post by DirkNL.

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