i have 4.19 in testing right now and all works well...
When I last tested it (very, very early on, so it might have changed meanwhile), USB/ USB3 were slightly problematic, but everything else was fine.
what usb problem you experience? we found a fix and i think it's still not in the commit...
my problem with usb was that device were actually recognized but never worked (the partittion didn't show up) and we fixed by editing the general dtsi)
It's been a couple of months - and I'm not even using any USB devices on my nbg6817 (this was just a quick test).
would you mind sharing a link for those with alternate intellects... I've looked over the past posts and its not entirely clear what I'd need to try/change if I run into issues.
I can see the hs_phy and the ss_phy entries under the usb3_x entries in the qcom-ipq8064.dtsi file and I gather from @chunkeey's comments I need to move and rename these to the same level as the usb3_x. I think the relevant part of your post from May 18 above doesn't show what you did...
I ordered a usb serial adapter and i figure trying 4.19 is a good way to motivate me to try both.
Also @chunkeey, do you plan to include #1922 to 4.19? its not there now... I assume cherry picking this commit (and making changes for overlay and usb functionality) is enough to get me started...
I found out why i never posted the dts... (it's too long lol....)
qcom-ipq8064.dtsi
https://pastebin.com/DsrubdFC
dts r7800 (enable usb and insert pinctrl)
https://pastebin.com/v846LqdF
Pay attention that in r7800 there are other changes that are not related to usb... the dts is set to use dsa switch driver and to use the mdio switch driver (so only copy the usb parts)
3 Likes
will using these two dts files improve performance over using the stock ones? by for instance using the sda switch driver instead of the stock one?
I'm trying to milk as much as I can from this router.
AFAIK using mdio instead of sdio reduce cpu usage but you need a custom driver (some additional patch) and this dts are fro kernel 4.19
They are still in testing
when do you think these changes will be merged into trunk ( just your idea what is your feeling )?
specifically:
- switch to 4.19 or newer kernel
- switch to mdio driver
@hnyman
Can you update the first post with up to date information, if any?
- was specifically hopping for a resume of work by @quarky and @drbrains and what that can bring in terms of features/performance to this platform
- also, regarding performance tweaks that still need to be made, like setting governor to performance, irq stuff and ethtool tweaks.
Finally, and I know this may be asking for too much, all of these questions actually have a particular reason for me, and that is sqm and cake. Having a clear answer as how much performance can be expected from this platform if supported with all its hardware optimized and working would be awesome.
Right now, using trunk with a few tweaks the most I can get is 140/150mbits of shaped traffic using the piece_of_cake script. If anyone can reply with a sensible answer to: when fully optimized we can expect it to shape about xxxmbits using the piece of cake that would be awesome.
Mostly this will greatly benefit users like me that have this device but don't engage that much with the developer community to be up to date on those things.
thanks!
the switch to 4.19 will happen some times but i think we need more testing and fixing
mdio driver... still dubious about seeing it in master
not tested but should work nbg6817 4.19 @chunkeey
INITRAMFS
https://github.com/wulfy23/c-no-syno/blob/master/NBGramfs
USBBOOT
https://github.com/wulfy23/c-no-syno/blob/master/NBGrootfs.tar.gz
https://github.com/wulfy23/c-no-syno/blob/master/NBGkernel
Hi, i installed ethtool package from LuCI package from LuCI GUI software page and now i'm not sure how to add to rc.local, thanks!
Hi, i have questions on this, have you tried this?
What does this exactly do?
Do you just insert this command just like that or requires installing?
Thank you.
If you want to implement this, then you can add the following to /etc/config/network and it disables that script:
config globals 'globals'
option default_ps '0'
The above config is handled by these two lines in the hotplug script:
default_ps="$(uci get "network.@globals[0].default_ps")"
[ -n "$default_ps" -a "$default_ps" != 1 ] && exit 0
Sorry, one thing i'm not following is i understand how to add it to /etc/config/network by ssh CLI but how do i do this and keep this running after a reboot?
Is it by running these commands from LuCI System / Startup at the very bottom of the page and type this?
Run this in commands via SSH CLI if want to use this once, correct? but not stick as it'll revert itself after reboot.
Sh /etc/config/network
config globals 'globals'
option default_ps '0'
Run this in LuCI System / Startup at the very bottom of the page and type this so i can have this always perform these commands automatically right after reboot? correct?
/etc/config/network
config globals 'globals'
option default_ps '0'
Also i don't need to touch the two lines in the hotplug script correct?
The reason why you left the hotplug script there is just to let me see whats going on, correct?
Or do i have to also type that in?
Thanks again!
You need to add the following two lines:
config globals 'globals'
option default_ps '0'
to /etc/config/network and it will survive a reboot. No other changes are necessary.
EDIT:** Just tried to
Sh /etc/config/network
config globals 'globals'
option default_ps '0'
Didn't work. How should i do this? Says line config not found.
Oh okay, thank you.
is there any command to check it afterwards? Thanks again!
Do the official and ct firmwares share the same driver and board bin file?
Just to let you know.
Some time ago while browsing through QSDK I've noticed a comment that l2 cache on ipq806x cannot operate properly at rate of 1ghz+ when either main core operates at 384mhz. That's why QSDK sets min rate of 800mhz .
It could be the source of performance problems on ipq806x in openwrt.
I suggest to pick my PR that adds fabrics and proper l2 scaling and adjust it to be accepted taking into account the forementioned l2 issue.
6 Likes
Do you think this can all be worked around by setting scaling governor to performance and running without frequency scaling altogether?