Re: [OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity
> > 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? > > thanks for the help with testing, something like this could work: > > cd openwrt.git > git remote add github-ynezz https://github.com/ynezz/openwrt.git > git fetch github-ynezz > git checkout -b nanostation-m-xw github-ynezz/wip/nanostation-m-xw > echo -e > "CONFIG_TARGET_ath79=y\nCONFIG_TARGET_ath79_generic=y\nCONFIG_TARGET_ath79_generic_DEVICE_ubnt_nano-m-xw=y" > > .config > make defconfig world -j$(nproc) > > > 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 > > BTW, nice project! FYI, my Bullet M2HP running airOS v6.1.7 doesn't switch to > TFTP server mode even after pressing reset for 1 minute. What airOS version do > you've on you Nanostation units that it works for you? > > This is my U-Boot 1.1.4-s1039 (May 24 2017 - 15:58:18) > > > 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. > > 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 root@AE6XE-NSM5XW-QTH:~# cat /dev/mtd0 | grep U-Boot U-Boot 1.1.4-s1039 (May 24 2017 - 15:58:18) root@AE6XE-NSM5XW-QTH:~# cat /tmp/sysinfo/model Ubiquiti Nanostation M XW I also use a dumb switch between ubnt device and laptop. If the ubnt doesn't have the port link up at the proper timing, then it doesn't respond. If you have a device with various tftp firmware uploads and bootloader versions, you may need to do serial console recovery to force the uboot version to be updated. Then once there is a version of AirOS loaded, load another version of AirOS from the UI, this is the only way I've found to get a device back to 'normal'. Following the various serial recovery procedures to force update of bootloader and set partition map to default, don't always work. I applied the equivalent change to your build: https://github.com/aredn/aredn_ar71xx/blob/develop/patches/002-firmware-check-fix.patch super-set of detail if interested, devices we have people in our community we're supporting: https://github.com/aredn/aredn_ar71xx/blob/develop/README.md Happy to help out to make sure these devices are migrated to ath97, otherwise we might end up implementing our self at some point. We're focused mostly on tower or roof mount type devices. Here in Southern CA, we have a network now passing over 400 nodes over 250 miles end to end outside unlicensed channels in ham radio only space, e.g. up to channel 184 in 5GHz. 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. What other data would be helpful? Joe root@OpenWrt:/# dmesg [0.00] Linux version 4.14.81 (aredn@7039ee8a4bea) (gcc version 7.3.0 (Op enWrt GCC 7.3.0 r8470-bc95553)) #0 Sat Nov 17 23:55:20 2018 [0.00] bootconsole [early0] enabled [0.00] CPU0 revision is: 0001974c (MIPS 74Kc) [0.00] MIPS: machine is Ubiquiti Nano-M (XW) [0.00] SoC: Atheros AR9342 rev 2 [0.00] Determined physical RAM map: [0.00] memory: 0400 @ (usable) [0.00] Initrd not found or empty - disabling initrd [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [0.00] Zone ranges: [0.00] Normal [mem 0x-0x03ff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x03ff] [0.00] Initmem setup node 0 [mem 0x-0x03ff] [0.00] On node 0 totalpages: 16384 [0.00] free_area_init_node: node 0, pgdat 805094a0, node_mem_map 8100752 0 [0.00] Normal zone: 128 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 16384 pages, LIFO batch:3 [0.00] random: get_random_bytes called from start_kernel+0x8c/0x474 with crng_init=0 [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 16256 [0.00] Kernel command line: console=ttyS0,115200 rootfstype=squashfs,jff s2 [0.00] PID hash table entries: 256 (order: -2, 1024 bytes)
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] [PATCH] ath79: Add support for Ubiquity
Joe Ayers [2018-11-17 06:11:11]: Hi Joe, > 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? thanks for the help with testing, something like this could work: cd openwrt.git git remote add github-ynezz https://github.com/ynezz/openwrt.git git fetch github-ynezz git checkout -b nanostation-m-xw github-ynezz/wip/nanostation-m-xw echo -e "CONFIG_TARGET_ath79=y\nCONFIG_TARGET_ath79_generic=y\nCONFIG_TARGET_ath79_generic_DEVICE_ubnt_nano-m-xw=y" > .config make defconfig world -j$(nproc) > 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 BTW, nice project! FYI, my Bullet M2HP running airOS v6.1.7 doesn't switch to TFTP server mode even after pressing reset for 1 minute. What airOS version do you've on you Nanostation units that it works for you? This is my U-Boot 1.1.4-s1039 (May 24 2017 - 15:58:18) > 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. Hm, I'm really wondering what version of airOS do you've on your devices, that the TFTP recovery method works for you. -- ynezz ___ 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
> 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. Rockets don't have USB ports on the vendor specification sheet (I don't recall a USB on any ubnt XW model). There's an early Rocket XM rev that had USB, but later XM models that do not. > >>> 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. The NS M5 XW is the odd-ball and has an external AR8236 off GMAC0 on the AR9344. If patch2 was implemented accordingly, I'd go give it a try. Here's a consolidated list that may be helpful, others are AR803x: PBE-M2-400 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:04 [uid=004dd072, driver=Atheros 8035 ethernet] PBE-M5-300 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:01 [uid=004dd023, driver=Generic PHY] PBE-M5-400 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:04 [uid=004dd072, driver=Atheros 8035 ethernet] PBE-M5-620 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:04 [uid=004dd072, driver=Atheros 8035 ethernet] Rocket M5 XW: ag71xx ag71xx.0: connected to PHY atag71xx-mdio.0:04 [uid=004dd072, driver=Atheros 8035 ethernet] NSM5-loco-XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:01 [uid=004dd023, driver=Generic PHY] Airgrid M5 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:01 [uid=004dd023, driver=Generic PHY] NBM5/16 XW: ag71xx ag71xx.0: connected to PHY at g71xx-mdio.0:01 [uid=004dd023, driver=Generic PHY] NBM5/19 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:01 [uid=004dd023, driver=Generic PHY] NS M5 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd043, driver=Atheros AR8216/AR8236/AR8316 ___ 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
> >> 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? > >> 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. ___ 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
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 > > > 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 -- ynezz ___ 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
Lech Perczak [2018-11-17 10:28:20]: > 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. I was using the same downgrade trick on other older UBNT devices as well, and I hoped, that it would still work for this new device as well, but it didn't. I simply couldn't find airOS v5 firmware image for XW, and flashing airOS v5 image for XM failed for me on XW: XW.v6.1.7# fwupdate.real -m /tmp/XM.v5.6.15.30572.170328.1107.bin -d ... Current: XW.ar934x.v6.1.7.32555.180523.1754 New ver: XM.ar7240.v5.6.15.30572.170328.1107 Versions: New(329231) 5.6.15, Required(393220) 6.0.4 Invalid version 'XM.ar7240.v5.6.15.30572.170328.1107' So for me it was clear, that it's different platform ar934x versus ar7240 and that minimum version allowed for XW is 6.0.4. As of today, for XW you can download just two firmware versions 6.1.7 and 6.1.8. My device came from factory flashed with 6.1.5. Wherever I looked it was all just about TFTP and initramfs methods, which needs soldering and possibly can cause warranty problems. -- ynezz ___ 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 TP-Link Archer A7
Hello David, On 2018-11-17 09:33:07, David Bauer wrote: > Hello Karl, > > On 10.11.18 18:06, Karl-Felix Glatzer wrote: > > This patch adds support for TP-Link Archer A7 > > > > Specification: > > - SOC: QCA9563 > > - Flash: 16 MiB (SPI) > > - RAM: 128 MiB (DDR2) > > - Ethernet: 4x 1Gbps LAN + 1x 1Gbps WAN > > - Wireless: > > - 2.4GHz (bgn) SoC internal > > - 5GHz (ac) QCA988x > > - USB: 1x USB 2.0 port > > - Button: 1x power, 1x reset, 1x wps > > - LED: 10x LEDs > > - UART: holes in PCB > > - Vcc, GND, RX, TX from ethernet port side > > - 115200n8 > > > > Flash instruction using factory image: > > > > 1. Connect the computer to one of the LAN ports of the Archer A7 > > 2. Set the computer IP to 192.168.0.66 > > 3. Start a tftp server with the OpenWrt factory image in the tftp > >root directory renamed to ArcherC7v5_tp_recovery.bin > > 2. Connect power cable to Archer A7, press and hold the reset button > >and turn the router on > > 3. Keep the reset button pressed for ~5 seconds > > 4. Wait ~150 seconds to complete flashing > > Does it really only accept the firmware by TFTP and blocks installation > thru the TP-Link UI? Also the filename seems odd, although completely > possible TP-Link uses the C7 filename. > Yes the filename is correct. The device tries to download a file named ArcherC7v5_tp_recovery.bin through tftp even though the model is an ArcherA7 and it checks for ArcherA7 in the supported versions list of the firmware. I did try flashing an openwrt ar71xx ArcherC7v5 firmware image through the TP-Link UI and via tftp but that got rejected due to the wrong version string. I did not try flashing the current ath79 ArcherA7v5 firmware through the UI. I'll reflash my device to stock and see if it will accept this firmware. > > Signed-off-by: Karl-Felix Glatzer > > --- > > .../ath79/base-files/etc/board.d/01_leds | 7 + > > .../ath79/base-files/etc/board.d/02_network | 4 + > > .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 + > > .../ath79/dts/qca9563_tplink_archer-a7-v5.dts | 255 ++ > > target/linux/ath79/image/common-tp-link.mk| 9 + > > target/linux/ath79/image/generic-tp-link.mk | 16 ++ > > tools/firmware-utils/src/tplink-safeloader.c | 46 +++- > > 7 files changed, 337 insertions(+), 1 deletion(-) > > create mode 100644 target/linux/ath79/dts/qca9563_tplink_archer-a7-v5.dts > > > > 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 f04eb7f5c6..4ddf04ef84 100755 > > --- a/target/linux/ath79/base-files/etc/board.d/01_leds > > +++ b/target/linux/ath79/base-files/etc/board.d/01_leds > > @@ -57,6 +57,13 @@ tplink,tl-mr3020-v1|\ > > tplink,tl-mr3040-v2) > > ucidef_set_led_netdev "lan" "LAN" "tp-link:green:lan" "eth0" > > ;; > > +tplink,archer-a7-v5) > > + ucidef_set_led_switch "wan" "WAN" "tp-link:green:wan" "switch0" "0x02" > > + ucidef_set_led_switch "lan1" "LAN1" "tp-link:green:lan1" "switch0" > > "0x04" > > + ucidef_set_led_switch "lan2" "LAN2" "tp-link:green:lan2" "switch0" > > "0x08" > > + ucidef_set_led_switch "lan3" "LAN3" "tp-link:green:lan3" "switch0" > > "0x10" > > + ucidef_set_led_switch "lan4" "LAN4" "tp-link:green:lan4" "switch0" > > "0x20" > > + ;; > > tplink,tl-wr1043nd-v4) > > ucidef_set_led_switch "wan" "WAN" "tp-link:green:wan" "switch0" "0x20" > > ucidef_set_led_switch "lan1" "LAN1" "tp-link:green:lan1" "switch0" > > "0x10" > > 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 5f02c5769a..7c7c9e14e1 100755 > > --- a/target/linux/ath79/base-files/etc/board.d/02_network > > +++ b/target/linux/ath79/base-files/etc/board.d/02_network > > @@ -107,6 +107,10 @@ ath79_setup_interfaces() > > ucidef_add_switch "switch0" \ > > "0@eth0" "3:lan:1" "5:lan:2" "4:wan" > > ;; > > + tplink,archer-a7-v5) > > + ucidef_add_switch "switch0" \ > > + "0@eth0" "2:lan:1" "3:lan:2" "4:lan:3" "5:lan:4" "1:wan" > > + ;; > > tplink,archer-c7-v1|\ > > tplink,archer-c7-v2|\ > > tplink,tl-wdr4900-v2) > > diff --git > > a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata > > b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata > > index dfe2d3ef31..6001df07bb 100644 > > --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata > > +++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata > > @@ -100,6 +100,7 @@ case "$FIRMWARE" in > > ath10kcal_extract "ART" 20480 2116 > > ath10kcal_patch_mac $(macaddr_add $(cat > > /sys/class/net/eth0/address) +16) > > ;; > > + tplink,archer-a7-v5|\ > > tplink,archer-c7-v2) > > ath10kcal_extract "art" 20480 2116 > > ath10kcal_patch_mac $(macaddr_add $(cat > >
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 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 TP-Link Archer A7
Hello Karl,
On 10.11.18 18:06, Karl-Felix Glatzer wrote:
> This patch adds support for TP-Link Archer A7
>
> Specification:
> - SOC: QCA9563
> - Flash: 16 MiB (SPI)
> - RAM: 128 MiB (DDR2)
> - Ethernet: 4x 1Gbps LAN + 1x 1Gbps WAN
> - Wireless:
> - 2.4GHz (bgn) SoC internal
> - 5GHz (ac) QCA988x
> - USB: 1x USB 2.0 port
> - Button: 1x power, 1x reset, 1x wps
> - LED: 10x LEDs
> - UART: holes in PCB
> - Vcc, GND, RX, TX from ethernet port side
> - 115200n8
>
> Flash instruction using factory image:
>
> 1. Connect the computer to one of the LAN ports of the Archer A7
> 2. Set the computer IP to 192.168.0.66
> 3. Start a tftp server with the OpenWrt factory image in the tftp
>root directory renamed to ArcherC7v5_tp_recovery.bin
> 2. Connect power cable to Archer A7, press and hold the reset button
>and turn the router on
> 3. Keep the reset button pressed for ~5 seconds
> 4. Wait ~150 seconds to complete flashing
Does it really only accept the firmware by TFTP and blocks installation
thru the TP-Link UI? Also the filename seems odd, although completely
possible TP-Link uses the C7 filename.
> Signed-off-by: Karl-Felix Glatzer
> ---
> .../ath79/base-files/etc/board.d/01_leds | 7 +
> .../ath79/base-files/etc/board.d/02_network | 4 +
> .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
> .../ath79/dts/qca9563_tplink_archer-a7-v5.dts | 255 ++
> target/linux/ath79/image/common-tp-link.mk| 9 +
> target/linux/ath79/image/generic-tp-link.mk | 16 ++
> tools/firmware-utils/src/tplink-safeloader.c | 46 +++-
> 7 files changed, 337 insertions(+), 1 deletion(-)
> create mode 100644 target/linux/ath79/dts/qca9563_tplink_archer-a7-v5.dts
>
> 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 f04eb7f5c6..4ddf04ef84 100755
> --- a/target/linux/ath79/base-files/etc/board.d/01_leds
> +++ b/target/linux/ath79/base-files/etc/board.d/01_leds
> @@ -57,6 +57,13 @@ tplink,tl-mr3020-v1|\
> tplink,tl-mr3040-v2)
> ucidef_set_led_netdev "lan" "LAN" "tp-link:green:lan" "eth0"
> ;;
> +tplink,archer-a7-v5)
> + ucidef_set_led_switch "wan" "WAN" "tp-link:green:wan" "switch0" "0x02"
> + ucidef_set_led_switch "lan1" "LAN1" "tp-link:green:lan1" "switch0"
> "0x04"
> + ucidef_set_led_switch "lan2" "LAN2" "tp-link:green:lan2" "switch0"
> "0x08"
> + ucidef_set_led_switch "lan3" "LAN3" "tp-link:green:lan3" "switch0"
> "0x10"
> + ucidef_set_led_switch "lan4" "LAN4" "tp-link:green:lan4" "switch0"
> "0x20"
> + ;;
> tplink,tl-wr1043nd-v4)
> ucidef_set_led_switch "wan" "WAN" "tp-link:green:wan" "switch0" "0x20"
> ucidef_set_led_switch "lan1" "LAN1" "tp-link:green:lan1" "switch0"
> "0x10"
> 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 5f02c5769a..7c7c9e14e1 100755
> --- a/target/linux/ath79/base-files/etc/board.d/02_network
> +++ b/target/linux/ath79/base-files/etc/board.d/02_network
> @@ -107,6 +107,10 @@ ath79_setup_interfaces()
> ucidef_add_switch "switch0" \
> "0@eth0" "3:lan:1" "5:lan:2" "4:wan"
> ;;
> + tplink,archer-a7-v5)
> + ucidef_add_switch "switch0" \
> + "0@eth0" "2:lan:1" "3:lan:2" "4:lan:3" "5:lan:4" "1:wan"
> + ;;
> tplink,archer-c7-v1|\
> tplink,archer-c7-v2|\
> tplink,tl-wdr4900-v2)
> diff --git
> a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> index dfe2d3ef31..6001df07bb 100644
> --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -100,6 +100,7 @@ case "$FIRMWARE" in
> ath10kcal_extract "ART" 20480 2116
> ath10kcal_patch_mac $(macaddr_add $(cat
> /sys/class/net/eth0/address) +16)
> ;;
> + tplink,archer-a7-v5|\
> tplink,archer-c7-v2)
> ath10kcal_extract "art" 20480 2116
> ath10kcal_patch_mac $(macaddr_add $(cat
> /sys/class/net/eth1/address) -1)
> diff --git a/target/linux/ath79/dts/qca9563_tplink_archer-a7-v5.dts
> b/target/linux/ath79/dts/qca9563_tplink_archer-a7-v5.dts
> new file mode 100644
> index 00..c62cb63b0d
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9563_tplink_archer-a7-v5.dts
> @@ -0,0 +1,255 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include
> +#include
> +
> +#include "qca956x.dtsi"
> +
> +/ {
> + compatible = "tplink,archer-a7-v5", "qca,qca9563";
> + model = "TP-Link Archer A7 Version 5";
This might e a bit of personal preference, but TP-Link never calls their
Devices "XXX Version Y", so i would go for "TP-Link Archer A7 v5", as
everywhere else it is referenced as such
