OpenWrt 22.03 and WDR4900v1

[urkelbundy]

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

[simpz]

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.

[simpz]

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?

[urkelbundy]

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

[simpz]

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

[hurricos]

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.

[hurricos]

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.

[hurricos]

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.

[urkelbundy]

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.

[simpz]

@urkelbundy Delighted to chip in, please message me details.

[dabyd64]

I also have this router since long time ago, recently I decided to try boosting its power.
After diving in the datasheet, I found the bootstrap pins that set the multipliers.
From 800MHz.. I got it running at 1.2GHz on the first try.
Finally, after slightly increasing the Vcore by +50mV, I reached the maximum multiplier, 1.4GHz!

Here're the modding details:

Now I thought on removing the old wireless chips.
They use PCIe, so I see no reason why it wouldn't be possible to carefully hardwire a mini PCIe slot and connect something else that uses modern 5G wifi AC, as long as Openwrt has drivers for it.

Also, it should be possible to re-configure the Serdes interface used for 2.4G wifi PCIe, and repurpose it as SATA, or keep it as PCIe and connect a USB 3.0 PCIe card, samba shares would fly!

[boq]

Hi. I do have 3 of the WDR4900V1 devices in use.
They are running fine and without any problems.
It would be great if you could make them to work with 22.03 !
Thanks for your support!

[slh]

For 22.03.x, the ship has sailed - 23.xy.z might be possible, if it gets fixed in master.

[urkelbundy]

Hi all,

The WDR4900v1 has been dropped at the postoffice today and is underway to hurricos.

@hurricos
No pressure but all eyes of WDR4900v1 users are on you
Many many many thanks in advance on behalf of all WDR4900v1 users.

@dabyd64
That is very interesting. Maybe I will try this on a spare unit.
Won't the CPU get hot at 1GHz or higher?

[dabyd64]

A little more, but I think it's manageable, about 0.2W each 200MHz.
These measurements where the whole router consumption, not just the cpu!

CPU stressed running: time dd if=/dev/zero bs=1M count=1024 | md5sum

Idle: ~480mA on all frequencies, 5.8W
Stress 0.8GHz 26s (39.4MB/s) 500mA 6.1W
Stress 1.0GHz 21s (48.8MB/s) 520mA 6.3W
Stress 1.2GHz 18s (56.9MB/s) 535mA 6.5W
Stress 1.4GHz 16s (64.0MB/s) 550mA 6.7w

I attached a thermal probe to the heatsink with a bit of thermal paste, closed the case and ran it at full load for 20 minutes, I'm getting ~60ºC, so it's fine!
Perhabs it could get around 70-75ºC on a hot day, not dangerous temps, pretty comon for this devices.
You can always replace the heatsink with a larger one!

[dabyd64]

Later I decided to lift the cpu to see the pins and check if there was some hackable stuff.
Sadly there're no possibilities, the 4th serdes interface (pcie,sata etc) is disabled and tied to ground, the SD interface pins aren't accessible...

I identified the rest of the boostrap pins, attaching the final modding pictures, if someone could add them to the wiki it would be nice.

The cpu speed seem to be hardcoded in some parts of the kernel, I still have some logs showing 800MHz:

[    0.000000] time_init: processor frequency   = 799.999992 MHz

Also

cat /proc/cpuinfo
processor       : 0
cpu             : e500v2
clock           : 799.999992MHz
revision        : 5.1 (pvr 8021 2151)
bogomips        : 99.99

timebase        : 49999999
platform        : Freescale P1014
model           : TP-Link TL-WDR4900 v1
Memory          : 128 MB

But the performance gain is clearly obvious when hashing md5.
I set the memory to DDR-800, seems to be working nicely for now , another slight performance increase (5% faster md5sum, went from 16s to 15.2s).
It seems stable, I hashed 100GB of data several times with same results.

[simpz]

@hurricos Just out of curiosity, and not hassling as all, did the router arrive yet?

[hurricos]

It has not.

Wait, I just checked the tracking -- apparently it arrived at 9AM, after I'd left for work. I'll take a look tonight.

[urkelbundy]

Yes, according to the track&trace it has arrived.

[xabolcs]

FYI: @CHKDSK88 has opened a PR:

mpc85xx: TP-Link TL-WDR4900 v1 resurrect and convert to DSA

He got the U-Boot patch hint from @hurricos :

mpc85xx: Patch HiveAP 330 u-boot to fix boot