Netgear R7800 exploration (IPQ8065, QCA9984)

For Developers
1646

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
1647

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.

1648

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

1649

@Ansuel

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!

1650

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

1651

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

1652

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!

1653

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.

1654

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
1655

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!

1656

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.

1657

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!

1658

Do the official and ct firmwares share the same driver and board bin file?

1659

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
1660

Do you think this can all be worked around by setting scaling governor to performance and running without frequency scaling altogether?

1661

You can workaround it just by setting minimum scaling frequency to 800mhz while on ondemand governor.
But fabric clock is not being handled at all in current setup.

1662

Unfortunately, you PR does not merge cleanly any more. I tried a few times this year, but every time the baseline code wold change a bit and I do not understand enough about this stuff to rebase it...

1663

I may be wrong, but the fabric clocks seems to be used by the NSS firmware only. They’re not used by any of the existing codes in the Linux kernel as far as I can tell. That’s why the RPM clocks are never initialized. I concluded this from my tinkering with the NSS drivers.

The NSS drivers would adjust the fabric clocks when it changes the NSS core clocks. The code is available from the QSDK Git repo. I’ve also included it in my NSS driver Git repo.

1664

Apart from nss fabrics there're also ddr and apps fabrics, not sure that those are not used anyhow. I understand what you are talking about, but QSDK scales those fabrics according to CPU cores, not nss cores. Only nss fabric is scaled according to nss cores afaict

1 Like
1665

The NSS drivers initializes the app and ddr fabric clocks and scales them. When the NSS core clocks are adjusted, the app and ddr fabric clocks are also adjusted. Without the NSS drivers active all those RPM clocks are never initialized. That’s why my conclusion is that they are used by the NSS firmware only. Without proper documentation, it’s hard to be sure tho.

In any case, the OpenWRT builds are working fine without those clocks initialized, so it’s likely never needed by standard Linux drivers in OpenWRT.

Edit:
The clocks used by the NSS drivers are listed here:

1 Like