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.

heji wrote:

root@OpenWrt:/tmp# dd if=wrt350nv2-uImage of=/dev/mtdblock0
dd: writing '/dev/mtdblock0': No space left on device
2049+0 records in
2048+0 records out

copy kernel from 0xff800000 to 0x400000 with size 0x200000
## Booting image at 00400000 ...
   Image Name:   Linux-2.6.28.10
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1061680 Bytes =  1 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
Marvell>>

How to change the size of mtd0?

Hello heji,
why did You need such a huge kernel file?

As recommended some pages before, You should compile a minimal configuration and than add the packages via opkg.
The kernel must be under 0x100000 bytes.

In wrt350nv2-setup.c the mtd-blocks are defined and the openwrt patch (100- ...) for the mtd_partitions can be found at ......openwrt/target/linux/orion/patches.
In my mind the parameters in the patch are quite useful and should be left as they are.

I added some lines of code to Dirk's imagebuilder checking the sizes of the kernel (<0x100000) and the sqashfs (<0x650000) file and doing the "-v" - parameter.

Maddes would You please publish the code? I don't have an accurate webspace for that.

Other tinks to do:
I am just analysing the original firmware and found out, that the mac-address is configures via a little helper programm.
When I am ready with my new computer, I will reproduce this for openwrt.

The leds for the wlan-activities are still aweful.
Has someone a hint for me to connect the led-triggers from ath9k to the leds of the wrt350n?
I am afraid, we need another helper-program for that.

(Last edited by mrk on 18 May 2009, 20:08)

I have got the same problem, compiling trunk just produces an kernel image, that is too big:

ls -l bin/
-rw-r--r-- 1 mm mm 1068940 2009-05-19 13:15 openwrt-wrt350nv2-uImage

echo $((1024*1024))
1048576

So it can't fit into the kernel mtd.

Or am I missing soemthing?

The image on
http://downloads.openwrt.org/snapshots/ … /packages/
is also too big.

MM wrote:

I have got the same problem, compiling trunk just produces an kernel image, that is too big:

ls -l bin/
-rw-r--r-- 1 mm mm 1068940 2009-05-19 13:15 openwrt-wrt350nv2-uImage

echo $((1024*1024))
1048576

So it can't fit into the kernel mtd.

Or am I missing soemthing?

The image on
http://downloads.openwrt.org/snapshots/ … /packages/
is also too big.

Well, try to delete the patch 100-openwrt_partition_map.patch at openwrt/target/linux/orion/patches and build the kernel again.
Then You have 0x1A0000 bytes for kernel an 0x5c0000 bytes for squashfs inclusive jffs2. That are the original sizes from linksys.
But with that sizes the jffs2-partition for the additional packages is rather reduced.

I think, we have to inspect the underlying config-file from the present kernel, maybe it could be cleaned.

Started another thread about setting up a router with USB stick (ext3) as jffs addition/replacement: http://forum.openwrt.org/viewtopic.php?id=20436
Please have a look at it, as this is something a lot of people will be interested in. Thanks.

I have some questions and suggestions regarding the mtd mapping.

#1 The original mtd mapping:
"kernel" = size 0x00760000, "truncated" by "rootfs" at 0x001A0000 (= 1,625 MB)
"rootfs" = size 0x005c0000 (=5,75 MB)
"lang" = size 0x00040000 (=256KB)
"nvram" = size 0x00020000 (=128KB)
"u-boot" = size 0x00040000 (=256KB)

Is the huge overlapping size of "kernel" a trick to allow for any kernel size?
Isn't there a marker after the kernel image that tells the system "here begins rootfs"?

If so then it would be good to keep this technique for any kernel size, "truncation" could be moved down to 0x100000 to allow for a bigger "rootfs".
Only issue is that a new kernel image with a different size (even only 1 byte more or less) and over 1MB will make the old "rootfs" unusable.

