[OpenWrt-Devel] [PATCH] ramips: add support for Nexx WT1520

This patch adds support for Nexx WT1520 devices. Signed-off-by: Roger Pueyo Centelles open...@rogerpueyo.com --- diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds b/target/linux/ramips/base-files/etc/board.d/01_leds index 01e2363..1806ff2 100755 --- a/target/linux/ramips/base-files

Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for MERCURY MAC1200R

Hi, Thank you both for your comments. @郭传鈜: + ucidef_set_led_wlan wlan2g WLAN2G mercury:green:wlan2g phy1tpt I think the following line is incorrect: + ucidef_set_led_wlan wlan5g WLAN5G mercury:green:wlan5g phy0tpt There is no LED trigger called 'phy0tpt' so I think we should

Re: [OpenWrt-Devel] [PATCH] ramips:Fix mt7612 support for Xiaomi Mini.

Hi, 2015-02-04 12:44 GMT+01:00 Chuanhong Guo gch981...@gmail.com: From: 郭传鈜 gch981...@gmail.com 2ghz should be disabled on this router. You're right. This should be patched. And I think 'mediatek,mtd-eeprom' should be defined asfactory 32768 instead of factory 0x8000 according to

Re: [OpenWrt-Devel] [PATCH] ramips:Fix mt7612 support for Xiaomi Mini.

: 1 [ 15.33] Build Time: 201406241830 [ 15.36] Firmware running! [ 15.37] pci device driver attached [1] https://github.com/openwrt/mt76/blob/master/eeprom.c 2015-02-04 17:56 GMT+01:00 John Crispin blo...@openwrt.org: On 04/02/2015 17:08, Roger Pueyo Centelles wrote: Hi

Re: [OpenWrt-Devel] [PATCH] ramips:Fix mt7612 support for Xiaomi Mini.

Crispin blo...@openwrt.org: On 04/02/2015 20:18, Roger Pueyo Centelles wrote: Hi, I tried with 0x8004 and I also got a random IP address. Actually, I changed this block in in eeprom.c (line 571) [1]: can you do a hexdump -C /dev/mtd2 and paste the output please

Re: [OpenWrt-Devel] [PATCH] ramips:Fix mt7612 support for Xiaomi Mini.

Yes, the MAC is where expected. I've tried unloading and reloading the mt76pci module; the second line of the log passed unnoticed for me before. root@OpenWrt:/# rmmod mt76pci modprobe mt76pci dmesg [...] [ 73.62] pci device driver detached [ 73.63] mt76pci :01:00.0: no of_node;

Re: [OpenWrt-Devel] [PATCH] ramips:Fix mt7612 support for Xiaomi Mini.

( if (!np) ). Any ideas? 2015-02-04 23:13 GMT+01:00 John Crispin blo...@openwrt.org: On 04/02/2015 22:11, Roger Pueyo Centelles wrote: root@OpenWrt:/# hexdump -C /dev/mtd2 20 76 05 01 64 09 80 01 66 5d ff ff ff ff ff ff | v..d...f]..| 0010 ff ff ff ff ff ff ff

Re: [OpenWrt-Devel] [PATCH] ramips:Fix mt7612 support for Xiaomi Mini.

-06 20:22 GMT+08:00 Roger Pueyo Centelles rogerpu...@rogerpueyo.com: Hi, I added some prints to the eeprom.c file and saw that in function: static int mt76_get_of_eeprom(struct mt76_dev *dev, int len) { int ret = -ENOENT; #ifdef CONFIG_OF struct device_node *np = dev-dev-of_node

[OpenWrt-Devel] [PATCH] ar71xx: Add support for MERCURY MAC1200R

This patch adds support for MERCURY MAC1200R, a dual band 802.11bgn + 802.11ac router based on the AR9344, with QCA988x ath10k radio and 5 Fast Ethernet ports Signed-off-by: Roger Pueyo Centelles roger.pu...@guifi.net --- target/linux/ar71xx/base-files/etc/diag.sh | 3 + .../ar71xx

Re: [OpenWrt-Devel] [PATCH] ar71xx: Add support for MERCURY MAC1200R

Fine. Resending... :) 2015-02-08 16:21 GMT+01:00 郭传鈜 gch981...@gmail.com: Ah…Someone added an LED trigger for ath10k serveral days ago…So phy0tpt is able to use now:D 2015年2月8日 下午10:25于 roger.pu...@guifi.net写道： From: Roger Pueyo Centelles roger.pu...@guifi.net This patch adds support

Re: [OpenWrt-Devel] [ramips] Help supporting Xiaomi MiWiFi Mini (.dts file)

