[PATCH] base-files: add blink and turnoff commands to the led script

2021-06-28 Thread John Crispin
This allows us to make all leds blink or force all leds to off.
It is also possible to force the default behaviour to not load
any led states/triggers by setting system.@system[-1].leds_off
to 1.

Signed-off-by: John Crispin 
---
 package/base-files/files/etc/init.d/led | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/package/base-files/files/etc/init.d/led 
b/package/base-files/files/etc/init.d/led
index 51cb8b5178..252bba623a 100755
--- a/package/base-files/files/etc/init.d/led
+++ b/package/base-files/files/etc/init.d/led
@@ -3,6 +3,9 @@
 
 START=96
 
+extra_command "turnoff" "Turn all leds off"
+extra_command "blink" "Blink all leds"
+
 load_led() {
local name
local sysfs
@@ -121,7 +124,25 @@ load_led() {
}
 }
 
+turnoff() {
+   for led in `ls /sys/class/leds/`; do
+   echo none > /sys/class/leds/$led/trigger
+   echo 0 > /sys/class/leds/$led/brightness
+   done
+}
+
+blink() {
+   for led in `ls /sys/class/leds/`; do
+   echo 0 > /sys/class/leds/$led/brightness
+   echo timer > /sys/class/leds/$led/trigger
+   done
+}
+
 start() {
+   [ "$(uci get system.@system[-1].leds_off)" -eq 1 ] && {
+   turnoff
+   exit 0
+   }
[ -e /sys/class/leds/ ] && {
[ -s /var/run/led.state ] && {
local led trigger brightness
@@ -137,5 +158,7 @@ start() {
 
config_load system
config_foreach load_led led
+   . /etc/diag.sh
+   set_state done
}
 }
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] base-files: add blink and turnoff commands to the led script

2021-06-28 Thread Nicholas Smith
ACK I like this.  Good for many applications, not the least of which
include a quick "stealth mode" LED setting or warning/notification LED
blink patterns.

All the best,
Nick

On Mon, 28 Jun 2021 at 17:18, John Crispin  wrote:
>
> This allows us to make all leds blink or force all leds to off.
> It is also possible to force the default behaviour to not load
> any led states/triggers by setting system.@system[-1].leds_off
> to 1.
>
> Signed-off-by: John Crispin 
> ---
>  package/base-files/files/etc/init.d/led | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/package/base-files/files/etc/init.d/led 
> b/package/base-files/files/etc/init.d/led
> index 51cb8b5178..252bba623a 100755
> --- a/package/base-files/files/etc/init.d/led
> +++ b/package/base-files/files/etc/init.d/led
> @@ -3,6 +3,9 @@
>
>  START=96
>
> +extra_command "turnoff" "Turn all leds off"
> +extra_command "blink" "Blink all leds"
> +
>  load_led() {
> local name
> local sysfs
> @@ -121,7 +124,25 @@ load_led() {
> }
>  }
>
> +turnoff() {
> +   for led in `ls /sys/class/leds/`; do
> +   echo none > /sys/class/leds/$led/trigger
> +   echo 0 > /sys/class/leds/$led/brightness
> +   done
> +}
> +
> +blink() {
> +   for led in `ls /sys/class/leds/`; do
> +   echo 0 > /sys/class/leds/$led/brightness
> +   echo timer > /sys/class/leds/$led/trigger
> +   done
> +}
> +
>  start() {
> +   [ "$(uci get system.@system[-1].leds_off)" -eq 1 ] && {
> +   turnoff
> +   exit 0
> +   }
> [ -e /sys/class/leds/ ] && {
> [ -s /var/run/led.state ] && {
> local led trigger brightness
> @@ -137,5 +158,7 @@ start() {
>
> config_load system
> config_foreach load_led led
> +   . /etc/diag.sh
> +   set_state done
> }
>  }
> --
> 2.25.1
>
>
> ___
> 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: [PATCH v2] cn913x: add support for iEi Puzzle-M901/Puzzle-M902

2021-06-28 Thread Daniel Golle
Hi,


On Fri, Jun 25, 2021 at 07:43:05AM +0800, eveans2...@gmail.com wrote:
> From: Ian Chang 
> 
>  Hardware specification
>  --
>  * CN9130 SoC, Quad-core ARMv8 Cortex-72 @ 2200 MHz
>  * 4 GB DDR
>  * 4 GB eMMC
>  mmcblk0
>  ├─mmcblk0p164M  kernel_1
>  ├─mmcblk0p264M  kernel_2
>  ├─mmcblk0p3   512M  rootfs_1
>  ├─mmcblk0p4   512M  rootfs_2
>  ├─mmcblk0p5   512M  Reserved
>  ├─mmcblk0p664M  Reserved
>  └─mmcblk0p7   1.8G  rootfs_data

Please stick with 7-bit ASCII characters in the commit description.


> 
>  * 4 MB (SPI Flash)
>  * 6 x 2.5 Gigabit  ports (Puzzle-M901)
> - External PHY with 6 ports (AQR112R)
>  * 6 x 2.5 Gigabit ports (Puzzle-M902)
> - External PHY with 6 ports (AQR112R)
>3 x 10 Gigabit ports (Puzzle-M902)
> - External PHY with 3 ports (AQR113R)
> 
>  * 4 x Front panel LED
>  * 1 x USB 3.0
>  * Reset button on Rear panel
>  * UART (115200 8N1,header on PCB)
> 
>  Flash instructions:
>The original firmware is based on OpenWrt.
>Flash firmware using LuCI and CLI
> 
> Signed-off-by: Ian Chang 
> ---
>  .../base-files/etc/board.d/02_network |   6 +
>  .../cortexa72/base-files/lib/upgrade/emmc.sh  |  45 
>  .../base-files/lib/upgrade/platform.sh|   8 +
>  target/linux/mvebu/cortexa72/config-5.4   |   4 +
>  .../dts/marvell/puzzle-armada-common.dtsi |  11 +
>  .../boot/dts/marvell/puzzle-armada-cp110.dtsi |  12 +
>  .../arm64/boot/dts/marvell/puzzle-cn9130.dtsi |  37 +++
>  .../boot/dts/marvell/puzzle-m901-cn9130.dts   | 219 
>  .../boot/dts/marvell/puzzle-m901-cn9131.dts   | 182 +
>  .../boot/dts/marvell/puzzle-m902-cn9130.dts   | 245 ++
>  .../boot/dts/marvell/puzzle-m902-cn9131.dts   | 140 ++
>  .../boot/dts/marvell/puzzle-m902-cn9132.dts   | 209 +++
>  target/linux/mvebu/image/cortexa72.mk |  20 ++
>  13 files changed, 1138 insertions(+)
>  create mode 100644 
> target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
>  create mode 100644 
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-armada-common.dtsi
>  create mode 100644 
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-armada-cp110.dtsi
>  create mode 100644 
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-cn9130.dtsi
>  create mode 100644 
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-m901-cn9130.dts
>  create mode 100644 
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-m901-cn9131.dts
>  create mode 100644 
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-m902-cn9130.dts
>  create mode 100644 
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-m902-cn9131.dts
>  create mode 100644 
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-m902-cn9132.dts
> 
> diff --git a/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network 
> b/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network
> index 9ab3c8174d..dc6d5bfd8b 100755
> --- a/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network
> +++ b/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network
> @@ -21,6 +21,12 @@ marvell,armada8040-db)
>  marvell,armada7040-db)
>   ucidef_set_interfaces_lan_wan "eth0 eth2" "eth1"
>   ;;
> +marvell,puzzle-m901-cn9131)
> + ucidef_set_interfaces_lan_wan "eth1 eth2 eth3 eth4 eth5" "eth0"
> + ;;
> +marvell,puzzle-m902-cn9132)
> + ucidef_set_interfaces_lan_wan "eth1 eth2 eth3 eth4 eth5 eth10 eth11 
> eth12" "eth0"
> + ;;

