Netgear R7800 exploration (IPQ8065, QCA9984)

hnyman · February 25, 2018, 8:58am

Funny. I am trying to apply the the v11 ath10k LED patch after being away for a week (so I tried v4 last time).

I do not seem to be able to get the leds properly defined:
/sys/class/leds/ has no trace of the two LEDs for ath10k.

I suspect that the reason is Kconfig changes in v10, so that the LED support needs to be specifically enabled for ath10k. I have tried adding config-y += ATH10K_LEDS to mac80211 Makefile, but that does not seem to produce the LEDs into the system.

Has anybody got v10-v11 successfully applied and LEDs enabled?

neheb · February 25, 2018, 3:17pm

Last I remember it was constant. It's one of the reasons I no longer use this router.

Ansuel · February 25, 2018, 3:21pm

for 2 ms... kay....

fantom-x · February 25, 2018, 3:31pm

Which one are you using?

neheb · February 25, 2018, 3:44pm

Currently Turris Omnia

fantom-x · February 25, 2018, 5:02pm

Is not it based on some older version of OpenWRT?

neheb · February 25, 2018, 5:35pm

There's a Pull Request that I'm using currently. Has DSA :).

luaraneda · February 26, 2018, 4:47am

@dissent1 I've added the PCI patches to k4.14, except 0071-4-PCIE-designware-Fixed-PCI-host-init.patch, because it wasn't present on your branch (is it necessary?).
It's compiling ok, but the kernel size remains an issue. In fact, after commit 46c49d8 (optimize for performance) it's worst, because now I have 5 devices failing the image size-check.
Some statistics:

* Kernel 4.9 (openwrt^0f54d96, after 46c49d8: optimize for performance)
  + d7800:   1997680 bytes ( +99472 bytes free)
  + r7500:   1997148 bytes (+100004 bytes free)
  + r7500v2: 1997730 bytes ( +99422 bytes free)
  + r7800:   2001567 bytes ( +95585 bytes free)
  + vr2600v: 1997600 bytes ( +99552 bytes free)

* Kernel 4.14 (openwrt^ae27cbf + k4.14 patches, before 46c49d8: optimize for performance)
  + d7800:   2095996 bytes (+1156 bytes free)
  + r7500:   2095464 bytes (+1688 bytes free)
  + r7500v2: 2096046 bytes (+1106 bytes free)
  + r7800:   2099883 bytes (-2731 bytes free) [fail]
  + vr2600v: 2095916 bytes (+1236 bytes free)

* Kernel 4.14 (openwrt^0f54d96 + k4.14 patches, after 46c49d8: optimize for performance)
  + d7800:   2284100 bytes (-186948 bytes free) [fail]
  + r7500:   2283568 bytes (-186416 bytes free) [fail]
  + r7500v2: 2284150 bytes (-186998 bytes free) [fail]
  + r7800:   2287987 bytes (-190835 bytes free) [fail]
  + vr2600v: 2284020 bytes (-186868 bytes free) [fail]

As you can see, even on the best case with kernel 4.14, only ~1.5kB remains free, and the R7800 is always failing.

@hnyman I've read several times that we should not modify the mtd partitions, but what can we do here? Compression might help if all devices support it.

I've just rebases my k4.14 branch against master. The numbers changed a little, but image creation is still failing.

slh · February 26, 2018, 6:06am

It is quite surprising that the results for d7800 and r7800 differ that much, if I don't miss anything obvious, both should result in identical images (given that they share the same DTS, the same DEVICE_PACKAGES and the same kernel, given that the VDSL modem of the d7800 isn't supported so far).

huaracheguarache · February 26, 2018, 9:28am

Whenever I run block info over ssh I get the following in the log:

Mon Feb 26 08:59:55 2018 kern.err kernel: [52808.016764] blk_update_request: I/O error, dev mtdblock0, sector 0
Mon Feb 26 08:59:55 2018 kern.err kernel: [52808.017799] blk_update_request: I/O error, dev mtdblock0, sector 8
Mon Feb 26 08:59:55 2018 kern.err kernel: [52808.022792] blk_update_request: I/O error, dev mtdblock0, sector 16
Mon Feb 26 08:59:55 2018 kern.err kernel: [52808.028889] blk_update_request: I/O error, dev mtdblock0, sector 24
Mon Feb 26 08:59:55 2018 kern.err kernel: [52808.035684] blk_update_request: I/O error, dev mtdblock0, sector 0
Mon Feb 26 08:59:55 2018 kern.err kernel: [52808.040430] Buffer I/O error on dev mtdblock0, logical block 0, async page read
Mon Feb 26 08:59:55 2018 kern.err kernel: [52808.055827] blk_update_request: I/O error, dev mtdblock0, sector 0
Mon Feb 26 08:59:55 2018 kern.err kernel: [52808.055869] Buffer I/O error on dev mtdblock0, logical block 0, async page read
Mon Feb 26 08:59:55 2018 kern.err kernel: [52808.062330] blk_update_request: I/O error, dev mtdblock1, sector 0
Mon Feb 26 08:59:55 2018 kern.err kernel: [52808.069014] blk_update_request: I/O error, dev mtdblock1, sector 8
Mon Feb 26 08:59:55 2018 kern.err kernel: [52808.075170] blk_update_request: I/O error, dev mtdblock1, sector 16
Mon Feb 26 08:59:55 2018 kern.err kernel: [52808.081396] blk_update_request: I/O error, dev mtdblock1, sector 24
Mon Feb 26 08:59:56 2018 kern.err kernel: [52808.089214] Buffer I/O error on dev mtdblock1, logical block 0, async page read
Mon Feb 26 08:59:56 2018 kern.err kernel: [52808.097016] Buffer I/O error on dev mtdblock1, logical block 0, async page read

