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.

Has anyone already created a WRT350Nv2 config for the U-Boot envtools? (opkg install uboot-envtools)

I get some output with the following /etc/fw_env.config but I do not know if this is 100% correct (I do not dare to write yet):

# WRT350N v2
# MTD device name    Device offset    Env. size    Flash sector size
/dev/mtd5        0x0003c000    0x00002000    0x00001000

What the output should look like can be seen in post #5 (3rd code part).

Update:
The first three entries are correct. (Will re-check in Linksys GPL source if time allows)
The fourth parameter is questionable. Writing is not possible, maybe due to the big mtd erase size of 0x00010000 (a zero more behind the one).
Can the erase size be reduced/changed for /dev/mtd5 only?

(Last edited by maddes.b on 14 Jun 2010, 17:43)

@maddes.b: Thank you! Thank you! Thank you! I'm able to compile trunk with no issues.

From Nilfred post#858:

Erik's (rectified) patch for the mwl8k driver from ticket #7209 was committed to trunk with r21167.
Hunting season for AP firmware is now officially open.

I have seen another thread talking about the firmware for the wireless in the WNR854T, but am unable to find it at the moment. Is anyone working on this? I am willing to help out testing, or digging through code (I'm no programmer), or lending access to hardware. How can I help in this area?

Thank you

(Last edited by jcwoltz on 27 May 2010, 00:55)

It's all set, but AP firmware missing.
Right now you can use it in STA mode.
The driver checks if firmware is AP or STA mode, can't be fooled.
Go help upstream or ask Marvell directly. Also apply for the job, as both developers left Marvell.

(Last edited by Nilfred on 27 May 2010, 13:32)

mwl8k author speaking.  (I don't generally monitor this forum, but was sent a link to this thread.)

First of all, the linked patch in r21167 isn't really correct -- PCI ID 0x2a02 corresponds to a 8361P card, not a 8363 card. Is this patch confirmed to make mwl8k work on the WNR854T (which seems to contain a 8361P) in STA mode? Can anyone post a full dmesg of that happening somewhere?

The difference between AP and STA firmware is not merely a magic bit that "unlocks" AP functionality in the driver -- STA firmware simply doesn't contain the necessary logic to implement AP mode.

Also, Nicolas Pitre (which I assume you're referring to) and I didn't leave Marvell because of being fired.

Nice to hear from you.
As you can see here is firmware 8XX0 loaded, renamed to 8363, working.
Does 8361P AP firmware exist? Even the extracted from original firmware seems to be an STA one.
OK, I edited the last (incorrect) sentence.

Hi Lennert.

The 8361P (PCI ID 0x2a02) works with fw:48c79b085f7f5a590d3dbc15647e519f in STA mode.
It seems a bit buggy/slow and I havent had the time to do complete performance testing on it yet. ( Thats why i didnt post it upstreams.).

I can only refer to FW files by the md5sums because I cant find the fw that the driver is refering to.
What is the hashes of the FW files that the driver refers to, and where can I find them?
If you cant include the fw files in the kernel tree because of legal reasons, could you maybe refer to them by hashes instead of names like 8363, 8687 etc?
This would really help when we extract them.


Example:
MODULE_FIRMWARE("mwl8k/48c79b085f7f5a590d3dbc15647e519f.fw");
MODULE_FIRMWARE("mwl8k/0fe11f415adbbd5e8ca03641705c4a6c.helper.fw");
instead of:
MODULE_FIRMWARE("mwl8k/fmimage_8363.fw");
MODULE_FIRMWARE("mwl8k/helper_8363.fw");


The dmesg from my wnr854t with fw:48c79b085f7f5a590d3dbc15647e519f and helper:0fe11f415adbbd5e8ca03641705c4a6c is

Marvell TOPDOG(R) 802.11 Wireless Network Driver version 0.12
phy0: Selected rate control algorithm 'minstrel'
phy0: 88w8363 v4, 00:18:4d:20:2a:bf, STA firmware 2.1.4.25

Im happy to provide any additional dmesgs or help.

Thanks for your work on mwl8k!
Erik.

(Last edited by erik___ on 27 May 2010, 22:26)

The "linkstation kernel" is for the 88F5182, and there are upstream patches for 88F5281. For the Orion 1, there is no other sources then the Linkys/Netgear ones.
Offline

Side note:
The MAC changing issues (#7111) are now solved in trunk (r21577, r21595) and also for Backfire 10.03.1 (r21581, r21596).

Erik,

mwl8k doesn't refer to any 8361P firmware files at all, so the question what the hashes are of the 8361P firmware files that mwl8k refers to is something I can't answer. smile

Even for the currently supported chips, 8363 and 8366, the idea is that you can use any firmware version as long as it conforms to the firmware interface API/ABI that mwl8k supports. Referring to firmware images by md5 sum would break this capability. The firmware images are referred to by chip name intentionally, as this allows easy identification of what chip a given firmware image is for.

The last patch I saw floating around for 8361P support in mwl8k breaks 8363 support, or at least, breaks being able to use 8361P and 8363 concurrently. If you want to add 8361P support, you should do something like this:

   http://www.wantstofly.org/~buytenh/mwl8k-8361p.diff

(and name the firmware image files accordingly).

Can you post a full dmesg somewhere (i.e. of _all_ the kernel boot messages on your machine including the mwl8k bits)?

Also, can you email me the 8361P helper and firmware images you extracted?

Firmware isn't included in the kernel tree anymore, there's the linux-firmware git tree for that these days. I will contact some people at Marvell to ask whether 8361P firmware can be included there.


thanks,
Lennert

Lennert,

I know that I shouldnt have paired the 0x2a02 pci id with the name fmimage_8363.fw.
My misstake. I will remove the patch.

The reason that I wanted to include the hashes of the fw was so it would be easy for us to identify them after extraction.
Can you get the FW files any other way? They are not in the linux-fw-git-tree. How did you get yours?
So far we have used the mrv8k_extract_fw tool as our only source for FW.
( Im talking about the regular 8363, 8687, 8366 fw )

I will send you the FW-files I used.


Full demsg:

Linux version 2.6.32.12 (erik@thinkpad) (gcc version 4.3.3 (GCC) ) #3 Wed May 5 22:22:43 CEST 2010
CPU: Feroceon [41069260] revision 0 (ARMv5TEJ), cr=a0053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Netgear WNR854T
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
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 8192
free_area_init_node: node 0, pgdat c0249a08, node_mem_map c025b000
  Normal zone: 64 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 8128 pages, LIFO batch:0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128
Kernel command line: root=/dev/mtdblock1 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 32MB = 32MB total
Memory: 30076KB available (2144K code, 132K data, 92K init, 0K highmem)
Hierarchical RCU implementation.
NR_IRQS:64
Calibrating delay loop... 332.59 BogoMIPS (lpj=1662976)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
Orion ID: MV88F5181-Rev-B1. TCLK=166666667.
Applying Orion-1/Orion-NAS PCIe config read transaction workaround
pci 0000:00:00.0: reg 10 64bit mmio pref: [0xf1000000-0xf10fffff]
pci 0000:00:00.0: reg 18 32bit mmio: [0x000000-0x1ffffff]
PCI: bus0: Fast back to back transfers disabled
pci 0000:01:00.0: reg 10 64bit mmio pref: [0x000000-0x1ffffff]
pci 0000:01:00.0: reg 18 64bit mmio pref: [0x10000000-0x1fffffff]
pci 0000:01:00.0: reg 20 64bit mmio: [0xf1000000-0xf10fffff]
pci 0000:01:00.0: reg 30 32bit mmio pref: [0xe0000000-0xe7ffffff]
pci 0000:01:00.0: supports D1 D2
pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot
pci 0000:01:00.0: PME# disabled
pci 0000:01:07.0: reg 10 32bit mmio: [0x40000000-0x4000ffff]
pci 0000:01:07.0: reg 14 32bit mmio: [0x40010000-0x4001ffff]
PCI: bus1: Fast back to back transfers enabled
bio: create slab <bio-0> at 0
Switching to clocksource orion_clocksource
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
NET: Registered protocol family 1
squashfs: version 4.0 (2009/01/31) Phillip Lougher
Registering mini_fo version $Id$
JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
msgmni has been set to 58
io scheduler noop registered
io scheduler deadline registered (default)
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 3) is a 16550A
console [ttyS0] enabled
physmap platform flash device: 00800000 at f4000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
 Intel/Sharp Extended Query Table at 0x0031
 Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
erase region 0: offset=0x0,size=0x20000,blocks=64
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Using physmap partition information
Creating 4 MTD partitions on "physmap-flash.0":
0x000000000000-0x000000100000 : "kernel"
0x000000100000-0x000000760000 : "rootfs"
mtd: partition "rootfs" set to be root filesystem
mtd: partition "rootfs_data" created automatically, ofs=260000, len=500000 
0x000000260000-0x000000760000 : "rootfs_data"
0x000000760000-0x0000007a0000 : "uboot"
0x000000000000-0x000000760000 : "image"
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
i2c /dev entries driver
TCP westwood registered
NET: Registered protocol family 17
Distributed Switch Architecture driver version 0.1
eth0[0]: 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>
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
VFS: Mounted root (squashfs filesystem) readonly on device 31:1.
Freeing init memory: 92K
Please be patient, while OpenWrt loads ...
mini_fo: using base directory: /
mini_fo: using storage directory: /overlay
eth0: link up, 1000 Mb/s, full duplex, flow control disabled
device lan3 entered promiscuous mode
device eth0 entered promiscuous mode
device lan4 entered promiscuous mode
device lan1 entered promiscuous mode
device lan2 entered promiscuous mode
Generic kernel compatibility enabled based on linux-next next-20100113
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Marvell TOPDOG(R) 802.11 Wireless Network Driver version 0.12
phy0: Selected rate control algorithm 'minstrel'
phy0: 88w8363 v4, 00:18:4d:20:2a:bf, STA firmware 2.1.4.25
PPP generic driver version 2.4.2
ip_tables: (C) 2000-2006 Netfilter Core Team
NET: Registered protocol family 24
nf_conntrack version 0.5.0 (471 buckets, 1884 max)
lan3: link up, 1000 Mb/s, full duplex, flow control disabled
br-lan: port 1(lan3) entering forwarding state
egisteredlash.0: Found 1 x16 devices at 0x0 in 16-bit bank
io scheduler deadline registered (default)
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 3) is a 16550A
console [ttyS0] enabled
physmap platform flash device: 00800000 at f4000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
 Intel/Sharp Extended Query Table at 0x0031
 Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
erase region 0: offset=0x0,size=0x20000,blocks=64
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Using physmap partition information
Creating 4 MTD partitions on "physmap-flash.0":
0x000000000000-0x000000100000 : "kernel"
0x000000100000-0x000000760000 : "rootfs"
mtd: partition "rootfs" set to be root filesystem
mtd: partition "rootfs_data" created automatically, ofs=260000, len=500000 
0x000000260000-0x000000760000 : "rootfs_data"
0x000000760000-0x0000007a0000 : "uboot"
0x000000000000-0x000000760000 : "image"
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
i2c /dev entries driver
TCP westwood registered
NET: Registered protocol family 17
Distributed Switch Architecture driver version 0.1
eth0[0]: 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>

//Erik

Erik,

Firmware images for 8687 exist in the linux-firmware git tree:

   http://git.kernel.org/?p=linux/kernel/g … e665247a73

Firmware for 8363 and 8366 (and possibly 8361 as well) should ideally also be obtainable from the linux-firmware git tree in the future.  I will work to try to make this happen.

How well does mwl8k in its current state work on your 8361 card?  Can you associate/ping/etc?


thanks,
Lennert

buytenh wrote:

Erik,

Firmware images for 8687 exist in the linux-firmware git tree:

   http://git.kernel.org/?p=linux/kernel/g … e665247a73

Firmware for 8363 and 8366 (and possibly 8361 as well) should ideally also be obtainable from the linux-firmware git tree in the future.  I will work to try to make this happen.

How well does mwl8k in its current state work on your 8361 card?  Can you associate/ping/etc?


thanks,
Lennert

I can do pretty much everything with it at a limited speed.
associate, ping, transfer files, etc.
[edit]
I actually forgot to mount the antennas wink. Turns out speed is great. 2MB/s at 10cm distance.
[/edit]

Yes, getting the FW in the linux-fw-tree would be great!
BTW, I just managed to extract the real 8361P AP fw from a binary only driver anyway. So it would only be goodwill for Marwell to release them.

//Erik

(Last edited by erik___ on 30 May 2010, 15:36)

Low yours weapons: Hunting AP season in now officially ended. THANKS Erik.

buytenh wrote:

Erik,
<cut>
If you (Erik, us, not Lennert) want to add 8361P support, you (again) should do something like this:
<cut>
thanks,
Lennert

@Erik, I read between lines that's your baby now. So, do not remove, replace the patch without mention where you get it from.
Go, Erik, go!

@buytenh, THANKS. Please confirm if this only be know to archive.org and self-destroy in 10 seconds.

Erik,

2MB/s (I assume you mean megabyte here) doesn't seem all that great -- as this is 11n capable hardware, you should be able to get a lot more than 16 megabit out of it. Do you get the same performance with other APs (if you have any)?

Nilfred,

If I had 8361 hardware myself I wouldn't mind doing the work myself to try and get this working, but I don't, so what I can contribute here is somewhat limited.  I'll see if I can get a 8361 card somewhere.


thanks,
Lennert

I expanded the wiki, explaining the download mode a bit less verbosely than DaBigMac did, for people like me with too little time on their hands wink

Also in my explanation I recommend simply flashing the openwrt recovery.bin as opposed to the stock linksys one.

http://wiki.openwrt.org/toh/linksys/wrt … nload.mode

(Last edited by StrikerNL on 31 May 2010, 18:06)

Compiled latest Backfire branch r21649 for Orion, and uploaded to ftp://ftp.maddes.net/openwrt/backfire/orion/
As always use at your own risk and keep a local copy of the repository as this ftp space is just temporary until final release of 10.03.1.
Remember that you can test a ramdisk image via tftpboot if you have serial access.

The general and WRT350Nv2 MAC fixes have been committed into trunk and the Backfire branch.

@StrikerNL:
Thanks a lot.
But you should use the "Preview" function a little bit more often. smile

(Last edited by maddes.b on 6 Jun 2010, 15:43)

Well done, maddes. I hope backfire 10.03.1 will be released soon so we can finally put this mac address misery behind us.

Compiled latest trunk r21682 for Orion with kernel 2.6.34, and uploaded to ftp://ftp.maddes.net/openwrt/trunk/orion/
As always use at your own risk and keep a local copy of the repository as this ftp space is just temporary until final release of 10.03.1.
Remember that you can test a ramdisk image via tftpboot if you have serial access.

(Last edited by maddes.b on 6 Jun 2010, 15:58)

I've started using the wireless in my router regularly, and it's dying every few days now. A simple 'wifi' fixes it for a few minutes, but then it stops again. Also, speed when it is working drops to about a tenth of normal: 200kiB/s vs nearly 2MiB/s on 802.11g. This is my /etc/config/wireless:

config 'wifi-device' 'phy0'
    option 'type' 'mac80211'
    option macaddr    00:xx:xx:xx:xx:xx
    option 'channel' '6'
    option 'hwmode' '11ng'
    option 'htmode' 'HT20'
    list 'ht_capab' 'SHORT-GI-40'
    list 'ht_capab' 'DSSS_CCK-40'
    option 'country' 'AU'

config 'wifi-iface'
    option 'device' 'phy0'
    option 'network' 'lan'
    option 'mode' 'ap'
    option 'ssid' 'redacted'
    option 'encryption' 'mixed-psk+ccmp'
    option 'key' 'redacted'
    option 'eap_type' 'TLS'

(Last edited by Watha on 12 Jun 2010, 11:54)

If a "wifi up" doesn't fix it, then try a daily reboot as mentioned in post #751.
Also try "11g" mode only (no N mode).

(Last edited by maddes.b on 12 Jun 2010, 14:04)

maddes.b wrote:

If a "wifi up" doesn't fix it, then try a daily reboot as mentioned in post #751.
Also try "11g" mode only (no N mode).

A daily reboot would fix it, but I dislike having my connections interrupted. I'll try 11g mode.

Watha wrote:
maddes.b wrote:

If a "wifi up" doesn't fix it, then try a daily reboot as mentioned in post #751.
Also try "11g" mode only (no N mode).

A daily reboot would fix it, but I dislike having my connections interrupted. I'll try 11g mode.

As maddes says, switching 11ng to 11g mode will likely fix it. We have multiple devices, and the wifi devices seem to differ between 2.0 and 2.1. On some of these it seems it will only work well with mode set to 11g, and for some it will only work well with mode set to 11ng. This is what I've experienced anyway.

Absolute newbie here... Please forgive if it is off-topic or has been answered.

I have a WNR854T that I originally flashed with http://downloads.x-wrt.org/xwrt/backfir … pgrade.img from the stock Netgear web ui.

As a result of doing so, I lost the ability to upgrade further, and the flashing page said that the functionality has not been implemented.

So I tried the flashing method described in post #764 to the (then) latest backfire build (r20728).
But now I still cannot update further using sysupgrade or via luci.

Here are some info from my router:

root@WNR854T:/lib/upgrade# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "kernel"
mtd1: 00660000 00020000 "rootfs"
mtd2: 004c0000 00020000 "rootfs_data"
mtd3: 00040000 00020000 "uboot"
mtd4: 00760000 00020000 "image"


root@WNR854T:/lib/upgrade# cat platform.sh
# use default "image" for PART_NAME
# use default for platform_do_upgrade()

platform_check_image() {
        [ "${ARGC}" -gt 1 ] && { echo 'Too many arguments. Only flash file expected.'; return 1; }

        local hardware=`sed -n /Hardware/s/.*:.//p /proc/cpuinfo`
        local magic="$(get_magic_word "$1")"

        case "${hardware}" in
         # hardware with padded uImage + padded rootfs
         'Netgear WNR854T' | 'Linksys WRT350N v2')
                [ "${magic}" != '2705' ] && {
                        echo "Invalid image type ${magic}."
                        return 1
                }
                return 0
                ;;
        esac

        echo "Sysupgrade is not yet supported on ${hardware}."
        return 1
}


root@WNR854T:/lib/upgrade# cd /tmp
root@WNR854T:/tmp# wget http://downloads.openwrt.org/backfire/1 … uashfs.img
Connecting to downloads.openwrt.org (78.24.191.177:80)
openwrt-wnr854t-squa 100% |***************************************************************************|  2816k 00:00:00 ETA
root@WNR854T:/tmp# sysupgrade -n -v /tmp/openwrt-wnr854t-squashfs.img
Invalid image type 8519.
Image check 'platform_check_image' failed.


root@WNR854T:/tmp# wget http://downloads.x-wrt.org/xwrt/kamikaz … uashfs.img
Connecting to downloads.x-wrt.org (88.198.39.176:80)
openwrt-wnr854t-squa 100% |***************************************************************************|  3200k 00:00:00 ETA
root@WNR854T:/tmp# sysupgrade -n -v /tmp/openwrt-wnr854t-squashfs.img
Invalid image type 8519.
Image check 'platform_check_image' failed.

Any idea what to do next? I'd like to
[1] Either go back to stock firmware till wireless is implemented [or]
[2] At least have the ability to sysupgrade or use the luci upgrade interface.
Also,
[3] Is there a way to set the boot_wait on this router? I tried to tftp a firmware from a connected PC, but without boot_wait, it is not happening?


Thanks in advance

(Last edited by redhat27 on 15 Jun 2010, 18:43)

Just downloaded an official Backfire release [1] and an image of my latest trunk build [2].
Both had an extra header before the U-Boot image, so the correct magic word seems to be "8519".

Can somebody explain if this is a standard, Netgear specific or WNR854T specific header?
Must the header be removed before flashing?

Change the platform.sh to the following code and retry at your own risk as the extra header my brick your router:

...
      case "${hardware}" in
         # hardware with padded uImage + padded rootfs
         'Linksys WRT350N v2')
                [ "${magic}" != '2705' ] && {
                        echo "Invalid image type ${magic}."
                        return 1
                }
                return 0
                ;;
         # special hardware with extra header before uImage
         'Netgear WNR854T')
                [ "${magic}" != '8519' ] && {
                        echo "Invalid image type ${magic}."
                        return 1
                }
                return 0
                ;;
        esac
...

[1] http://downloads.openwrt.org/backfire/1 … uashfs.img
[2] ftp://ftp.maddes.net/openwrt/trunk/orio … i+ipv6.img

(Last edited by maddes.b on 15 Jun 2010, 14:27)

Thank you very much maddes for helping me, I will edit platform.sh to allow for 8519 magic word. Any idea what is the probability that this extra header may brick my router? I don't have jtag... smile Also, I am in North America, I noticed Netgear have a separate firmware just for here. Not sure if if the hardware for North America and rest of the world is different on the WNT854T...

Also, I'm guessing there is no way to make the WNR854T wait for a firmware image on booting? No nvram variables to manipulate to set boot_wait on?