Is that board really made by Marvell themselves, ie. is it a
reference design?
If not, please use ieiworld,puzzle* as primary compatible string.
See e.g. armada-3720-gl-mv1000.dts for an example of the naming scheme
and try to be in line with that as much as possible (Adrian had
already requested that when reviewing your first submission).

>  *)
>   ucidef_set_interface_lan "eth0"
>   ;;
> diff --git a/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh 
> b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
> new file mode 100644
> index 00..d959350ff4
> --- /dev/null
> +++ b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
> @@ -0,0 +1,45 @@
> +platform_do_upgrade_emmc() {
> + local board=$(board_name)
> + local diskdev partdev diff
> +
> + export_bootdevice && export_partdevice diskdev 0 || {
> + v "Unable to determine upgrade device"
> + return 1
> + }
> +
> + sync
> +
> + if [ "$UPGRADE_OPT_SAVE_PARTITIONS" = "1" ]; then
> + get_partitions "/dev/$diskdev" bootdisk
> +
> + v "Extract boot sector from the image"
> + get_image_dd "$1" of=/tmp/image.bs count=1 bs=512b
> +
> + get_partitions /tmp/image.bs image
> +
> + #compare tables
> + diff="$(grep -F -x -v -f /tmp/partmap.bootdisk 
> /tmp/partmap.image)"
> + else
> + diff=1
> + fi

You are setting

Re: [PATCH] base-files: add blink and turnoff commands to the led script

2021-06-28 Thread Karl Palsson

John Crispin  wrote:
> This allows us to make all leds blink or force all leds to off.
> It is also possible to force the default behaviour to not load
> any led states/triggers by setting system.@system[-1].leds_off
> to 1.

You actually force them all off though, rather than "not load any
state" ? Is the intention for "leds_off" like the name, or the
intention to be "don't touch any leds" in which case the name and
implementation don't match the commit description?

Also, what's the use case for blink in the default install? It's
not pushing any stack for a temporary blink, it just hard sets
all led to blink. I can see plenty of uses for this in
private testing builds, I have something similar myself for
production testing that all leds function, but i'm having a hard
time seeing what the use case for it is in general, and why it
should be in the default build.

Sincerely,
Karl Palsson


> 
> Signed-off-by: John Crispin 
> ---
>  package/base-files/files/etc/init.d/led | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/package/base-files/files/etc/init.d/led
> b/package/base-files/files/etc/init.d/led index
> 51cb8b5178..252bba623a 100755
> --- a/package/base-files/files/etc/init.d/led
> +++ b/package/base-files/files/etc/init.d/led
> @@ -3,6 +3,9 @@
>  
>  START=96
>  
> +extra_command "turnoff" "Turn all leds off"
> +extra_command "blink" "Blink all leds"
> +
>  load_led() {
>   local name
>   local sysfs
> @@ -121,7 +124,25 @@ load_led() {
>   }
>  }
>  
> +turnoff() {
> + for led in `ls /sys/class/leds/`; do
> + echo none > /sys/class/leds/$led/trigger
> + echo 0 > /sys/class/leds/$led/brightness
> + done
> +}
> +
> +blink() {
> + for led in `ls /sys/class/leds/`; do
> + echo 0 > /sys/class/leds/$led/brightness
> + echo timer > /sys/class/leds/$led/trigger
> + done
> +}
> +
>  start() {
> + [ "$(uci get system.@system[-1].leds_off)" -eq 1 ] && {
> + turnoff
> + exit 0
> + }
>   [ -e /sys/class/leds/ ] && {
>   [ -s /var/run/led.state ] && {
>   local led trigger brightness
> @@ -137,5 +158,7 @@ start() {
>  
>   config_load system
>   config_foreach load_led led
> + . /etc/diag.sh
> + set_state done
>   }
>  }
> -- 
> 2.25.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

OpenPGP-digital-signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] base-files: add blink and turnoff commands to the led script

2021-06-28 Thread John Crispin
you can either use the uci option to make this a boot default or use the 
commands to do this manually


this is a common feature of LEDs. they can be on/off have a trigger etc etc.

 John

On 28.06.21 12:01, Karl Palsson wrote:

John Crispin  wrote:

This allows us to make all leds blink or force all leds to off.
It is also possible to force the default behaviour to not load
any led states/triggers by setting system.@system[-1].leds_off
to 1.

You actually force them all off though, rather than "not load any
state" ? Is the intention for "leds_off" like the name, or the
intention to be "don't touch any leds" in which case the name and
implementation don't match the commit description?

Also, what's the use case for blink in the default install? It's
not pushing any stack for a temporary blink, it just hard sets
all led to blink. I can see plenty of uses for this in
private testing builds, I have something similar myself for
production testing that all leds function, but i'm having a hard
time seeing what the use case for it is in general, and why it
should be in the default build.

Sincerely,
Karl Palsson



Signed-off-by: John Crispin 
---
  package/base-files/files/etc/init.d/led | 23 +++
  1 file changed, 23 insertions(+)

diff --git a/package/base-files/files/etc/init.d/led
b/package/base-files/files/etc/init.d/led index
51cb8b5178..252bba623a 100755
--- a/package/base-files/files/etc/init.d/led
+++ b/package/base-files/files/etc/init.d/led
@@ -3,6 +3,9 @@
  
  START=96
  
+extra_command "turnoff" "Turn all leds off"

+extra_command "blink" "Blink all leds"
+
  load_led() {
local name
local sysfs
@@ -121,7 +124,25 @@ load_led() {
}
  }
  
+turnoff() {

+   for led in `ls /sys/class/leds/`; do
+   echo none > /sys/class/leds/$led/trigger
+   echo 0 > /sys/class/leds/$led/brightness
+   done
+}
+
+blink() {
+   for led in `ls /sys/class/leds/`; do
+   echo 0 > /sys/class/leds/$led/brightness
+   echo timer > /sys/class/leds/$led/trigger
+   done
+}
+
  start() {
+   [ "$(uci get system.@system[-1].leds_off)" -eq 1 ] && {
+   turnoff
+   exit 0
+   }
[ -e /sys/class/leds/ ] && {
[ -s /var/run/led.state ] && {
local led trigger brightness
@@ -137,5 +158,7 @@ start() {
  
  		config_load system

config_foreach load_led led
+   . /etc/diag.sh
+   set_state done
}
  }
--
2.25.1


___
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


[PATCH] hostapd: fix 11w support in eap192 mode

2021-06-28 Thread John Crispin
wpa3 enterprise does not work without enabling 11w support.

Signed-off-by: John Crispin 
---
 package/network/services/hostapd/files/hostapd.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 7d035a299b..06d6c579af 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -49,6 +49,7 @@ hostapd_append_wpa_key_mgmt() {
eap192)
append wpa_key_mgmt "WPA-EAP-SUITE-B-192"
[ "${ieee80211r:-0}" -gt 0 ] && append wpa_key_mgmt 
"FT-EAP"
+   [ "${ieee80211w:-0}" -gt 0 ] && append wpa_key_mgmt 
"WPA-EAP-SHA256"
;;
eap-eap192)
append wpa_key_mgmt "WPA-EAP-SUITE-B-192"
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH 0/1] Workaround for rut955 modem initialization

2021-06-28 Thread Ontje.Luensdorf
From: Ontje Lünsdorf 

Hi all,

The rut955 fails to activate its modem upon every second reboot. By resetting
the modem upon initialization, we get it to work reliably.

This will probably affect all other modems and we are not sure if this may cause
side-effects on other devices.

Best regards,
Ontje

Ontje Lünsdorf (1):
  Reset modem upon initialization.

 package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh | 4 
 1 file changed, 4 insertions(+)

-- 
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH 1/1] Reset modem upon initialization.

