Netgear R7800 exploration (IPQ8065, QCA9984)

[slh]

I don't really want to derail this thread with nbg6817 specifics, please switch to the nbg6817 thread (or create a new one) instead, but in short.

@quarky

I don’t see the nbg6817:amber:wifi2g or the nbg6817:amber:wifi5g LED devices in my lede-17.01 snapshot builds. Are they available only in the master builds?

I'm only running recent master builds, not 17.01.x/ stable (I have backported some important fixes to the post 17.01.4 stable branch, but with 18.x.y not too far away, I won't bother about new features, e.g. dual-boot support, for 17.01.x), but according to target/linux/ipq806x/base-files/etc/board.d/01_leds and target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts, the amber LEDs should work on lede-17.01 as well.

So basically on the nbg6817, all LEDs are working perfectly, the WLAN LEDs are just the wrong colour (amber instead of white. yes, technically they are different LEDs, but sharing the same light pipe).

@quarky

Is there anyway to disable the amber WiFi LEDs controlled by the SoC GPIOs? Likely that is over-riding the white LEDs controlled by the QCA9984 GPIOs.

The amber wlan (and white power & WAN-) LEDs are controlled by the SOC, fully working and configurable - including brightness (down to zero) and can be disabled alltogether. The white wlan LEDs are connected to the QCA9984 cores and should be covered by this new patch - and obviously there is some kind of support, it just doesn't work properly yet.

Both LEDs just share the same light pipe and accordingly appear to be the same, but electronically they are completely independent - and they can both work at the same time (tested), but for obvious (cosmetic) reasons I did disable the amber LEDs for most of my tests.

[Magnetron1.1]

V8 Patch ... http://lists.infradead.org/pipermail/ath10k/2018-February/010846.html

[slh]

At least the version changelog doesn't suggest any functional changes (compared to v6, which I tested) - and very obviously it hasn't been run through checkpatch either, as there are still horrible coding style issues that prevent it from being merged alone.

[quarky]

@Magnetron1.1

V8 Patch … http://lists.infradead.org/pipermail/ath10k/2018-February/010846.html

Looks like v8 fixed the LED issue. I applied it to my 17-01 snapshot builds and both LEDs turns on every time upon reboot. Looks good.

[Magnetron1.1]

V9 Patch ... http://lists.infradead.org/pipermail/ath10k/2018-February/010852.html
Looks like same basic code as V8 but led and led code have been moved to separate sourcefile (gpio.c).
Probably done to make it easier to maintain.

[bouwew]

Just noticed that nbd has released his fast-path patches to master. But, kernel 4.14 is required.
Now that dissent1 has sold his R7800, who is capable and willing to take the software for our beloved router to kernel 4.14?

[robimarko]

I began rebasing patches and removing upstreamed stuff.
A lot of patches have been fully or partially upstreamed.

Almost finished with that but I doubt that there won't be a lot of issues.

[bouwew]

@robimarko very much appreciated, good luck!

[luaraneda]

Hey,

I finally had some time to do the rebase on the first work that I did with kernel 4.14.
I've cleaned-up and split the commits, so they can be better understood.
Currently, I'm running it on an Asus ac58u, which has an ipq4019 SoC.
Also, I've compile tested all ipq806x devices, and the only one failing is the R7800, because the kernel size is larger than the kernel partition (2MB?).
Finally, there is still work to do (check the commit marked with [temporal]), specially for the PCIe of the ipq8064/5, which is out of my scope for now.

My work is on the branch ipq806x-k4.14 from my OpenWRT fork:
https://github.com/luaraneda/openwrt/tree/ipq806x-k4.14

[bouwew]

Maybe superfluous, but dissent1' s latest work on ipq806x kernel 4.14 can be found here:

dissent1/openwrt

Please look at branch 414.14 and earlier.

[dissent1]

@luaraneda

Finally, there is still work to do (check the commit marked with [temporal]), specially for the PCIe of the ipq8064/5, which is out of my scope for now.

Just pick pcie patches out of my 4.14 tree mentioned above. Some of these patches were upstreamed.