; }; 2015-01-29 7:29 GMT+08:00, Roger Pueyo Centelles open...@rogerpueyo.com : Hi, Some days ago I received a Xiaomi MiWiFi Mini and I've managed to run OpenWrt on it [1] (i.e. trunk OpenWrt, not the very modified stuff the vendor provides). I started with this initial patch [2] and I

Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for MERCURY MAC1200R

Hi, @Hartmut Ok, now I see. Thanks! @郭传鈜 Acoording to mach-archer-c7.c ,I think we should use ath79_register_pci(); here and use /lib/preinit/81_load_ath10k_board_bin to load calibration data for ath10k. So, I understand I have to remove this line from

Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for MERCURY MAC1200R

get a bunch of kernel errors. I agree, it doesn't make much sense to put a 10/100 switch, but it must be cheaper than a Gb one. Cheers, 2015-01-11 22:25 GMT+01:00 Gioacchino Mazzurco g...@eigenlab.org: On Sunday, January 11, 2015 09:30:34 PM Roger Pueyo Centelles wrote: Apparently it does

Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for MERCURY MAC1200R

Hi, Please check http://wiki.openwrt.org/toh/mercury/mac1200r Regards, Roger 2015-01-12 0:21 GMT+01:00 Bruno Randolf b...@einfach.org: On 01/11/2015 09:25 PM, Gioacchino Mazzurco wrote: The device has two radios: - 802.11abgn AR9344 SoC, ath9k, working OK - 802.11ac QCA988x, ath10k,

[OpenWrt-Devel] [PATCH] ar71xx: add mc-mac1200r to do_load_ath10k_board_bin()

This patch adds the mc-mac1200r target to do_load_ath10k_board_bin() in target/linux/ar71xx/base-files/lib/preinit/81_load_ath10k_board_bin to load the ath10k radio MAC address from the EEPROM in MERCURY MAC1200R devices Signed-off-by: Roger Pueyo Centelles roger.pu...@guifi.net --- .../ar71xx

Re: [OpenWrt-Devel] lantiq v3.18