2021-06-28 Thread Ontje.Luensdorf
From: Ontje Lünsdorf 

The rut955 fails to activate its modem upon every second reboot otherwise.

Co-authored-by: hans-hermann.reden...@dlr.de
Co-authored-by: jonas.stuehrenb...@dlr.de
---
 package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh 
b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
index c0134f4..60695ec 100755
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -81,6 +81,10 @@ proto_qmi_setup() {
 
echo "Waiting for SIM initialization"
local uninitialized_timeout=0
+
+   # Reset modem, workaround for a buggy modem after an reboot
+   uqmi -s -d "$device" --set-device-operating-mode reset
+
while uqmi -s -d "$device" --get-pin-status | grep '"UIM 
uninitialized"' > /dev/null; do
[ -e "$device" ] || return 1
if [ "$uninitialized_timeout" -lt "$timeout" -o "$timeout" = 
"0" ]; then
-- 
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH 1/1] Reset modem upon initialization.

2021-06-28 Thread Piotr Dymacz

Hi Ontje,

On 28.06.2021 13:56, ontje.luensd...@dlr.de wrote:

From: Ontje Lünsdorf 

The rut955 fails to activate its modem upon every second reboot otherwise.


This will issue reset every time the qmi connection is (re-)initialized, 
making the whole (re-)connection process much longer. Does the modem 
really need to be reset every time the connection is brought up or just 
once, after the bootup?


IIRC, RUT9xx series has a dedicated GPIO for modem power enable/disable. 
How about using that instead?


--
Cheers,
Piotr



Co-authored-by: hans-hermann.reden...@dlr.de
Co-authored-by: jonas.stuehrenb...@dlr.de
---
  package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh | 4 
  1 file changed, 4 insertions(+)

diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh 
b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
index c0134f4..60695ec 100755
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -81,6 +81,10 @@ proto_qmi_setup() {
  
  	echo "Waiting for SIM initialization"

local uninitialized_timeout=0
+
+   # Reset modem, workaround for a buggy modem after an reboot
+   uqmi -s -d "$device" --set-device-operating-mode reset
+
while uqmi -s -d "$device" --get-pin-status | grep '"UIM uninitialized"' 
> /dev/null; do
[ -e "$device" ] || return 1
if [ "$uninitialized_timeout" -lt "$timeout" -o "$timeout" = 
"0" ]; then




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH 0/1] Workaround for rut955 modem initialization

2021-06-28 Thread John Crispin


On 28.06.21 13:56, ontje.luensd...@dlr.de wrote:

This will probably affect all other modems and we are not sure if this may cause
side-effects on other devices.



As similar problem can be observed when looking at swconfig. some 
switches need a reset, others do not. for this purpose an "option reset 
0/1" was introduced in uci. In this case maybe "modem_reset" might be a 
good option.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH 0/1] Workaround for rut955 modem initialization

2021-06-28 Thread Arjun AK

On 28/06/21 5:26 pm, ontje.luensd...@dlr.de wrote:

From: Ontje Lünsdorf 

Hi all,

The rut955 fails to activate its modem upon every second reboot. By resetting
the modem upon initialization, we get it to work reliably.

This will probably affect all other modems and we are not sure if this may cause
side-effects on other devices.




We definitely should not reset all modems just because one specific 
modem doesn't work. If you reset the modem, it might take another 10s+ 
to come back up thereby delaying the time taken for the router to be 
ready. Could you filter by PID/VID and reset only rut955?


-
Arjun

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH 1/1] Reset modem upon initialization.

2021-06-28 Thread Sergey Ryazanov
Hello Ontje,

On Mon, Jun 28, 2021 at 3:00 PM  wrote:
> The rut955 fails to activate its modem upon every second reboot otherwise.

What does it mean "fails to activate modem"? Could you be more
specific? A bit more detailed issue description will be helpful if
someone faces a similar case, even possibly with another modem model.

Whether the modem does not respond at all or it is unable to establish
a new data connection? Did you try to purge the modem clients list and
then reestablish the connection?

> Co-authored-by: hans-hermann.reden...@dlr.de
> Co-authored-by: jonas.stuehrenb...@dlr.de