#2 The patched mtd mapping:
"u-boot" should never be touched. "lang" can definitely be added to "rootfs".
"nvram" could be kept to preserve the config for the stock firmware (it's just 128KB)


If all would apply then I would define the following mtd:
"kernel" = size 0x007a0000, offset 0x00000000
"rootfs" = size 0x006A0000, offset 0x00100000 (max. 6,625 MB, truncated at the beginning through kernel image size, "save" kernel update up to 1MB)
"nvram" = size 0x00020000, offset 0x007a0000
"u-boot" = size 0x00040000, offset 0x007c0000

Or to allow updating [mini] kernel with a higher chance to continue with the old rootfs. Writing into "rootfs" area with a mini kernel would be quite unlikely.
"rootfs" = size 0x00600000, offset 0x001A0000 (= 1,625 MB for "save" kernel update)
- or -
"rootfs" = size 0x00660000, offset 0x00140000 (= 1,25 MB for "save" kernel update)

Can somebody confirm or deny?

Can the mtd mapping be changed after flashing?

Maddes

(Last edited by maddes.b on 24 May 2009, 00:42)

I can be very short in answering that, no you can't change MTD after flashing.

It's because the kernel you flash with contains the offset address for the rootfs (hardcoded in the wrt's setup.c file). So if you would change the mtd map your kernel would still try to jump to the old address space. Ofcourse that will fail and you'll get a kernel panic about not able to find a valid root filesystem.

The default mtd Linksys provided has got overlapping kernel/rootfs space for simple firmware upgrades. e.g. if you flash a complete image containing both kernel and rootfs with the correct address mappings, you'll only have to overwrite 1 mtd space.

Though that's very convenient for flashing purposes, OpenWRT chose not maintain these overlapping spaces. It's a bit safer that way, e.g. when you flash a kernel which is too large to fit in the kernel space it'll just fail. Whereas it would with the original firmware overwrite the first bit of your rootfs.

It doesn't mean ofcourse that you're stuck using the OpenWRT layout. If you really need more space for your kernel you could just patch your kernel with a larger kernel mtd and a smaller rootfs partition. If you would want to create a webupgrade image from those sources DON'T forget to change the .par file you provide the builderprogram with!

nvram is deprecated so indeed only for original "backup" you could leave it alone, but don't forget we're already losing some space for the "ErCoMm" safety patch.

So to sum up, you can change the mtd to your likings, just make sure you stay clear from the ercomm bytes and the u-boot partition and you'll be fine. And MTD changes inevitably mean you need to reflash your kernel and rootfs. Hope this clears everything up for you.

Sorry, didn't remember your posting about ErCoMm hell, where the problem with the ErCoMm signature and erasesize was mentioned  (near the end of that post).

So there should be still some buffer for newer, and maybe bigger, kernel images:
"kernel" = offset 0x00000000, size 0x00140000 (= 1280 KB)
"rootfs" = offset 0x00140000, size 0x00610000 (= 6208 KB)
"ErCoMm" = offset 0x00750000, size 0x00010000 (= preserve ErCoMm signature for LinkSys U-Boot)
"lang" = offset 0x00760000, size 0x00040000
"nvram"  = offset 0x007a0000, size 0x00020000 (= preserve config of stock firmware)
"u-boot" = offset 0x007c0000, size 0x00040000

Only an self-made U-Boot would make the area 0x00750000 to 0x007a0000/0x007c0000 accessible for "rootfs" or something else.
relghuar has created a custom U-Boot for his WRT350Nv2.
As far as I know OpenWrt doesn't include U-Boot, so this would be a side project.
Would re-flashing the stock firmware result in a booting router with this U-Boot version?

Thanks
Maddes

Edit:
Uploaded adopted 100-openwrt_partition_map.patch to my ftp space. (best choice is 0x00120000 for now)
Please check and tell if I followed all the rules.
Now working.

And changed rootfs.squash in tools/wrt350nv2-builder/src/wrt350nv2-par like this (for 0x00120000 kernel mtd size):

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

Edit II:
The new MTD configuration was submitted to the developer mailing list.

(Last edited by maddes.b on 7 Apr 2010, 19:28)

How do I flash from inside U-Boot with the following files:
openwrt-wrt350nv2-uImage
openwrt-orion-squashfs.img

maddes.b wrote:

How do I flash from inside U-Boot with the following files:
openwrt-wrt350nv2-uImage
openwrt-orion-squashfs.img

Maddes take care. Don't use the *.img file.
Search for the original root.squashfs at openwrt/build_dir/linux-orion-generic
I admit, that uImage size is 0x140000 and squashfs 0x1fffff.
It is shown after tftboot.
I installed a tftp-server with IP according to the uBoot variables, I think it is serverip.