Hi John, I tested Linux 3.18.7 on three different lantiq boards (ARV4518PW, ARV7518PW, ARV7159RW22). Here are the results: *ARV4518PW* Boot: Yes (Linux OpenWrt 3.18.7 #1 Sun Feb 22 09:51:57 CET 2015 mips GNU/Linux) Ethernet: Yes Switch: Yes Wireless: Probably yes¹² ADSL: Not tested, but

Re: [OpenWrt-Devel] lantiq v3.18

Sure. U-Boot 2013.10-openwrt5-00014-g0b78b5c-dirty (Mar 11 2014 - 22:56:27) arv7519rw Board: Lantiq ARV7519RW VRX200 Family Board SoC: Lantiq VRX288 v1.1 CPU: 500 MHz IO:250 MHz BUS: 250 MHz BOOT: NOR DRAM: 128 MiB Flash: 32 MiB In:serial Out: serial Err: serial Net:

[OpenWrt-Devel] [PATCH] [ramips] Add support for Comfast CF-WR800N

This patch adds support for Comfast CF-WR800N, a wall-plug wireless router based on the MT7620N SoC with one Ethernet port and a 802.11n 2.4 GHz radio. Signed-off-by: Roger Pueyo Centelles roger.pu...@guifi.net --- target/linux/ramips/base-files/etc/board.d/01_leds | 4 + .../linux/ramips/base

[OpenWrt-Devel] [PATCH] ar71xx: Add pll_1000 value for eth0

This patch adds the pll_1000 value for eth0 interface. This makes the Rocket M XW image compatible with other Ubiquiti devices with similar hardware with a Gigabit Ethernet port. --- .../ar71xx/patches-3.18/903-MIPS-ath79-ubnt-rocket-m-xw-support.patch | 3 ++- 1 file changed, 2 insertions(+), 1

[OpenWrt-Devel] [PATCH] ar71xx: Add pll_1000 value for eth0 to Ubiquiti Rocket M XW

This patch adds the pll_1000 value for eth0 interface. This makes the Rocket M XW image compatible with other Ubiquiti devices with similar hardware with a Gigabit Ethernet port. Signed-off-by: Roger Pueyo Centelles roger.pu...@guifi.net --- .../ar71xx/patches-3.18/903-MIPS-ath79-ubnt-rocket-m

Re: [OpenWrt-Devel] [ar71xx] Help with Ubiquiti Rocket M5 XW support patch

Hi lynxis, Just one port, but without switch. The init is correct now and the Ethernet port works. I was using the wrong mask, I thought it would be BIT(2) but I was wrong. I'll be submitting the patch in a while. Thank you very much! Roger 2015-04-16 0:15 GMT+02:00 Alexander Couzens

Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for Ubiquiti Rocket M XW devices

Hi, Just setting the mask with BIT(4) does not work. The Rocket needs this line: ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII; for the RGMII AR8035 Ethernet controller, while the Nano/Loco use the MII mode: ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII; Therefore the

[OpenWrt-Devel] [ar71xx] Help with Ubiquiti Rocket M5 XW support patch

! Roger [1] https://forum.openwrt.org/viewtopic.php?id=56830 [2] http://pastebin.com/aZTgZtzB From 56e0fd19d8976e11fd4bd1a0b0e8d962cedf4d4c Mon Sep 17 00:00:00 2001 From: Roger Pueyo Centelles roger.pu...@guifi.net Date: Wed, 15 Apr 2015 11:19:28 +0200 Subject: [PATCH] [RFC] [ar71xx] Add support

[OpenWrt-Devel] Help with sysupgrade/factory images for YunCore CPE-880 (ar71xx)

Hi, Some days ago I received a YunCore CPE-880 router. It's an AR9344-based outdoor 5 GHz CPE. You can read more about it at https://wiki.openwrt.org/toh/yuncore/cpe-880. Up to now I've succeeded in adding OpenWrt support for this device (see attached patch) with: - Ethernet+switch

Re: [OpenWrt-Devel] Ath10k mesh with OpenWRT question

Hi, At some point I was able to get IBSS running with an ath10k radio (QCA988X) using firmware-2.bin_999.999.0.636 [1]. I couldn't test it thoroughly, but it ran for some days in a production BMX6 mesh. I also tried Ben Greear's CT firmware, with no success. If you are starting a network from

Re: [OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?

uld I be coherent to U-Boot and use the more common LAN-eth0//WAN-eth1 assignation, or do it the other way round (LAN-eth1//WAN-eth0) as in the stock firmware? Thanks for your comments, Roger El 17/12/18 a les 5:50, Chuanhong Guo ha escrit: > Hi! > > On Mon, Dec 17, 2018 at 7:43 AM Roger Pu

[OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?

Hi, Some weeks ago I sent a PR adding ar71xx support for the Comfast CF-E110N [1], an outdoor 2,4 GHz router. Everything was working fine. A few days later I started working on adding ath79 support for the same device [2]. Almost everything worked, except for three GPIOs which I was not able to

Re: [OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?

age this? Thank you very much for your support. Best, Roger El 16/12/18 a les 19:07, Sebastian Kemper ha escrit: > On Sun, Dec 16, 2018 at 06:23:53PM +0100, Roger Pueyo Centelles | Guifi.net > wrote: >> >> Hi, > Hello Roger! > >> [...] >>

Re: [OpenWrt-Devel] [RFC] ath79: add support for COMFAST CF-E313AC

Roger [1] https://github.com/openwrt/openwrt/pull/1942/commits/9028a627bb9eb39ba74c9273cdf393bcd12c30cb#diff-8c41cbed377d406698f49b82d78a2057 [2] https://github.com/openwrt/openwrt/pull/1942 El 19/3/19 a les 13:33, Roger Pueyo Centelles ha escrit: > Hi, > > I've just added support for

[OpenWrt-Devel] [RFC] ath79: add support for COMFAST CF-E313AC

Hi, I've just added support for the COMFAST CF-E313AC, an outdoor wireless CPE with two Ethernet ports and a 802.11ac radio (see patch below). Everything is working fine but I've got two issues for which I'd like to get some advise: 1)

Re: [OpenWrt-Devel] [PATCH] ath79: add support for COMFAST CF-E130N v2

Well, rather than looking at the specifications, I'd check if the actual hardware is 802.11bgn. :) You could try the "iw list" command to see if the available channels match the 802.11bgn band or not. Cheers! El 13/11/19 a les 11:33, Kryma ha escrit: > Hi, > >> In addition to Adrian's comments,

Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for COMFAST CF-E130N v2

Hi Pavel, > Specifications: > > - QCA9531 SoC > - 1x 10/100 Mbps Ethernet, both with PoE-in support If it has one Ethernet, then there's only one PoE-in. Cheers! signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list

Re: [OpenWrt-Devel] [PATCH] ath79: add support for COMFAST CF-E130N v2

Hi, In addition to Adrian's comments, could it be that the device was a 802.11bgn router? www.comfast.com.cn/index.php?m=content=index=show=19=23 Cheers, Roger El 11/11/19 a les 10:09, Adrian Schmutzler ha escrit: > Hi, > >> +aliases { >> +serial0 = >> +led-boot =

Re: [OpenWrt-Devel] (no subject)

Hi, Have you checked https://openwrt.org/trademark ? Cheers! El 11/12/19 a les 20:43, sagar jain ha escrit: > > Can i sell OpenWRT based router ? > >   > > Sent from Mail for > Windows 10 > >   > > >

Re: [OpenWrt-Devel] [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2

Hi, Mine were just suggestions; feel free to do it or not! :) Roger El 21/10/19 a les 14:53, John Crispin ha escrit: > On 31/08/2019 23:32, m...@adrianschmutzler.de wrote: >> "6t@eth0" and "6@eth0" should be the same, so this can be merged with >> cudy,wr1000. > > I meant that part, sorry the

[OpenWrt-Devel] [RFC] ath79: support for MikroTik wAP AC: vmlinux.elf + DTB file

Hi, I am trying to port the "MikroTik RouterBOARD wAP G-5HacT2HnD", also known as "wAP AC" to ath79 (it's already supported in ar71xx) and I got stuck. I think I can't add the corresponding DTB to the kernel image, which has to be in ELF format so that the bootloader accepts it. So far, I get

Re: [OpenWrt-Devel] [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2

Hi Paul, I opened a pull request on GitHub to support the Mi Router 4A Gigabit Edition, which is essentially the same device. You can find it at https://github.com/openwrt/openwrt/pull/2486 There are a few differences you may want to address: >>> + xiaomi,mir3g-v2) >>> +

Re: [OpenWrt-Devel] ath79 equivalent of disable_smarteee

Hi Martin, Adrian, Thanks for the info. The device is advertising EEE capabilities, and so is the adapter on my computer it is connected to: root@computer:~# ethtool --show-eee eth2 EEE Settings for eth2:     EEE status: enabled - active     Tx LPI: disabled     Supported EEE link modes: 

Re: ath79: mikrotik mac issue

Hi, I gave it a try with OpenWrt SNAPSHOT, r16574-f7e00d81bc and Linux OpenWrt 5.10.31 #0 Sun Apr 18 14:14:52 2021 mips GNU/Linux. The MAC addresses are correct too. Do we have the same file and drivers? root@OpenWrt:/# md5sum /etc/*/02_network* 02ddf92ac3486bc00a25e0fa436bbba6 

Re: ath79: mikrotik mac issue

Hi, Sorry, no clue. I am getting MAC addresses correctly assigned on a MikroTik RB922UAGS-5HPacD running OpenWrt SNAPSHOT, r16574-f7e00d81bc. As expected, random MAC addresses appear for both eth0 and eth1 on a fresh boot after flashing with "sysupgrade -v -n. At around ~40 seconds uptime, the

Re: [OpenWrt-Devel] [PATCH 2/2] ramips: fix and tidy up DTS for D-Link DIR-810L

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, El 3/3/20 a les 19:14,

Re: [OpenWrt-Devel] [PATCH 2/2] ramips: fix and tidy up DTS for D-Link DIR-810L

e is hindering the max. frequency from being achieved. Roger El 28/2/20 a les 13:33, Roger Pueyo Centelles | Guifi.net ha escrit: > Hi Adrian, > > I tested the patches on the device. I sysupgraded from the current > master and everything seems OK. > > - Partitions > > ro

Re: [OpenWrt-Devel] [PATCH 2/2] ramips: fix and tidy up DTS for D-Link DIR-810L

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Adrian, I tested the patches

[OpenWrt-Devel] 4k sectors in ath79's SPI NOR for MikroTik devices

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, Recently, a couple of

Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD

ess the > issue will also be present over there. > > Thanks again, > > Koen > > On 27.01.20 15:16, Roger Pueyo Centelles | Guifi.net via openwrt-devel > wrote: >> The sender domain has a DMARC Reject/Quarantine policy which disallows >> sending mailing list

Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD

2e31 I wonder, though, which is the "correct" one --or how to change ath79's, so that it is coherent with the previous target--. Roger El 27/1/20 a les 18:17, Roger Pueyo Centelles | Guifi.net ha escrit: > Hi Koen, > > Please find the bootlogs

Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Michal, El 29/1/20 a les

[OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, I'm working on porting a

Re: [OpenWrt-Devel] Mikrotik ar71xx -> ath79 port

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Christopher, Congratulations

Re: [OpenWrt-Devel] [PATCH v2] ar71xx: add support for RB SXTsq 2nD

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, > I believe this is a waste

Re: [OpenWrt-Devel] [PATCH v2] ar71xx: add support for RB SXTsq 2nD

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Thibaut, We're actually

Re: [OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix it in 19.07.3 (?)

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, Thanks Chuanghong, I was

Re: [OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix it in 19.07.3 (?)

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, You're right, it's a bug and

Re: [OpenWrt-Devel] newer mikrotik boards not booting?

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Joe, El 13/6/20 a les 21:00,

Re: [PATCH 1/3] generic: platform/mikrotik: make soft_config writable without 4K sectors

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, Oskari, I could successfully

Re: Comfast CF-E110n

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, Bill, I have a couple of

Re: OpenWrt 19.07.10 service release

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, Congratulations for this