BTW, you missed the Signed-of-by :)

> ---
>  package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh 
> b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> index c0134f4..60695ec 100755
> --- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> +++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> @@ -81,6 +81,10 @@ proto_qmi_setup() {
>
> echo "Waiting for SIM initialization"
> local uninitialized_timeout=0
> +
> +   # Reset modem, workaround for a buggy modem after an reboot
> +   uqmi -s -d "$device" --set-device-operating-mode reset
> +

As already mentioned by Piotr, resetting the modem on each connection
establishing attempt is overkill. Did you consider using a hotplug
script to reset the modem after the initial detection?

With a hotplug script you even will be able to reset only a specific
buggy modem model and reduce side-effects.

--
Sergey

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH] comgt: Move to community packages repo

2021-06-28 Thread Arjun AK
Signed-off-by: Arjun AK 
---
 package/network/utils/comgt/Makefile  | 106 
 package/network/utils/comgt/files/3g.chat |  12 -
 package/network/utils/comgt/files/3g.sh   | 116 
 package/network/utils/comgt/files/3g.usb  |  33 ---
 .../utils/comgt/files/directip-stop.gcom  |  16 --
 .../network/utils/comgt/files/directip.gcom   |  55 
 package/network/utils/comgt/files/directip.sh | 114 
 package/network/utils/comgt/files/evdo.chat   |  17 --
 .../utils/comgt/files/getcardinfo.gcom|  14 -
 .../network/utils/comgt/files/getcarrier.gcom |  20 --
 .../network/utils/comgt/files/getcnum.gcom|  20 --
 .../network/utils/comgt/files/getimsi.gcom|  17 --
 .../utils/comgt/files/getstrength.gcom|  14 -
 package/network/utils/comgt/files/ncm.json|  78 --
 package/network/utils/comgt/files/ncm.sh  | 255 --
 .../network/utils/comgt/files/runcommand.gcom |  31 ---
 .../network/utils/comgt/files/setmode.gcom|  26 --
 package/network/utils/comgt/files/setpin.gcom |  56 
 package/network/utils/comgt/files/ussd.gcom   |  21 --
 .../utils/comgt/patches/001-compile_fix.patch |  23 --
 .../utils/comgt/patches/002-termios.patch | 105 
 .../utils/comgt/patches/003-no_XCASE.patch|  20 --
 .../utils/comgt/patches/004-check_tty.patch   |  68 -
 23 files changed, 1237 deletions(-)
 delete mode 100644 package/network/utils/comgt/Makefile
 delete mode 100644 package/network/utils/comgt/files/3g.chat
 delete mode 100644 package/network/utils/comgt/files/3g.sh
 delete mode 100644 package/network/utils/comgt/files/3g.usb
 delete mode 100644 package/network/utils/comgt/files/directip-stop.gcom
 delete mode 100644 package/network/utils/comgt/files/directip.gcom
 delete mode 100644 package/network/utils/comgt/files/directip.sh
 delete mode 100644 package/network/utils/comgt/files/evdo.chat
 delete mode 100644 package/network/utils/comgt/files/getcardinfo.gcom
 delete mode 100644 package/network/utils/comgt/files/getcarrier.gcom
 delete mode 100644 package/network/utils/comgt/files/getcnum.gcom
 delete mode 100644 package/network/utils/comgt/files/getimsi.gcom
 delete mode 100644 package/network/utils/comgt/files/getstrength.gcom
 delete mode 100644 package/network/utils/comgt/files/ncm.json
 delete mode 100644 package/network/utils/comgt/files/ncm.sh
 delete mode 100644 package/network/utils/comgt/files/runcommand.gcom
 delete mode 100644 package/network/utils/comgt/files/setmode.gcom
 delete mode 100644 package/network/utils/comgt/files/setpin.gcom
 delete mode 100644 package/network/utils/comgt/files/ussd.gcom
 delete mode 100644 package/network/utils/comgt/patches/001-compile_fix.patch
 delete mode 100644 package/network/utils/comgt/patches/002-termios.patch
 delete mode 100644 package/network/utils/comgt/patches/003-no_XCASE.patch
 delete mode 100644 package/network/utils/comgt/patches/004-check_tty.patch

diff --git a/package/network/utils/comgt/Makefile 
b/package/network/utils/comgt/Makefile
deleted file mode 100644
index db5ea57473..00
--- a/package/network/utils/comgt/Makefile
+++ /dev/null
@@ -1,106 +0,0 @@
-#
-# Copyright (C) 2006-2014 OpenWrt.org
-#
-# This is free software, licensed under the GNU General Public License v2.
-# See /LICENSE for more information.
-#
-
-include $(TOPDIR)/rules.mk
-
-PKG_NAME:=comgt
-PKG_VERSION:=0.32
-PKG_RELEASE:=33
-
-PKG_SOURCE:=$(PKG_NAME).$(PKG_VERSION).tgz
-PKG_SOURCE_URL:=@SF/comgt
-PKG_HASH:=0cedb2a5aa608510da66a99aab74df3db363df495032e57e791a2ff55f1d7913
-
-PKG_MAINTAINER:=Felix Fietkau 
-PKG_LICENSE:=GPL-2.0+
-
-PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME).$(PKG_VERSION)
-PKG_CHECK_FORMAT_SECURITY:=0
-
-PKG_FLAGS:=nonshared
-
-include $(INCLUDE_DIR)/package.mk
-
-define Package/comgt/Default
-  SECTION:=net
-  CATEGORY:=Network
-  SUBMENU:=WWAN
-endef
-
-define Package/comgt
-$(call Package/comgt/Default)
-  TITLE:=Option/Vodafone 3G/GPRS control tool
-  DEPENDS:=+chat
-  URL:=http://manpages.ubuntu.com/manpages/trusty/man1/comgt.1.html
-endef
-
-define Package/comgt-directip
-$(call Package/comgt/Default)
-  TITLE:=Sierra Wireless Direct-IP support
-  DEPENDS:=+comgt +kmod-usb-serial +kmod-usb-serial-sierrawireless 
+kmod-usb-net +kmod-usb-net-sierrawireless
-endef
-
-define Package/comgt-ncm
-$(call Package/comgt/Default)
-  TITLE+=NCM 3G/4G Support
-  DEPENDS:=+comgt +wwan +kmod-usb-serial-option +kmod-usb-net-huawei-cdc-ncm
-endef
-
-define Package/comgt/description
- comgt is a scripting language interpreter useful for establishing 
- communications on serial lines and through PCMCIA modems as well as GPRS 
- and 3G datacards.
-endef
-
-define Build/Compile
-   $(MAKE) -C $(PKG_BUILD_DIR) \
-   $(TARGET_CONFIGURE_OPTS) \
-   CFLAGS="$(TARGET_CFLAGS)" \
-   LDFLAGS="" \
-   comgt
-endef
-
-define Package/comgt/install
-   $(INSTALL_DIR) $(1)/usr/bin
-   $(INSTALL_BIN) $(PKG_BUILD_DIR)/comgt $(1)/

