OpenWrt Support for Armor G5 (NBG7815)

Hi guys, correctly configured PPPoE WAN.

config interface 'wan'
	option proto 'pppoe'
	option username 'XXX'
	option password 'XXX'
	option ipv6 'auto'
	option device 'wan.835'

But the performance are lower than old ISP modem. Speedtest shows 550 on openwrt and 900 on isp modem. What cloud be the problem. The ISP is TIM Italia.

Do you enabled "Packet Steering" (Enable packet steering across all CPUs. May help or hinder network speed.)?
What MTU did you set, and what did you have set on the old modem?

no and i think the problem is that i'm using only one core. Where can i enable Packet Steering?

If you are using luci, You can find it under: Network -> Interfaces -> Global network options

1 Like

Still not using all 4 core and 100% load on 1 core but it increase a lot pppoe performance thanks.

Hello, @psychowood and to all of you who have used some of my forks that include the modification of the fan support.

There was a typo and a permissions error in the fan_ctrl.sh file that prevented it from running correctly and as a result the fan would not turn on when the designated temperature was reached.

Now the bug is fixed in all forks except nbg7815-nss repository

For those who already included the previous commit in their own build, copying the new fan_ctrl.sh file to target/linux/ipq807x/base-files/sbin/ and generating a new commit would be fastest way to update.

I'm sorry for the inconveniences.

EDIT: Fan bug is now also correct in the nbg7815-nss repository. There you can see what are the changes

1 Like

Mine is based off asvio's repo (note the branch, G5 stuff is not on main), with added fstools block patch for extroot. I have a working image built but I honestly don't feel confident enough to share it :slight_smile:

If you have docker it is quite simple to do it yourself, you can use docker-openwrt-builder and follow the instructions, besides changing the cloned repo (and checking out the correct branch).

@asvio thanks for the heads up on the fan typo, no worries since the fan wasn't working anyways before :smiley:

1 Like

Thanks for information. I prepared the environment for the build. There are several branches in @asvio repo. Which branch should I choose?

hi, thanks all for the support. i have this router and install last zyxel_nbg7815-squashfs-sysupgrade and Luci. I have a question, inside this firmware, the optimization for cpu,led, fan,etc are implemented or i need to install in other way? if is not implemented is possible to have a list of this command/code? thanks all

@asvio can you help me in this questions? thanks

The nbg7815 branch is base on openwrt main branch. I will also push commits that i would think is going to be good for this router.

The nbg7815-23.05 is base on openwrt-23.05 branch. Like before branch i'll update with commits tested before.

The test branch is for testing commits that i think its can fix problem or lack of performance.

The led_fan_support branch is there to get a fixed reference to the led and fan support. It wil only be update when something change in main openwrt that will broke that support.

If you want to be on the more stable branch go for the nbg7815-23.05 one

1 Like

I'm tring to turn back in order to test if wifi performance are the same from original firmware and openwrt but ....

Return to original firmware from Openwrt
sh change_boot_partition.sh

return this error

OpenWrt release
1+0 records in
1+0 records out
1+0 records in
1+0 records out
Could not open mtd device: /dev/mtd2
Can't open device for writing!
Could not open mtd device: /dev/mtd3
Can't open device for writing!

Some one can help me?

If you have updated openwrt once you have installed it you will need serial access.

i don't think i updated it, how can i check?

I'm sorry. I've no knowlege about your matter. I can't help you.

My goal is to create a led and fan driver supported firmware that includes openwrt master changes. Is there any led and fan driver support in nbg7815-23.05 branch? I saw some fan related changes in nbg7815-23.05 branch, but I wanted to ask to confirm.

Yes, it has led and fan support

1 Like

Hey @robimarco.
I take the patch of Enrico for fan support on nbg7815.

Initially I have simplified the patch to determine what temperature may be appropriate.

I have changed the temperature from 70ºC to 75ºC because at 70ºC it does the fan always works under normal conditions in a room at 24ºC.

Without a fan, the temperature reached by the CPU is around 77ºC in the aforementioned room.

You can see the commit here.

The problem is that the hysteresis doesn't seem to work since once the cpu reaches 75º the fan starts turning on and off in very short periods of time (1 or 2 seconds) without taking into account the 5º that I initially assigned.

I have tried different values for hysteresis and it is always the same.
Can you review the code? Is there a bug that prevents normal operation?
Thanks.

I dont really have time to debug tsens, last time I tested it, it properly waited for the hysteresis to trip again.

There are some debug prints that you can enable in tsens to see whats going on.

Ok. Thanks for the hint.

I've tried to adjust settings as well and trying to fine tune. So far I'm struggling to monitor temperature via collectd to verify my settings easy for a longer period. Without thermal in dts collectd is producing a graph. As soon its in dts included it does not anymore.

But why did you strip aqr_thermal? This is actually the control when the fan starts and how long. Because I think the CPU is not relevant and the entries just there.

We have 3 sensors:

ath11k_hwmon-isa-c000000 = very hot at all >=80°C (with fan in action it is around 85°C); this sensor is present 2 times and cannot be read due to this behaviour. There is sth. wrong. On top the 2nd one has a range from -255 to +255 (just garbage).

tmp103-i2c-0-70 = is always about 10°C lower then 90000mdio108-mdio-8

90000mdio108-mdio-8 = is the relevant sensor for us; I've installed OEM FW for this to test. I've meassured the time span from a cold device running idle until the fan started the first time. It's if 90000mdio108-mdio-8 reaches 70°C. To be sure I meassured the time span for OpenWrt reaching 70°C on 90000mdio108-mdio-8. It was about the same.

The on off thing is controlled by (CPU is IMO irrelevant here because we have a sensor):

	thermal-zones {
		aqr_thermal: aqr-thermal {
			polling-delay-passive = <30000>;
			polling-delay = <90000>;
			thermal-sensors = <&aqr113c>;
		};

&aqr_thermal {
	trips {
		aqr_thermal_active: aqr-thermal-active {
			temperature = <75000>;
			hysteresis = <5000>;
			type = "active";
		};
	};

	cooling-maps {
		map1 {
			trip = <&aqr_thermal_active>;
			cooling-device = <&fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
		};
	};

This is my test setting atm. While polling delay is 90 seconds. This indicates the fan has to run a minmum of 90 seconds after 75°C is hit for more the 5s (hysterisis). If the fan is not running arq113c is checked every 30 seconds (polling-delay-passive) if set active.
Hysteresis is giving you a timespan of 5s the sensor can be over its limit before the fan is set to active. If its set on active then the fan starts on next check. That is how I understand it.
With this setting the fan is starting ~ every 10-15 minutes if the device is idle with USB3 device connected.

That's how I understand it.

Despite that I have still lets call it hick-ups while the fan starts for a few seconds and stops after a few seconds. But I think this is due to the CPU settings which I didn't touch so far. I will strip it if I have a script to monitor the sensor without collectd.

EDIT: The device itself is very hot around the 10G connector. That's why I think aqr113c was choosen. And www was telling me it has an mdio management interface. Where I think it provides temperatures as well? So it makes sense to me to use this?

1 Like