#### Firmware flash via U-BOOT ####
tftpboot 0x400000 openwrt-wrt350nv2-uImage

erase 0xff800000 0xfff4ffff
protect off 0xff800000 0xfff4ffff

cp.b 0x400000 0xff800000 0x140000

### Don't use the *.img file, take the root.squashfs
tftpboot 0x400000 squashfs.image
cp.b 0x400000 0xff940000 0x1fffff

If there are some errors with the second cp.b - command, try to erase and protect off als well.

Update:
The file openwrt-orion-squashfs.img should be the combined kernel and rootfs.
So You can use:

tftpboot 0x400000 openwrt-orion-squashfs.img
erase 0xff800000 0xfff4ffff
protect off 0xff800000 0xfff4ffff
cp.b 0x400000 0xff800000 0x30ffff

If You have a freeze after reboot.
Try to reflash only the openwrt-wrt350nv2-uImage file.

tftpboot 0x400000 openwrt-wrt350nv2-uImage
protect off 0xff800000 0xff94ffff
cp.b 0x400000 0xff800000 0x140000

If there is still something wrong, please recalc the values.

(Last edited by mrk on 26 May 2009, 22:10)

Thanks mrk for the hints.

Just successfully tested the first way by mrk. It can be summed up as following:

# temporary change network settings to fit your network
setenv ipaddr 10.0.0.99
setenv serverip 10.0.0.1

# clear flash and unprotect for writing
erase 0xff800000 0xfff4ffff
protect off 0xff800000 0xfff4ffff

# flash kernel
tftpboot 0x400000 "openwrt-wrt350nv2-uImage"
cp.b 0x400000 0xff800000 <transferred bytes>

# flash rootfs
tftpboot 0x400000 "root.squashfs"
cp.b 0x400000 <0xff800000 + used rootfs MTD offset> <transferred bytes>

Update:
The second way didn't work for me, also flashing takes longer (big img + kernel) and needs some more calculation.
I assume the .img is not just kernel + mtd padding + rootfs

(Last edited by maddes.b on 27 May 2009, 02:51)

I know that a larger kernel with new MTD mapping can be flashed from inside Linux if there's access to serial console.
Compile it once as a ramdisk build and once as a squashfs build.
TFTBOOT the ramdisk image of the kernel with new MTD mapping.
Telnet to the router, use passwd to set password and enable SSH.
When inside Linux use wget or SFTP/SSH to retrieve the squashfs kernel, then flash it with dd writing to /dev/mtdblock0.
Remove the squashfs kernel to re-gain space, then fetch the root.squashfs from the other machine and flash it with dd writing to /dev/mtdblock1.
(root.squashfs can be found under ./build_dir/linux-orion_generic in the trunk directory, or use: find . -name "root.squashfs" inside the trunk directory)
Remove the power from the router, then reestablish it.
Now you can telnet to the router again.

Question:
Is it possible to flash a bigger kernel with a new MTD mapping without TFTPBOOT/serial console?
If not, should there be an extra overlapping MTD entry, e.g. "org_mtd0" (0x0-0x760000)?
Or better keep the original MTD settings?

How does Luci, X-Wrt or OpenWrt normally flash updates?
Does the same issue apply to this way of flashing?

I think this flashing "issue" is the last hurdle to let it loose onto the normal user.

Kind regards
Maddes

P.S.: Will add all information to the wiki, when the new wiki is available.

(Last edited by maddes.b on 31 May 2009, 21:03)

You can always flash from inside a running device, just use ssh or telnet...

The problem with this method is that you need to divide your new kernel/rootfs to the correct lengths so that they will connect once you reboot with the new layout.

I'll try to explain with some `graphics`:

00 -> Space left for the partition
11 -> Kernel
22 -> Rootfs

Default layout:
1111 1111 1111 0000 2222 2222 2222 2222 2222 2222 2222 2222 2222 2222 2222 0000 0000 0000 0000 0000

Extended layout:
1111 1111 1111 1111 1111 1111 0000 2222 2222 2222 2222 2222 2222 2222 2222 2222 2222 0000 0000 0000
                    ^
                    Here is where you should cut off the kernel
                              ^    ^ 
                              Here you need to add zero padding to the leftover from the kernel, after that you can just paste the rootfs