Re: [PATCH] comgt: Move to community packages repo

2021-06-28 Thread Arjun AK

On 28/06/21 10:22 pm, Arjun AK wrote:

Signed-off-by: Arjun AK 
---
  package/network/utils/comgt/Makefile  | 106 
  package/network/utils/comgt/files/3g.chat |  12 -
  package/network/utils/comgt/files/3g.sh   | 116 
  package/network/utils/comgt/files/3g.usb  |  33 ---
  .../utils/comgt/files/directip-stop.gcom  |  16 --
  .../network/utils/comgt/files/directip.gcom   |  55 
  package/network/utils/comgt/files/directip.sh | 114 
  package/network/utils/comgt/files/evdo.chat   |  17 --
  .../utils/comgt/files/getcardinfo.gcom|  14 -
  .../network/utils/comgt/files/getcarrier.gcom |  20 --
  .../network/utils/comgt/files/getcnum.gcom|  20 --
  .../network/utils/comgt/files/getimsi.gcom|  17 --
  .../utils/comgt/files/getstrength.gcom|  14 -
  package/network/utils/comgt/files/ncm.json|  78 --
  package/network/utils/comgt/files/ncm.sh  | 255 --
  .../network/utils/comgt/files/runcommand.gcom |  31 ---
  .../network/utils/comgt/files/setmode.gcom|  26 --
  package/network/utils/comgt/files/setpin.gcom |  56 
  package/network/utils/comgt/files/ussd.gcom   |  21 --
  .../utils/comgt/patches/001-compile_fix.patch |  23 --
  .../utils/comgt/patches/002-termios.patch | 105 
  .../utils/comgt/patches/003-no_XCASE.patch|  20 --
  .../utils/comgt/patches/004-check_tty.patch   |  68 -
  23 files changed, 1237 deletions(-)
  delete mode 100644 package/network/utils/comgt/Makefile
  delete mode 100644 package/network/utils/comgt/files/3g.chat
  delete mode 100644 package/network/utils/comgt/files/3g.sh
  delete mode 100644 package/network/utils/comgt/files/3g.usb
  delete mode 100644 package/network/utils/comgt/files/directip-stop.gcom
  delete mode 100644 package/network/utils/comgt/files/directip.gcom
  delete mode 100644 package/network/utils/comgt/files/directip.sh
  delete mode 100644 package/network/utils/comgt/files/evdo.chat
  delete mode 100644 package/network/utils/comgt/files/getcardinfo.gcom
  delete mode 100644 package/network/utils/comgt/files/getcarrier.gcom
  delete mode 100644 package/network/utils/comgt/files/getcnum.gcom
  delete mode 100644 package/network/utils/comgt/files/getimsi.gcom
  delete mode 100644 package/network/utils/comgt/files/getstrength.gcom
  delete mode 100644 package/network/utils/comgt/files/ncm.json
  delete mode 100644 package/network/utils/comgt/files/ncm.sh
  delete mode 100644 package/network/utils/comgt/files/runcommand.gcom
  delete mode 100644 package/network/utils/comgt/files/setmode.gcom
  delete mode 100644 package/network/utils/comgt/files/setpin.gcom
  delete mode 100644 package/network/utils/comgt/files/ussd.gcom
  delete mode 100644 package/network/utils/comgt/patches/001-compile_fix.patch
  delete mode 100644 package/network/utils/comgt/patches/002-termios.patch
  delete mode 100644 package/network/utils/comgt/patches/003-no_XCASE.patch
  delete mode 100644 package/network/utils/comgt/patches/004-check_tty.patch

diff --git a/package/network/utils/comgt/Makefile 
b/package/network/utils/comgt/Makefile
deleted file mode 100644
index db5ea57473..00
--- a/package/network/utils/comgt/Makefile
+++ /dev/null
@@ -1,106 +0,0 @@
-#
-# Copyright (C) 2006-2014 OpenWrt.org
-#
-# This is free software, licensed under the GNU General Public License v2.
-# See /LICENSE for more information.
-#
-
-include $(TOPDIR)/rules.mk
-
-PKG_NAME:=comgt
-PKG_VERSION:=0.32
-PKG_RELEASE:=33
-
-PKG_SOURCE:=$(PKG_NAME).$(PKG_VERSION).tgz
-PKG_SOURCE_URL:=@SF/comgt
-PKG_HASH:=0cedb2a5aa608510da66a99aab74df3db363df495032e57e791a2ff55f1d7913
-
-PKG_MAINTAINER:=Felix Fietkau 
-PKG_LICENSE:=GPL-2.0+
-
-PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME).$(PKG_VERSION)
-PKG_CHECK_FORMAT_SECURITY:=0
-
-PKG_FLAGS:=nonshared
-
-include $(INCLUDE_DIR)/package.mk
-
-define Package/comgt/Default
-  SECTION:=net
-  CATEGORY:=Network
-  SUBMENU:=WWAN
-endef
-
-define Package/comgt
-$(call Package/comgt/Default)
-  TITLE:=Option/Vodafone 3G/GPRS control tool
-  DEPENDS:=+chat
-  URL:=http://manpages.ubuntu.com/manpages/trusty/man1/comgt.1.html
-endef
-
-define Package/comgt-directip
-$(call Package/comgt/Default)
-  TITLE:=Sierra Wireless Direct-IP support
-  DEPENDS:=+comgt +kmod-usb-serial +kmod-usb-serial-sierrawireless 
+kmod-usb-net +kmod-usb-net-sierrawireless
-endef
-
-define Package/comgt-ncm
-$(call Package/comgt/Default)
-  TITLE+=NCM 3G/4G Support
-  DEPENDS:=+comgt +wwan +kmod-usb-serial-option +kmod-usb-net-huawei-cdc-ncm
-endef
-
-define Package/comgt/description
- comgt is a scripting language interpreter useful for establishing
- communications on serial lines and through PCMCIA modems as well as GPRS
- and 3G datacards.
-endef
-
-define Build/Compile
-   $(MAKE) -C $(PKG_BUILD_DIR) \
-   $(TARGET_CONFIGURE_OPTS) \
-   CFLAGS="$(TARGET_CFLAGS)" \
-   LDFLAGS="" \
-   comgt
-endef
-
-define Package/comgt/install
- 

