Re: [OpenWrt-Devel] Use DHCP by default on single port devices
Hi, W dniu 2018-08-28 o 22:29, Michael Heimpold pisze: Hi, "DHCP Client", even with an alternative static IP address, might not work for some home users. to make this work better, some companies are choosing the static fallback IP address in the AutoIP range 169.254.x.x/16. At least Windows will fallback to this range if it does not find a DHCP server on this link; so it should at least possible to browse to the web gui and/or open a SSH connection... without reconfiguring your Windows system. I don't know whether this works out-of-the-box on Mac or usual Linux distros, too. At least on my Debian boxen, using NetworkManager, it does not. I have to select this type of autoconfiguration manually first. Regards, Michael ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel To me, adding of 2 separate mechanisms (mDNS, UPnP) on top of fixed IP address or APIPA sounds like a horrendous feature creep, just to replace one mechanism that works (DHCP). On my machines, I use none of the mechanisms. I don't like the idea of installing Avahi on Linux boxen, or enabling UPnP on Windows ones, just to get to my router/bridge/AP/whatever-runs-OpenWrt for initial configuration. When configuring the Ubiquiti bridges (for example Nanobridge M5) for the first time, while sitting on rooftop with my laptop only, DHCP works quite well - it is not a big effort to just disable it at the end of configuration. When doing testing on the ground, I usually have a router with DHCP server already available, so using it to assign IP to newly configured device might be useful, but it usually is not a big problem to temporarily connect Ethernet to the newly configured device, still having Wi-Fi connectivity. Also, there is another class of devices, beside "bridges". Travel routers, such as TP-Link WR703N. Having only one USB port it is clearly a router, having USB port dedicated for mobile broadband modem. Yet this is the most typical scenario. One might use it as an access point, or as weather station as well. Those configurations suit different types of address assignment method. Do we really need to make the distinction between them? Actually, when writing the above, one idea struck me. When starting, dnsmasq checks if there are no other DHCP servers present on the network, and if they are, it bails out. Maybe it would be possible to use IP assigned by authoritative DHCP server, if one is already present, otherwise startup DHCP as before. Still, this would be quite unusual behaviour, and this might have flaws I have yet to think of -- With kind regards, Lech ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity Bullet M2HP
Hi,
Just a couple of remarks inline, based on my knowledge about XM series.
W dniu 2018-11-15 o 13:32, Petr Štetiar pisze:
From: Petr Štetiar
CPU: AR9342 SoC
RAM: 64 MB DDR2
Flash:8 MB NOR SPI
Ports: 100 MBit (24V PoE in)
WLAN: 2.4 GHz
UART: 1 UART on PCB marked as J1 with 115200 8N1 config
LEDs: Power, Ethernet, WPS, USB, RF 2.4G, RF 5G
Buttons:Reset
UART connection details
.-.
| |
[ETH] J1 [ANT]
|o VCC o RX o TX o GND|
`-'
Flashing instructions
A) Serial console, U-Boot and TFTP
1. Connect to serial header J1 on the PCB
2. Power on device and enter U-Boot console
3. Set up TFTP server serving an OpenWrt initramfs build
4. Load initramfs build using the command tftpboot in the U-Boot cli
5. Boot the loaded image using the command bootm
6. Copy squashfs OpenWrt sysupgrade build to the booted device
7. Use mtd to write sysupgrade to partition "firmware"
8. Reboot and enjoy
B) Sysupgrade over SSH in airOS v6.1.7
1. Upgrade or downgrade airOS to v6.1.7
2. git clone
https://github.com/true-systems/ubnt-bullet-m2hp-openwrt-flashing
3. cd ubnt-bullet-m2hp-openwrt-flashing
4. less README.md
5. make flash
FW_UBNT=/path/to/your/openwrt-ath79-generic-ubnt_bullet-m2hp-squashfs-sysupgrade.bin
Signed-off-by: Petr Štetiar
---
target/linux/ath79/base-files/etc/board.d/01_leds | 1 +
.../linux/ath79/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/dts/ar9342_ubnt_bullet-m2hp.dts | 66
target/linux/ath79/dts/ar9342_ubnt_xw.dtsi | 88 ++
target/linux/ath79/image/generic-ubnt.mk | 16
5 files changed, 172 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_bullet-m2hp.dts
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds
b/target/linux/ath79/base-files/etc/board.d/01_leds
index f04eb7f..281686e 100755
--- a/target/linux/ath79/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/base-files/etc/board.d/01_leds
@@ -94,6 +94,7 @@ tplink,tl-wr841-v11)
ucidef_set_led_switch "lan4" "LAN4" "tp-link:green:lan4" "switch0"
"0x02"
;;
ubnt,bullet-m|\
+ubnt,bullet-m2hp|\
ubnt,nano-m|\
ubnt,rocket-m)
ucidef_set_rssimon "wlan0" "20" "1"
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
b/target/linux/ath79/base-files/etc/board.d/02_network
index 5f02c57..8556bd3 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -22,6 +22,7 @@ ath79_setup_interfaces()
tplink,tl-wa901nd-v2|\
tplink,tl-wr703n|\
ubnt,bullet-m|\
+ ubnt,bullet-m2hp|\
I'd call it ubnt,bullet-m-xw, as this patch will very likely support
Bullet-M5HP also.
ubnt,lap-120|\
ubnt,nanostation-ac-loco|\
ubnt,rocket-m|\
diff --git a/target/linux/ath79/dts/ar9342_ubnt_bullet-m2hp.dts
b/target/linux/ath79/dts/ar9342_ubnt_bullet-m2hp.dts
new file mode 100644
index 000..2e978cf
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_bullet-m2hp.dts
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include
+#include
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,bullet-m2hp", "ubnt,xw";
+ model = "Ubiquiti Bullet M2HP (XW)";
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ link1 {
+ label = "ubnt:red:link1";
+ gpios = < 11 GPIO_ACTIVE_LOW>;
+ };
+
+ link2 {
+ label = "ubnt:orange:link2";
+ gpios = < 16 GPIO_ACTIVE_LOW>;
+ };
+
+ link3 {
+ label = "ubnt:green:link3";
+ gpios = < 13 GPIO_ACTIVE_LOW>;
+ };
+
+ link4 {
+ label = "ubnt:green:link4";
+ gpios = < 14 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
Shouldn't those LEDs be defined in ar9342_ubnt_xw.dtsi?
AFAIK all XW boards (Bullet, Nano, Rocket) use same LED configurations,
like in XM target also.
Please take a look at ath79 device tree for XM boards and for board file
for XW in ar71xx.
+
+ {
+ status = "okay";
+
+ phy-mask = <4>;
+ phy4: ethernet-phy@4 {
+ phy-mode = "rgmii";
+ reg = <4>;
+ };
+};
+
+ {
+ status = "okay";
+
+ pll-data = <0x0600 0x0101 0x1313>;
+ mtd-mac-address = < 0x0>;
+
+ phy-mode = "rgmii";
+ phy-handle = <>;
+
+ gmac-config {
+ device = <>;
+ rxd-delay = <3>;
+ rxdv-delay = <3>;
+ };
+};
+
+ {
+ status =
Re: [OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity Bullet M2HP
Hi Petr, Thanks for testing! W dniu 2018-11-18 o 17:05, Petr Štetiar pisze: Lech Perczak [2018-11-18 01:29:08]: Hi, Actually, I meant building and testing on ar71xx target instead of ath79. But anyway, you might include this little change in your patch, because when I added this support, XW wasn't ported to ath79 yet. Therefore the LED configuration didn't need any alterations, as on ath79 it doesn't specify PWM support. I've just pulled your changes into my testing branch so it looks like this now: 07b41e3 Merge commit 'refs/pull/1372/head' of https://github.com/openwrt/openwrt into nanostation-m-xw a49e6d0 ar71xx: ubnt-(xm,xw): add rssileds package 78c3af2 ar71xx: ubnt-(xm,xw): create RSSI monitor on wlan0 bc95553 ath79: ubnt-xw: Add rssileds kernel package ffc74ff WIP: ath79: Add support for Ubiquiti Nanostation M (XW) 67a8871 ath79: Add support for Ubiquity Bullet M (XW) dd02a19 ar71xx: fix TP-Link Archer C7 v5 switch LEDs 251c350 mt76: update to the latest version Then I've built ar71xx image for nano-m-xw, but it seems like this image doesn't work out of the box on bullet-m-xw, the green/link4 is on after boot, and RSSI LEDs doesn't work as on ath79. Setting timer tigger on the LEDs manually works. Don't have time right now to find out what's the problem, any idea where should I look at? -- ynezz A dump of /etc/config/system right after first boot might be useful, as well as checking if rssileds package was indeed pulled in via "opkg list --installed | grep rssileds" . Maybe .config needs to be refreshed. At least on XM it worked for me :) -- Pozdrawiam, Lech Perczak lech.perc...@gmail.com Mobile: +48 694 309 185 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity Bullet M2HP
Hello Petr, W dniu 2018-11-18 o 21:18, Petr Štetiar pisze: Lech Perczak [2018-11-18 17:21:46]: well as checking if rssileds package was indeed pulled in via "opkg list Somehow the rssileds package wasn't enabled even if I've selected building of nano-xm-w via menu config. I've deleted the .config and created a new one, then it was selected, weird. Anyway it works also on ar71xx/bullet-m-xw. -- ynezz Big thanks for testing! Can I add Tested-By tag to my patch? :) -- Pozdrawiam, Lech Perczak lech.perc...@gmail.com Mobile: +48 694 309 185 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity
Hi Petr, Joe, W dniu 2018-11-18 o 10:03, Petr Štetiar pisze: Joe Ayers [2018-11-17 18:40:56]: Hm, I'm really wondering what version of airOS do you've on your devices, that the TFTP recovery method works for you. root@AE6XE-NSM5XW-QTH:~# cat /etc/openwrt_version r7258-5eb055306f I was asking for airOS version, so it should rather be `cat /etc/version`. I don't have /etc/openwrt_version in my airOS v6.1.7 system. I applied this 002-firmware-check-fix.patch to your build referenced above and tftp'd it to a NS M5 XW with "U-Boot 1.1.4-s1039 (May 24 2017 - 15:58:18)" bootloader. Looks like nano-m-xw is missing from .../base-files/etc/board.d/02_network. Consequently, the network physical ports are non-functional and the wireless is not showing up. nano-m-xw missing in 02_network as it's probably standard eth0/eth1 setup so it would use the default: *) ucidef_set_interfaces_lan_wan "eth0" "eth1" ;; This is indeed the case, also for XM. >From the dmesg it seems like both eth0/eth1 devices are setup, but they apparently doesn't work for you for some reason. Are at least the MAC addresses correct? I recall that ar71xx had a hack for freezing Ethernet ports on XW boards. This may need to be ported also. I need to dig into the sources for details. This is likely as according to Joe's kernel log both links are up and established actually, but nothing is received. Don't know why the wifi interface wasn't autodetected. It seems like I might have something wrong in my DTS, maybe something is missing in the generic code somewhere. This indeed seems like issue with device tree, as in kernel log I don't see the ath9k driver even probing the radio. In XM case it would at least complain about missing calibration data. I'd also take a look at UBNT WA device tree, ath9k wmac is used there as 2.4GHz-only management radio, and configuration looks very similar to yours. You might also take a look at ar9344_tplink_tl-wdr4300.dtsi for more examples on configuration of ath9k driver via device tree. Also, you might want to take a look at "target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom" - maybe you need to extract ath9k eeprom there. But this is when you actually get ath9k to at least start probing. What other data would be helpful? I would probably need to read the sources, add some debugging printfs and do a few (maybe a lot) reboots to find out where the problem is. I'll try to look at it more when I've some spare time, until then it will probably need someone more experienced with this platform (Lech?) to tell us what might be wrong here. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Pozdrawiam, Lech Perczak lech.perc...@gmail.com Mobile: +48 694 309 185 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity Bullet M2HP
Hi,
W dniu 2018-11-16 o 16:13, Petr Štetiar pisze:
Lech Perczak [2018-11-15 19:30:00]:
Hi,
Just a couple of remarks inline, based on my knowledge about XM series.
thanks for the review!
+ ubnt,bullet-m2hp|\
I'd call it ubnt,bullet-m-xw, as this patch will very likely support
Bullet-M5HP also.
Ok
+ link4 {
+ label = "ubnt:green:link4";
+ gpios = < 14 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
Shouldn't those LEDs be defined in ar9342_ubnt_xw.dtsi?
AFAIK all XW boards (Bullet, Nano, Rocket) use same LED configurations, like
in XM target also.
It's hard for me to add support for something I don't have on the table and
can't test it at least quickly, so it's hard to guess what should be
common and share stuff and what's separate for each device.
This is the situation where we have to rely on knowledge of others :)
The whole range of Ubiquiti Airmax devices uses essentially those two
boards, with functionally-equivalent variants based on XM and XW boards.
For example, Nanostation is basically a Bullet with extra ethernet port,
and Rocket is a Bullet with added USB port.
As far as I understand ar71xx code, the same situation is present on XW
boards. Same functionality, different SoCs.
Feel free to ask me any questions on this topic :)
Please take a look at ath79 device tree for XM boards and for board file for
XW in ar71xx.
I did, but wasn't smart from that anyway. I would need more experience with
those device to understand the differencies.
It'd be great if support for all of them could be included in
ar9342_ubnt_xw.dtsi, and then secondary ethernet and USB only enabled in
respective .dts files. It'd be even better if someone on the list had a
Rocket M XW to test, as it is the fullest variant.
Unfortunately I only have access to XM-based devices :(
+ DEVICE_TITLE := Ubiquiti Bullet M2HP
Same as before, I'd call it ubnt_bullet-m-xw, as this patchset should
automatically support Bullet-M5HP also.
Ok so it might be safe to change it to `Ubiquiti Bullet M2 and M5 HP (XW)` ?
I'd go with just Ubiquiti Bullet-M (XW), as this target will directly
support also Nanobridge and Powerbeam series, which also have frequency
variants available for 900MHz and 3.4GHz bands (for licensed or amateur
radio use).
-- ynezz
Also, wouldn't you mind reviewing and/or testing my PR regarding RSSI
indicator LEDs on your M2HP on ar71xx target?
It is located on Github: https://github.com/openwrt/openwrt/pull/1372
I only had a chance to test it against Nanobridge M5 (XM version).
Also please rebase it on top of current master if you do decide to test
it :)
--
With kind regards,
Lech
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity Bullet M2HP
W dniu 2018-11-17 o 07:33, Petr Štetiar pisze: Lech Perczak [2018-11-16 18:46:40]: Hi, For example, Nanostation is basically a Bullet with extra ethernet port, and Rocket is a Bullet with added USB port. Ah, thanks for explanation. You're welcome It'd be great if support for all of them could be included in ar9342_ubnt_xw.dtsi, and then secondary ethernet and USB only enabled in respective .dts files. It'd be even better if someone on the list had a Rocket M XW to test, as it is the fullest variant. Hm, so maybe I should move definition of mdio and eth0 from ar9342_ubnt_bullet-m-xw.dts to ar9342_ubnt_xw.dtsi as well? But this could be done later once someone with Nanostation XW shows up and can confirm, that it actually works. Yes please :) Also, wouldn't you mind reviewing and/or testing my PR regarding RSSI indicator LEDs on your M2HP on ar71xx target? It is located on Github: https://github.com/openwrt/openwrt/pull/1372 I only had a chance to test it against Nanobridge M5 (XM version). Ok, but I don't have much experience with RSSI LEDs, so can you tell me how would you like me to test it on my M2HP? Thanks. It's just a matter of flashing build including my patch, and then establishing a connection. Bullet may work either as AP or client, the link LEDS should just light up and show the signal strength after you connect :) -- ynezz . -- Pozdrawiam, Lech Perczak lech.perc...@gmail.com Mobile: +48 694 309 185 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity Bullet M2HP
Hi Petr, Adrian, W dniu 2018-11-17 o 07:44, Petr Štetiar pisze: m...@adrianschmutzler.de [2018-11-16 19:15:41]: Hi Adrian, if I haven't overlooked it, the patch does not provide a "factory" Image as in ar71xx, at least according to "Flashing instructions". if I parse this correctly, then my answer is, that I simply didn't included instructions for flashing of factory image as it wasn't possible at that time, because `fwupdate.real` utility in airOS v6+ (I'm not 100% sure about this), doesn't allow flashing of unsigned factory images, so you simply couldn't flash other factory images then those from Ubiquity. XW.v6.1.7# fwupdate.real -m /tmp/openwrt-ath79-generic-ubnt_bullet-m2hp-squashfs-factory.bin -d ... Current: XW.ar934x.v6.1.7.32555.180523.1754 New ver: XW.ar934x.v6.0.4-OpenWrt-r8452+9-e95e9fc Versions: New(393220) 6.0.4, Required(393220) 6.0.4 ... Bad Image Structure Signature check failed But in the meantime it was possible to remove this RSA signature checking in `fwupdate.real`, so in v2 of this patch, there are instructions for flashing of factory images: B) Experimental factory image flashing over SSH from airOS v6.1.7 1. You need to flash your UBNT M2HP with airOS v6.1.7 firmware no other airOS version is currently supported 2. git clone https://github.com/true-systems/ubnt-bullet-m2hp-openwrt-flashing 3. cd ubnt-bullet-m2hp-openwrt-flashing 4. make flash-factory FW_OWRT=/path/to/your/openwrt-ath79-generic-ubnt_bullet-m-xw-squashfs-factory.bin Please note, that so far it was tested only on two different Bullet M2HP (XW) devices and it worked. If you've such device and are willing to risk testing it, you're more then welcome. Any feedback is appreciated. Thanks! Wasn't this possible with downgrading to AirOS 5 first just as it is done for XM series? Please take a look for instructions for them, on XM the procedure is quite easy. -- ynezz -- Pozdrawiam, Lech Perczak lech.perc...@gmail.com Mobile: +48 694 309 185 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity
W dniu 2018-11-17 o 15:11, Joe Ayers pisze: For example, Nanostation is basically a Bullet with extra ethernet port, and Rocket is a Bullet with added USB port. Ah, thanks for explanation. You're welcome It'd be great if support for all of them could be included in ar9342_ubnt_xw.dtsi, and then secondary ethernet and USB only enabled in respective .dts files. It'd be even better if someone on the list had a Rocket M XW to test, as it is the fullest variant. Hm, so maybe I should move definition of mdio and eth0 from ar9342_ubnt_bullet-m-xw.dts to ar9342_ubnt_xw.dtsi as well? But this could be done later once someone with Nanostation XW shows up and can confirm, that it actually works. Yes please :) I have a NanoStation M5 XW (and can get access to a NS M2 XW).I can test. What's the reference to build and test? I'd go against ar71xx images, as those support XW line already. if I haven't overlooked it, the patch does not provide a "factory" Image as in ar71xx, at least according to "Flashing instructions". if I parse this correctly, then my answer is, that I simply didn't included instructions for flashing of factory image as it wasn't possible at that time, because `fwupdate.real` utility in airOS v6+ (I'm not 100% sure about this), doesn't allow flashing of unsigned factory images, so you simply couldn't flash other factory images then those from Ubiquity. The signature restriction for Ubiquiti is enforced in the AirOS UI. The bootloader does not check for signatures. We routinely tftp images to all the newer UBNT devices based on 3.18.06.1, including latest models for NanoStation M2 XW. http://www.arednmesh.org XW.v6.1.7# fwupdate.real -m /tmp/openwrt-ath79-generic-ubnt_bullet-m2hp-squashfs-factory.bin -d ... Current: XW.ar934x.v6.1.7.32555.180523.1754 New ver: XW.ar934x.v6.0.4-OpenWrt-r8452+9-e95e9fc Versions: New(393220) 6.0.4, Required(393220) 6.0.4 ... Bad Image Structure Signature check failed The current bootloader version in AirOS is checking the version string. I don't know exactly the check, but if using the format above of "Current", then tftp works. It doesn't work with the string "OpenWrt"... Wasn't this possible with downgrading to AirOS 5 first just as it is done for XM series? Please take a look for instructions for them, on XM the procedure is quite easy. These newer models didn't exist when AirOS 5 was released, like the NanoStation M2 XW. The AirOS 5 firmware won't install, at least we never found a way for it to work, but didn't need to as we directly tftp to the latest AirOS versions. Note, the NS M2 XW has a 8035 PHY and works with the rocket-m-xw image in 3.18.06.1. It didn't work with the loco-m-xw image, did't recognize PHY. This seems expected, as Nanostation Loco is basically a Bullet with a different type of antenna (a sector one), and it lacks 2nd ethernet port. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Pozdrawiam, Lech Perczak lech.perc...@gmail.com Mobile: +48 694 309 185 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity Bullet M2HP
Hello Petr, W dniu 2018-11-17 o 14:04, Petr Štetiar pisze: Lech Perczak [2018-11-17 10:25:30]: ar9342_ubnt_xw.dtsi, and then secondary ethernet and USB only enabled in respective .dts files. It'd be even better if someone on the list had a Rocket M XW to test, as it is the fullest variant. Hm, so maybe I should move definition of mdio and eth0 from ar9342_ubnt_bullet-m-xw.dts to ar9342_ubnt_xw.dtsi as well? But this could be done later once someone with Nanostation XW shows up and can confirm, that it actually works. Yes please :) Yes to what? :-) a) Send third version of the patch with mdio/eth0 in ar9342_ubnt_xw.dtsi b) Wait for someone with Nanostation XW to confirm, that it could work and don't assume anything I meant sending new patch, but after reading recent emails I believe it 's in the works already :) Also, wouldn't you mind reviewing and/or testing my PR regarding RSSI indicator LEDs on your M2HP on ar71xx target? It is located on Github: https://github.com/openwrt/openwrt/pull/1372 I only had a chance to test it against Nanobridge M5 (XM version). Ok, but I don't have much experience with RSSI LEDs, so can you tell me how would you like me to test it on my M2HP? Thanks. It's just a matter of flashing build including my patch, and then establishing a connection. Bullet may work either as AP or client, the link LEDS should just light up and show the signal strength after you connect :) It seems, that as being on the latest master, all I had to do was adding the module package: diff --git a/target/linux/ath79/image/generic-ubnt.mk b/target/linux/ath79/image/generic-ubnt.mk index 2d0b1ad..00f1159 100644 --- a/target/linux/ath79/image/generic-ubnt.mk +++ b/target/linux/ath79/image/generic-ubnt.mk @@ -66,6 +66,7 @@ endef define Device/ubnt-xw $(Device/ubnt) UBNT_TYPE := XW + DEVICE_PACKAGES += rssileds UBNT_CHIP := ar934x UBNT_BOARD := XM UBNT_VERSION := 6.0.4 and the light show has started, so it works, nice. Thanks! Tested-by: Petr Štetiar Actually, I meant building and testing on ar71xx target instead of ath79. But anyway, you might include this little change in your patch, because when I added this support, XW wasn't ported to ath79 yet. Therefore the LED configuration didn't need any alterations, as on ath79 it doesn't specify PWM support. My 1st patch drops it also from ar71xx, which seems likely to stay for 19.01 release. If you'd like, I can build the ar71xx image for you, or you can just checkout my branch from github directly. I'll rebase it against current master. -- ynezz -- Pozdrawiam, Lech Perczak lech.perc...@gmail.com Mobile: +48 694 309 185 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79 policy questions
Hello Daniel, Answers inline. W dniu 2018-09-12 o 04:24, Daniel F. Dickinson pisze: Hi, I'm having trouble finding a concise summary of what is the policy for using multiple leds for boot/failsafe, etc status (in this case updating CAP324 to use both colours of the 'power' led, now that such logic in in ath79 tree). Also are leds supposed to be named according to manufacturer or according to model number (presuming that for ath79 we don't care about using the same led names as for ar71xx)? IIRC most targets use same names as for ar71xx. I'd go and review a few other device trees for supported devices and check that, to maintain consistency across the target. Also pursuant to https://github.com/openwrt/openwrt/pull/1062 should CAP324 be DHCP or a static IP on it's only wired interface? (It's an AP). Since no decision regarding that PR was made by maintainers yet, I believe the old policy is still in effect. I don't think that your changes should depend on this one, and IMHO consistency is more important here. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- With kind regards, Lech ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add support for tplink tl-wdr3600 modified with 16M flash
Hi, W dniu 2019-03-15 o 10:18, Chuanhong Guo pisze: Hi! On Fri, Mar 15, 2019 at 2:42 PM Russell Senior wrote: To modify a WDR3600 with 16MB flash, you will need an external SPI programmer and soldering tools. First, obtain a copy of the starting contents either with the external programmer or from commands in OpenWrt: Unfortunately OpenWrt never accepts device support requiring hardware modifications. I think part of the reason is that there are too many possible variants when it comes to hardware modifications and all those variants will make users confused. Yeah, that's the rule. In ar71xx such Device Tree mods weren't needed at all, flash size was autodetected at bootup. Maybe you can think about implementing such generic autodetection mechanism for ath79 target instead, so there would be no need to support modded routers explicitly, so standard images could be used on modded routers too. I think that quite many users could benefit from this. Some maintainers talked about this problem in a past thread but I can't find it now. Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Pozdrawiam, Lech Perczak lech.perc...@gmail.com Mobile: +48 694 309 185 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Has OpenWrt suport for Powerline devices
W dniu 2019-08-10 o 16:30, Enrico Mioso pisze: Hello! I guess this is in a case-by-case basis - I have a TP-Link RE450 which is supported. I know there are also Wi-Fi-only devices, but don't think OpenWRt supports any of them. I guess this happens also due to the amount of flash and RAM memory those devices have. And - if you're going for the RE450, keep in mind it's u-boot doesn't seem to have any recovery method, so soldering an UART right away maybe a good option. Enrico ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel RE450 is Wifi-only. There is actually one supported: https://openwrt.org/toh/hwdata/tp-link/tp-link_tl-wpa8630 -- Pozdrawiam, Lech Perczak ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k memory leak on 19.07 branch and mikrotik RB952Ui-5ac2nD?
W dniu 2019-12-06 o 18:44, Joe Ayers pisze: Possibly the same symptoms don't exist on 128MB RAM devices. Like there is some if condition, which is doing some nasty things on 64M devices? I admit, that I don't have ath10k-ct source code under my pillow, but it doesn't make much sense to me. Comparable results between above and my 64MB device. However, if the sleep time is extended the consumption is more Ok, I'll let it run overnight with 120s sleep in between. I suspect this is not the intended behavior. No its not and it's even strange, that I'm not seeing it here if it should happen in the "default setup". Maybe its because: 1. You're using custom image (I'm using official prebuilt images) 2. You're not providing all the steps needed to reproduce the issue 3. I've way different hardware Every detail could make huge difference. -- ynezz On the device I am testing, it is both (2GHz) ath9k and (5GHz) ath10k. These look to be related patches to this issue: 960-0010-ath10k-limit-htt-rx-ring-size.patch 960-0011-ath10k-limit-pci-buffer-size.patch In the v19.07.0-rc2 build for the rb-nor-flash-16M-ac ar71xx image, these patches are applied to backports-4.19.85-1, but don't seem to be applied to ath10k-ct-2019-09-09-5e8cd86f.Should ath10k-ct have these and other patches?The device's installed packages do include ath10k-ct (from downloads.openwrt.org installed image). Joe AE6XE ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel . I can only add that I got the same behaviour with my TL-WR902AC just ported to ath79 on master (based on f19e471f3206d0b5885490e52972085d2da2a10b). In about 20 minutes system was unusable - I couldn't fully copy a 4MB sysupgrade image to /tmp. Branch used to build the image is here: https://github.com/Leo-PL/openwrt/commits/tl-wr902ac-v1_ath79 I can offer my help with testing the fixes, as it seems to me that it's not the first time I observe this issue, only now I got a device affected by it. With kind regards, Lech ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] R: Next maintenance releases
W dniu 2020-02-21 o 16:48, ansuels...@gmail.com pisze: >> Hi, >> >> I'd like to release 19.07.2 and 18.06.8 sometime between Sun 23rd and >> Tue 25th. If you have pending important fixes you like to see backported >> to the respective branches please do so ASAP or mention the commits in a >> reply to this mail. >> >> >> Regards, >> Jo >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > https://github.com/openwrt/openwrt/pull/2769 > Can this be merged? It fix important performance problem for ipq806x > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel I'd very much like to see this merged too: https://github.com/openwrt/openwrt/pull/2683 As I stated in PR: Tested-By: Lech Perczak -- With kind regards, Lech Perczak ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: tp-link: use ath10k-ct-smallbuffers for 64 MiB devices
Hi, Answers inline. W dniu 2019-12-24 o 20:47, Paul Fertser pisze: Hi Lech, Any reason you omit the list from Cc? This way nobody but me is going to comment on your message and I'm obviously biased :) Just forgot to use "reply to all". On Tue, Dec 24, 2019 at 08:26:09PM +0100, Lech Perczak wrote: I think that TL-WR902AC v1 should be included as well, as it is 64M device and I also experienced issues with ath10k-ct on it while porting. Device like that requires the tweak, no doubt. But I'm not feeling like going through the whole ar71xx target since it's deprecated anyway and whoever cares should port the needed boards to ath79 AFAIK. So if one stays on ar71xx for the upcoming release the workaround would be to manually run opkg remove kmod-ath10k-ct && opkg install kmod-ath10k-ct-smallbuffers That said, I have no idea if patches to ar71xx are accepted or not. This device was just ported to ath79 recently. I think grepping by device trees could be used to determine devices which need the changes. -- With kind regards, Lech ___ 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
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] comgt: Move to community packages repo
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 v3] ath79: add support for onion omega
kmod-usb-chipidea2 + SUPPORTED_DEVICES += onion-omega + KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | uImage lzma + IMAGE_SIZE := 16192k + TPLINK_HWID := 0x0471 +endef +TARGET_DEVICES += onion_omega + define Device/openmesh_common_64k DEVICE_VENDOR := OpenMesh DEVICE_PACKAGES := uboot-envtools -- 2.32.0 _______ 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Pozdrawiam, Lech Perczak lech.perc...@gmail.com Mobile: +48 694 309 185 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for onion omega
W dniu 2021-08-14 o 17:43, Tomasz Maciej Nowak pisze:
W dniu 14.08.2021 o 16:37, Jan-Niklas Burfeind pisze:
Hey there; answer is inline too.
Thanks for picking this up!
On 8/14/21 3:54 PM, Tomasz Maciej Nowak wrote:
Hi,
one comment inline.
W dniu 14.08.2021 o 14:33, Jan-Niklas Burfeind pisze:
[...]
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uboot: partition@0 {
+ label = "u-boot";
+ reg = <0x00 0x02>;
Is this really the size of the U-Boot? According to the sources of
U-Boot [1] the max size of bootloader is 64KiB. If the sources don't
lie, what's between 0x1-0x2? Is that some hardcoded data or
U-Boot environment? If it's the environment, You can't use static
address of the MAC in nvmem-cells, because it can move around if
someone modified the environment. For that You'll need to extract it in
userspace.
1.
https://github.com/OnionIoT/uboot/blob/684829a3a89eabca4b573530e89d60faed277dee/Makefile#L31
uboot knows it is 64KiB, printenv yields uboot_size=0x1
That should be reflected in partitions list and the space between
0x1-0x2 partition name should reflect what's inside. If the
vendor firmware had a name for this space, use that.
It further knows, firmware starts not before 128Kib:
firmware_addr=0x9F02
these are the last lines of mtd0:
000f8d0
*
001fc00 40a3 6bc1 10b2
001fc10
*
001fd00 4f4d 4547 41ff
001fd10
*
002
The six bytes at 001fc00 are the macaddress.
The six bytes at 001fd00 spell OMEGA.
Is this the only data in 0x1-0x2? What's in 0x1-0x11000?
+ read-only;
+ compatible = "nvmem-cells";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ macaddr_uboot_1fc00: macaddr@1fc00 {
+ reg = <0x1fc00 0x6>;
+ };
+ };
+
+ partition@2 {
+ compatible = "tplink,firmware";
+ label = "firmware";
+ reg = <0x02 0xfd>;
+ };
+
+ art: partition@ff {
+ label = "art";
+ reg = <0xff 0x01>;
+ read-only;
+ };
The whole ordeal looks very much like typical pre-safeloader TP-link
flash layout, so I expect no writable U-boot environment there, at least
for stock U-boot.
Of course, it would be best to check if it's possible to write it using
serial console, on actual device.
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ mtd-cal-data = < 0x1000>;
+ nvmem-cells = <_uboot_1fc00>;
+ nvmem-cell-names = "mac-address";
+};
[ snip ]
Regards
Kind regards,
Lech
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for onion omega
W dniu 2021-08-15 o 10:30, Jan-Niklas Burfeind pisze:
On 8/14/21 7:08 PM, Lech Perczak wrote:
[...]
The six bytes at 001fd00 spell OMEGA.
Is this the only data in 0x1-0x2? What's in 0x1-0x11000?
+ read-only;
+ compatible = "nvmem-cells";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ macaddr_uboot_1fc00: macaddr@1fc00 {
+ reg = <0x1fc00 0x6>;
+ };
+ };
+
+ partition@2 {
+ compatible = "tplink,firmware";
+ label = "firmware";
+ reg = <0x02 0xfd>;
+ };
+
+ art: partition@ff {
+ label = "art";
+ reg = <0xff 0x01>;
+ read-only;
+ };
The whole ordeal looks very much like typical pre-safeloader TP-link
flash layout, so I expect no writable U-boot environment there, at least
for stock U-boot.
Of course, it would be best to check if it's possible to write it using
serial console, on actual device.
I just tried to copy part of the string "OMEGA" from its current position.
md 0x9F01FD00
9F01FD00: 4F4D4547[...]
cp 0x9F01FD00 0x9F01FE00 3
md 0x9F01FE00
9F01FE00: [...]
Reading the partition works fine; writing not so much; at least not
within uboot.
I rather meant checking if it is possible to 'saveenv' from within stock
U-boot, rebooting and seeing if changes to the environment change stay
there.
Given, that the typical SPI-NOR sector size on this target is 64k, it's
very unlikely that there is writable environment there, as the MAC part
doesn't follow its format, and U-boot would need to use 4k page erase
for that,
as does pepe2k's u-boot_mod, but OpenWrt currently cannot reliably
support writing such environment.
[...]
___
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] ath79: add support for onion omega
W dniu 2021-08-15 o 13:03, open...@aiyionpri.me pisze: On 8/15/21 11:39 AM, Lech Perczak wrote: [...] I rather meant checking if it is possible to 'saveenv' from within stock U-boot, rebooting and seeing if changes to the environment change stay there. Given, that the typical SPI-NOR sector size on this target is 64k, it's very unlikely that there is writable environment there, as the MAC part doesn't follow its format, and U-boot would need to use 4k page erase for that, as does pepe2k's u-boot_mod, but OpenWrt currently cannot reliably support writing such environment. The command "saveenv" is not available in the stock uboot. So, we've got the answer - the flash layout in device tree is then correct. ___ 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] ath79: use lzma-loader for ZyXEL NBG6716
Since gzip-compressed kernel image stopped fitting on 4MB kernel
partition on the device, use lzma-loader wrapping LZMA-compressed
kernel. This yields bootable device once again, and saves a very
substantial amount of space, the kernel size decreasing from about 4.4MB
to about 2.5MB for 5.10 kernel. This avoids changing of the flash layout
for the device.
While at that, reactivate the build for the device.
Fixes: 5d8ea6d34f9 ("ath79: Deactivate ZyXEL NBG6716 by default")
Cc: André Valentin
Cc: Hauke Mehrtens
Tested-by: Alex Henrie
Signed-off-by: Lech Perczak
---
target/linux/ath79/image/nand.mk | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index 91fd7ec301..d31aba1abc 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -301,8 +301,9 @@ define Device/zyxel_nbg6716
KERNEL_SIZE := 4096k
BLOCKSIZE := 128k
PAGESIZE := 2048
- KERNEL := kernel-bin | append-dtb | uImage none | zyxel-buildkerneljffs | \
- check-size 4096k
+ LOADER_TYPE := bin
+ KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | uImage none | \
+ zyxel-buildkerneljffs | check-size 4096k
IMAGES := sysupgrade.tar sysupgrade-4M-Kernel.bin factory.bin
IMAGE/sysupgrade.tar/squashfs := append-rootfs | pad-to (BLOCKSIZE) | \
sysupgrade-tar rootfs=@ | append-metadata
@@ -311,6 +312,5 @@ define Device/zyxel_nbg6716
IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | append-ubi |
\
zyxel-factory
UBINIZE_OPTS := -E 5
- DEFAULT := n
endef
TARGET_DEVICES += zyxel_nbg6716
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Help unbricking AC750
Hi! W dniu 2022-06-18 o 17:14, Luca Bertoncello pisze: Hi! I have an TP-Link AC750 Archer C2. It worked with TP-Link Firmware and I wanted to install OpenWRT. Unfortunately, something went really wrong and now the devices seems to be bricked... Only Power-LED is on, no other activity. Has someone an idea how can I try to recover it? If that's C2v1 and you attempted flashing it over TFTP without appending U-boot to the factory image first, then you might need to desolder the SPI flash chip and use an external programmer, for example one based on CH341 and reflash it externally with "flashrom" or similar tool. I recovered one unit that way, and found OpenWrt uImage where U-boot should have been. Thanks a lot Luca Bertoncello (lucab...@lucabert.de) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Pozdrawiam, Lech Perczak ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ZTE MF286R modem support
Hello, Recently my PR #9670 [1] which includes fixes needed to support built-in modem of ZTE MF286R router was merged to master. The (incomplete) support for MF286R landed together with MF286A before branching off 22.03 release. I'd be grateful if fixes from [1] could be cherry-picked to 22.03, for MF286R to have full support in that release. Required commits are c99013e, b2940bb, ed79578 and e02fb42, a67629b is optional, but would be beneficial if another variant of the modem is found, with different interface configuration - that may require to override the autodetection results. Also, skipping that patch can yield merge conflicts. [1] https://github.com/openwrt/openwrt/pull/9670 -- Pozdrawiam/Kind regards, Lech Perczak ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ZTE MF286R modem support
W dniu 2022-04-23 o 22:32, Hauke Mehrtens pisze: On 4/16/22 22:26, Lech Perczak wrote: Hello, Recently my PR #9670 [1] which includes fixes needed to support built-in modem of ZTE MF286R router was merged to master. The (incomplete) support for MF286R landed together with MF286A before branching off 22.03 release. I'd be grateful if fixes from [1] could be cherry-picked to 22.03, for MF286R to have full support in that release. Required commits are c99013e, b2940bb, ed79578 and e02fb42, a67629b is optional, but would be beneficial if another variant of the modem is found, with different interface configuration - that may require to override the autodetection results. Also, skipping that patch can yield merge conflicts. [1] https://github.com/openwrt/openwrt/pull/9670 Hi, I ported the changes to OpenWrt 22.03 branch. I will also add the new change you posted some hours ago. Hauke Hi Hauke, Thanks for backporting these changes. I noticed that 8a1003c5986514d7a78f78b3ee94003837d82582 is still missing on 22.03 branch, so a kind reminder :-) Kind regards, Lech ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: When should gpio-restart be used/avoided?
W dniu 2022-08-14 o 21:15, Bjørn Mork pisze: Lech Perczak writes: W dniu 2022-08-14 o 18:40, Bjørn Mork pisze: Lech Perczak writes: I'll try your settings, on MF286D and on older MF286 as well. My setup is a bit more convoluted, since my build has patches to use split APN for IPv4v6 dual stack and I use DHCP. Are patches still required for dual-stack with uqmi? For generic ipv4v6 they are not, however my usecase is even more special. I use "internet" APN for v4 and "internetipv6" APN for v6, hence "split APN". Ah, right. That's unusual. My configuration is like this: config interface 'wan' option device '/dev/cdc-wdm0' option proto 'qmi' option apn 'internet' option v6apn 'internetipv6' option profile '1' option v6profile '5' option autoconnect '1' option dhcpv6 '1' option auth 'none' option pdptype 'ipv4-and-ipv6' Very strange. I would not have guessed that this was possible. I've always assumed that the QMI dual stack model depended on two sessions to the same APN, and a single IPV4V6 context to the network. Learning something every day. And forgetting two things. Do you think it's worth upstreaming? Users of Orange Poland would benefit from that, not sure how in other parts of the world. If it's useful to you, then I'm sure it will be useful to someone else as well. Please do upstream it. Assuming that it's not too ugly :-) Ok, I'll open a RFC PR soon. It seems doable with ModemManager as well, by creating two separate bearers (and that's done under the hood for single APN as well), but I haven't tried so far, uqmi works fine for me, albeit it lacks connection drop monitoring. I'm not sure if MM can do that with one network interface on the host side. Two bearers need two interfaces. But if we have QMAP support then there shouldn't be any problem having one IPv4 and one IPv6 interface connected to separate APNs. That warning isn't there when the "power button blocker" is disabled. This part was expected. Just checked on my unit, and this still did reboot the modem. How do you check for modem reboot? I checked for modem LEDs to turn off after executing reboot (with GPIO421 set high) So it seems, that the modem reset is still possible by toggling this GPIO from userspace, while holding power button blocker, even without rebooting whole device. That sounds more useful than having this wired up as a router reboot device. Yes, but fiddling with two GPIOs to do just that is finicky. Let's see what Paweł thinks on that, I'll try digging into MF286 a bit more to get the modem to restart without rebooting device, for newer ones we can redefine this to be two separate GPIO switches. This won't be possible on MF286 though, it lacks the power button blocker line in hardware - it's physically present only from MF286A onwards, It would be certainly nice, if the behaviour is consistent across the whole line of devices. Yes, dream on. The only consistent part of a ZTE device is the model number :-) But in OpenWrt we can still at least try to achieve that. Based on MF286 series I tend to disagree, they are very similar to each other. Router part of MF286A and MF286R is the very same device. Too bad, that all of them have just "MF286" written on the boilerplate. Bjørn -- Pozdrawiam, Lech Perczak ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: When should gpio-restart be used/avoided?
W dniu 2022-08-14 o 18:40, Bjørn Mork pisze: Lech Perczak writes: I'll try your settings, on MF286D and on older MF286 as well. My setup is a bit more convoluted, since my build has patches to use split APN for IPv4v6 dual stack and I use DHCP. Are patches still required for dual-stack with uqmi? For generic ipv4v6 they are not, however my usecase is even more special. I use "internet" APN for v4 and "internetipv6" APN for v6, hence "split APN". My configuration is like this: config interface 'wan' option device '/dev/cdc-wdm0' option proto 'qmi' option apn 'internet' option v6apn 'internetipv6' option profile '1' option v6profile '5' option autoconnect '1' option dhcpv6 '1' option auth 'none' option pdptype 'ipv4-and-ipv6' Do you think it's worth upstreaming? Users of Orange Poland would benefit from that, not sure how in other parts of the world. It seems doable with ModemManager as well, by creating two separate bearers (and that's done under the hood for single APN as well), but I haven't tried so far, uqmi works fine for me, albeit it lacks connection drop monitoring. FWIW, this just works with ModemManager. Tested this interface config now: config interface 'wan' option device '/sys/devices/platform/soc/8af8800.usb3/8a0.dwc3/xhci-hcd.0.auto/usb2/2-1' option proto 'modemmanager' option apn 'telenor.smart' option iptype 'ipv4v6' and got: root@mf286d:/# ifconfig wwan0 wwan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.201.240.26 P-t-P:10.201.240.26 Mask:255.255.255.252 inet6 addr: 2a02:2121:285:6c98:ed02:dc3b:8d92:ba9b/128 Scope:Global inet6 addr: fe80::6481:c58c:9848:2b5/64 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1540 Metric:1 RX packets:13 errors:0 dropped:0 overruns:0 frame:0 TX packets:20 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1415 (1.3 KiB) TX bytes:1669 (1.6 KiB) root@mf286d:/# mmcli -b 1 General| path: /org/freedesktop/ModemManager1/Bearer/1 | type: default Status | connected: yes | suspended: no |multiplexed: no | interface: wwan0 | ip timeout: 20 Properties |apn: telenor.smart |roaming: allowed |ip type: ipv4v6 IPv4 configuration | method: static |address: 10.201.240.26 | prefix: 30 |gateway: 10.201.240.25 |dns: 193.213.112.4, 130.67.15.198 |mtu: 1500 IPv6 configuration | method: static |address: 2a02:2121:285:6c98:ed02:dc3b:8d92:ba9b | prefix: 64 |gateway: 2a02:2121:285:6c98:f4b2:80d1:eba3:9279 |dns: 2001:4600:4:fff::52, 2001:4600:4:1fff::52 |mtu: 1540 Statistics | duration: 30 | bytes rx: 1204 | bytes tx: 722 | attempts: 1 | total-duration: 30 | total-bytes rx: 1204 | total-bytes tx: 722 root@mf286d:/# ip route default via 10.201.240.25 dev wwan0 src 10.201.240.26 10.201.240.24/30 dev wwan0 scope link src 10.201.240.26 192.168.99.0/24 dev lan4.203 scope link src 192.168.99.56 root@mf286d:/# ip -6 route default from 2a02:2121:285:6c98::/64 via 2a02:2121:285:6c98:f4b2:80d1:eba3:9279 dev wwan0 metric 1024 2a02:2121:285:6c98:ed02:dc3b:8d92:ba9b dev wwan0 metric 256 2a02:2121:285:6c98:f4b2:80d1:eba3:9279 dev wwan0 metric 1024 2a02:2121:285:6c98::/64 dev lan4.203 metric 1024 unreachable 2a02:2121:285:6c98::/64 dev lo metric 2147483647 fd63:fcae:6f0::/64 dev lan4.203 metric 1024 unreachable fd63:fcae:6f0::/48 dev lo metric 2147483647 fe80::/64 dev eth0 metric 256 fe80::/64 dev lan4 metric 256 fe80::/64 dev lan4.203 metric 256 fe80::/64 dev br-lan metric 256 fe80::/64 dev br-iot metric 256 fe80::/64 dev wwan0 metric 256 anycast 2a02:2121:285:6c98:: dev lan4.203 metric 0 anycast fd63:fcae:6f0:: dev lan4.203 metric 0 anycast fe80:: dev eth0 metric 0 anycast fe80:: dev br-lan metric 0 anycast fe80:: dev br-iot metric 0 a
Re: When should gpio-restart be used/avoided?
W dniu 2022-08-14 o 13:35, Bjørn Mork pisze: Bjørn Mork writes: FWIW, I did a simple test now using ModemManager on the MF286D. There is no issue with the modem after reboot, even if the gpio-restart device is disabled. This is my MM config: config interface 'wan' option device '/sys/devices/platform/soc/8af8800.usb3/8a0.dwc3/xhci-hcd.0.auto/usb2/2-1' option proto 'modemmanager' option apn 'internet.public' I disabled the gpio-restart by doing echo gpio-restart >/sys/bus/platform/drivers/restart-gpio/unbind Rebooting brings up the modem connection comes up just fine. I can't see anything wrong with it. In theory all services in a QMI modem should be reset to defaults and all state cleared by simply sending a QMI_CTL SYNC request to the modem. And I see that we do send this during setup in package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh A bit late maybe, after PIN and framing config, but that's probably fine. At least I don't expect the SIM state to be reset by SYNC. Don't know about 802.3 framing, but I'd have to dig out an old modem to find out. I guess it will work since the framing is a persistent setting IIRC. I'll do a test with uqmi too. Now tested with uqmi. ModemManager disabled by removing the /etc/rc.d symlink. gpio-restart disabled as before. Otherwise default config except for this uqmi network interface: config interface 'wan' option device '/dev/cdc-wdm0' option proto 'qmi' option apn 'internet.public' option dhcp '0' option autoconnect '0' I don't see any issues after rebooting multiple times. The modem is re-initialised and the connection is brought up on boot. Note that I haven't tested with PIN verification enabled. And I am disabling dhcp and autoconnect since these features depends on some buggy vendor firmware implementation. In my experience, using modem firmware for session management is about as good idea as running vendor firmware on your router... I guess these choices might affect the test result though. I'll try your settings, on MF286D and on older MF286 as well. My setup is a bit more convoluted, since my build has patches to use split APN for IPv4v6 dual stack and I use DHCP. But AFAICS the gpio-restart is not required for proper modem reset. The modem works just fine without it. Please check what happens if you set the "power button blocker" GPIO switch high instead of default low. It will block the rear power switch, and should allow modem restart without forcing power-down of whole board during reboot, IIRC. Bjørn -- Pozdrawiam, Lech Perczak ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: When should gpio-restart be used/avoided?
Hi,
Yes, I can confirm, this is used to reset the modem on rebooting the device.
At least when used in conjunction with uqmi, the modem would misbehave
otherwise,
and connection attempts would fail after rebooting the device. The same
is true for its ath79-based predecessors.
I think this issue deserves investigation on its own.
Issue with this pin is that if we'd just like to reset the modem, it's
not possible without resetting the device,
as this is basically a "suicide switch" rather than just USB power cutoff.
Kind regards,
Lech
W dniu 2022-08-13 o 22:48, Robert Marko pisze:
I had just that question today when reviewing a similar ZTE modem.
It appears that its to reset the modem as well:
https://github.com/openwrt/openwrt/pull/10418/files#r945125301
Regards,
Robert
On Sat, 13 Aug 2022 at 19:13, Bjørn Mork wrote:
I just got myself a ZTE286D. But after installing OpenWrt I had an
unexpected problem on reboot. The Openwrt DTS includes a gpio-restart
device:
gpio-restart {
compatible = "gpio-restart";
gpios = < 8 GPIO_ACTIVE_HIGH>;
};
The gpio-restart driver is therefore used to reboot the system due to
default priorities.
I have two concerns about this:
1) it's different from OEM, and
2) it cuts power to the 3.3V VCC console line on reboot
A quick test indicates that reboot works just fine without using
gpio-restart in OpenWrt too. And a similar node seems to be rare in
this target. AFAICS, this is the only device having one.
So I wonder if we could/should remove that gpio-restart device. What do
you think?
The reason I ask is because the VCC toggling causes unnecessary problems
for me. I realize that I have an unusual setup, but I have connected a
bluetooth module to the console port. Toggling the console VCC on
reboot makes it hard/imposible to enter the bootloader, or to capture
the whole boot log. It takes some time before the console server
notices that the bluetooth device disappeared and tries to reconnect. I
believe this is an unwanted side effect. And it wasn't like that with
OEM.
This is of course only a minor problem. In addition to just pathcing the
DTS myself, I could also put something like
test -w /sys/bus/platform/drivers/restart-gpio/unbind && echo gpio-restart
>/sys/bus/platform/drivers/restart-gpio/unbind
into /etc/rc.local. That's a perfectly fine workaround. But I wanted
to ask becasuse of the different behaviour in OEM.
Bjørn
___
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
--
Pozdrawiam,
Lech Perczak
lech.perc...@gmail.com
Mobile: +48 694 309 185
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/4] imx: copy patches 5.15 to 6.1
W dniu 2024-01-08 o 22:25, Tim Harvey pisze:
copy 5.15 patches excluding some that need manual rework touching
non-upstream led props.
Signed-off-by: Tim Harvey
---
.../linux/imx/patches-6.1/100-bootargs.patch | 11 +
...-pico-pi.dts-add-default-stdout-path.patch | 23 +++
2 files changed, 34 insertions(+)
create mode 100644 target/linux/imx/patches-6.1/100-bootargs.patch
create mode 100644
target/linux/imx/patches-6.1/311-ARM-imx7d-pico-pi.dts-add-default-stdout-path.patch
diff --git a/target/linux/imx/patches-6.1/100-bootargs.patch
b/target/linux/imx/patches-6.1/100-bootargs.patch
new file mode 100644
index ..cf63a3bdb1a3
--- /dev/null
+++ b/target/linux/imx/patches-6.1/100-bootargs.patch
@@ -0,0 +1,11 @@
+--- a/arch/arm/boot/dts/imx6dl-wandboard.dts
b/arch/arm/boot/dts/imx6dl-wandboard.dts
+@@ -16,4 +16,8 @@
+ device_type = "memory";
+ reg = <0x1000 0x4000>;
+ };
++
++ chosen {
++ bootargs = "console=ttymxc0,115200";
++ };
+ };
diff --git
a/target/linux/imx/patches-6.1/311-ARM-imx7d-pico-pi.dts-add-default-stdout-path.patch
b/target/linux/imx/patches-6.1/311-ARM-imx7d-pico-pi.dts-add-default-stdout-path.patch
new file mode 100644
index ..5248e8c74c1a
--- /dev/null
+++
b/target/linux/imx/patches-6.1/311-ARM-imx7d-pico-pi.dts-add-default-stdout-path.patch
@@ -0,0 +1,23 @@
+From 6e8e5ccfbee7a531b035ffce3f95f3901946fa9d Mon Sep 17 00:00:00 2001
+From: Robert Nelson
+Date: Wed, 9 Jan 2019 14:33:24 -0600
+Subject: [PATCH] ARM: imx7d-pico-pi.dts: add default stdout-path
+
+Signed-off-by: Robert Nelson
+---
+ arch/arm/boot/dts/imx7d-pico-pi.dts | 4
+ 1 file changed, 4 insertions(+)
+
+--- a/arch/arm/boot/dts/imx7d-pico-pi.dts
b/arch/arm/boot/dts/imx7d-pico-pi.dts
+@@ -16,6 +16,10 @@
+ label-mac-device =
+ };
+
++ chosen {
++ stdout-path = "serial4:115200n8";
++ };
++
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
Hi Tim,
In an effort to get camera working on Pico Pi i.MX7 board, I rebased the
remaining patches and put that on Github:
https://github.com/Leo-PL/openwrt/commits/pico-pi-imx7-camera-6.1/
Feel free to integrate them.
--
Pozdrawiam,
Lech Perczak
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] kernel: usb: Autoprobe g_serial
Hi Linus, W dniu 2023-11-11 o 23:02, Linus Walleij pisze: For devices using USB gadget serial we need to probe the modules usb_f_acm and g_serial in order, then the available UDC (USB device controller) interface will be hooked up to a serial port as /dev/ttyGS0. (On the host side this appears as /dev/ttyACM0 when plugging in the USB cable.) I don't quite understand why this wasn't done before for the module explicitly called kmod-usb-serial. Before this patch we have to enter a console and type modprobe g_serial To get a serial console on /dev/ttyGS0, after this it is automatic. Since you might only have the serial console, it is a bit catch 22 to have to use a serial console to activate the serial console. Signed-off-by: Linus Walleij --- package/kernel/linux/modules/usb.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/kernel/linux/modules/usb.mk b/package/kernel/linux/modules/usb.mk index 0a5f5a8993c9..f54dc4380737 100644 --- a/package/kernel/linux/modules/usb.mk +++ b/package/kernel/linux/modules/usb.mk @@ -207,7 +207,7 @@ define KernelPackage/usb-gadget-serial $(LINUX_DIR)/drivers/usb/gadget/function/usb_f_obex.ko \ $(LINUX_DIR)/drivers/usb/gadget/function/usb_f_serial.ko \ $(LINUX_DIR)/drivers/usb/gadget/legacy/g_serial.ko - AUTOLOAD:=$(call AutoLoad,52,usb_f_acm) + AUTOLOAD:=$(call AutoLoad,52,usb_f_acm g_serial) $(call AddDepends/usb) endef I think I know the reason why it isn't the case. kmod-usb-gadget-cdc-composite which pulls both kmod-usb-gadget-serial and kmod-usb-gadget-eth packages, and including autoprobingf g_serial within this would clash with that. I think the gadget configuration itself (apart from implementation) could be packaged separately and included as device packages, pulling needed dependencies. And something like that just appeared on Github: https://github.com/openwrt/openwrt/pull/14005/ -- Pozdrawiam/Kind regards, Lech ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