If you cut up and paste your kernel and rootfs like this you can use the result to flash from inside a running openwrt with the default layout.

I've flashed like this dozens of times and if you be carefull enough it will succeed. Just double check your mtd sizes multiple times!!!

afaik there is no "default" way of flashing/upgrading for OpenWRT, maybe someone like Kaloz could answer that one a bit more truthfully.

(Last edited by dirkNL on 29 May 2009, 15:23)

OK, I have extended Dirk's wrt350nv2-webbuilder app a little bit.
You can find the new wrt350nv2-builder.c - source here.
Many thanks to maddes, who gives his webspace for that.

Just extract the zip into the source folder of the webbuilder and recompile.

The current release now has some new commands which are:

buildimg [-v] [-img] [-cut <hex-value>] parfile
  -v      set verbose mode
  -img  produce uBoot flash image
  -cut <hex-adress>  produce flash image for mtdblock0 and mtdblock1, cut at given position

Explain:
-v is for verbosing. There are quit interesting information.
-img produces a via uBoot flashable image-file. It has a fixed filename called wrt350n-uBoot.img.
-cut <hex-adress> Is for flahing via the mtdblocks in openwrt.
This command follows Dirk's last posting concerning flashing new imagefiles though current mtd-borders in openwrt.
The <hex-adress> represents the current size of mtdblock0 in Your current openwrt and this would be the cutting-point for the webbuilder-app.

The resulting files can be flashed in openwrt-console with:

dd if=wrt350n.img.mtd0 of=/dev/mtdblock0
dd if=wrt350n.img.mtd1 of=/dev/mtdblock1

Take care about the topics in the parfile!
The webbuilder uses filenames (i.e. uImage) given there.
So if You are in trouble, check the par-file first and look after the filenames and sizes of uImage and rootfs.

Using the commands -img or -cut will not create a additional webbuilder-flash-file.

Please let me know, if You are in trouble.

PS: The full webbuilder files with makefile are here

(Last edited by mrk on 31 May 2009, 17:14)

Hello

Today I have bricked my WRT-350n v2 smile. Since I haven't googled out way to unbrick it, I'm writing this post.

Bricking it was very simple - I have uploaded root.squashfs insted of uImage. Now power led blinks amber and green and on console i have:

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

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

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


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


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

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

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

*******************************************
dbSign is:65:52:63:4f:6d:4d
mac address in flash is:00:1a:70:9c:51:18
have eRcOmM
Firmware is damaged,enter download mode
mvEgigaLoad: egiga0 load ok
egiga0 [PRIME]

mvEgigaInit: egiga0 init - mvBoardPhyAddrGet()=0x0 , priv->port =0x0
ring full
mvEgigaInit: egiga0 complete ok
In download function
 mac address:00:1a:70:9c:51:18
Pin:33.32.38.32.39.34.30.32

I have no access to U-Boot command line (normally after pressing enter) so I cannot reflash my router.
Does message " Firmware is damaged,enter download mode" means that my router automatically tries to download firmware from tftp ? I have tried to set up tftp server with address 172.21.5.30 with uImage file but router doesn't even send one ip packet to me (tried with all router interfaces) I have also tried uploading file to router using tftp client on my pc to different default ip's found on the net, but without success.  (no working address found by ARP)

I have never flashed anything below 0x400000 so my u-boot should be ok ?

Please help smile

Regards

(Last edited by motopompa on 4 Jun 2009, 21:53)

There's another way to create images for flashing a kernel to a different kernel mtd definition by just using standard linux commands.
So, from my point of view I would not "complicate" the usage of the wrt350nv2-webbuilder for this.

Note that all sizes for dd have to be stated in decimal values, this is automatically done by the builtin bash command 'declare' and its option -i.
The latest version of the my script "create_images_orion.sh" is always available at http://ftp.maddes.net/openwrt/.

Either create a build yourself or download it from the OpenWrt snapshots as mentioned here:

BOARD='orion'
BUILDTYPE='snapshot'
FSTYPE='squashfs'