Re: [PATCH] comgt: Move to community packages repo

2021-06-28 Thread Piotr Dymacz

Hi Arjun,

On 28.06.2021 18:52, Arjun AK wrote:

Signed-off-by: Arjun AK 


The only problem here is a D-Link DWR-512B device (ramips/rt305x target) 
which has 'comgt-ncm' package listed under 'DEVICE_PACKAGES', see [1].


I might be wrong here but I think we don't include packages from 
external feeds inside 'DEVICE_PACKAGES' (not sure/don't remember why).


[1] 
https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/image/rt305x.mk#L476


--
Cheers,
Piotr


---
  package/network/utils/comgt/Makefile  | 106 
  package/network/utils/comgt/files/3g.chat |  12 -
  package/network/utils/comgt/files/3g.sh   | 116 
  package/network/utils/comgt/files/3g.usb  |  33 ---
  .../utils/comgt/files/directip-stop.gcom  |  16 --
  .../network/utils/comgt/files/directip.gcom   |  55 
  package/network/utils/comgt/files/directip.sh | 114 
  package/network/utils/comgt/files/evdo.chat   |  17 --
  .../utils/comgt/files/getcardinfo.gcom|  14 -
  .../network/utils/comgt/files/getcarrier.gcom |  20 --
  .../network/utils/comgt/files/getcnum.gcom|  20 --
  .../network/utils/comgt/files/getimsi.gcom|  17 --
  .../utils/comgt/files/getstrength.gcom|  14 -
  package/network/utils/comgt/files/ncm.json|  78 --
  package/network/utils/comgt/files/ncm.sh  | 255 --
  .../network/utils/comgt/files/runcommand.gcom |  31 ---
  .../network/utils/comgt/files/setmode.gcom|  26 --
  package/network/utils/comgt/files/setpin.gcom |  56 
  package/network/utils/comgt/files/ussd.gcom   |  21 --
  .../utils/comgt/patches/001-compile_fix.patch |  23 --
  .../utils/comgt/patches/002-termios.patch | 105 
  .../utils/comgt/patches/003-no_XCASE.patch|  20 --
  .../utils/comgt/patches/004-check_tty.patch   |  68 -
  23 files changed, 1237 deletions(-)
  delete mode 100644 package/network/utils/comgt/Makefile
  delete mode 100644 package/network/utils/comgt/files/3g.chat
  delete mode 100644 package/network/utils/comgt/files/3g.sh
  delete mode 100644 package/network/utils/comgt/files/3g.usb
  delete mode 100644 package/network/utils/comgt/files/directip-stop.gcom
  delete mode 100644 package/network/utils/comgt/files/directip.gcom
  delete mode 100644 package/network/utils/comgt/files/directip.sh
  delete mode 100644 package/network/utils/comgt/files/evdo.chat
  delete mode 100644 package/network/utils/comgt/files/getcardinfo.gcom
  delete mode 100644 package/network/utils/comgt/files/getcarrier.gcom
  delete mode 100644 package/network/utils/comgt/files/getcnum.gcom
  delete mode 100644 package/network/utils/comgt/files/getimsi.gcom
  delete mode 100644 package/network/utils/comgt/files/getstrength.gcom
  delete mode 100644 package/network/utils/comgt/files/ncm.json
  delete mode 100644 package/network/utils/comgt/files/ncm.sh
  delete mode 100644 package/network/utils/comgt/files/runcommand.gcom
  delete mode 100644 package/network/utils/comgt/files/setmode.gcom
  delete mode 100644 package/network/utils/comgt/files/setpin.gcom
  delete mode 100644 package/network/utils/comgt/files/ussd.gcom
  delete mode 100644 package/network/utils/comgt/patches/001-compile_fix.patch
  delete mode 100644 package/network/utils/comgt/patches/002-termios.patch
  delete mode 100644 package/network/utils/comgt/patches/003-no_XCASE.patch
  delete mode 100644 package/network/utils/comgt/patches/004-check_tty.patch

diff --git a/package/network/utils/comgt/Makefile 
b/package/network/utils/comgt/Makefile
deleted file mode 100644
index db5ea57473..00
--- a/package/network/utils/comgt/Makefile
+++ /dev/null
@@ -1,106 +0,0 @@
-#
-# Copyright (C) 2006-2014 OpenWrt.org
-#
-# This is free software, licensed under the GNU General Public License v2.
-# See /LICENSE for more information.
-#
-
-include $(TOPDIR)/rules.mk
-
-PKG_NAME:=comgt
-PKG_VERSION:=0.32
-PKG_RELEASE:=33
-
-PKG_SOURCE:=$(PKG_NAME).$(PKG_VERSION).tgz
-PKG_SOURCE_URL:=@SF/comgt
-PKG_HASH:=0cedb2a5aa608510da66a99aab74df3db363df495032e57e791a2ff55f1d7913
-
-PKG_MAINTAINER:=Felix Fietkau 
-PKG_LICENSE:=GPL-2.0+
-
-PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME).$(PKG_VERSION)
-PKG_CHECK_FORMAT_SECURITY:=0
-
-PKG_FLAGS:=nonshared
-
-include $(INCLUDE_DIR)/package.mk
-
-define Package/comgt/Default
-  SECTION:=net
-  CATEGORY:=Network
-  SUBMENU:=WWAN
-endef
-
-define Package/comgt
-$(call Package/comgt/Default)
-  TITLE:=Option/Vodafone 3G/GPRS control tool
-  DEPENDS:=+chat
-  URL:=http://manpages.ubuntu.com/manpages/trusty/man1/comgt.1.html
-endef
-
-define Package/comgt-directip
-$(call Package/comgt/Default)
-  TITLE:=Sierra Wireless Direct-IP support
-  DEPENDS:=+comgt +kmod-usb-serial +kmod-usb-serial-sierrawireless 
+kmod-usb-net +kmod-usb-net-sierrawireless
-endef
-
-define Package/comgt-ncm
-$(call Package/comgt/Default)
-  TITLE+=NCM 3G/4G Support
-  DEPENDS:=+comgt +wwan +kmod-usb-serial-option +kmod-usb-net-huawei-cdc-ncm
-endef
-
-define Package/comgt/description

Re: [PATCH] comgt: Move to community packages repo

2021-06-28 Thread Arjun AK

On 28/06/21 10:56 pm, Piotr Dymacz wrote:

Hi Arjun,

On 28.06.2021 18:52, Arjun AK wrote:

Signed-off-by: Arjun AK 


