u-boot_mod
u-boot_mod copied to clipboard
pepe2k
initial support for TP-Link Archer C7 v1 & AP135 - QCA9558
a set of commits to support QCA9558. tested for more than 48hours on Archer C7 v1 - no issues
Signed-off-by: Tomislav Požega [email protected]
Works great for me on my Archer C7 V2 as well. Thanks for that, but could we merge this ever? I received a request in a private message to share my binary build. Here you go: u-boot_tp-link_archer-c7_v1.7z I followed the steps from the readme file while I was using GCC from the openwrt-sdk-19.07.3-ath79-generic_gcc-7.5.0_musl.Linux-x86_64.tar.xz package.
***************************************
* U-Boot 1.1.4--clean *
* Build: 2020-07-03 *
***************************************
** Warning: bad env CRC, using default,
use 'saveenv' to save it in FLASH
BOARD: TP-Link Archer C7 v1
SOC: QCA9558 ver. 1 rev. 0
CPU: MIPS 74Kc
RAM: 128 MB DDR2 32-bit CL5-4-4-12
FLASH: 16 MB Winbond W25Q128
PCIe: no device, 168C:003C
MAC: 80:89:17:3A:CE:4A
CLOCKS: CPU/RAM/AHB/SPI/REF
720/600/200/ 25/ 40 MHz
still some minor bug, see PCIe: no device, 168C:003C
PCIe: PCIe slot 0, PCIe slot 1
great work! better than original tplink uboot!! It works in my chinese version of wdr7500 ver3.0 I mod it to 16MB w25q128, with archer C7 v2 openwrt, without questions!
Also works great on four of my C7v2 - no surprise at all, since hardware differs basically only by Wi-Fi card on those. A ton of great work!
After testing for a while, two out of four C7v2 exhibited RAM corruption issues and restarted up to a few times per day, so I had to revert them. There are actually some minor differences between C7v1 and v2, like flash size, aside from the obvious AR1A vs BL1A 5GHz Wi-Fi, which is out of scope for U-boot.
any specific configuration on these two units in regard to the other two? did all the units ran the same firmware image? have you overclocked any of them?
I would have to check exact HW revisions - I'll do so and post them here later today or tomorrow. I didn't overclock any of them. All ran exactly the same build of OpenWrt.
I wasn't referring to HW revision, but rather on software configuration e.g. WiFi mode AP/client/WDS, or Ethernet config bridge/WAN etc. Also how were you able to determine the cause is RAM corruption, did you save any logs?
I do have logs, thanks to remote syslog, I just need to dig them out.
3 devices work as routers, all serving >1 SSID over both bands, and one device works as AP behind one of routers, serving the exact same SSIDs as the router - and was one of failing devices. It served 4 SSIDs per band, the same as its parent router. The other failing device was a router serving 2 SSIDs on 2.4GHz band, and one on 5GHz. Load and traffic on them was minimal.
Regarding memory corrpution, it manifested itself as:
- warnings from kernel regarding corrupted pages
- sporadic errors from
memtester- unfortunately I didn't save that. - Crashes, around once per day., but of course - this varied quite heavily. Other two devices ran without problems for two weeks, interrupted only once for sysupgrade.
In near future I'll try to open them up and compare memory chips soldered on board, they might differ with timings ever so slightly - this might take some time, as they are all in active use and I have no spare unit at the moment to swap one out.
Came across my mind too. These devices usually come with different RAM chips even in the same revision. At least I've seen winbond and zentel versions, possibly there are ESMT or hynix too... Another idea is that memory is failing, if it doesn't crash with factory u-boot try keep running them for a while to see if it will be fully stable or it will crash at some point
Edit: take a look here too https://github.com/pepe2k/u-boot_mod/pull/120
That's my plan - I'll let them run for a while to double check - I don't recall any stability issues before installing u-boot_mod.
Both routers affected previously are running stable for 5 days now on stock U-boot, and the same OpenWrt build as previously. I plan to swap two devices, to get the affected device in home and test the build with 2CL+1 gate open latency.
I bought another Archer C7v2 (couldn't resist...) so soon I'll have another device just to play around with this ;-)
For the past two weeks, my devices were running fine on stock U-boot. 3 days ago I updated them to test build with increased gate open latency to 2CL+1 (#120), and all units are fine so far. I wonder why all 11 of WDR4300 I had are fine on just 2CL.
@Leo-PL did you ever got a chance to open problematic units and check memory chips? maybe they are W9751G6KB-25 ?
I opened one up, but did not write the exact part number down. Maybe tomorrow I can open up one or two of the units.
@Leo-PL did you ever got a chance to open problematic units and check memory chips? maybe they are W9751G6KB-25 ?
Two of three units that exhibited instability use Zentel A3R12E40C8F-8E chips. I currently have no physical access to the third unit.
Ok, thanks. Wondering if lower memory voltage could cause any instabilities, default on my v1 is 1.69V, stock u-boot sets it to 1.83V. It can be changed in 50mV steps through a PMU register
@psyborg55 I think you may be correct. The JEDEC DDR2 standard has it's operating voltage at 1.8v. The datasheet A3R12E40CBF-8E (I could not find A3R12E40C8F-8E, might just be difficulty reading chip markings?) which states that under "Specifications"
- Power supply: VDD, VDDQ = 1.8V ± 0.1V
Running RAM on the edge of operational on low voltage can lead to issues beyond those associated with timings. As for why some routers run without issue, it could be anything from a more stable supply (so that even at a low voltage, it does not dip any lower under load), or memory chips which are more tolerant of lower voltages, even just board layout can affect it.
@psyborg55 I think you may be correct. The JEDEC DDR2 standard has it's operating voltage at 1.8v. The datasheet A3R12E40CBF-8E (I could not find A3R12E40C8F-8E, might just be difficulty reading chip markings?) which states that under "Specifications"
It indeed is, the font on the chip has very similar "8" and "B".
* Power supply: VDD, VDDQ = 1.8V ± 0.1VRunning RAM on the edge of operational on low voltage can lead to issues beyond those associated with timings. As for why some routers run without issue, it could be anything from a more stable supply (so that even at a low voltage, it does not dip any lower under load), or memory chips which are more tolerant of lower voltages, even just board layout can affect it.
@psyborg55 do you know a good test point to measure DRAM Vdd? I'd like to check this on my routers as well.
For the past two weeks, my devices were running fine on stock U-boot. 3 days ago I updated them to test build with increased gate open latency to 2CL+1 (#120), and all units are fine so far. I wonder why all 11 of WDR4300 I had are fine on just 2CL.
You run 2CL+1 build on all of them or only those with RAM corruption problems?
For the past two weeks, my devices were running fine on stock U-boot. 3 days ago I updated them to test build with increased gate open latency to 2CL+1 (#120), and all units are fine so far. I wonder why all 11 of WDR4300 I had are fine on just 2CL.
You run 2CL+1 build on all of them or only those with RAM corruption problems?
On all of the units.
R384, located between LEDs and DRAM module
I finally had a chance to measure the voltage. 1.69V indeed. So yeah, we're undervolting the memory substantially.
While in general, my routers run stable - I get resets on starting sysupgrade every so often, even before actual flashing starts. And this happens on a device which wasn't exhibiting issues before, even with 2CL+1 build.
You can write 633C8178 to PMU1 and 00380000 to PMU2 registers, this is what stock uboot does to maintain optimal voltage.
tried 2CL+1 build on my device and all boot attempts either crashed or console output hanged and watchdog reset was triggered
I tested this (finally) on my device and the voltage is now 1.83V, which is within the range. Including 2CL+1 patch together with this resulted in unbootable (silent) device.
While measuring voltage I managed to short something for a split second, hanging the router - then it started crashing randomly and throwing errors in memtester. I restored my previous build using 2CL+1 timings and lower voltage - the router seems operational again.