erm we don't need 701.... openwrt still don't use dsa...
making a pr with my changes...
1 Like
Hmm, i'll try it (after my current build has gone 14 days up or crashes, whichever comes first - 9+ days currently).
I'm pretty sure it will compile but it may not function as intended. I think the dts hierarchy needs to know how to associate "spc" with the cpus, idle-states nodes which is why I did it this way in the build I'm currently testing.
Also, I'd recommend this change to the r7500v2 only for now. A r7500 user should test that enabling spc works.
1 Like
thanks for that... no need to try... consider them "thinking aloud" samples 
wasn't sure which model you had... > fix for r7500v2 only
wget https://raw.githubusercontent.com/wulfy23/rt2600ac/master/kernel.svg
open in chrome
feel free to copy and paste anything from my git tree btw.
However, my 0067 "fix" will likely not be accepted by a kernel dev. I think a patch on a patch is considered kluge and bad form. They will probably request redo/replace the entire patch.
1 Like
i cleaned (i use qca8k dsa with mdio patch ) and tested on my r7800
All works well
I'm not sure about usb changes on other dts but this should be the start for kernel 4.19 support
there are extra patch like mdio extra driver and qca8k fix (also some backport from mainline kernel for cpuidle) but should be good...
Can someone review it?
2 Likes
I'll look it over and comment, give me a day or so...
I was thinking you planned to submit "fixes" for 4.19 and not the 4.19 patch itself as this may annoy the dev and delay it further - you may wan't to "socialize" your intent with him and others before doing it.
I saw an issue with software offloading on 4.19 that I don't think has been fixed yet and the EOL is still 12/2020, 4 years sooner than 4.14. I suspect that 4.19 may never make it into master for ipq806x with this EOL (I'd rather just start working on 5.4 myself).
1 Like
well... for now i'm just collecting all the info intro one pr... We have lots of repo/patch with partial change... One with testing dsa-mdio, one that just bootloop ipq8065 router...
It's easier to work on a solid base than a spread fixed source. Also kernel 4.19 is already on ath79 mvebu and others. The only reason ipq806x doesn't have 4.19 is that we can't find enough tester that can actually test all the board supported...
1 Like
My last info about qca8k suggests that it won't work with MAC addresses stored in ASCII (uboot-env) yet, which affects (at least) the nbg6817 and ea8500 - compared to the binary representation used by most other devices.
I wouldn't worry too much about the stated EOL dates for LTS kernels, those will get extended closer to their due date (Debian 10/ buster is using kernel 4.19, so even if Greg Kroah-Hartman would drop its maintenance, Debian/ Ben Hutchings will (have to-) take over the LTS work (for at least 2+1 years), as they have done/ are doing now already). Most of the issues with kernel 4.19 should be the same in 5.4, so work on getting 4.19 ready for ipq806x shouldn't be wasted either but will make getting 5.4 working easier.
1 Like
I had a chance to briefly look over this patch. I have not tested it. I can try next week if you think its ready to be tested on r7500v2 (see comments below regarding extending overlay).
I hope these comments are helpful. If not, feel free to ignore them.
-
The patch contains code to enable USB - perhaps mention this in the comments as you did for tsense and cpuidle.
-
In target/linux/ipq806x/Makefile there is:
kmod-usb3 kmod-usb-dwc3-qcom \
kmod-usb-dwc3-of-simple kmod-usb-phy-qcom-dwc3 \
I had removed the line with dwc3-of-simple and phy-qcom-dwc3... I assume i'll need to change my .config to disable these...
-
it looks like this contains "opp table patch(es)" mention in this thread above - perhaps a comment for this also in the patch description. Its not clear to me (yet) what is the benefit of having this/these patch/patches (that said I still am interested in learning more later). I thought cpuidle (wfi only, spc disabled) works on r7800 with out this change. See the comment about cpuidle spc on the r7800 below.
-
how you handle cpuidle spc on r7800 is different than me. You leave status="okay" under the cpus, idle-states, spc nodes in qcom-ipq8064.dtsi (enableing spc for all targets that include this file) and only disable spc in qcom-ipq8065.dtsi. This could cause issues for other targets dependent on qcom-ipq8064.dtsi for which spc has not yet been tested.
-
There are changes/patches regarding cpuidle that I am not using (perhaps from prior troubleshooting?). Are these necessary for the r7800?:
- 0076-Fix-regression-in-cpuidle-arm-4_9.patch
- 0077-fix-refactor-cpuidle.patch
-
There are changes around tsens that I am not using (again perhaps from prior troubleshooting?) Most notably in 0063-2-tsens-support-configurable-interrupts.patch in file drivers/thermal/of-thermal.c. Output from a git diff of your k419 patch with the patch from chunkeey's staging tree shows:
-+ if (data->num_sensors <= 0) {
-+ dev_err(dev, "invalid number of sensors\n");
-+@@ -146,6 +174,9 @@ static int tsens_probe(struct platform_d
++ num_sensors = data->num_sensors;
++
++@@ -155,6 +183,9 @@ static int tsens_probe(struct platform_d
+ tmdev->dev = dev;
-+ tmdev->num_sensors = data->num_sensors;
++ tmdev->num_sensors = num_sensors;
-
qcom-ipq8064-r7500v2.dtsi does not extend the overlay for the r7500v2. Any r7500v2 user trying out this patch from 4.14 master or 18+ will have to flash via tftp - sysupgrade will bootloop the router. That said, its easy enough for me to workaround and I don't think there are many users...
-
There are several other changes regarding mdio, pcie, others... (again perhaps mention that these are present in the patch comments?) Noteably:
- 0071-2-PCI-qcom-Fixed-IPQ806x-PCIE-reset-changes.patch
- 700-net-mdio-add-ipq8064-mdio-driver.patch
- 701-extend_slave-bus-implementations.patch
-
with so many changes included in a large patch set, its difficult for me to identify them, review, and comment. Others may have similar issues... consider making your changes in patch groups e.g. cpuidle, tsens, usb, etc. apart from chunkeey's baseline 4.19 patch set. If your patches are accepted into openwrt, they can be consolidated upon merging or thereafter. Also, should the baseline kernel 4.19 patch change outside of your control, you may find updating your patches easier.
- I make dwc-of-simple and usb-phy-qcom-dwc3 not compatible with kernel 4.19 in usb.mk
- opp table are there "just for fun"... i don't think they cause any trouble...
- IMHO cpuidle is broken in ipq8065 soc... i really don't think spc is compatible with only one target based on ipq8064
- I can remove cpuidle patches.. they are just backport from mainline kernel.. they were there to try to fix cpuidle problem...
- Didn't notice the presence of this extra patch about tsense...
- r7500v2 dts problem is just old base ... need to update it...
- As i said mdio patch are just extra patch that i think they will be used when dsa will be enabled for this target...
Should i make a PR to include only the new dts and patch for 4.19 ? @chunkeey should i?
just over 14 days up now and still going...
Just after 13 days up, the ath10k-ct driver/htt-firmware had some issues. The firmware has crashed but gracefully reset about 3 times over the past day. I submitted a bug report to candela.
There is nothing that stands out to me that suggests the firmware crashes are related to 4.19 or my patches but I am perhaps not the best judge of that.
I plan to test @ansuel's patch and build a new 4.19 image with my patches this weekend. I'll report back on that; however, this is likely the last 4.19 testing I'll be doing for a while.
FWIW, the last 4.14 snapshot I built with image builder for the r7500v2 just under a month ago went for 2 days before it crashed. Using "stable" builds I typically get less than that (but it has been a while since I've used one).
14 days up with some ath10k issues is about par for the course for openwrt and this qca hardware. Compared to the last soho router I used that gave me 90+ days up with no issues???
Compared to price, performance, and stability I can get with a used core 2 duo (about 30 euro ex a hard drive) running a linux distro and little effort to set up routing, there is just no comparison.
I like openwrt. I'd recommend it as long as its not running on recent qca hardware.
1 Like
x86 can get expensive very fast with good switch card and decent wifi card...
Sorry for ot...
2 Likes
Exactly that (WiFi && managed switch (running 3 independent private subnets and unmanaged switches from there on[0])) was my reason for going with my nbg6817 as well.
That and keeping myself from playing around with (breaking) it (o.k., the later only works partially 
), as the phones (SIP) also go through the router.
--
[0] to replicate that with a single managed switch, I'd need at least 24 (better >=32) ports, which is expensive enough - but thinking about IPv6 support and 10 GB (10000base-t) makes this expensive/ unviable. Yes, one might say if I can get along with the 4+1 managed switch ports of my router, I'd surely need to get along with a cheap'ish managed 8 port switch as well, but once you go that route, you'd want to do it properly (and there are many more reasons to isolate individual hosts)
1 Like
Still using a recent 4.19 build with cpuidle, usb and thermal sensors working but I'm testing some ath10k-ct-htt firmware changes from candla for a wireless issues that seems to be related to a single client. Otherwise no issues.
Others have made some progress on software offloading but I have not tried this to see if I can reproduce the reported issue with ipv6.
it may be a week or two before I post again...
Same... r7800+ usb fix + cpu idle+ tsense + qca8k no crash...
made a PR
Hope it doesn't cause any problem... I removed the extra 4 patch and opp table value
4 Likes
of course it is not a problem.
FWIW
OpenWrt # uptime
20:22:21 up 11 days, 11:04, load average: 0.18, 0.15, 0.10
usb, cpuidle, and temps all working.
It's looking like @greearb fixed the ath10k-ct-htt firmware issue I had with one client so that's good as well.
I hope the PR goes through and thanks again for taking notice - I really appreciated your help.
2 Likes
I getting errors compiling this PR
kernel/module.c:1264:12: warning: 'try_to_force_load' defined but not used [-Wunused-function]
static int try_to_force_load(struct module *mod, const char *reason)
^~~~~~~~~~~~~~~~~
arch/arm/boot/dts/qcom-ipq8064-ap148.dtb: ERROR (phandle_references): /cpus/cpu@0: Reference to non-existent node or label "cpu0_opp_table"
arch/arm/boot/dts/qcom-ipq8064-ap148.dtb: ERROR (phandle_references): /cpus/cpu@1: Reference to non-existent node or label "cpu0_opp_table"
ERROR: Input tree has errors, aborting (use -f to force output)
make[6]: *** [scripts/Makefile.lib:293: arch/arm/boot/dts/qcom-ipq8064-ap148.dtb] Error 2
make[5]: *** [arch/arm/Makefile:350: dtbs] Error 2
make[5]: *** Waiting for unfinished jobs....
drivers/cpufreq/cpufreq-dt.c: In function 'cpufreq_init':
drivers/cpufreq/cpufreq-dt.c:233:29: warning: unused variable 'opp_srcu_head' [-Wunused-variable]
struct srcu_notifier_head *opp_srcu_head;
^~~~~~~~~~~~~
At top level:
drivers/cpufreq/cpufreq-dt.c:132:12: warning: 'opp_notifier' defined but not used [-Wunused-function]
static int opp_notifier(struct notifier_block *nb, unsigned long event,
^~~~~~~~~~~~
cc1: warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch
net/core/dev.c: In function 'validate_xmit_skb_list':
net/core/dev.c:3394:15: warning: 'tail' may be used uninitialized in this function [-Wmaybe-uninitialized]
tail->next = skb;
~~~~~~~~~~~^~~~~
net/ipv4/fib_trie.c: In function 'fib_trie_unmerge':
net/ipv4/fib_trie.c:1769:8: warning: 'local_tp' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (fib_insert_alias(lt, local_tp, local_l, new_fa,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NULL, l->key)) {
~~~~~~~~~~~~~
drivers/net/ethernet/stmicro/stmmac/dwmac5.c: In function 'dwmac5_rxp_config':
drivers/net/ethernet/stmicro/stmmac/dwmac5.c:408:18: warning: 'min_prio_idx' may be used uninitialized in this function [-Wmaybe-uninitialized]
return &entries[min_prio_idx];
^
drivers/net/ethernet/stmicro/stmmac/dwmac5.c:378:9: note: 'min_prio_idx' was declared here
int i, min_prio_idx;
^~~~~~~~~~~~
drivers/phy/qualcomm/phy-qcom-dwc3.c: In function 'qcom_dwc3_phy_probe':
drivers/phy/qualcomm/phy-qcom-dwc3.c:494:21: warning: unused variable 'res' [-Wunused-variable]
struct resource *res;
^~~
drivers/pinctrl/qcom/pinctrl-msm.c: In function 'msm_gpio_irq_mask':
drivers/pinctrl/qcom/pinctrl-msm.c:634:16: warning: unused variable 'reg' [-Wunused-variable]
const __be32 *reg;
^~~
drivers/pinctrl/qcom/pinctrl-msm.c:633:6: warning: unused variable 'ret' [-Wunused-variable]
int ret;
^~~
drivers/pinctrl/qcom/pinctrl-msm.c:632:6: warning: unused variable 'addr' [-Wunused-variable]
u32 addr;
^~~~
drivers/pinctrl/qcom/pinctrl-msm.c: In function 'msm_gpio_irq_set_type':
drivers/pinctrl/qcom/pinctrl-msm.c:739:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
int ret = of_device_is_compatible(pctrl->dev->of_node,
^~~
drivers/thermal/qcom/tsens-ipq8064.c: In function 'tsens_scheduler_fn':
drivers/thermal/qcom/tsens-ipq8064.c:264:4: warning: 'sensor_addr' may be used uninitialized in this function [-Wmaybe-uninitialized]
regmap_read(tmdev->map, sensor_addr, &adc_code);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[4]: *** [Makefile:30: /media/JC/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/linux-4.19.76/.image] Error 2
make[3]: *** [Makefile:13: install] Error 2
time: target/linux/install#393.39#42.53#22.16
1 Like
This seems to fall over the DTS compilation for me:
DTC arch/arm/boot/dts/qcom-ipq8064-ap148.dtb
arch/arm/boot/dts/qcom-ipq8064-ap148.dtb: ERROR (phandle_references): /cpus/cpu@0: Reference to non-existent node or label "cpu0_opp_table"
arch/arm/boot/dts/qcom-ipq8064-ap148.dtb: ERROR (phandle_references): /cpus/cpu@1: Reference to non-existent node or label "cpu0_opp_table"
ERROR: Input tree has errors, aborting (use -f to force output)
make[6]: *** [scripts/Makefile.lib:293: arch/arm/boot/dts/qcom-ipq8064-ap148.dtb] Error 2
make[5]: *** [arch/arm/Makefile:350: dtbs] Error 2