The only problem here is a D-Link DWR-512B device (ramips/rt305x target) 
which has 'comgt-ncm' package listed under 'DEVICE_PACKAGES', see [1].
But the package name is "comgt" not "comgt-ncm". Does this mean DWR-512B 
has no dependency on comgt and is trying to build a non existent package?


-
Arjun

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] comgt: Move to community packages repo

2021-06-28 Thread Piotr Dymacz

Hi Arjun,

On 28.06.2021 19:43, Arjun AK wrote:

On 28/06/21 10:56 pm, Piotr Dymacz wrote:

Hi Arjun,

On 28.06.2021 18:52, Arjun AK wrote:

Signed-off-by: Arjun AK 


The only problem here is a D-Link DWR-512B device (ramips/rt305x target) 
which has 'comgt-ncm' package listed under 'DEVICE_PACKAGES', see [1].

But the package name is "comgt" not "comgt-ncm". Does this mean DWR-512B
has no dependency on comgt and is trying to build a non existent package?


'comgt-ncm' is part of the 'comgt', see:
https://github.com/openwrt/openwrt/blob/master/package/network/utils/comgt/Makefile#L47

--
Cheers,
Piotr



-
Arjun




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] comgt: Move to community packages repo

2021-06-28 Thread John Crispin


On 28.06.21 19:26, Piotr Dymacz wrote:
I might be wrong here but I think we don't include packages from 
external feeds inside 'DEVICE_PACKAGES' (not sure/don't remember why). 


I am in favour of moving all none-core packages to the feeds. the 
dependency should be removed and a note should be added to the wiki 
indicating that if a release/snapshot image is installed an opkg call 
shall be issued


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] comgt: Move to community packages repo

2021-06-28 Thread Piotr Dymacz

Hi John,

On 28.06.2021 20:32, John Crispin wrote:


On 28.06.21 19:26, Piotr Dymacz wrote:
I might be wrong here but I think we don't include packages from 
external feeds inside 'DEVICE_PACKAGES' (not sure/don't remember why). 


I am in favour of moving all none-core packages to the feeds. the
dependency should be removed and a note should be added to the wiki
indicating that if a release/snapshot image is installed an opkg call
shall be issued


Sounds good to me, just wanted to warn about the existing dependency.

--
Cheers,
Piotr



      John




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] comgt: Move to community packages repo

2021-06-28 Thread Paul Spooren



On 6/28/21 8:53 AM, Piotr Dymacz wrote:

Hi John,

On 28.06.2021 20:32, John Crispin wrote:


On 28.06.21 19:26, Piotr Dymacz wrote:
I might be wrong here but I think we don't include packages from 
external feeds inside 'DEVICE_PACKAGES' (not sure/don't remember why). 


I am in favour of moving all none-core packages to the feeds. the
dependency should be removed and a note should be added to the wiki
indicating that if a release/snapshot image is installed an opkg call
shall be issued
I'm in favor of this too but if it's a core feature (i.e. SIM card 
support) we should provide the package by default to, not?


Sounds good to me, just wanted to warn about the existing dependency.



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] comgt: Move to community packages repo

2021-06-28 Thread John Crispin


On 28.06.21 21:14, Paul Spooren wrote:
I'm in favor of this too but if it's a core feature (i.e. SIM card 
support) we should provide the package by default to, not? 


this should be explained in the wiki,

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] comgt: Move to community packages repo

2021-06-28 Thread Paul Spooren


On 6/28/21 9:53 AM, John Crispin wrote:


On 28.06.21 21:14, Paul Spooren wrote:
I'm in favor of this too but if it's a core feature (i.e. SIM card 
support) we should provide the package by default to, not? 


this should be explained in the wiki,
Agree, APU boards etc also need some extra packages to support SDcards 
and things. Let's do this.


    John


___
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


Usability issues for DSA upgrade

2021-06-28 Thread Luiz Angelo Daros de Luca
Hello,

While upgrading from 19.07 to 21.02, there is an scary error message
when target migrates to DSA (both Luci or CLI):

root@OpenWrt:/tmp# sysupgrade -n
openwrt-21.02.0-rc3-mvebu-cortexa9-linksys_wrt1900acs-squashfs-sysupgrade.bin
Device linksys,shelby not supported by this image
Supported devices: linksys,wrt1900acs armada-385-linksys-shelby
linksys,shelby - Image version mismatch: image 1.1, device 1.0. Please
wipe config during upgrade (force required) or reinstall. Reason:
Config cannot be migrated from swconfig to DSA
Image check failed.

OpenWrt devs are probably confident that they can force an upgrade for
that image. "force" means "I know what I'm doing, ignore the checks".
However, for many users, sometimes non-technical ones, they do not
really know what they are doing. There might be a wave of support
requests about that message and another wave of bricked devices. Even
knowing some OpenWrt internals, I'm not sure what "...or reinstall"
means. Shouldn't '-n' be enough? Isn't sysupgrade already a reinstall?
Or should it be the factory image? If it is really suggesting factory
images, should I return to the original firmware before or use some
emergency firmware recovery?

Can we provide a 19.07 update to, at least, allow the upgrade without
errors or "force" if confs are not kept? "Force" comes with great
responsibility and it will overwrite other checks as board
compatibility.

The error message could be, instead of:

"Please wipe config during upgrade (force required) or reinstall.
Reason: Config cannot be migrated from swconfig to DSA"

Something like this:

"Configuration cannot be migrated from swconfig to DSA. To properly
validate this firmware, please update OpenWrt at least to version
19.07.8 or pkgfoobar to version 1.2.3 and retry. Alternatively, if you
are sure that this image is compatible, you can proceed not retaining
the current configuration and forcing the process."

I omitted the "...or reinstall'' as I'm still not sure what it means.
I also used "not retaining the current configuration" as Luci (nor
sysupgrade) does not mention wipe but "Keep settings and retain the
current configuration" (which, by the way, seems to be two redundant
sentences).

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] comgt: Move to community packages repo

2021-06-28 Thread Lech Perczak

W dniu 2021-06-28 o 21:55, Paul Spooren pisze:


On 6/28/21 9:53 AM, John Crispin wrote:


On 28.06.21 21:14, Paul Spooren wrote:
I'm in favor of this too but if it's a core feature (i.e. SIM card 
support) we should provide the package by default to, not? 


this should be explained in the wiki,
Agree, APU boards etc also need some extra packages to support SDcards 
and things. Let's do this.


    John


___
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


OTOH, this differs a bit from such packages, by being needed to connect 
to WAN on such devices. This is the same way as uqmi does on some - 
removing it would require other Internet connection to bootstrap its 
installation.


