Re: [OpenWrt-Devel] [lantiq] help in supporting FRITZ!BOX 3272 (Fritz_Box_HW198))
Dear Bjorn,
Thank you very very much! You've been always helpful tome... :)
thank you for pointing me at your work - it has been very useful. I was using
as references sources from the TP-Link Archer D2.
thanks to your hints and work, I arrived to some of the conclusions you did.
Your device was booting, instead in my case I am not able to get it past the
PMU issue.
And even ignoring this error I end up having issues with the GPTU.
I guess the FRITZ!BOX3272 is maybe of another family of devices. don't know,
running out of ideas.
Any hint of what I might try next?
I didn't find GPL code for this device from AVM - but maybe it's just me. Any
help would be really apreciated.
BTW - PMU activation fails in sysctrl.c, in function
static int pmu_enable(struct clk *clk) ...
Enrico
On Wed, 28 Aug 2019, Bjørn Mork wrote:
Date: Wed, 28 Aug 2019 18:52:38
From: Bjørn Mork
To: Enrico Mioso
Cc: Martin Blumenstingl ,
Hauke Mehrtens , openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [lantiq] help in supporting FRITZ!BOX 3272
(Fritz_Box_HW198))
Enrico Mioso writes:
I am still trying to port a FRITZ!BOX3272 device to OpenWRt.
I tried to grab as much informations as I could, but I am arriving to the
conclusion I hould be doing something really wrong.
First of all, the kernel panics due to a data abort at
linux-4.19.66/arch/mips/lantiq/xway/sysctrl.c, line 478
/* make sure to unprotect the memory region where flash is located */
ltq_ebu_w32(ltq_ebu_r32(LTQ_EBU_BUSCON0) & ~EBU_WRDIS, LTQ_EBU_BUSCON0);
..
[SYSTEM:] AR10 on 500MHz/250MHz/250MHz
..
Eva_AVM >
..[
0.00] Linux version 4.19.66 (mrkiko@mStation) (gcc version 7.4.0
(OpenWrt GCC 7.4.0 r10863-e1dcfe02b2)) #0 SMP Mon Aug 26 16:21:13 2019
[0.00] SoC: xRX300 rev 1.2
Right, so this is AR10/xRX300. Been there, trying to get a D-Link
DWR-956 running, and gave up without getting the T-Shirt ;-)
I believe the problem you are hitting right now is caused by wrong
address for the EBU. It is not at 0x1E105300 like for the VR9 etc, but
at 0x1600 on the AR10.
So change this:
ebu0: ebu@e105300 {
compatible = "lantiq,ebu-xway";
reg = <0xe105300 0x100>;
};
into
ebu0: ebu@600 {
compatible = "lantiq,ebu-xway";
reg = <0x600 0x100>;
};
I was stuck the same place for quite some time
I pushed my abandoned DWR-956 branch here now:
https://github.com/bmork/OpenWrt/tree/dwr-956-wip
in case it is of any use to you.
Note that this branch is a terrible mess of Work-in-Progress, meant for
my eyes only. And even I can't make much sense out of it anymore. So
you might be better off just ignoring it. Your call.
Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lua: create lua symlink for host installation
Hello Karl,
the version built last is the one which will have the symlink set.
However, i think this is not the ideal solution in terms of
reproducibility, so we should probably only symlink lua5.1 for
the Host installation?
A bit more background on this topic (as I've forgotten to add this
to the commit message): LuaSrcDiet currently fails silently as it
expects a "lua" named binary in it's path. I suspect there could be
more silent breakage because of this currently.
Best wishes
David
On 8/28/19 10:53 PM, Karl Palsson wrote:
>
> How is this meant to work when you have both?
>
> David Bauer wrote:
>> Since the binaries for both lua as well as lua5.3 contain the
>> version number, invocations of the "lua" binary are failing, as
>> it's not created anymore for the host package.
>>
>> Fixes: fe59b46 ("lua: include version number in installed
>> files") Signed-off-by: David Bauer
>> ---
>> package/utils/lua/Makefile| 4 +++-
>> package/utils/lua5.3/Makefile | 4 +++-
>> 2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/package/utils/lua/Makefile
>> b/package/utils/lua/Makefile index a2870448bd..e376e8c472
>> 100644
>> --- a/package/utils/lua/Makefile
>> +++ b/package/utils/lua/Makefile
>> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>>
>> PKG_NAME:=lua
>> PKG_VERSION:=5.1.5
>> -PKG_RELEASE:=5
>> +PKG_RELEASE:=6
>>
>> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>> PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
>> @@ -133,6 +133,8 @@ define Host/Install
>> $(MAKE) -C $(HOST_BUILD_DIR) \
>> INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
>> install
>> +
>> +$(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.1 $(STAGING_DIR_HOSTPKG)/bin/lua
>> endef
>>
>> define Build/InstallDev
>> diff --git a/package/utils/lua5.3/Makefile
>> b/package/utils/lua5.3/Makefile index c9e9bebb1a..7f835dd41f
>> 100644
>> --- a/package/utils/lua5.3/Makefile
>> +++ b/package/utils/lua5.3/Makefile
>> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>>
>> PKG_NAME:=lua
>> PKG_VERSION:=5.3.5
>> -PKG_RELEASE:=4
>> +PKG_RELEASE:=5
>>
>> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>> PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
>> @@ -118,6 +118,8 @@ define Host/Install
>> $(MAKE) -C $(HOST_BUILD_DIR) \
>> INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
>> install
>> +
>> +$(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.3 $(STAGING_DIR_HOSTPKG)/bin/lua
>> endef
>>
>> define Build/InstallDev
>> --
>> 2.23.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
Re: [OpenWrt-Devel] [PATCH] lua: create lua symlink for host installation
How is this meant to work when you have both?
David Bauer wrote:
> Since the binaries for both lua as well as lua5.3 contain the
> version number, invocations of the "lua" binary are failing, as
> it's not created anymore for the host package.
>
> Fixes: fe59b46 ("lua: include version number in installed
> files") Signed-off-by: David Bauer
> ---
> package/utils/lua/Makefile| 4 +++-
> package/utils/lua5.3/Makefile | 4 +++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/package/utils/lua/Makefile
> b/package/utils/lua/Makefile index a2870448bd..e376e8c472
> 100644
> --- a/package/utils/lua/Makefile
> +++ b/package/utils/lua/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>
> PKG_NAME:=lua
> PKG_VERSION:=5.1.5
> -PKG_RELEASE:=5
> +PKG_RELEASE:=6
>
> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
> @@ -133,6 +133,8 @@ define Host/Install
> $(MAKE) -C $(HOST_BUILD_DIR) \
> INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
> install
> +
> + $(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.1 $(STAGING_DIR_HOSTPKG)/bin/lua
> endef
>
> define Build/InstallDev
> diff --git a/package/utils/lua5.3/Makefile
> b/package/utils/lua5.3/Makefile index c9e9bebb1a..7f835dd41f
> 100644
> --- a/package/utils/lua5.3/Makefile
> +++ b/package/utils/lua5.3/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>
> PKG_NAME:=lua
> PKG_VERSION:=5.3.5
> -PKG_RELEASE:=4
> +PKG_RELEASE:=5
>
> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
> @@ -118,6 +118,8 @@ define Host/Install
> $(MAKE) -C $(HOST_BUILD_DIR) \
> INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
> install
> +
> + $(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.3 $(STAGING_DIR_HOSTPKG)/bin/lua
> endef
>
> define Build/InstallDev
> --
> 2.23.0
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenPGP-digital-signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] lua: create lua symlink for host installation
Since the binaries for both lua as well as lua5.3 contain the version
number, invocations of the "lua" binary are failing, as it's not created
anymore for the host package.
Fixes: fe59b46 ("lua: include version number in installed files")
Signed-off-by: David Bauer
---
package/utils/lua/Makefile| 4 +++-
package/utils/lua5.3/Makefile | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/package/utils/lua/Makefile b/package/utils/lua/Makefile
index a2870448bd..e376e8c472 100644
--- a/package/utils/lua/Makefile
+++ b/package/utils/lua/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=lua
PKG_VERSION:=5.1.5
-PKG_RELEASE:=5
+PKG_RELEASE:=6
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
@@ -133,6 +133,8 @@ define Host/Install
$(MAKE) -C $(HOST_BUILD_DIR) \
INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
install
+
+ $(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.1 $(STAGING_DIR_HOSTPKG)/bin/lua
endef
define Build/InstallDev
diff --git a/package/utils/lua5.3/Makefile b/package/utils/lua5.3/Makefile
index c9e9bebb1a..7f835dd41f 100644
--- a/package/utils/lua5.3/Makefile
+++ b/package/utils/lua5.3/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=lua
PKG_VERSION:=5.3.5
-PKG_RELEASE:=4
+PKG_RELEASE:=5
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
@@ -118,6 +118,8 @@ define Host/Install
$(MAKE) -C $(HOST_BUILD_DIR) \
INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
install
+
+ $(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.3 $(STAGING_DIR_HOSTPKG)/bin/lua
endef
define Build/InstallDev
--
2.23.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] firewall3: zones: Use ipsets instead of interfaces in zone rules
firewall3 currently creates one rule for each interface that is a member of a
zone. On for example devices with multiple interfaces, the current firewall3
behavior quickly leads to a lot of rules. In order to reduce the number of
rules, this patch replaces the per-interface rules with ipset matches (if ipset
is available). Since 2011, ipset has supported the set type "hash:net,iface".
By adding (and matching on) on pairs consiting of the v4/v6 any-address and an
interface name, we get the same behavior as the current interface-rules.
After applying this patch (and assuming ipset is available), the following
actions are performed when a zone is created:
* We creates (allocate) an ipset of type "hash:net,iface" for each zone. The
name follows the following format: zone__<4/6>_set.
* If creating a set fails, then we ignore the zone. This is something we can
change, but my reason for this behavior is to have consistent firewall rules.
I.e., zone-rules either match on ipset or interface names, and not a mix.
* Each set is populated with pairs consisting of the IPv4/IPv6 any-address and
an interface name, for example "0.0.0.0/0, eth0.2".
* Instead of one rule per device, a single rule is created matching on the
ipset.
* The check used to select the OUTPUT/PREROUTING-chain when adding rules to the
raw-table has been moved to print_interface_rules_{default,set}. The motivation
behind this move was to avoid changing print_interface_rule() too much. As far
as I can see (and have tested), the logic for selecting chain/creating the
rules is the same as before.
Because the change introduced by this patch is quite intrusive and I am sure
there will be comments/disagreements/suggestions, I have sent this patch as an
RFC. One thing that I am aware of and will fix before the final submission, is
to add support for printing ipsets. Right now "fw3 print" prints per-interface
rules.
Signed-off-by: Kristian Evensen
---
ipsets.c | 38 ++-
ipsets.h | 7 ++
main.c| 8 +-
options.c | 3 +-
options.h | 4 +
zones.c | 291 +++---
zones.h | 15 ++-
7 files changed, 347 insertions(+), 19 deletions(-)
diff --git a/ipsets.c b/ipsets.c
index 280845b..e052278 100644
--- a/ipsets.c
+++ b/ipsets.c
@@ -81,6 +81,8 @@ static struct ipset_type ipset_types[] = {
OPT_FAMILY | OPT_HASHSIZE | OPT_MAXELEM),
T(HASH, NET, PORT, UNSPEC, 0,
OPT_FAMILY | OPT_HASHSIZE | OPT_MAXELEM),
+ T(HASH, NET, IFACE, UNSPEC, 0,
+ OPT_FAMILY | OPT_HASHSIZE | OPT_MAXELEM),
T(HASH, IP, PORT, IP, 0,
OPT_FAMILY | OPT_HASHSIZE | OPT_MAXELEM),
T(HASH, IP, PORT, NET,0,
@@ -247,7 +249,7 @@ check_ipset(struct fw3_state *state, struct fw3_ipset
*ipset, struct uci_element
return false;
}
-static struct fw3_ipset *
+struct fw3_ipset *
fw3_alloc_ipset(struct fw3_state *state)
{
struct fw3_ipset *ipset;
@@ -611,3 +613,37 @@ fw3_ipsets_update_run_state(enum fw3_family family, struct
fw3_state *run_state,
ipset_run->reload_set = ipset_cfg->reload_set;
}
}
+
+void
+fw3_ipset_add_devices(struct list_head *devices, enum fw3_family family,
+ const char *set_name)
+{
+ struct fw3_device *dev;
+ bool exec = false;
+ const char *addr;
+
+ fw3_foreach(dev, devices) {
+ if (!dev)
+ continue;
+
+ if (!exec) {
+ exec = fw3_command_pipe(false, "ipset", "-exist", "-");
+
+ if (!exec)
+ return;
+ }
+
+ if (family == FW3_FAMILY_V4) {
+ addr = "0.0.0.0/0";
+ } else {
+ addr = "::/0";
+ }
+
+ fw3_pr("add %s %s,%s\n", set_name, addr, dev->name);
+ }
+
+ if (exec) {
+ fw3_pr("quit\n");
+ fw3_command_close();
+ }
+}
diff --git a/ipsets.h b/ipsets.h
index 76078d4..19528e9 100644
--- a/ipsets.h
+++ b/ipsets.h
@@ -41,6 +41,13 @@ void
fw3_ipsets_update_run_state(enum fw3_family family, struct fw3_state
*run_state,
struct fw3_state *cfg_state);
+struct fw3_ipset *
+fw3_alloc_ipset(struct fw3_state *state);
+
+void
+fw3_ipset_add_devices(struct list_head *devices, enum fw3_family family,
+ const char *set_name);
+
static inline void fw3_free_ipset(struct fw3_ipset *ipset)
{
list_del(>list);
diff --git a/main.c b/main.c
index 7ad00b4..7b9c9e3 100644
--- a/main.c
+++ b/main.c
@@ -266,6 +266,9 @@ start(void)
continue;
}
+ if (!print_family)
+ fw3_fill_zone_ipsets(family, cfg_state);
+
for (table = FW3_TABLE_FILTER; table <= FW3_TABLE_RAW; table++)
{
if
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> > initialized the ackto to max: > > > > A) avoidance of late-ack state > > B) not require wpa_supplicant -- not in use by our community today > > C) Suspect some conditions, e.g. low SNR Neighbors, do not trigger > > "late ack" (consistent, with observation of low SNR Neighbors sticking > > at max ack_to with my changes ) > > > > flip the algo off/on when new neighbor joins: > > > > Intended technique to reset ack_to to max. If ack_to is set to 20km > > and then a new adhoc neighbor joins at 30km, this would be a late ack > > state, and unable to detect.My early testing results showed the > > algo off/on would restart the ack_to to max and start the process over > > with the new neighbor. I trust I got it right? > > > > There are 10s to 100s of users testing this bleeding edge change from > > nightly builds, and so far, I've not found a failure case. > > Although, the findings are showing the cases where static setting has > > better throughput. > > > > Joe AE6XE > > > >>> > Hi Joe, > > Purely fyi > > I just pushed dynack improvements to all openwrt branches. > > I also noticed the issues you addressed above, and these patches fix > them for me. > > Regards, > > Koen > Thanks for update. Updates on performance observations, I've been recommending usage of auto settings to the AREDN community as follows: * best performance gain on Point-to-Point longer distance links (back bone links). I saw ~30% iperf improvement results on a 60km 5GHz link -- ack-to floats up under load. This was about the difference I measured on a similar 3GHz 60km link head-to-head comparison between AirOS auto distance with TDMA and openwrt static distance with CSMA. (3GHz because it takes wifi noise out of the picture.) I want to do a head-to-head comparison again to confirm, but it appears a P2P w/ auto setting CSMA in openwrt will compare similar thoughput as AirOS auto distance TDMA. * good/poor performance for Point-to-Multipoint long distance settings, up to 20km range (cell coverage). If weak SNR stations, a static setting is optimal. If quality signal, auto works good. * Poor performance for short distances, e.g. in the house. auto calculated ack_to settings are several km. Performance is much poorer than a static setting of <1km. There seems to be something going on with calculation when 'on the bench' testing with short distances. Maybe a bias needs to be applied? Joe AE6XE ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [lantiq] help in supporting FRITZ!BOX 3272 (Fritz_Box_HW198))
Enrico Mioso writes:
> I am still trying to port a FRITZ!BOX3272 device to OpenWRt.
> I tried to grab as much informations as I could, but I am arriving to the
> conclusion I hould be doing something really wrong.
>
> First of all, the kernel panics due to a data abort at
> linux-4.19.66/arch/mips/lantiq/xway/sysctrl.c, line 478
> /* make sure to unprotect the memory region where flash is located */
> ltq_ebu_w32(ltq_ebu_r32(LTQ_EBU_BUSCON0) & ~EBU_WRDIS, LTQ_EBU_BUSCON0);
..
> [SYSTEM:] AR10 on 500MHz/250MHz/250MHz
>
> ..
> Eva_AVM >
>
>
>
>
>
>
>
> ..[
> 0.00] Linux version 4.19.66 (mrkiko@mStation) (gcc version 7.4.0
> (OpenWrt GCC 7.4.0 r10863-e1dcfe02b2)) #0 SMP Mon Aug 26 16:21:13 2019
> [0.00] SoC: xRX300 rev 1.2
Right, so this is AR10/xRX300. Been there, trying to get a D-Link
DWR-956 running, and gave up without getting the T-Shirt ;-)
I believe the problem you are hitting right now is caused by wrong
address for the EBU. It is not at 0x1E105300 like for the VR9 etc, but
at 0x1600 on the AR10.
So change this:
ebu0: ebu@e105300 {
compatible = "lantiq,ebu-xway";
reg = <0xe105300 0x100>;
};
into
ebu0: ebu@600 {
compatible = "lantiq,ebu-xway";
reg = <0x600 0x100>;
};
I was stuck the same place for quite some time
I pushed my abandoned DWR-956 branch here now:
https://github.com/bmork/OpenWrt/tree/dwr-956-wip
in case it is of any use to you.
Note that this branch is a terrible mess of Work-in-Progress, meant for
my eyes only. And even I can't make much sense out of it anymore. So
you might be better off just ignoring it. Your call.
Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [lantiq] help in supporting FRITZ!BOX 3272 (Fritz_Box_HW198))
Dear OpenWRt list, Dear Martin, Dear Hauke, TL;DR: Can you help me out with the DTS? I have no access to datasheets and I couldn't recover useful infos from the original firmware... Attached my DTS I am still trying to port a FRITZ!BOX3272 device to OpenWRt. I tried to grab as much informations as I could, but I am arriving to the conclusion I hould be doing something really wrong. First of all, the kernel panics due to a data abort at linux-4.19.66/arch/mips/lantiq/xway/sysctrl.c, line 478 /* make sure to unprotect the memory region where flash is located */ ltq_ebu_w32(ltq_ebu_r32(LTQ_EBU_BUSCON0) & ~EBU_WRDIS, LTQ_EBU_BUSCON0); Secondly, commenting out this line just to see how it goes, I can see the kernel fails to communicate with the PMU - and... ROM VER: 1.1.0 CFG 05 ??K ]Y QQK
[OpenWrt-Devel] (no subject)
زبان چینی رابه انگلیسی تغییردهید ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
initialized the ackto to max: A) avoidance of late-ack state B) not require wpa_supplicant -- not in use by our community today C) Suspect some conditions, e.g. low SNR Neighbors, do not trigger "late ack" (consistent, with observation of low SNR Neighbors sticking at max ack_to with my changes ) flip the algo off/on when new neighbor joins: Intended technique to reset ack_to to max. If ack_to is set to 20km and then a new adhoc neighbor joins at 30km, this would be a late ack state, and unable to detect.My early testing results showed the algo off/on would restart the ack_to to max and start the process over with the new neighbor. I trust I got it right? There are 10s to 100s of users testing this bleeding edge change from nightly builds, and so far, I've not found a failure case. Although, the findings are showing the cases where static setting has better throughput. Joe AE6XE Hi Joe, Purely fyi I just pushed dynack improvements to all openwrt branches. I also noticed the issues you addressed above, and these patches fix them for me. Regards, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2
- CMIIT ID: 2019AP2581
- SoC: MediaTek MT7621
- Flash:16MiB NOR SPI (GigaDevice GD25Q128B)
- RAM: 128MiB DDR3 (ESMT M15T1G1664A)
- Serial: As marked on PCB, 3V3 logic, baudrate is 115200, 8n1
- Ethernet: 3x 10/100/1000 Mbps (switched, 2xLAN + WAN)
- WIFI0:MT7603E 2.4GHz 802.11b/g/n
- WIFI1:MT7612E 5GHz 802.11ac
- Antennas: 4x external (2 per radio), non-detachable
- LEDs: Programmable "power" LED (two-coloured, yellow/blue)
Non-programmable "internet" LED (shows WAN activity)
- Buttons: Reset
INSTALLATION:
Bootloader won't accept any serial input unless "boot_wait" u-boot
environment variable is changed to "on". Vendor firmware (looks like
an illegal OpenWrt fork) won't accept any serial input unless
"uart_en" is set to "1". Tricks to force u-boot to use default
environment do not help as it's restricted in the same way.
With bootloader unlocked the easiest way would be to TFTP the
sysupgrade image or to sysupgrade after loading an initramfs one.
For porting the flash contents were changed externally with an SPI
programmer (after lifting Vcc flash IC pin away from the PCB).
Forum thread [0] indicates that this device is identical to "Xiaomi Mi
Router 4A Gigabit Edition".
[0]
https://forum.openwrt.org/t/xiaomi-mi-router-4a-gigabit-edition-r4ag-r4a-gigabit-fully-supported-but-requires-overwriting-spi-flash-with-programmer/36685
Signed-off-by: Paul Fertser
---
Changes for v2:
- Addressed all Adrian Schmutzl's comments
Changes for v3:
- Add SPDX license header
- Use new ALT variables to support R4AG model name
.../linux/ramips/base-files/etc/board.d/02_network | 7 +
target/linux/ramips/dts/mt7621_xiaomi_mir3g-v2.dts | 147 +
target/linux/ramips/image/mt7621.mk| 12 ++
3 files changed, 166 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_xiaomi_mir3g-v2.dts
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index 27f85d7458..2b166dd944 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -469,6 +469,10 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"2:lan:2" "3:lan:1" "1:wan" "6t@eth0"
;;
+ xiaomi,mir3g-v2)
+ ucidef_add_switch "switch0" \
+ "2:lan:2" "3:lan:1" "4:wan" "6t@eth0"
+ ;;
xiaomi,mir3p)
ucidef_add_switch "switch0" \
"1:lan:3" "2:lan:2" "3:lan:1" "4:wan" "6@eth0"
@@ -683,6 +687,9 @@ ramips_setup_macs()
xiaomi,mir3p)
lan_mac=$(mtd_get_mac_binary factory 0xe006)
;;
+ xiaomi,mir3g-v2)
+ wan_mac=$(mtd_get_mac_binary factory 0xe006)
+ ;;
xiaomi,miwifi-mini)
lan_mac=$(macaddr_setbit_la "$(cat
/sys/class/net/eth0/address)")
;;
diff --git a/target/linux/ramips/dts/mt7621_xiaomi_mir3g-v2.dts
b/target/linux/ramips/dts/mt7621_xiaomi_mir3g-v2.dts
new file mode 100644
index 00..58da88a862
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_xiaomi_mir3g-v2.dts
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "xiaomi,mir3g-v2", "mediatek,mt7621-soc";
+ model = "Xiaomi Mi Router 3G v2";
+
+ aliases {
+ led-boot = _status_yellow;
+ led-failsafe = _status_yellow;
+ led-running = _status_blue;
+ led-upgrade = _status_yellow;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_status_blue: status_blue {
+ label = "mir3gv2:blue:status";
+ gpios = < 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led_status_yellow: status_yellow {
+ label = "mir3gv2:yellow:status";
+ gpios = < 10 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ button {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = < 18 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ m25p80@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <8000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
