Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet)
Hi, Paul Thanks for your answers. How often do you really need to feed the watchdog? >> 10s a falling edge triggers dog feeding Why do you have an additional MCU taking care of capturing the level change, what else isit doing? >>MCU is also responsible for other functions, external RTC, and some indicators Can this MCU firmware be upgraded without external hardware? >>No, With gpio_wdt driver when you're using LEVEL mode the GPIO will be pulsed (high level for 1 us (microsecond!)) each time the watchdog is pinged. With TOGGLE mode the GPIO will be toggled each ping. >> Thank you for your explanation, I should use TOGGLE mode, -- Original --From: "Paul Fertser";Date: Sat, Apr 11, 2020 07:07 PMTo: "guilin.wang"; Cc: "Martin Blumenstingl"; "openwrt-devel"; Subject: Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet) Hi, On Fri, Apr 10, 2020 at 07:23:44PM +0800, guilin.wang wrote: > now the external single-chip cannot detect the level change of GPIO How often do you really need to feed the watchdog? Why do you have an additional MCU taking care of capturing the level change, what else is it doing? Can this MCU firmware be upgraded without external hardware? > I now suspect that the wdt-gpio delay is too short and the > microcontroller part has not detected a falling edge change. I tried > both toggle and level, With gpio_wdt driver when you're using LEVEL mode the GPIO will be pulsed (high level for 1 us (microsecond!)) each time the watchdog is pinged. With TOGGLE mode the GPIO will be toggled each ping. Default watchdog ping frequency in procd is 5 seconds. You can see more info on [0]. > but unfortunately both failed, and I will continue to test. It's not a matter of testing, it's a matter of understanding what's really going on. HTH [0] https://openwrt.org/docs/guide-user/hardware/watchdog -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet)
Hi , Paul Sorry, I misread the mail contact. Our watchdog uses two GPIO to control, one is to use pulse to switch the watchdog, one GPIO is used to feed the dog, specifically the external single-chip to feed the dog, now the external single-chip cannot detect the level change of GPIO I now suspect that the wdt-gpio delay is too short, and the microcontroller part has not detected a falling edge change. I tried both toggle and level, but unfortunately both failed, and I will continue to test. -- Original -- From: "guilin.wang"http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet)
Hi , MartinOur Watchdog uses two GPIO to control, one is to use pulse to switch the watchdog, one GPIO is used to feed the dog, specifically the external single-chip to feed the dog, now the external single-chip cannot detect the level change of GPIO I now suspect that the wdt-gpio delay is too short, and the microcontroller part has not detected a falling edge change. I tried both toggle and level, but unfortunately both failed, and I will continue to test. -- Original --From: "Paul Fertser";Date: Fri, Apr 10, 2020 07:10 PMTo: "guilin.wang"; Cc: "Martin Blumenstingl"; "openwrt-devel"; Subject: Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet) Hi, On Fri, Apr 10, 2020 at 06:55:59PM +0800, guilin.wang wrote: > but found that the dog could not be fed successfully. Why exactly? > Our external microcontroller feeds the dog. The cpu just gives the > microcontroller a trigger signal, but I tested that the > microcontroller cannot detect the level change using this method How is it able to detect the level change using another method then, what exactly makes them different? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet)
Hi ,Martin Thank your for your suggest, I initially followed this method, but found that the dog could not be fed successfully. Our external microcontroller feeds the dog. The cpu just gives the microcontroller a trigger signal, but I tested that the microcontroller cannot detect the level change using this method you said So I used the script. -- Original --From: "Martin Blumenstingl";Date: Fri, Apr 10, 2020 05:55 PMTo: "guilin.w...@gl-inet.com"; Cc: "openwrt-devel"; Subject: Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet) Hi, On Fri, Apr 10, 2020 at 11:47 AM guilin.w...@gl-inet.com wrote: > > Signed-off-by: guilin.w...@gl-inet.com the format should be "your name " > --- > package/kernel/om-watchdog/Makefile | 2 +- > package/kernel/om-watchdog/files/om-watchdog | 40 > +++ > package/kernel/om-watchdog/files/om-watchdog.init | 2 ++ > 3 files changed, 37 insertions(+), 7 deletions(-) why not use a GPIO watchdog node in board.dts instead? see [0] for an example Martin [0] https://github.com/torvalds/linux/blob/v5.4/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200
I agree with Jeff that we need to test in detail before switching to ath79. -- Original -- From: "Jeff"; Date: Thu, Apr 11, 2019 10:31 PM To: "Petr Štetiar"; "wellnw"; Cc: "openwrt-devel"; "Kevin 'ldir' Darbyshire-Bryant"; Subject: Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200 On 4/11/19 5:56 AM, Petr Štetiar wrote: > Guilin.Wang [2019-04-11 17:18:12]: > > Hi, > >> I want to submit it to ar71xx first, and I will submit it to ath79 later. > tl;dr version: > > please don't waste your (and our time) with ar71xx anymore. BTW it was ath79 > first and ar71xx possibly later, but this period is already over. At least for > me ar71xx is currently in 'fixes only' mode. > > Longer version: > > Even if you've provided ath79 support first I would simply hesitate to include > ar71xx support for this device as it has simply non trivial amount of changes > (the non-written rule it was agreed upon). Your changeset has following > numstats: > > 12 files changed, 218 insertions(+) > > Please take a look at the recent commits to ar71xx, it's pretty much 'fixes > only' mode already: > > 93d23aced ar71xx: Correct MAC address for WAN interface of Archer C7 v5 >1 file changed, 4 insertions(+) [...] Wow, I would have thought a simple "Thank you for your submission. We appreciate your commercial concerns. We look forward to your future submissions on the ath79 platform." would have been more than enough. GL.iNet is one of the few OEMs that commercially benefit from OpenWrt development that take the time to try to return patches and enhancements directly to the project. "Don't waste our time" comes through loud and clear. If I were an OEM, why should I bother submitting patches? There is real opportunity cost associated with doing so, and not very much tangible benefit compared to maintaining their own "private" branch. That the ath79 target on Linux 4.14 doesn't support NAND makes it challenging for a manufacturer to simply switch over their entire code development. Yes, patches for ath79 on Linux 4.19 dropped a week or two ago. However, a reputable manufacturer isn't going to ship product on an untested code line. So far I have seen that batman-adv won't even compile under ath79/4.19. Also, while the framework is supposedly present for NAND in Linux 4.19, as far as I know no devices have been demonstrated to be able to use it under OpenWrt. Not that I expect those things to magically happen, but they do make it challenging for a responsible OEM to switch over as easily as a hobbyist. Jeff ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200
Thanks for your suggestion.
Since the customer is waiting for urgent use, I want to submit it to ar71xx
first, and I will submit it to ath79 later.
-- Original --
From: "Kevin 'ldir' Darbyshire-Bryant";
Date: Thu, Apr 11, 2019 05:05 PM
To: "wellnw";
Cc: "openwrt-devel@lists.openwrt.org";
Subject: Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200
> On 11 Apr 2019, at 08:53, wellnw wrote:
>
> This patch adds supports for GL-X1200.
>
> Specification:
> - SOC: QCA9563 (775MHz)
> - Flash: 16 MiB (W25Q128FVSG)
> - RAM: 128 MiB DDR2
> - Ethernet: 4x 1Gbps LAN + 1x 1Gbps WAN
> - Wireless: QCA9563(2.4GHz) and QCA9886(5GHz)
> - SIM: 2x SIM card slots
> - MicroSD: 1x microSD slot
> - Antenna: 2x external 5dBi antennas
> - USB: 1x USB 2.0 port
> - Button: 1x reset button
> - LED: 16x LEDs (3x GPIO controllable)
> - UART: 1x UART on PCB (JP1: 3.3V, RX, TX, GND)
>
> Signed-off-by: wellnw
> ---
> target/linux/ar71xx/base-files/etc/board.d/01_leds | 4 +
> .../linux/ar71xx/base-files/etc/board.d/02_network | 4 +
> .../etc/hotplug.d/firmware/11-ath10k-caldata | 5 +
> target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
> .../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
> target/linux/ar71xx/config-4.14| 1 +
> .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 11 ++
> target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
> .../ar71xx/files/arch/mips/ath79/mach-gl-x1200.c | 173 +
> .../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
> target/linux/ar71xx/generic/config-default | 1 +
> target/linux/ar71xx/image/generic.mk | 13 ++
> 12 files changed, 218 insertions(+)
> create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-gl-x1200.c
>
> diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
> b/target/linux/ar71xx/base-files/etc/board.d/01_leds
> index 41dd8c5..eb455ce 100755
> --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
> @@ -448,6 +448,10 @@ gl-inet)
> ucidef_set_led_netdev "lan" "LAN" "$board:green:lan" "eth1"
> ucidef_set_led_wlan "wlan" "WLAN" "$board:red:wlan" "phy0tpt"
> ;;
> +gl-x1200)
> + ucidef_set_led_wlan "wlan2g" "WLAN2G" "$board:green:wlan2g" "phy1tpt"
> + ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:green:wlan5g" "phy0tpt"
> + ;;
> hiwifi-hc6361)
> ucidef_set_led_netdev "inet" "INET" "hiwifi:blue:internet" "eth1"
> ucidef_set_led_wlan "wlan" "WLAN" "hiwifi:blue:wlan-2p4" "phy0tpt"
> diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
> b/target/linux/ar71xx/base-files/etc/board.d/02_network
> index 68874e0..6fd4c25 100755
> --- a/target/linux/ar71xx/base-files/etc/board.d/02_network
> +++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
> @@ -456,6 +456,10 @@ ar71xx_setup_interfaces()
> ucidef_add_switch "switch0" \
> "0@eth0" "2:lan:2" "3:lan:1" "1:wan"
> ;;
> + gl-x1200)
> + ucidef_add_switch "switch0" \
> + "0@eth0" "1:lan" "2:lan" "3:lan" "4:lan" "5:wan"
> + ;;
> jwap230)
> ucidef_set_interfaces_lan_wan "eth0.1" "eth1.2"
> ucidef_add_switch "switch0" \
> diff --git
> a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> index 2ded261..fd6f213 100644
> --- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -187,6 +187,11 @@ case "$FIRMWARE" in
> cf-e385ac)
> ath10kcal_extract "art" 20480 12064
> ;;
> + gl-x1200)
> + ath10kcal_extract "art" 20480 12064
> + ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin \
> + /lib/firmware/ath10k/QCA9888/hw2.0/board.bin
> + ;;
> esac
> ;;
> *)
> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> index 990683a..42902d0 100755
> --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> @@ -794,6 +794,9 @@ ar71xx_board_detect() {
> *"GL-USB150")
> name="gl-usb150"
> ;;
> + *"GL-X1200")
> + name="gl-x1200"
> + ;;
> *"HiveAP-121")
> name="hiveap-121"
> ;;
> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> index 8173501..55be0a3 100755
> --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> @@ -273,6 +273,7 @@ platform_check_image() {
> gl-domino|\
> gl-mifi|\
> gl-usb150|\
> + gl-x1200|\
> hiwifi-hc6361|\
> hornet-ub-x2|\
> jwap230|\
> diff --git a/target/linux/ar71xx/config-4.14 b/target/linux/ar71xx/config-4.14
> index 9a524fa..8f8d8ce 100644
> --- a/target/linux/ar71xx/config-4.14
> +++ b/target/linux/ar71xx/config-4.14
> @@ -130,6 +130,7 @@ CONFIG_ATH