--
Kind regards,
Lech


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH 0/1] Workaround for rut955 modem initialization

2021-06-28 Thread Daniel Golle
On Mon, Jun 28, 2021 at 02:19:11PM +0200, John Crispin wrote:
> 
> On 28.06.21 13:56, ontje.luensd...@dlr.de wrote:
> > This will probably affect all other modems and we are not sure if this may 
> > cause
> > side-effects on other devices.
> 
> 
> As similar problem can be observed when looking at swconfig. some switches
> need a reset, others do not. for this purpose an "option reset 0/1" was
> introduced in uci. In this case maybe "modem_reset" might be a good option.

This particular device (Teltonika RUT955) got a dedicated reset line for
the USB-connected internal Quectel EC-25 modem available as GPIO which
could be toggled on boot if needed (in user-space or by wiring up
device-tree magic doing that).

That's more reliable than using QMI to trigger the reset, and also more
generic in terms of people not even using 'uqmi' on that device.


Cheers


Daniel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] comgt: Move to community packages repo

2021-06-28 Thread Sergey Ryazanov
On Mon, Jun 28, 2021 at 11:57 PM Lech Perczak  wrote:
> W dniu 2021-06-28 o 21:55, Paul Spooren pisze:
>> On 6/28/21 9:53 AM, John Crispin wrote:
>>> On 28.06.21 21:14, Paul Spooren wrote:
 I'm in favor of this too but if it's a core feature (i.e. SIM card
 support) we should provide the package by default to, not?
>>>
>>> this should be explained in the wiki,
>>
>> Agree, APU boards etc also need some extra packages to support SDcards
>> and things. Let's do this.
>
> OTOH, this differs a bit from such packages, by being needed to connect
> to WAN on such devices. This is the same way as uqmi does on some -
> removing it would require other Internet connection to bootstrap its
> installation.

Yep, removing the comgt package from the firmware sounds like an
anecdote from the 90's: The modem driver is on CD, the CD-ROM driver
on the Internet.

OTOH, Arjun has been trying to draw attention to the patch for comgt
for a year. And no one reacted to his quite reasonable fix.

-- 
Sergey

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] comgt: Move to community packages repo

2021-06-28 Thread Lech Perczak

W dniu 2021-06-29 o 01:07, Sergey Ryazanov pisze:

On Mon, Jun 28, 2021 at 11:57 PM Lech Perczak  wrote:

W dniu 2021-06-28 o 21:55, Paul Spooren pisze:

On 6/28/21 9:53 AM, John Crispin wrote:

On 28.06.21 21:14, Paul Spooren wrote:

I'm in favor of this too but if it's a core feature (i.e. SIM card
support) we should provide the package by default to, not?

this should be explained in the wiki,

Agree, APU boards etc also need some extra packages to support SDcards
and things. Let's do this.

OTOH, this differs a bit from such packages, by being needed to connect
to WAN on such devices. This is the same way as uqmi does on some -
removing it would require other Internet connection to bootstrap its
installation.

Yep, removing the comgt package from the firmware sounds like an
anecdote from the 90's: The modem driver is on CD, the CD-ROM driver
on the Internet.

OTOH, Arjun has been trying to draw attention to the patch for comgt
for a year. And no one reacted to his quite reasonable fix.


My thoughts exactly.
Also, I realized that removing comgt would render the device requiring 
it unable to reestablish WAN connection also after sysupgrade - which is 
a no-brainer for me.
My custom builds carry a very similar patch for a few years now, and 
Arjun's patch looks very reasonable to me - maybe I shall test it in my 
builds very soon, and provide feedback, as I'd like to see it merged as 
well.


--
Kind regards,
Lech


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH 0/1] Workaround for rut955 modem initialization

2021-06-28 Thread Reiner Karlsberg

+1

Actually, I am using the RUT955 running PPP, _not_ qmi.
For the requirement (or precaution) of a reset of the modem, using the GPIO for 
the RUT955
looks like the proper solution to go.

In the opposite, ZBT confirmed, that on their WE826 there is no wiring
to (power-)reset the installed Quectel EC25.


@Daniel:
Could you please publish a complete shell-script on the openwrt forum, using 
the GPIO on the RUT955
to reset the EC25 ?

Cheers,

Reiner Karlsberg


Am 29.06.2021 um 01:38 schrieb Daniel Golle:

On Mon, Jun 28, 2021 at 02:19:11PM +0200, John Crispin wrote:


On 28.06.21 13:56, ontje.luensd...@dlr.de wrote:

This will probably affect all other modems and we are not sure if this may cause
side-effects on other devices.



As similar problem can be observed when looking at swconfig. some switches
need a reset, others do not. for this purpose an "option reset 0/1" was
introduced in uci. In this case maybe "modem_reset" might be a good option.


This particular device (Teltonika RUT955) got a dedicated reset line for
the USB-connected internal Quectel EC-25 modem available as GPIO which
could be toggled on boot if needed (in user-space or by wiring up
device-tree magic doing that).

That's more reliable than using QMI to trigger the reset, and also more
generic in terms of people not even using 'uqmi' on that device.


Cheers


Daniel

___
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: [PATCH 0/1] Workaround for rut955 modem initialization

2021-06-28 Thread Ontje.Luensdorf
Hi all,


Daniel Golle  writes:

> On Mon, Jun 28, 2021 at 02:19:11PM +0200, John Crispin wrote:
> This particular device (Teltonika RUT955) got a dedicated reset line for
> the USB-connected internal Quectel EC-25 modem available as GPIO which
> could be toggled on boot if needed (in user-space or by wiring up
> device-tree magic doing that).
>
> That's more reliable than using QMI to trigger the reset, and also more
> generic in terms of people not even using 'uqmi' on that device.

thanks for the feedback. We will attempt to follow the advices. This
will take time, though. The device is currently being field tested.

Best regards,
Ontje
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


RE: [PATCH v2] cn913x: add support for iEi Puzzle-M901/Puzzle-M902

2021-06-28 Thread Ian Chang
Hi Daniel

>> @@ -0,0 +1,182 @@
>> +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
>> +/*
>> + * Copyright (C) 2019 Marvell International Ltd.
>> + *
>> + * Device tree for the CN9131-DB board.
>> + */
>> +
>> +#include "puzzle-m901-cn9130.dts"

>Please do not include a 'dts' file, but rather move common properties to a 
>shared 'dtsi' and include that for both boards.

The dts file I referenced from Marvell, it also contains a "dts" in 
arch/arm64/boot/dts/marvell/cn9132-db.dts of kernel 5.10.40
May I use the same way, or is it necessary to change

Best Regards
Ian Chang


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel