Hi,I use your repository to build a r7800 firmware,and flash via tftp, but can't boot up, what did I miss?
That the "repository" is for r7500v2.
I suspect the boot issue is related to how I got usb working. My repo has edits in qcom-ipq8064-r7500v2.dts tied to edits in qcom-ipq8064.dtsi to get usb working. I think you'll need to make "consistent" edits in qcom-ipq8065-r7800.dts (ty @slh) and qcom-ipq8064.dtsi (see @Ansuel's post above).
Note, my choice of labels and node names in these files is slightly different than what @Ansuel choose so be careful. I don't think it matters what label/names you choose as long as you are consistent; however, the "community" should decide soon to avoid this kind of confusion.
EDIT0: I did what I did because I can and I don't think many people care all that much what I'm doing... If I'm wrong about that, I'd be happy to update my repo for the r7800 as well. I don't have a r7800 so you'd have to test it.
EDIT1: I pushed a change to my repo for qcom-ipq8065-r7800.dts that you can try. For any R7800 user who might want to try, please search the thread for WARNING and read first. Test with caution. I believe a couple of other users have tried these changes on the r7800 but I don't know for certain. 4+ days up for me and no obvious issues.
Note, every time the kernel 4.19 patch is "refreshed" in the staging tree, I check for changes and update my repo using things like reset hard HEAD and reapply my patch set. Lastly, I'm currently not up to date with master due to the possible mac80211 issues mentioned above.
1 Like
qcom-ipq8065.dtsi includes qcom-ipq8064.dtsi, so the generic parts needed for USB bringup under v4.19 are already done, what's missing are the (trivial) changes to the r7800.dts (tested on nbg6817).
1 Like
Thanks, I will have a try
Still can't work
Same symptom (won't boot)? If so try without the "ipq806x: k419 thermal sensors fix" patch if your willing.
Thank you for testing.
EDIT. I'm pulling out the thermal sensors fix patch from my k419 branch as this is my best guess for what might cause a boot issue (details here). I'd really like to know if you can boot without this but no worries if you don't try.
Regarding usb, make sure your .config has
(p372.ob) [17] $ cat .config | grep dwc3
CONFIG_PACKAGE_kmod-usb-dwc3=y
CONFIG_PACKAGE_kmod-usb-dwc3-qcom=y
I won't be able to work on this for a few weeks...
What 160mhz-capable clients do you use and what kind of throughput are you getting? Thanks
Hello friends, has any of this router's support changed since the first post of this thread? I would like to know if it has improved. I need an openwrt router with functional 5ghz wifi
thank you very much to all
I can do it on weekends, too.
@quarky will save us all, by porting all the code to 4.19, creating a patch with all hardware enabled that is accepted by owrt developers, and after that creating another patch to add the supported traffic shapers to sqm scripts and luci, that will then also be incorporated into master.
when that happens, this router soc will finally shine its true power and maybe I can forget buying a x86 for running openwrt at a decent speed with sqm enabled. 
and obviously, lets not forget the amazing work also done by all the developers before, that made reaching this point possible.
2 Likes
What speed do you consider to be decent. The R7800 should easily handle 300Mbps with sqm. I know it doesn't with these releases here, as they contain several bugs which render this hardware useless.
Not a chance. I specifically tested this case and the CPU flatlined at 100% around 130..140Mbps.
1 Like
indeed. I can only get past 140 with codel instead of cake.
anything above 400Mbps would work for me.
I got almost the same with cake with eth0 on one CPU and eth1 on the other.
Is this with the 4.19 kernel? The ipq8065 SoC should have enough grunt to do handle more than 140 with fq_codel qdisc. Could be a regression with the 4.19.
Have you tried with the 4.4.x lede-17-01.x releases?
I'm running latest master with kernel 4.14. I can do codel at 200mbps but not cake. cake tops out at around 140.
And codel at 200 is also near its limit. I think one of the cpu's ( the one dealing with the codel thread ) runs at around 90 % when shaping a 200/100 connection.
The only change I did to the master code was disabling the switch pooling stuff that was making ksoftirqd eat all the cpu, and I also run this on rc local:
echo 2 > /proc/irq/31/smp_affinity
echo 2 > /proc/irq/32/smp_affinity
echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo performance > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
echo 800000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
echo 800000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq
sleep 1
echo 1750000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
echo 1750000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq
ethtool -C eth0 tx-usecs 0
ethtool -C eth1 tx-usecs 0
ethtool -C eth0 rx-usecs 31
ethtool -C eth1 rx-usecs 31
exit 0
1 Like
I tested a week ago and used 19.07.
What is that for and how did you make this change?
please check:
The MIB thing was fixed back in May and this hack is not needed any more.