| Message ID | mailman.114478.1726625362.1280.openwrt-devel@lists.openwrt.org |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [1/2] realtek: rtl838x: refactor hpe_1920-24g dts | expand |
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. Hi, I prepared a patch for this switch about 6 months ago, but never got around to submitting it. The OEM firmware seems to do fan speed control in firmware - although the algorithm used is not obvious - it's probably temperature sensor or total power draw feedback, or some combination of the two. Additionally when one fan fails the others go full-speed (and log faults). The best policy is unfortunately probably to run the fans at full speed by default. If you want to take a look it's here, and should be pretty much complete. https://github.com/openwrt/openwrt/compare/main...tim-seoss:openwrt:hpe-1920-24g-poe-370w-jg926a Cheers, Tim. On 18/09/2024 03:09, Evan Jobling via openwrt-devel wrote: > The sender domain has a DMARC Reject/Quarantine policy which disallows > sending mailing list messages using the original "From" header. > > To mitigate this problem, the original message has been wrapped > automatically by the mailing list software. > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. Hi Evan, On 19/09/2024 01:36, Evan Jobling wrote: > I don't have a JG925A to test so I wasn't game to submit for that. > Everything else looks similar which is nice. So far as I know everything is the same except the power supply module. There were a couple of users willing to test here: https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2670 > So your feedback here is to get this merged, I should change the fan control into the DTS as you have done? I think that seems best to me - the kernel has a thermal management subsystem and future enhancements could use this for fan control by implementing the same algorithm as the OEM firmware. > I was also unaware that there was another GPIO for fan failure so that's great news. It looked like the OEM firmware could be made aware of this, so I just found this by trial and error. Safest way to provoke this during test is to poke something soft and non-conductive (e.g. plastic foam) in through the fan grille to temporarily stop one fan. >> The best policy is unfortunately probably to run the fans at full speed by default. > > I guess then we should also submit a patch so the default for the JG922A is also max? > Then the user can elect to turn down the fans? Yes, I think that's the case. The OEM firmware setup is that during boot: Initially fan speed is set to high (by uboot and/or OEM kernel - can't remember exactly) . OEM user space manages fan speed based on some unknown algorithm (presumably by the "FanT" user space process, which isn't present on the very similar fanless JG924A). https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2668 The behaviour of the in-kernel gpio fan speed controller is to leave the fan speed as it was when the driver loaded (e.g. to inherit hardware default speed, or the speed which was set by the bootloader etc.). IIRC, the OpenWRT kernel resets the GPIO state at init time, so the fan speed is set to low - which is "wrong". One approach would be some sort of addition to the patch set to change that (either to force it back high again, or to retain the pre-boot settings), but I didn't have time to look at that, and then life got in the way as usual... The SoC does have a temperature sensor built-in, but the driver is incomplete and not upstreamed. Also relevant: https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2676 and: https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2679 https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2680 ... and a few other posts around that time in that thread. Cheers, Tim.
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. Tim Small via openwrt-devel <openwrt-devel@lists.openwrt.org> writes: >> So your feedback here is to get this merged, I should change the fan control into the DTS as you have done? > > I think that seems best to me - the kernel has a thermal management > subsystem and future enhancements could use this for fan control by > implementing the same algorithm as the OEM firmware. I wrote this as a proof-of-concept many years ago: https://github.com/bmork/openwrt/commit/8043178a6bf439ebd7665c0ad1e36aa89847fc38 Maybe usable as a start for someone? I don't have any switches with fans, so for me it was mostly about reading the temp sensor for fun. Bjørn
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. > I wrote this as a proof-of-concept many years ago: > https://github.com/bmork/openwrt/commit/8043178a6bf439ebd7665c0ad1e36aa89847fc38 > > Maybe usable as a start for someone? First, this is excellent thanks. Are you able to elaborate on any further work you think is required? I don't know where to start, other than "make it build", "port to Kernel 6.6" and then "configure the device tree correctly." Whilst I've done C. My kernel device driver experience approximates zero. Cheers, Evan.
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. Thanks for your response Tim! >> I don't have a JG925A to test so I wasn't game to submit for that. >> Everything else looks similar which is nice. Thanks for providing the context. If we ever get to the stage where the patch set is looking good I guess i can reach out. > > So far as I know everything is the same except the power supply module. There were a couple of users willing to test here: > > https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2670 > >> So your feedback here is to get this merged, I should change the fan control into the DTS as you have done? > > I think that seems best to me - the kernel has a thermal management subsystem and future enhancements could use this for fan control by implementing the same algorithm as the OEM firmware. I've put my patches in patchwork as "changes requested" and will be working on another set. Similarly I've started work on updating JG922A and getting that with gpio-fan driver. > >> I was also unaware that there was another GPIO for fan failure so that's great news. > > It looked like the OEM firmware could be made aware of this, so I just found this by trial and error. Safest way to provoke this during test is to poke something soft and non-conductive (e.g. plastic foam) in through the fan grille to temporarily stop one fan. Confirmed and checked that JG922A also has the same functionality. I used a paperclip but foam is a good idea. Fan datasheet for JG922A says 8200rpm max. Haven't estimated the low speed RPM. > > >>> The best policy is unfortunately probably to run the fans at full speed by default. I've also looked and the 48G model also just got merged, but I didn't see any fan control stuff there? the 48G-PoE model (jg928a) appears to have two fan levels per HPE documentation. The non poe one (jg927a) says it has one fan loudness (i.e. speed). > > Initially fan speed is set to high (by uboot and/or OEM kernel - can't remember exactly) uboot does it from what I understand. > The behaviour of the in-kernel gpio fan speed controller is to leave the fan speed as it was when the driver loaded (e.g. to inherit hardware default speed, or the speed which was set by the bootloader etc.). IIRC, the OpenWRT kernel resets the GPIO state at init time, so the fan speed is set to low - which is "wrong". One approach would be some sort of addition to the patch set to change that (either to force it back high again, or to retain the pre-boot settings), but I didn't have time to look at that, and then life got in the way as usual... I had a look into this on JG922A today. I can set the fans to max on initialisation of RTL8231 using gpio-hog. But it not only is setting initalisation, it also 'hogs' it per description. So that basically locks out gpio-fan or userspace setting it. I don't think there's currently a method in openwrt to set fan speed without writing your own fan_ctrl script like on one of the d-link switches, or doing the control in the device tree thermal section? I don't know the best way to set /sys/class/hwmon/hwmon0/pwm1_enable and then /sys/class/hwmon/hwmon0/pwm1 to 1 at boot. I'm thinking duplicate something like /etc/init.d/gpio_switch but for various hwmon devices? That sounds like lots of work =( I had a look at what fancontrol and pwmconfig did ( lm-sensors ?) They require a temperature sensor and aren't in openwrt yet anyway. > > The SoC does have a temperature sensor built-in, but the driver is incomplete and not upstreamed. So we can set the fan speeds by thermal, if we can get that upstreamed? Or per Bjørn's patch and keep it in OpenWrt? I don't understand how much "Further work" is required there. Whilst I can code in C. My kernel device driver experience approximates zero. I can try to build it and get closed loop fan control working. I haven't figured out whether a fan alarm can be part of the thermal control scheme in device tree to set the fan state. The scope creep here is getting a little much for me if I need to get closed or open loop fan control working in a short time frame. JG922A and JG928A got accepted without max fans by default? So I hope moving to hwmon and gpio-fan is sufficient? Then of course update the wiki on how to control/slow down fans, leave it up to user? As I'm going to be operating in hot environments with large PoE loads. I am also eager to have some sort of algorithm implemented. But I'd like to put that as "future work"? I've had thoughts regarding what fan control algorithm to use. (Without attempting to reverse engineer what factory did, or do my own thermal characterisation of the power supply and PSE controller FET's) I'm thinking "just max the fans" if sourcing more than 65W, fan failure, or CPU temp gets too high. Further reasoning/notes on thermal load: 65W passive was deemed acceptable by factory for JG921A. JG922A is same except for 180W PSU. So 65W passive is fine per set of 8 ports. So if sourcing >65W is an unknown, max the fans? (I know that even minimal airflow is much more efficient than convection cooling, so the set point for should be higher but eh) For JG925A, we have three sets of 8. Theoretically if we distribute evenly the PoE load we probably don't have an issue at stock as it is <65W per set of 8? We could have 180W through a one set of 8 ports, which would be a "Max the fans" scenario. Still safest would be sourcing >65W max the fans. For JG926A/JG928A we have an EPS port so we can have significant thermal load. We could end up with internal PSU sourcing 370W and the EPS providing another ~400? We can end up in a situation where we have 240W through a set of 8 ports.
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. Evan Jobling <evan.jobling@mslsc.com.au> writes: >> I wrote this as a proof-of-concept many years ago: >> https://github.com/bmork/openwrt/commit/8043178a6bf439ebd7665c0ad1e36aa89847fc38 >> >> Maybe usable as a start for someone? > > First, this is excellent thanks. > > Are you able to elaborate on any further work you think is required? > I don't know where to start, other than "make it build", > "port to Kernel 6.6" and then "configure the device tree correctly." I believe that's pretty much it. If you already have a "cooling-device" implementation using the gpio-fan driver, then you just have to extend the thermal-zone with cooling-maps and trips. See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/thermal/thermal-zones.yaml The RPi PoE hat device tree overlay is another example of adding a cooling-device (fan) into an existing thermal-zone with a sensor: https://github.com/raspberrypi/linux/blob/rpi-6.6.y/arch/arm/boot/dts/overlays/rpi-poe-overlay.dts We obviously don't want overlays - just think of it as a device tree diff. And the trip point params are also irrelevant. AFAICS, thermal_of will set THERMAL_TRIP_FLAG_RW_TEMP. So the trip points should be configurable from userspace using sysfs. Unless I'm missing something. In any case, a fixed high/low setting like OEM is probably good enough for most users. > Whilst I've done C. My kernel device driver experience approximates zero. I've never written thermal drver either. There's only one way out of that :-) Bjørn
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. Hi Evan, Thanks for your email... On 21/09/2024 15:06, Evan Jobling wrote: > I had a look into this on JG922A today. > I can set the fans to max on initialisation of RTL8231 using gpio-hog. > But it not only is setting initalisation, it also 'hogs' it per description. > > So that basically locks out gpio-fan or userspace setting it. My thoughts were that the kernel's gpio-init code for that SoC shouldn't reset the gpio state - rather it should leave it in the state that the firmware configured it. gpio-fan would then do the right thing. > JG922A and JG928A got accepted without max fans by default? > So I hope moving to hwmon and gpio-fan is sufficient? I think that was probably a mistake - since there is definitely scope for hardware damage (conceivably even fire) with what is now the default OpenWRT behaviour for these devices. This problem is gnarly unfortunately. I think the only really "correct" ways to proceed are either to allow user control (defaulting to high speed i.e. delegating the decision), or to re-implement the same fan control algorithm as the OEM firmware does. That algorithm could probably be discovered by treating it as a black box (e.g. giving it different PoE power loads, and/or operating temperatures, simulating fan failures etc. and observing behaviour). Unfortunately I think that without access to the hardware specs and/or carrying out a lot of hardware characterisation work there is too much guesswork involved in implementing any other algorithm. Tim.
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. Hi Tim!> > My thoughts were that the kernel's gpio-init code for that SoC shouldn't reset the gpio state - rather it should leave it in the state that the firmware configured it. gpio-fan would then do the right thing. I've read the RTL8231 device driver and code sets everything to input to ensure output drivers are always in a valid state. Commit is 3810e897295cb66bc45a62bc2c0b70a01004fe3b "realtek: ensure output drivers are enabled in RTL8231" I guess this is going to require per device patching to restore the fan (and other?) GPIO state set by the bootloader when initialising RTL8231's? Still working on it. > > I think the only really "correct" ways to proceed are either to allow user control (defaulting to high speed i.e. delegating the decision), or to re-implement the same fan control algorithm as the OEM firmware does. > > That algorithm could probably be discovered by treating it as a black box (e.g. giving it different PoE power loads, and/or operating temperatures, simulating fan failures etc. and observing behaviour) > > Unfortunately I think that without access to the hardware specs and/or carrying out a lot of hardware characterisation work there is too much guesswork involved in implementing any other algorithm. I think my laziness will prevail and I'll end up cooking up my own script rather than doing the reverse engineering work haha. Hotbox and loading up with PoE to near max on JG926A isn't out of the realm of possibility. Don't really want to try to run equipment at 40C ambient but I guess that's summer here anyway. Won't be able to get higher than 80W PoE draw on the JG922A with my current equipment. Cheers, Evan.
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. On 22/9/24 19:50, Bjørn Mork wrote: > I believe that's pretty much it. If you already have a "cooling-device" > implementation using the gpio-fan driver, then you just have to extend > the thermal-zone with cooling-maps and trips. See > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/thermal/thermal-zones.yaml > > The RPi PoE hat device tree overlay is another example of adding a > cooling-device (fan) into an existing thermal-zone with a sensor: > > https://github.com/raspberrypi/linux/blob/rpi-6.6.y/arch/arm/boot/dts/overlays/rpi-poe-overlay.dts > > We obviously don't want overlays - just think of it as a device tree > diff. And the trip point params are also irrelevant. AFAICS, > thermal_of will set THERMAL_TRIP_FLAG_RW_TEMP. So the trip points should > be configurable from userspace using sysfs. Unless I'm missing > something. > > In any case, a fixed high/low setting like OEM is probably good enough > for most users. OK thanks. I did some reading on thermal zones trying to find a way to set default fans. Need to do more reading. Thanks for the heads up. > > I've never written thermal drver either. There's only one way out of > that :-) > Okay cool. More reading in my future to do things kernel safe I guess. > > Bjørn
diff --git a/target/linux/realtek/base-files/etc/board.d/02_network b/target/linux/realtek/base-files/etc/board.d/02_network index 35c79cffa2..2dd99d502e 100644 --- a/target/linux/realtek/base-files/etc/board.d/02_network +++ b/target/linux/realtek/base-files/etc/board.d/02_network @@ -35,7 +35,8 @@ hpe,1920-8g|\ hpe,1920-8g-poe-65w|\ hpe,1920-8g-poe-180w|\ hpe,1920-16g|\ -hpe,1920-24g) +hpe,1920-24g|\ +hpe,1920-24g-poe-370w) label_mac=$(mtd_get_mac_binary factory 0x68) lan_mac=$label_mac mac_count1=$(hexdump -v -n 4 -s 0x110 -e '4 "%d"' $(find_mtd_part factory) 2>/dev/null) @@ -89,6 +90,9 @@ hpe,1920-8g-poe-65w) hpe,1920-8g-poe-180w) ucidef_set_poe 180 "$(filter_port_list_reverse "$lan_list" "lan9 lan10")" ;; +hpe,1920-24g-poe-370w) + ucidef_set_poe 370 "$(filter_port_list_reverse "$lan_list" "lan25 lan26 lan27 lan28")" + ;; netgear,gs110tpp-v1) ucidef_set_poe 130 "$(filter_port_list "$lan_list" "lan9 lan10")" ;; diff --git a/target/linux/realtek/base-files/etc/board.d/03_gpio_switches b/target/linux/realtek/base-files/etc/board.d/03_gpio_switches index 1e49d89c64..684d7f795e 100644 --- a/target/linux/realtek/base-files/etc/board.d/03_gpio_switches +++ b/target/linux/realtek/base-files/etc/board.d/03_gpio_switches @@ -6,7 +6,8 @@ board_config_update board=$(board_name) case "$board" in -hpe,1920-8g-poe-180w) +hpe,1920-8g-poe-180w|\ +hpe,1920-24g-poe-370w) ucidef_add_gpio_switch "fan_ctrl" "Fan control" "456" "0" ;; esac diff --git a/target/linux/realtek/dts/rtl8382_hpe_1920-24g-poe-370w.dts b/target/linux/realtek/dts/rtl8382_hpe_1920-24g-poe-370w.dts new file mode 100644 index 0000000000..88427a45e1 --- /dev/null +++ b/target/linux/realtek/dts/rtl8382_hpe_1920-24g-poe-370w.dts @@ -0,0 +1,12 @@ +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT + +#include "rtl8382_hpe_1920-24g.dtsi" + +/ { + compatible = "hpe,1920-24g-poe-370w", "realtek,rtl838x-soc"; + model = "HPE 1920-24G-PoE+ 370W (JG926A)"; +}; + +&uart1 { + status = "okay"; +}; diff --git a/target/linux/realtek/image/rtl838x.mk b/target/linux/realtek/image/rtl838x.mk index c44e3a74f7..7ad9beec4a 100644 --- a/target/linux/realtek/image/rtl838x.mk +++ b/target/linux/realtek/image/rtl838x.mk @@ -135,6 +135,15 @@ define Device/hpe_1920-24g endef TARGET_DEVICES += hpe_1920-24g +define Device/hpe_1920-24g-poe-370w + $(Device/hpe_1920) + SOC := rtl8382 + DEVICE_MODEL := 1920-24G-PoE+ 370W (JG926A) + DEVICE_PACKAGES += realtek-poe + H3C_DEVICE_ID := 0x00010029 +endef +TARGET_DEVICES += hpe_1920-24g-poe-370w + define Device/inaba_aml2-17gp SOC := rtl8382 IMAGE_SIZE := 13504k
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. Hardware information: --------------------- The HPE 1920-24G-PoE+ (370W) (JG926A) is a switch that is part of the 1920 family with 370W nominal PoE+ support. Common with HPE 1920-24G: - RTL8382 SoC - 24 Gigabit RJ45 ports (built-in RTL8218B, 2 external RTL8218D) - 4 SFP ports (external RTL8214FC) - RJ45 RS232 port on front panel - 32 MiB NOR Flash - 128 MiB DDR3 DRAM - PT7A7514 watchdog HPE 1920-24G-PoE+ (370W): - PoE chip - 3 fans (40mm) Known issues: --------------------- - PoE LEDs are uncontrolled. (Manual taken from f2f09bc) Booting initramfs image: ------------------------ - Prepare a FTP or TFTP server serving the OpenWrt initramfs image and connect the server to a switch port. - Connect to the console port of the device and enter the extended boot menu by typing Ctrl+B when prompted. - Choose the menu option "<3> Enter Ethernet SubMenu". - Set network parameters via the option "<5> Modify Ethernet Parameter". Enter the FTP/TFTP filename as "Load File Name" ("Target File Name" can be left blank, it is not required for booting from RAM). Note that the configuration is saved on flash, so it only needs to be done once. - Select "<1> Download Application Program To SDRAM And Run". Initial installation: --------------------- - Boot an initramfs image as described above, then use sysupgrade to install OpenWrt permanently. After initial installation, the bootloader needs to be configured to load the correct image file - Enter the extended boot menu again and choose "<4> File Control", then select "<2> Set Application File type". - Enter the number of the file "openwrt-kernel.bin" (should be 1), and use the option "<1> +Main" to select it as boot image. - Choose "<0> Exit To Main Menu" and then "<1> Boot System". NOTE: The bootloader on these devices can only boot from the VFS filesystem which normally spans most of the flash. With OpenWrt, only the first part of the firmware partition contains a valid filesystem, the rest is used for rootfs. As the bootloader does not know about this, you must not do any file operations in the bootloader, as this may corrupt the OpenWrt installation (selecting the boot image is an exception, as it only stores a flag in the bootloader data, but doesn't write to the filesystem). Example PoE config file (/etc/config/poe): --------------------- config global option budget '370' config port option enable '1' option id '1' option name 'lan8' option poe_plus '1' option priority '2' config port option enable '1' option id '2' option name 'lan7' option poe_plus '1' option priority '2' config port option enable '1' option id '3' option name 'lan6' option poe_plus '1' option priority '2' config port option enable '1' option id '4' option name 'lan5' option poe_plus '1' option priority '2' config port option enable '1' option id '5' option name 'lan4' option poe_plus '1' option priority '2' config port option enable '1' option id '6' option name 'lan3' option poe_plus '1' option priority '2' config port option enable '1' option id '7' option name 'lan2' option poe_plus '1' option priority '2' config port option enable '1' option id '8' option name 'lan1' option poe_plus '1' option priority '2' config port option enable '1' option id '9' option name 'lan16' option poe_plus '1' option priority '2' config port option enable '1' option id '10' option name 'lan15' option poe_plus '1' option priority '2' config port option enable '1' option id '11' option name 'lan14' option poe_plus '1' option priority '2' config port option enable '1' option id '12' option name 'lan13' option poe_plus '1' option priority '2' config port option enable '1' option id '13' option name 'lan12' option poe_plus '1' option priority '2' config port option enable '1' option id '14' option name 'lan11' option poe_plus '1' option priority '2' config port option enable '1' option id '15' option name 'lan10' option poe_plus '1' option priority '2' config port option enable '1' option id '16' option name 'lan9' option poe_plus '1' option priority '2' config port option enable '1' option id '17' option name 'lan24' option poe_plus '1' option priority '2' config port option enable '1' option id '18' option name 'lan23' option poe_plus '1' option priority '2' config port option enable '1' option id '19' option name 'lan22' option poe_plus '1' option priority '2' config port option enable '1' option id '20' option name 'lan21' option poe_plus '1' option priority '2' config port option enable '1' option id '21' option name 'lan20' option poe_plus '1' option priority '2' config port option enable '1' option id '22' option name 'lan19' option poe_plus '1' option priority '2' config port option enable '1' option id '23' option name 'lan18' option poe_plus '1' option priority '2' config port option enable '1' option id '24' option name 'lan17' option poe_plus '1' option priority '2' Signed-off-by: Evan Jobling <evan.jobling@mslsc.com.au> --- .../linux/realtek/base-files/etc/board.d/02_network | 6 +++++- .../realtek/base-files/etc/board.d/03_gpio_switches | 3 ++- .../realtek/dts/rtl8382_hpe_1920-24g-poe-370w.dts | 12 ++++++++++++ target/linux/realtek/image/rtl838x.mk | 9 +++++++++ 4 files changed, 28 insertions(+), 2 deletions(-) create mode 100644 target/linux/realtek/dts/rtl8382_hpe_1920-24g-poe-370w.dts