I've seen others complaining about this as well, and I'm wondering if it's something I should be concerned about.

Magnetron1.1 · February 26, 2018, 2:02pm

v12 ... http://lists.infradead.org/pipermail/ath10k/2018-February/010866.html

Fix the following warning from the kbuild test robot:

In file included from drivers/net/wireless/ath/ath10k/core.c:29:0:

drivers/net/wireless/ath/ath10k/core.h:815:13: warning: 'ath10k_unregister_gpio_chip' used but never defined
static void ath10k_unregister_gpio_chip(struct ath10k *ar);
^~~~~~~~~~~~~~~~~~~~~~~~~~~

hnyman · February 26, 2018, 2:07pm

Have you been able to get the R7800 LEDs working with recent versions, v8-v12?
If yes, please share you changes/patches. I tried several recent versions yesterday, and did not get the LEDs working properly.

Magnetron1.1 · February 26, 2018, 2:39pm

No ... Unfortunately this is beyond my knowledge. Perhaps @quarky could tell us how he got v8 to work.

hnyman · February 26, 2018, 2:42pm

Yeah, I tried applying the v8 patch to 17.01 and got compile errors. I didn't look further into it, as it is kernel 4.4 and I see this mostly as forwardlooking kernel 4.9 and 4.14 stuff.

hnyman · February 26, 2018, 3:00pm

sounds nasty that we are reaching kernel size limits with 4.14 for ipq806x.

In R7800 it might be possible to reacllocate the current flash space of kernel+rootfs (2+30?) to e.g. 3+27 and still keep the separate Netgear partition intact. That would leave flashback to OEM firmware possible. But even that might make it difficult to upgrade from 17.01 to master, as the kernel size changes, so it might require TFTP flashing via factory image (due to the nature of having separately kernel and rootfs inside the sysupgrade file). This likely requires input from the core devs. I think that @blogic and @mkresin have most experience with ipq806x deep stuff.

Regarding your reference to my earlier comments: It would be yet quite another additional thing to start taking space from the unused Netgear partition, as that might remove compatibility with Netgear OEM firmware, so it might be that OEM firmware would not work any more. So I do not like that option as the default option for the built firmware image.

Ansuel · February 26, 2018, 3:24pm

can confirm about the upgrade problem... the sysupgrade process fail with unsupported image... (only way is use tftp)

quarky · February 26, 2018, 3:55pm

My changes for v8 can be found here:

Seems to work ok for me. I only tried up to v8 as v9 and later modified the build files and it seems like it’s patching against later revisions of the Linux kernel. Haven’t had time to modify against lede-17.01 4.4 builds.

Ansuel · February 26, 2018, 4:20pm

@hnyman can you make a patch if you manage to apply it?

hnyman · February 26, 2018, 6:07pm

Thanks for the repo link.

I had got ok the other context changes in v8, but had overlooked the kernel-version dependent change below (which was behind a dependency check in v7, but which check was removed for v8). That caused the compilation problem I mentioned earlier.

-+gpio->gchip.parent = ar->dev;
++gpio->gchip.dev = ar->dev;

After correcting that, I got the v8 patch applied and compiled ok for 17.01.

However, it seems that the initialisation of the LEDs is sporadic. I have rebooted the 17.01 router four times and have seen so far three outcomes: both LEDs dark, both LEDs work, only 5GHz LED works.

hnyman · February 26, 2018, 6:17pm

Sure.
Here is the link for 17.01 patch.
https://gist.github.com/hnyman/1e3bfc9d35e53351e6b4a9e4806ef2c1

It is otherwise the Brainslayer v8 patch, but

non-existent ubiquiti-specific device spec has been removed
context corrected for debugfs stuff
kernel version dependent change of gpio->gchip.dev = ar->dev; as 17.01 is with old kernel 4.4 (and not 4.5+)
patch line numbers refreshed for 17.01

I did not attach the LED definitions in the gist, as those can be done manually.
The needed code for etc/board.d/01_leds (if you want to do it by script):

+       ucidef_set_led_wlan "wlan2g" "WLAN 2G" "ath10k-phy1" "phy1tpt"
+       ucidef_set_led_wlan "wlan5g" "WLAN 5G" "ath10k-phy0" "phy0tpt"

My own test 17.01 build can be found from my community build download directory:
Download site: https://www.dropbox.com/sh/ew0gap0crn30wyk/AADQLCBF5All8wc8RXmxisqAa
lede1701-r3843-4db583b9c2-20180226-ath10k-LED-test

EDIT:
v8 seems to work also for master, at least some times...
master-r6323-a49f6565b3-20180226-ath10k-LEDpatch-v8-test
patch: https://gist.github.com/hnyman/d7c39e14e078e301a73a936958424eba