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.

maddes.b wrote:

c) Crypto hardware (What config is needed for what device or for Orion in general?)

kmod-crypto-mv-cesa Cryptographic Engines and Security Accelerator for Marvell Orion and Kirkwood SoCs
Found via Seagate Dockstar Wiki

The kmod-crypto-mv-cesa package was added by LarsC, and enabled for Orion on my request.
I worked this weekend on a Makefile cleanup for the Orion platform and included the crypto package.
See ticket #8154.

I added support for the leds and reset button on wnr854t. Ticket 8160.
I also began writing scripts for all orions. Not final yet though.

I also did profiles in the buildsystem this weekend but I guess maddes.b beat me to it. Will try your patch.

I have done profiles too, but not included them into ticket #8154.
It's better to keep the change volume low, to get a faster commit to trunk and/or Backfire.
Also my profile change was not polished yet, I still have to create the correct Profile image rules (like used for the "adm5120" platform).

First it is always done for yourself to learn and get experience (my point of view).
And when several people try to solve the same the problem, then it is interesting to see where the solutions differ and to get new ideas.
Thanks for working on the LEDs.
Every addition to the Orion platform makes it more complete.

(Last edited by maddes.b on 1 Nov 2010, 21:02)

I made a for orions. Could someone with other HW then the wnr854t test it / comment on it before I commit.
If you wanna try it on wnr854t you will need the patch from ticket 8160.

# Copyright (C) 2010

# WNR854T have four states
# Solid Green :     Bootloader running, or kernel hung (timer task stalled)
# Solid Orange:     Normal operation
# Green blinkint:   Failsafe
# Orange blinking:  Preinit

# WRT350N v2 have two states
# Solid Green :     Bootloader running, kernel hung (timer task stalled), failsafe, preinit
# Solid Orange:     Normal operation

set_state() {

local wnr854t_blink="/sys/class/leds/wnr854t:blink:power/brightness"
local wnr854t_green="/sys/class/leds/wnr854t:green:power/brightness"
local wrt350nv2_orange="/sys/class/leds/wrt350nv2:orange:power/brightness"
local hardware=`sed -n /Hardware/s/.*:.//p /proc/cpuinfo`

    case "$1" in
            case "${hardware}" in
                'Netgear WNR854T')
                    [ -e $wnr854t_green ] && [ -e $wnr854t_blink ] && {
                        echo 0 > $wnr854t_green
                        echo 255 > $wnr854t_blink
                'Linksys WRT350N v2')
                    [ -e $wrt350nv2_orange ] && {
                        echo 0 > $wrt350nv2_orange
            case "${hardware}" in
                'Netgear WNR854T')
                    [ -e $wnr854t_green ] && [ -e $wnr854t_blink ] && {
                        echo 255 > $wnr854t_green
                        echo 255 > $wnr854t_blink
                'Linksys WRT350N v2')
                    [ -e $wrt350nv2_orange ] && {
                        echo 0 > $wrt350nv2_orange
            case "${hardware}" in
                'Netgear WNR854T')
                    [ -e $wnr854t_green ] && [ -e $wnr854t_blink ] && {
                        echo 0 > $wnr854t_green
                        echo 0 > $wnr854t_blink
                'Linksys WRT350N v2')
                    [ -e $wrt350nv2_orange ] && {
                        echo 255 > $wrt350nv2_orange

I agree that that you do it for yourself.
The profiles that I made was only additions to the existing system. The cleanup looks better and good.

(Last edited by erik___ on 1 Nov 2010, 22:47)

There is a official snapshot of kmod-crypto-mv-cesa for kirkwood, but not for Orion. Where should I push?

WRT350Nv2 doesn't allow LEDs to blink?

kmod-crypto-mv-cesa was enabled for Orion with r23229 (back then with a wrong underscore).
Unfortunately sometimes Makefile changes require a `make distclean` or at least a clean-up of the tmp folder, so that the new settings are recognized by make.
Just create a defect ticket or send a notice to the developer mailing list.

Will do my own trunk build next weekend, so will look after this too.

(Last edited by maddes.b on 3 Nov 2010, 10:25)

#8167 sent.

After several build-error rounds with "all packages" I updated my build recipe in Ubuntu as follow:
First time:

sudo apt-get -y install subversion g++ ncurses-term gawk flex patch openssh-server
sudo apt-get -y install minicom tftp tftpd gettext zlib1g-dev libssl-dev fastjar sdcc
cd ~
mkdir openwrt
cd openwrt
svn co svn://

First time and subsequent updates:

cd ~/openwrt/trunk
svn up
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig
make -j8 download
make -j2 world
ls -la ~/openwrt/trunk/bin/orion/

But some packages unselected to accelerate process:

Requires jikes not available in newer Ubuntu repositories:

Doesn't compile for whatever reason:

So unselect them after select "all packages"

What this does exactly?:

make package/symlinks

2.6.36 is out in master for orion.

It boots fine on wnr854t courtesy of the 8b22* commit. Second reboot generates a BUG though.

kernelroot@OpenWrt:/# kernel BUG at fs/inode.c:1244!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c109c000
[00000000] *pgd=01091031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1]

Have not looked in to it that much but … 01581.html seems to give some clues.
I would have looked in to it more if Angry birds would not have been adictive.

The RTC still seems be broken.

drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

@Nilfred. No the leds on the wrt350tn2 does not blink to my knowledge.

(Last edited by erik___ on 11 Nov 2010, 02:43)

you can give a try to this.

it is great to see that development for this platform hasn't stopped and that it seems that maddes.b
is back and pushing this project forward big_smile

As I said I will look into the project when time allows.
For the current process other people have to be credited, like Acoul, Kaloz, Nilfred and others.
Just trying to help out when time permits.

As baxter104 in Post #870 mentioned, we have two buttons at the wrt350nv2.
DirkNL added them in wrt350nv2-setup.c.

What I wanted to do, is to activate these buttons and integrate them into the OpenWrt package tools.

When You roam through "menuconfig", You will find these packages
* Kernel Modules -> other modules -> kmod-hotplug-button and
* Utilities -> wifitoggle
and many other kmods regarding GPIO and buttons.

Lets take a look at wifitoggle. It is a script for hotplug and toggles the wifi device.
You find it at /etc/hotplug.d/button/30-wifitoggle.
It also sets some uci - variables, starting with wifitoggle.


points at the button wps

So exactly want I want to use. Wifitoggle needs an adequate system message for button handling.
This delivers the package kmod-hotplug-button. It's an custom kernelmodule in OpenWrt.
It bases on diag.c for broadcom-routers, so I thought it's only for bcm and exactly; it doesn't work for the first try (and some much more).

So I started my journey into the linux platform- and driver model. I'm not a linux-pro, so it was not easy for me to understand all theses mechanism. And when You google around, You will find many solutions with custom GPIO driver for polling and so on.

In post #872 DirkNL explains, that the buttons can be found at /proc/interrups.
But Backfire r23797 only shows me:

  0:      16962   orion_irq  orion_tick
  3:         16   orion_irq  serial
 17:          0   orion_irq  ehci_hcd:usb1
 21:       1700   orion_irq  eth0
 22:       1135   orion_irq  mv643xx_eth
 28:          0   orion_irq  mv_crypto
 36:      15804  orion_gpio_irq  ath9k
Err:          0

no buttons at all in standard backfire.

Then I turned to trunk r23965, because there are some newer programs and some more improvements.

Digging deeper into the newest kernel 2.6.34, I found the kernel driver gpio-keys.
In theory this handles the declared gpio-buttons from wrt350nv2-setup.c.
But in reality, nothing happens.

I found out, that You can give the GPIO keys a key-type, so I added the .type = EV_SW,
because the buttons are in fact switches.

Heureka, first goal. Looking at /proc/interrups shows:

  0:       3450   orion_irq  orion_tick
  3:         14   orion_irq  serial
 17:          0   orion_irq  ehci_hcd:usb1
 21:        105   orion_irq  eth0
 22:        467   orion_irq  mv643xx_eth
 28:          0   orion_irq  mv_crypto
 34:          0  orion_gpio_irq  WPS Button
 35:          0  orion_gpio_irq  Reset Button
 36:          0  orion_gpio_irq  ath9k
Err:          0

So ups, gpio-keys bind the buttons to interrups.

Then I tried to integrate it into kmod-hotplug-buttons, but nothing happens. Maybe the broadcom restriction?
But I also could'nt find anything at cat /sys/devices/platform/gpio-keys/keys or switches.

Turning the WPS Button to type EV_KEY, lets them arrive at gpio-keys.
Second goal!

Finally, the hotplug mechanism fires and let the wifi led switch off.
Match won!!

My cookbook for trunk r23965:

patch the setup and add the key-type EV_KEY:

--- a/arch/arm/mach-orion5x/wrt350n-v2-setup.c
+++ b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
@@ -74,11 +74,13 @@
         .code        = KEY_RESTART,
         .gpio        = 3,
+        .type        = EV_KEY,
         .desc        = "Reset Button",
         .active_low    = 1,
     }, {
         .code        = KEY_WPS_BUTTON,
         .gpio        = 2,
+        .type        = EV_KEY,
         .desc        = "WPS Button",
         .active_low    = 1,

Integrate the kernel module gpio-keys.
I decided to integrate it into the konfig-default at target orion, so patch:

--- target/linux/orion/config-default    (Revision 23967)
+++ target/linux/orion/config-default    (Arbeitskopie)
@@ -98,6 +98,10 @@
 # CONFIG_IDE is not set
 # CONFIG_IP6_NF_MANGLE is not set
 # CONFIG_IP6_NF_MATCH_EUI64 is not set
 # CONFIG_IP6_NF_MATCH_FRAG is not set
@@ -126,6 +130,15 @@
 # CONFIG_LANMEDIA is not set

Note, that kconfig needs the "is not set" lines, otherwise the build needs a userinput and can not run without "V=99".

Then choose Kernel Modules -> other modules -> kmod-hotplug-button in make menuconfig.
This package doesn't deliver a load_module script, so we have to add:



or insmod button-hotplug.ko at comandline.

Please check it and comment, if we should realize this feature in this way.
Next step would be an adequate function to the reset button, maybe a firstboot function.

So, that's all ... for now.
Greetz mrk

@maddes.b nice to see you again, after this long time

15.11.10 new patch for kernel 2.6.36

(Last edited by mrk on 15 Nov 2010, 23:57)

Nice to have buttons on wnr854t, too.
Standard behavior is to enter failsafe, not firstboot directly.

Have a look at OpenWrt's makefiles if some packages already set these config settings. Quicker search possible with this script.
That web folder has some more scripts which I use to speed up my OpenWrt development and searches.

(Last edited by maddes.b on 14 Nov 2010, 01:23)

Btw put some work into the Wiki page for WRT350N v2, especially for the different flashing/recovery methods.
Please have a look and review/correct the text.

I just sent my wrt350nv2 to hell.

Yesterday I had some problems with "sysupgrade".
Don't know why, but my lan connection broke down and flashing fails.

After updating trunk this evening, I found a new patch for upslug2 with wrt350nv2.
My serial connection shows me a checksum error with kernel, so I thought just use upslug2 with --kernel option will bring it back.

I tried:
sudo ./upslug2 -d eth1 -t 00:1d:xx:xx:xx:42 --kernel=openwrt-wrt350nv2-uImage -e l

Upslug2 reboots the machine after flashing. And then I got not have eRcOmM .... enter download mode and flashing power-light on the wrt.
Fortunately we have the recovery-image, mentioned in the wiki.

I used

sudo ./upslug2 -d eth1 -t 00:1d:xx:xx:xx:42 --image=openwrt-wrt350nv2-squashfs-recovery.bin

and succeeded.

So maddes, I can confirm that using upslug2 with option --image recovers the wrt350nv2 safely.
[s]And never, never, never use option -e l. even if upslug2 will mention this.[/s]

25.11.2010 The cause of failure was not option "-e l", but option "--kernel" at all. Only use "--image" and recovery image.

See also post #953

(Last edited by mrk on 25 Nov 2010, 10:46)

Wiki for WRT350N v2 page updated accordingly.

(Last edited by maddes.b on 14 Nov 2010, 10:45)

Description for wrt350nv2 Ver 2.1.

The router reaches download mode:
   a) if eRcOmM is broken
   b) activating via reset button

Variant a) could usually not happen, if you use present OpenWrt and sysupgrade; but can happen if You use upslug2 in a wrong way. (see my last post)

In the net are many tutorials activating download mode for various router, but they all don't fit for my V2.1.

So the right way is:
   1. Unplug power-cable from the router
   2. Press the reset button at the backside
   3. Hold down reset button an power on the router
   4. wait about 1 second - but not longer than three second - and release the button
   5. Observe the power led. If it's blinking green/yellow, You are in download mode. If not - start again with no. 1.

When entering download mode, the router uses the mac address from U-Boot.
This is the one given by linksys and written on the label at the bottom of the router.

So the right mac usually starts with 00:1d...... which is the linksys id.
U-Boot does not use mac 00:00:00:00:51:81.

mrk wrote:

In the net are many tutorials activating download mode for various router, but they all don't fit for my V2.1.

What about the guideline from DaBigMac in this thread, linked as second post in the wiki. Was there anything wrong with it for 2.1?

mrk wrote:

When entering download mode, the router uses the mac address from U-Boot.
This is the one given by linksys and written on the label at the bottom of the router.

So the right mac usually starts with 00:1d...... which is the linksys id.
U-Boot does not use mac 00:00:00:00:51:81.

Correct. Tested with my testing device. Fixed on Wiki page.
The "ethaddr" setting in U-Boot only matters for OpenWrt/Linux not U-Boot (modified build by Linksys).


(Last edited by maddes.b on 14 Nov 2010, 13:42)

maddes.b wrote:

What about the guideline from DaBigMac in this thread, linked as second post in the wiki. Was there anything wrong with it for 2.1?

I think, that waiting for the lan led, could be to late.
U-Boot recognizes, if You power on with reset button pressed. -> Shows You at serial output.
Than it counts down the three seconds.

In this time period (3, 2, 1, ...), You have to release the reset button to enter the download mode.
Releasing later, U-Boot boots the kernel and doesn't take care of the reset button anymore.

DaBigMac wrote about the two seconds, too, but he is waiting for the lan led.
I would say, when You see the power led, just release the reset button.

He, who releases too late, will be punished by power led.
little joke, with a good known cite wink

Btw, maddes, You really know ever corner in this thread, don't you!
As is explained it in the last post, I just read the wrong way on the upslug2 page.

Regarding the different flashing and recovering methods,
I would say, that writing an squash image in U-Boot to flash is an historic path. (Yes I know, I myself explained it last year!)
And should not be recommended, because of the many pitfalls.

Nowadays, I would prefer using upslug2, because You don't need the serial connection.
Or a ramdisk image tftp and bootm it and then use sysupgrade with squash image.

And what about a section with settings for make menuconfig ?
For instance, I ran into a kernel boot error deselecting libgcc.

The other system components needed by wrt350nv2 should be explainted, too.
kmods for led, buttons, crypt, wlan(ath), etc.

Maybe we can discuss a perfect plattform-config for wrt350nv2/orion.


(Last edited by mrk on 14 Nov 2010, 18:54)

First: when looking for WRT350N v2 related, read the wiki page and this thread, not some obscure upslug2 page smile

Booting a ramdisk build via TFP and then do a sysupgrade implies the same requirements as flashing directly in U-Boot. No big difference to me.
But this way could be added to the wiki page too.

Upslug2 with WRT350N v2 support is not available for Windows (like my desktop and the one of most end users), so maybe not the preferred way for the majority of users. Definitely a nice way for developers (remember you have to build it yourself).
Another question when can you use Upslug2 to flash? Always? Or only in Download mode and/or U-Boot and/or OpenWrt/Linux?

The perfect platform config should go to trunk and not to a wiki page. Also this may change from kernel release to kernel release.
Of course the Orion config should be discussed here (e.g. what about CONFIG_OPTIMIZE_FOR_SIZE for the subtarget "generic" (=WRT350Nv2 & WNR854T)).

(Last edited by maddes.b on 14 Nov 2010, 22:18)

I opened Ticket #8271 for gpio-button patch.
Hope it will be accepted.

Upslug2 is only for download mode.
I inspected stock sources from linksys/cisco and found out, that there is a binary from linksys in u-boot to add on this functionality. So it is no origin u-boot feature.

You will find the wrt350nv2 with upslug2 when adding patch

--- a/
+++ b/
@@ -10,6 +13,7 @@
 namespace NSLU2Upgrade {
     /* Hardware ID field, add others as required. */
     static const unsigned char NSLU2ID0[][32] = {
+        {0x59, 0x42, 0x50, 0x00, 0x01, 0x10}, /* WRT350N V2.1 */
         {4, 112, 49, 149, 88, 16}, /* remainder 0 */
         {0x44, 0x47, 0x38, 0x33, 0x34, 0x56, 0x33},  /* remainder 0 */

Just start upslug2 without parameters or with -d - param an You will see the router.
Well it is still named as NSLU, because I didn't changed this.

In wiki I overwrote "getting in download mode", because it's in the section for windows wink
Would be better to shift it at the headline download mode.
There is no need to port upslug2 to windows, I think Upgrage_207_XP is the equivalent.

Today, again I ran into the "kernel exceeds mtd bounds" error.
Kernel was too big and rootfs could not be created.
Maybe it would be a nice idea to add a "touch KERNEL_IS_TO_BIG" warning in bin-dir.
Well, I try a new config.

#1 big kernel
I only get a too big kernel when I compile with symbols enabled.
For a fix see #8183 and its patch trunk_orion_flexible_kernel_mtd_support.patch.

#2 download mode
Yes, download mode is a LinkSys modification, as are the SERCOM marker checks.

#3 upslug2 wrt350n v2.x support
Can you also add name support to it? This would be worth to commit to trunk.

#4 Upgrage_207_XP
Does not work on my Win7 x64 sad
And setting up a virtual machine with bridged network may not be an easy task for the average user.
Maybe a x86 Linux binary for download may work on a Knoppix/Ubuntu/Debian/etc. Live CD.

#5 Wiki
Do not see any change on the Wiki page.
But the move of them points up for fit better, additionally some typos should be fixed.
Update: Wiki page updated accordingly. Please review/edit.

(Last edited by maddes.b on 19 Nov 2010, 00:56)