mkdir bin || rm bin/*
cd bin

# get latest uImage for router and pad it
wget http://downloads.openwrt.org/snapshots/trunk/orion/openwrt-wrt350nv2-uImage
dd if=openwrt-wrt350nv2-uImage of=openwrt-wrt350nv2-uImage.${BUILDTYPE}.${FSTYPE}.padded bs=1024k conv=sync

# get latest openwrt-orion-squashfs.img
wget http://downloads.openwrt.org/snapshots/trunk/orion/openwrt-orion-${FSTYPE}.img

# extract general uImage (padded to 1024k) from openwrt-orion-squashfs.img
#dd if=openwrt-orion-${FSTYPE}.img of=uImage.padded bs=1024k count=1

# extract root.squashfs (padded to 128k) from openwrt-orion-squashfs.img
dd if=openwrt-orion-${FSTYPE}.img of=root.${FSTYPE}.${BOARD}.${BUILDTYPE} bs=128k skip=8

# create combined flash image (uImage + padding + rootfs)
cat openwrt-wrt350nv2-uImage.${BUILDTYPE}.${FSTYPE}.padded root.${FSTYPE}.${BOARD}.${BUILDTYPE} >openwrt-wrt350nv2-${FSTYPE}.${BUILDTYPE}.img

cd ..

# create further images if wanted
~/create_images_orion.sh "${BUILDTYPE}" "${FSTYPE}"

~/create_images_orion.sh (to copy configs and create images directly after a build, also works with above mentioned downloads)

#!/bin/bash

#
# Intended Usage:
#
# BOARD='orion'
#
# BUILDTYPE='tun'
# - or -
# BUILDTYPE='all'
#
# FSTYPE='squashfs'
# - or -
# FSTYPE='ramdisk'
#
# mkdir bin || rm bin/*
# LOGFILE="bin/compilelog.${BOARD}.${BUILDTYPE}.${FSTYPE}.`svnversion`.`date +%Y%m%d_%H%M%S`.log"
# script -f -c 'make V=99 IGNORE_ERRORS=m' "${LOGFILE}" ; bzip2 "${LOGFILE}" ; ~/create_images_orion.sh "${BUILDTYPE}" "${FSTYPE}" ; echo -e '\a'
#
# ToDo:
# - check sizes of existing files, if mismatch then error message so user can react on it
# - check md5sum of existing files, if mismatch then error message so user can react on it
#

# check parameters
rc=0
#
if [ -z "$1" ]
 then
  echo 'build type not stated (e.g. tun or all)'
  rc=1
fi
#
if [ -z "$2" ]
 then
  echo 'filesystem type not stated (squashfs or ramdisk)'
  rc=1
fi
#
[ "${rc}" -ne 0 ] && exit "${rc}"

# define mtd and erase sizes
KERNELMTDSIZE='0x00100000'
declare -i ROOTFSMTDSIZE=0x00750000-"${KERNELMTDSIZE}"

# define kernel file names
KERNELORG='openwrt-wrt350nv2-uImage'
KERNEL="${KERNELORG}.$1.$2"
KERNELPAD="${KERNEL}.padded"

# define rootfs file names
FSIMGORG='openwrt-orion-squashfs.img'
FSIMG="openwrt-orion-squashfs.$1.img"
#
ROOTFSORG='root.squashfs'
ROOTFS="${ROOTFSORG}.orion.$1"
ROOTFSPAD="${ROOTFS}.padded"

# define kernel+rootfs merge file names
MERGE="${KERNELPAD}+${ROOTFSORG}"
MERGEPAD="${MERGE}.padded"

# define misc file names
MD5SUMS="md5sums.orion.$1.$2"
SPLITFILE="${MERGEPAD}"

# define integer variables for dd
declare -i SIZE1
declare -i SIZE2

# switch to bin folder
cd bin ; rc=$?
[ "${rc}" -ne 0 ] && exit "${rc}"

# create md5sums file
[ ! -f "${MD5SUMS}" ] && touch "${MD5SUMS}"

# copy general config
CONFIG="config.orion.$1.$2"
[ ! -f "${CONFIG}" ] && cp ../.config "${CONFIG}"
grep -e "${CONFIG}" "${MD5SUMS}" >/dev/null || md5sum --text "${CONFIG}" >>"${MD5SUMS}"

# copy kernel config
CONFIG="kconfig-orion.$1.$2"
[ ! -f "${CONFIG}" ] && cp ../tmp/.kconfig-orion "${CONFIG}"
grep -e "${CONFIG}" "${MD5SUMS}" >/dev/null || md5sum --text "${CONFIG}" >>"${MD5SUMS}"

# checksum compilelog
grep -e "compilelog.orion.$1.$2.*.*.log.bz2" "${MD5SUMS}" >/dev/null || md5sum --binary compilelog.orion.$1.$2.*.*.log.bz2 >>"${MD5SUMS}"

# rename kernel image
[ ! -f "${KERNEL}" ] && mv "${KERNELORG}" "${KERNEL}"
grep -e "${KERNEL}" "${MD5SUMS}" >/dev/null || md5sum --binary "${KERNEL}" >>"${MD5SUMS}"

## --- squashfs build only  begin ---
if [ "$2" == "squashfs" ]
 then
  # rename squashfs image
  [ ! -f "${FSIMG}" ] && mv "${FSIMGORG}" "${FSIMG}"
  grep -e "${FSIMG}" "${MD5SUMS}" >/dev/null || md5sum --binary "${FSIMG}" >>"${MD5SUMS}"

  # get latest rootfs
  [ ! -f "${ROOTFS}" ] && dd if="../build_dir/linux-orion_generic/${ROOTFSORG}" of="${ROOTFS}" bs=128k conv=sync
  grep -e "${ROOTFS}" "${MD5SUMS}" >/dev/null || md5sum --binary "${ROOTFS}" >>"${MD5SUMS}"

  # create a padded kernel image
  SIZE1="${KERNELMTDSIZE}"
  [ ! -f "${KERNELPAD}" ] && {
    echo "Creating ${KERNELPAD}..."
    dd if="${KERNEL}" of="${KERNELPAD}" bs="${SIZE1}" conv=sync
  }
  SIZE2=`stat -c %s "${KERNELPAD}"`
  [ "${SIZE2}" -ne "${SIZE1}" ] && { echo "STOP!!! Kernel too big!!!"; exit 1 ; }
  grep -e "${KERNELPAD}" "${MD5SUMS}" >/dev/null || md5sum --binary "${KERNELPAD}" >>"${MD5SUMS}"

  # create a concatenated image (for split and flashing in U-Boot)
  [ ! -f "${MERGE}" ] && cat "${KERNELPAD}" "${ROOTFS}" >"${MERGE}"
  grep -e "${MERGE}" "${MD5SUMS}" >/dev/null || md5sum --binary "${MERGE}" >>"${MD5SUMS}"

  # create a padded rootfs image
  SIZE1="${ROOTFSMTDSIZE}"
  [ ! -f "${ROOTFSPAD}" ] && {
    echo "Creating ${ROOTFSPAD}..."
    dd if="${ROOTFS}" of="${ROOTFSPAD}" bs="${SIZE1}" conv=sync
  }
  SIZE2=`stat -c %s "${ROOTFSPAD}"`
  [ "${SIZE2}" -ne "${SIZE1}" ] && { echo "STOP!!! rootfs too big!!!"; exit 1 ; }
  grep -e "${ROOTFSPAD}" "${MD5SUMS}" >/dev/null || md5sum --binary "${ROOTFSPAD}" >>"${MD5SUMS}"

  # create a concatenated padded image
  [ ! -f "${MERGEPAD}" ] && cat "${KERNELPAD}" "${ROOTFSPAD}" >"${MERGEPAD}"
  grep -e "${MERGEPAD}" "${MD5SUMS}" >/dev/null || md5sum --binary "${MERGEPAD}" >>"${MD5SUMS}"

  ### split for flashing in Linux with different mtd sizes
  echo "Splitting '${SPLITFILE}' with kernel mtd size of ${KERNELMTDSIZE} in..."
  for OTHERSIZE in '0x00100000' '0x00120000' '0x001A0000'
   do
    [ "${OTHERSIZE}" == "${KERNELMTDSIZE}" ] && continue
    #
    SIZE1="${OTHERSIZE}"
    #
    IMGFILE="img.wrt350nv2.$1.$2.${OTHERSIZE}.mtd0"
    [ ! -f "${IMGFILE}" ] && {
      echo "...mtd0 for kernel mtd size ${OTHERSIZE}"
      dd if="${SPLITFILE}" of="${IMGFILE}" bs="${SIZE1}" count=1
    }
    grep -e "${IMGFILE}" "${MD5SUMS}" >/dev/null || md5sum --binary "${IMGFILE}" >>"${MD5SUMS}"
    #
    IMGFILE="img.wrt350nv2.$1.$2.${OTHERSIZE}.mtd1"
    [ ! -f "${IMGFILE}" ] && {
      echo "...mtd1 for kernel mtd size ${OTHERSIZE}"
      dd if="${SPLITFILE}" of="${IMGFILE}" bs="${SIZE1}" skip=1
    }
    grep -e "${IMGFILE}" "${MD5SUMS}" >/dev/null || md5sum --binary "${IMGFILE}" >>"${MD5SUMS}"
  done
fi
# --- squashfs build only  end ---

# go back up
cd ..

Flashing in U-Boot:

# temporary change network settings to fit your network
setenv ipaddr 10.0.0.99
setenv serverip 10.0.0.1

# erase and unprotect flash for writing
erase 0xff800000 0xfff4ffff
protect off 0xff800000 0xfff4ffff

# flash kernel + rootfs
tftpboot 0x400000 "openwrt-wrt350nv2-uImage.snapshot.squashfs.padded+root.squashfs"
# recognize the download size in its output, it will be used in the next command
cp.b 0x400000 0xff800000 <transferred bytes in hex/0x>

reset

Flashing in Linux:
Copy files via SFTP to /tmp or get them with wget over http or ftp.
To copy a new kernel and rootfs to the router via SCP/SFTP checkout this wiki page

Flashing with same kernel mtd size:

# check mtd sizes
cat /proc/mtd
ls -la /dev/mtdblock*

dd if=/tmp/openwrt-wrt350nv2-uImage.snapshot.squashfs.padded of=/dev/mtdblock0 ; echo -e '\a'   #ring the bell when done
sync ; dd if=/tmp/root.squashfs of=/dev/mtdblock1 ; rc=$? ; \
 [ ${rc} -eq 0 ] && reboot ; echo -e '\a'   # reboot immediately so the new rootfs is not destroyed by any action (and force you to use U-Boot to reflash)

Flashing with different kernel mtd sizes (here 0x00120000):

# check mtd sizes
cat /proc/mtd
ls -la /dev/mtdblock*

sync ; dd if=/tmp/img.wrt350nv2.snapshot.squashfs.0x00120000.mtd0 of=/dev/mtdblock0 ; rc=$? ; \
 [ ${rc} -eq 0 ] && { dd if=/tmp/img.wrt350nv2.snapshot.squashfs.0x00120000.mtd1 of=/dev/mtdblock1 ; rc=$? ; } ; \
 [ ${rc} -eq 0 ] && reboot ; echo -e '\a'   # reboot immediately so the new rootfs is not destroyed by any action (and force you to use U-Boot to reflash)

Flashing on stock firmware:

# check mtd sizes
cat /proc/mtd
ls -la /dev/mtdblock*

sync ; dd if=/tmp/openwrt-wrt350nv2-uImage.padded+root.squashfs.padded of=/dev/mtdblock0 ; rc=$? ; \
 [ ${rc} -eq 0 ] && reboot ; echo -e '\a'   # reboot immediately so the new rootfs is not destroyed by any action (and force you to use U-Boot to reflash)

Update:
Even faster (less dd action) and simpler way by calculating the correct pad size via bash's 'declare' and standard stat command.

Update 2:
Flashing information

Update 3:
Updated to padded images to reduce risk of destroyed rootfs.
Splitting for different mtd sizes is now done in a second.

Update 4:
Added sync command to reduce risk of destroyed rootfs mtd partition.

Update 5:
With sync and immediate reboot I never had any flashing issues again.
Outcommented all lines with padded rootfs.
Updated flashing commands to check for errors and not rebooting if anything failed.

Update 6:
Had another flashing despite using sync and immediate reboot.
Difference was that the kernel mtd size was downsized from 0x00120000 to 0x00100000.
Further tests showed that upsizing works with unpadded images, but downsizing needs padded images.
Hence reverted back to padded images for different mtd sizes.

Update 7:
New script, works with own compiled builds and snapshot downloads.

(Last edited by maddes.b on 3 Apr 2010, 16:59)

I updated my package repository to trunk revision 16424 (12h compile time), as the OpenWrt snapshot package repository still lacks some packages (e.g. ticket #5253).

To use edit /etc/opkg.conf to add a new line which points to my package repository:

src/gz Maddes ftp://ftp.maddes.net/openwrt/kamikaze/orion/packages

Kernel builds, root.squashfs and info can be found at ftp://ftp.maddes.net/openwrt/trunk/orion and http://ftp.maddes.net/openwrt/

(Last edited by maddes.b on 7 Apr 2010, 19:29)

motopompa wrote:

Hello

Today I have bricked my WRT-350n v2 smile. Since I haven't googled out way to unbrick it, I'm writing this post.

Bricking it was very simple - I have uploaded root.squashfs insted of uImage. Now power led blinks amber and green and on console i have:

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

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

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


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


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

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

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

*******************************************
dbSign is:65:52:63:4f:6d:4d
mac address in flash is:00:1a:70:9c:51:18
have eRcOmM
Firmware is damaged,enter download mode
mvEgigaLoad: egiga0 load ok
egiga0 [PRIME]

mvEgigaInit: egiga0 init - mvBoardPhyAddrGet()=0x0 , priv->port =0x0
ring full
mvEgigaInit: egiga0 complete ok
In download function
 mac address:00:1a:70:9c:51:18
Pin:33.32.38.32.39.34.30.32

I have no access to U-Boot command line (normally after pressing enter) so I cannot reflash my router.
Does message " Firmware is damaged,enter download mode" means that my router automatically tries to download firmware from tftp ? I have tried to set up tftp server with address 172.21.5.30 with uImage file but router doesn't even send one ip packet to me (tried with all router interfaces) I have also tried uploading file to router using tftp client on my pc to different default ip's found on the net, but without success.  (no working address found by ARP)

I have never flashed anything below 0x400000 so my u-boot should be ok ?

Please help smile

Regards

Me too.
I use sercomm-utility and firmware from this post http://forum.openwrt.org/viewtopic.php?pid=74729#p74729 and my linksys back to life wink

OpenVPN crashes on my WRT350Nv2.
Opened a separate thread about it.
Please have a look maybe you can confirm or report or your working configuration.

Update:
Workaround found, read the above mentioned thread.

(Last edited by maddes.b on 2 Jul 2009, 22:45)

I try your version yesterday, and i can make USB and wifi N work...

maddes.b wrote:

OpenVPN crashes on my WRT350Nv2.
Opened a separate thread about it.
Please have a look maybe you can confirm or report or your working configuration.

My OpenVPN crashes as well, but I've not gotten any stacktraces. Where do I get these?

You get the stack traces on the serial console.

Figures, I've not got one here. Only DirkNL has one.

Hello,

this sounds really great.
Is openwrt trunk usable on my WRT350N v2 for daily usage?
All 4 LAN ports are working, aren't they?
What about the speed of WLAN? Are there any performance issues compared to the original Linksys firmware?
Is the USB port working?
Are there any (supported) binary packages released / will this router be officially supported by openwrt / dd-wrt soon?
Is it possible to install a webinterface (x-wrt)?

(Last edited by LuHe on 20 Jun 2009, 17:10)

@LuHe:
Depends on what you need for daily usage. For me OpenVPN is important and that currently crashes with the current trunk.

All 4 LAN ports are working fine. Haven't done any speed tests yet.
But if you read all pages of this thread you'll find some information about it.

WLAN not really used yet, it worked and I could access the internet.
Can not comment on long-time stability and speed.

USB not tested yet (USB support is excellenty according to mrk's following post).

Packages are available from my site, see page #13 and #14, which also include X-Wrt and Luci.

Last but not least, the WRT350Nv2 is not officially supported and it is recommend to have serial access to the WRT350N v2 before testing (already explained in this thread).

(Last edited by maddes.b on 22 Jun 2009, 18:03)

USB support is excellent.

You only have to install the various packages (kmod-usb-ohci, -uhci, -usb2, -printer, -storage)
USB-hub is working.
USB-storage works with menory-sticks and harddisks.
USB-printer is funny as well

(Last edited by mrk on 6 Jul 2009, 15:57)