OpenWrt 22.03 and WDR4900v1

Hi devs,

Is there any news on the TP-Link WDR4900v1 going to be supported by OpenWrt 22.03?
This unit has enough RAM and flash storage but there seems to be an issue with the flash layout if I understand it correctly.
I have a couple of these units running on 21.02.3 and would like to keep them running OpenWrt with newer builds in the future.
Can anyone put some effort in it to get the WDR4900v1 supported?

Many thanks and best regards,
Peter

That would be sad. I have 6 of those units and they never let me down. They have a stable connection on 2.4GHz compared to the Archer C7 v2 that has stability issues with ESP8266 units.

The post you showed mentioned that wireless is out dated. Maybe that is so compared to modern routers but other routers that are supported have the same or less specifications and 450Mbs at 5GHz is more than enough to use on a 100Mbs internet connection.
The SOC is indeed powerful. I get better performance out of the WDR4900v1 than out of Archer C7 v2, v4 and v5. So there may be specs that are out-dated compared to modern units, but there is enough in this WDR4900v1 worth keep it running.

A compile setting was mentioned that seems to help (for now).
CONFIG_KERNEL_CC_OPTIMIZE_FOR_SIZE=y

I have no idea what to do with this setting and it would be great if I could download an image for the WDR4900v1

Are there other models that have the same kernel size issue? I can imagine that the WDR4900v1 is not the only one and that it is worth saving those units by developing a fix.
If necessary for a dev, I can supply a WDR4900v1 unit.

Best regards,
Peter

1 Like

We are using some WDR4900 in our family with 21.02.* too. To keep the effort as low as possible I would like to use the same OpenWrt Version on all those devices (WDR4900, Archer C7 V5, NanoPi R2S, NETGEAR GS308T, AVM 4020, x86_64).

The WDR4900 are the most reliable devices I ever used.
5GHz ? Seems to be a publicity stunt to me. Its mostly useless, since most clients (like the lawn mower, all my IOT devices) support 2,4 GHZ only.

So I would be very dissapointed if the WDR4900 are not supported in 22.03.

And because I don't have the money to replace all the WDR4900, no support means to me: Stay at 21.02.* with all devices in the family as long as possible :frowning:

You really want 22.03~ on x86_64, gs308t and r2s - and c7-v5, 4020 won't have any problems with 22.03~ either. Currently there is no future for the wdr4900, while chances are non-zero, it's very unlikely to be fixed (probably never at all).

Hello,

Any newses about possibilities to have 22.03 on WDR4900v1? I saw v2 have posibility to download image.

Regards

Note that the WDR4900 v1 has a JTAG port -- the 16-pin set of headers here.

I have the tools I need to build a u-boot replacement: U-Boot replacement for mpc85xx (e.g. HP MSM466)

... I just haven't found the time to do so.

I'm sure we'd all appreciate if you get time to look at this. I think quite a few of us have WDR4900 v1's and now we have run out of road, so will be creating more e-waste.

Plus the fact that I'd personally switch to a RPi4 next for 22.03, but they are impossible to get just now...so would be nice to keep the old router going for longer, until supply chain issues improve.

Is there anyone here in the United States that could ship me one of these?

In the staging tree of @NeoRaider you will find a second stage bootloader for the wdr4900:
https://git.openwrt.org/?p=openwrt/staging/neoraider.git;a=shortlog;h=refs/heads/mpc85xx-spi-loader

Not sure why this did not find its way to upsteam OpenWrt. Maybe it still needs some work to finish it.

1 Like

@PolynomialDivision
That is good news. How do we proceed from here? Is a dev going to pick this up and make it work?
Can we give someone a little push?

@hurricos
That is also good news. I'm not fully aware of the impact of your approach and if it is feasible but please continue with your work.

Any solution for the WDR4900 v1 is more than welcome.
I can't believe the WDR4900 v1 is the only unit that has issues with large kernels and flash layout, there must be more out there. I assume this issue has been dealt with before and will probably will come for other units in the future.
It is a waste to throw all these units in the bin while they have plenty RAM and FLASH.

I would like to encourage any dev that is capable of fixing this to do so. The best approach of course is that devs join forces to develop the best solution.

I don't have a spare WDR4900v1 in the US. But if we see one on ebay or elsewhere just now at a reasonable price (even $70-$80) happy to purchase for a dev willing to work this issue.

I can't see a WDR4900v1 anywhere worldwide on ebay. Anyone have an unused one that can be donated to the cause of getting this working with 22.03?

I will see what I can find.
Do you have a suggestion to which dev to send a unit if we can find one?

hurricos seems to be willing to work on this with a donation.

A second stage bootloader solution, as mentioned by someone else, sounds like a solution that doesn't change the layout of the flash so it is possible to go back to previous firmware versions or even stock firmware.

I will not be working with a second-stage bootloader: "RAM" boot for mpc85xx is far from usable in mainline U-boot, and the mpc85xx target is already the only target that already needs a 4K TPL to boot the 64K SPL to boot U-boot. It's too many moving parts. I'm going to be building a U-boot replacement; U-boot can be overwritten from a live system, though without proper checks there is a risk of bricking.

Does your solution with a u-boot replacement change the flash layout. in other words, can you go back using older firmwares or even stock or is it a one way street?

It will most likely be a two-way street -- I'll have to look more closely at the partitioning layout to confirm -- but you should just need to

  1. boot an older, working OpenWrt,
  2. backup the original u-boot,
  3. insmod mtd-rw i_want_a_brick=yes
  4. Erase and rewrite the bootloader partition with the new, freshly-compiled mainline U-boot
  5. fw_setenv to set change the bootcmd
  6. sysupgrade to the target OpenWrt

The reversion to pre-upgrade OpenWrt is the same thing, just booting a newer OpenWrt and writing the old U-boot and U-boot environment, then sysupgrading to the old OpenWrt.

But this all depends on the feasibility of reusing the partition layout; my fix for booting on the Aerohive HiveAP 330 has the same issue; in that case we needed to change the partition layout, because stock U-boot had an upper limit on the size of the compressed kernel which conflicted with the partition size.

Can you give me a rough estimate when you may have a working solution?

I have no idea. It will be around the same time that I get U-boot working for other mpc85xx boards; see this thread.

Is this solution a one time solution or will future OpenWRT images adapt your solution?

My plan is to build U-boot compilation into the OpenWrt buildsystem, sharing the build toolchain, as is done with e.g. kirkwood boards. I will also test U-boot from time to time, and should an updated U-boot brick the board, can recover the board using my BDI2000.

Across the board, vendor mpc85xx u-boots have various issues - another example is on the AP3825i. I really would prefer to unify all of these so we can stop struggling to keep board support going.

For what it's worth: back in 2019, @blocktrron had ramboot building for mpc85xx, but he did not have time to balance that against Uni studies and has since put the laptop in question into storage. The WDR4900v1 has extensive application in the Freifunk network, because the P101X in it was much faster than other contemporary boards.

I want the solution to be able to be deployed remotely without opening the board up or needing to interact with U-boot directly, but I also want it to be maintainable longer-term. Those are my only two goals: ease of reversion to stock is entirely secondary to me.

Thank you for this. I did not see @NeoRaider's work on lzma-loader. This was my initial strategy -- MANY ramips and ath79 boards use the same strategy, mostly because the solution is not invasive -- but I did not have enough experience working with PowerPC assembly (c.f. head.S) to do this.

I still want a U-boot replacement for the mpc85xx, but this solution is much easier to debug the same machinery, since as I mentioned I don't yet have stock mpc85xx U-boot working.

Edit: Nor did I even realize that the WRD4900v1 uses SPI-NOR, which as the commit mentions, is not memory-mappable -- only NOR devices addressed over the eLBC are. Again, I never got anywhere near as far; I had no idea where to start.

Good news. I received a WDR4900v1. It was a bargain. EUR15 for the WDR4900 and EUR6 to ship it to my location. Schipping it from the Netherlands to the US will cost around EUR25.
I would appreciate it if the fellow WDR4900v1 users would assist in these costs. Send me a PM. Thanks in advance.

It is a funny unit. It has 3 different antennas. Seems to be working fine though.

I will ship this WDR4900 unit to hurricos probably this weekend. Will let you know when it is shipped.

1 Like