[Ansuel]

Think we should really expand the kernel partition 2mb is too low... A stock image will create a 2mb even in kernel 4.9
But to do this we need to use tftp and reset

[luaraneda]

Ok, I'ill try to do that.

Are you referring to commit a77957a from your repo:
https://github.com/dissent1/r7800/commit/a77957a153e2df94cc9a4315c57d3c9c0eb49fca

I looked at it some days ago, but there were so many 4.14-x branches that I got confused.
Has that commit the most up to date patches?

btw, patch 0071-4-PCIE-designware-Fixed-PCI-host-init.patch is not present, but it is on OpenWRT master.

EDIT: If you have the time, could you point me to the upstream commit for the patches? I'm trying to keep all that documented

[luaraneda]

I agree, 2MB is too small for the kernel, but wouldn't that break stock firmware compatibility?
I don't have an R7800 to test modifications or if it even boots.

[Ansuel]

i modified the kernel partition without any problem except the fact that openwrt doesn't recognize the new image and mark it as invalid... (we have 32 mb of extra space so we can increase the kernel partition with no damage)
(u-boot doesn't have any pattition table at allo, it's openwrt that creates it)

---

also why not compressing it? if it's a problem increase the size... i will check if stock uboot support kernel compression

---

"sleep 2; nmrp; "
"if loadn_dniimg 0 0x1480000 0x44000000 && "
"chk_dniimg 0x44000000; then "
"bootipq2; "

this is the uboot command to boot... it just load the kernel and put in ram...

[slh]

@quarky

Looks like v8 fixed the LED issue.

I don't see any change or improvement with v9 on the nbg6817, the ath10k controlled LEDs randomly work after some reboots - but most of the time they don't.

No reaction triggering it manually either:

# cat /sys/kernel/debug/gpio 
gpiochip0: GPIOs 0-68, parent: platform/800000.pinmux, 800000.pinmux:
 gpio0   : in  0 8mA no pull
 [...]
 gpio68  : in  0 2mA pull down

gpiochip2: GPIOs 442-476, parent: pci/0001:01:00.0, ath10k-phy1:

gpiochip1: GPIOs 477-511, parent: pci/0000:01:00.0, ath10k-phy0:

# cat /sys/class/gpio/gpiochip442/base 
442
# cat /sys/class/gpio/gpiochip442/ngpio 
35
# echo default-on >/sys/class/leds/ath10k-phy0/trigger
# echo none >/sys/class/leds/ath10k-phy0/trigger

# cat /sys/class/gpio/gpiochip477/base 
477
# cat /sys/class/gpio/gpiochip477/ngpio 
35
# echo default-on >/sys/class/leds/ath10k-phy1/trigger
# echo none >/sys/class/leds/ath10k-phy1/trigger

[Magnetron1.1]

v11 Patch ... http://lists.infradead.org/pipermail/ath10k/2018-February/010862.html

Reason for patches:
v10 compile fix if gpiolib isnt included
v11 make register_cpio_chip static. advise by krobot

[quarky]

@slh

I don’t see any change or improvement with v9 on the nbg6817, the ath10k controlled LEDs randomly work after some reboots - but most of the time they don’t.

Odd. V8 works quite well on my R7800. I just applied the patches and configured the LEDs using LuCI for both, but I used a different trigger. I used the phy[0/1]tpt trigger. Seems to work fine across router reboots.

[slh]

I've tested phy0tpt/ phy1tpt as well (first, actually), using default-on was just an attempt in getting it to light up at all (for manual manipulation via sysfs). The same works fine for SOC GPIOs or a connected USB stick (ath9k_htc-phy2).

[fantom-x]

@neheb

Yep. expect 2ms more latency. Noticeable when gaming.

Is this a constant +2ms additional latency? or very spiky? I am seeing around 1.5ms, which is close. But I am also seeing significant spikes to 50.100ms once or twice a minute (with ping 8.8.8.8 test), which are not present at all with the stock firmware or when connecting my PC directly to the modem.