ipq40xx: Add ZTE MF289F #10710

stich86 · 2022-09-14T12:25:24Z

It's a 4G Cat.20 router used by Vodafone Italy (called Vodafone FWA) and Vodafone DE\T-Mobile PL (called GigaCube). Modem is a MiniPCIe-to-USB based on Snapdragon X24, it supports 4CA aggregation.

There are currently two hardware revisions, which differ on the 5Ghz radio:

AT1 = QCA9984 5Ghz Radio on PCI-E bus
AT2 = IPQ4019 5Ghz Radio insde IPQ4019 like 2.4Ghz

Device specification

SoC Type: Qualcomm IPQ4019
RAM: 256 MiB
Flash: 128 MiB SPI NAND (Winbond W25N01GV)
ROM: 2MiB SPI Flash (GD25Q16)
Wireless 2.4 GHz (IP4019): b/g/n, 2x2
Wireless 5 GHz (QCA9984): a/n/ac, 4x4 HW REV AT1 OR 5 GHz (IPA4019): a/n/ac, 2x2 HW REV AT2 Ethernet: 2xGbE (WAN/LAN1, LAN2)
USB ports: No
Button: 2 (Reset/WPS)
LEDs: 3 external leds: Network (white or red), Wifi, Power and 1 internal (blue) -- NOTE: Power and Network leds are controlled by board and cannot be modified by OpenWRT
Power: 12 VDC, 1 A
Connector type: Barrel
Bootloader: U-Boot

Installation

Place OpenWrt initramfs image for the device on a TFTP in the server's root. This example uses Server IP: 192.168.0.2
Connect serial console (115200,8n1) to serial connector (refer to this image: https://ibb.co/31Gngpr).
Connect TFTP server to RJ-45 port (WAN/LAN1).
Stop in u-Boot (using ESC button) and run u-Boot commands:

setenv serverip 192.168.0.2
setenv ipaddr 192.168.0.1
set fdt_high 0x85000000
tftp openwrt-ipq40xx-generic-zte_mf289f-initramfs-fit-zImage.itb bootm $loadaddr

Please make backup of original partitions, if you think about revert to stock, specially mtd16 (Web UI) and mtd17 (rootFS). Use /tmp as temporary storage and do:

WEB PARITION

cat /dev/mtd16 > /tmp/mtd16.bin
scp /tmp/mtd16.bin root@YOURSERVERIP:/
rm /tmp/mtd16.bin

ROOT PARITION

cat /dev/mtd17 > /tmp/mtd17.bin
scp /tmp/mtd17.bin root@YOURSERVERIP:/
rm /tmp/mtd17.bin

Login via ssh or serial and remove stock partitions (default IP 192.168.0.1):

ubiattach -m 17 # it could return error if ubi was attached before or rootfs part was erased before ubirmvol /dev/ubi0 -N ubi_rootfs # it could return error if rootfs part was erased before ubirmvol /dev/ubi0 -N ubi_rootfs_data # some devices doesn't have it

Install image via “sysupgrade -n” (like “sysupgrade -n /tmp/openwrt-ipq40xx-generic-zte_mf289f-squashfs-sysupgrade.bin”; previously wgeting bin). Sometimes it could print ubi attach error, but please ignore it if process goes forward.

Flash Layout

NAND:
mtd8: 000a0000 00020000 "fota-flag"
mtd9: 00080000 00020000 "0:ART"
mtd10: 00080000 00020000 "mac"
mtd11: 000c0000 00020000 "reserved2"
mtd12: 00400000 00020000 "cfg-param"
mtd13: 00400000 00020000 "log"
mtd14: 000a0000 00020000 "oops"
mtd15: 00500000 00020000 "reserved3"
mtd16: 00800000 00020000 "web"
mtd17: 01d00000 00020000 "rootfs"
mtd18: 01900000 00020000 "data"
mtd19: 03200000 00020000 "fota"
mtd20: 0041e000 0001f000 "kernel"
mtd21: 0101b000 0001f000 "ubi_rootfs"

SPI:
mtd0: 00040000 00010000 "0:SBL1"
mtd1: 00020000 00010000 "0:MIBIB"
mtd2: 00060000 00010000 "0:QSEE"
mtd3: 00010000 00010000 "0:CDT"
mtd4: 00010000 00010000 "0:DDRPARAMS"
mtd5: 00010000 00010000 "0:APPSBLENV"
mtd6: 000c0000 00010000 "0:APPSBL"
mtd7: 00050000 00010000 "0:reserved1"

Back to Stock (!!! need original dump taken from initramfs !!!) -------------

Place mtd16.bin and mtd17.bin initramfs image for the device on a TFTP in the server's root. This example uses Server IP: 192.168.0.2
Connect serial console (115200,8n1) to serial console connector (refer to this image: https://ibb.co/31Gngpr).
Connect TFTP server to RJ-45 port (WAN/LAN1).
rename mtd16.bin to web.img and mtd17.bin to root_uImage_s
Stop in u-Boot (using ESC button) and run u-Boot commands:

This will erase RootFS+Web:
nand erase 0x1000000 0x800000
nand erase 0x1800000 0x1D00000

This will restore RootFS:
tftpboot 0x84000000 ${dir}root_uImage_s
nand erase 0x1800000 0x1D00000
nand write $fileaddr 0x1800000 $filesize

This will restore Web Interface:
tftpboot 0x84000000 ${dir}web.img
nand erase 0x1000000 0x800000
nand write $fileaddr 0x1000000 $filesize

After first boot on stock firwmare, do a factory reset. Push reset button for 5 seconds so all parameters will be reverted to the one printed on label on bottom of the router

Signed-off-by: Giammarco Marzano stich86@gmail.com

target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-mf289f.dts

target/linux/ipq40xx/image/generic.mk

Leo-PL · 2022-09-15T00:24:48Z

@stich86 Aside from a few tiny cosmetic issues in device tree, and the DEVICE_PACKAGES line, LGTM. Great work!

stich86 · 2022-09-15T07:31:08Z

@stich86 Aside from a few tiny cosmetic issues in device tree, and the DEVICE_PACKAGES line, LGTM. Great work!

thanks for you time
i've implemented all your advice.

Let me know if i'm missing something

Leo-PL · 2022-09-15T21:58:25Z

@stich86 Aside from a few tiny cosmetic issues in device tree, and the DEVICE_PACKAGES line, LGTM. Great work!

thanks for you time i've implemented all your advice.

Let me know if i'm missing something

It'd be nice to restore Paweł's copyright notice in the device tree, maybe it was dropped by accident.
Also, I thought that Github's diff viewer is broken, but there is still one tab too much in the nvmem range nodes (precal_art_1000, precal_art_5000, macaddr_config_0)

stich86 · 2022-09-16T07:32:24Z

@stich86 Aside from a few tiny cosmetic issues in device tree, and the DEVICE_PACKAGES line, LGTM. Great work!

thanks for you time i've implemented all your advice.
Let me know if i'm missing something

It'd be nice to restore Paweł's copyright notice in the device tree, maybe it was dropped by accident. Also, I thought that Github's diff viewer is broken, but there is still one tab too much in the nvmem range nodes (precal_art_1000, precal_art_5000, macaddr_config_0)

Do you mean these?

                        partition@a0000 {
                                label = "ART";
                                reg = <0xa0000 0x80000>;
                                read-only;
                                compatible = "nvmem-cells";
                                #address-cells = <1>;
                                #size-cells = <1>;

                                precal_art_1000: precal@1000 {
                                                reg = <0x1000 0x2f20>;
                                };

                                precal_art_5000: precal@5000 {
                                                reg = <0x5000 0x2f20>;
                                };
                        };

                        partition@120000 {
                                label = "mac";
                                reg = <0x120000 0x80000>;
                                read-only;
                                compatible = "nvmem-cells";
                                #address-cells = <1>;
                                #size-cells = <1>;

                                macaddr_config_0: macaddr@0 {
                                                reg = <0x0 0x6>;
                                };
                        };

EDIT: it should be fixed now, i've also restore Pawel 's Copyright

Let me know!

Leo-PL · 2022-09-16T16:19:09Z

@stich86 Yes, that's what I meant. Thanks! Looking good now, I believe now it's @chunkeey's or @hauke's turn.

stich86 · 2022-09-19T12:23:10Z

@stich86 Yes, that's what I meant. Thanks! Looking good now, I believe now it's @chunkeey's or @hauke's turn.

ok let's wait for @chunkeey and @hauke
hope to avoid a full resync of the repo before the merge :D

Leo-PL · 2022-09-19T20:12:36Z

Just to make it clear:
Reviewed-by: Lech Perczak lech.perczak@gmail.com

MiG-41 · 2022-09-20T14:21:25Z

Tested by @MiG-41 , works without issues on my MF289F.

MayorBug · 2022-09-20T19:34:12Z

Tested-by: @MayorBug on my MF289F AT2 with the build uploaded on @stich86 github. Flashing went smoothly and everything seems to work except I have some isolated issues when connecting to 5 GHz network when set to 80 MHz with my laptop. My phone (OP7TP) connects fine. So it might be a problem with my QCA6174 network card.

Angemon25 · 2022-09-22T11:53:18Z

Tested by @Angemon25 on my MF289F AT2. The installation was very simple and everything works perfectly, besides it's stable and I have not had any crashes.

stich86 · 2022-09-24T17:37:19Z

here is a build from SNAPSHOT r20640-780e592f03 using these patches, if anyone want to test it feel free to comment :)

Inside the build there are some custom packages (from @4IceG and eko.one.pl) and it's preconfigured with:

hostname: MF289F
IP: 192.168.0.1 (192.168.1.1 in InitRAMFS)
APN on QMI interface: internet

Custom packages:

3g-infolite
modem-band
atinout
sms-tool
comgt
picocom
ser2net listen on port 5000 to access module with QPST (and run EFS Explorer)
bbr module
SQM module
tcpdump
socat
sysinfo
wireguard
openvpn

https://github.com/stich86/OpenWRT-ZTE-MF289F/tree/main/test_build_220924

kirdesde · 2022-09-24T17:41:58Z

Hi, thanks for adding support for that device.

I've found only a small issue on my device (Vodafone device, AT2))

The led-status is not gpio controlled (at least on my device) . To me it looks like it's directly connected to the power supply
The led-status and led-wlan nodes are looking like a copy & paste from the MF286F, however the wlan-led works fine though.

Probably it's better to rm the led-status node add the board-led (the blue one on the board, gpio 35) as a default led to see the boot/sysupgrade status.

In addition it would be good to add a note, that the 3rd led (network led) seems controlled by the wwan card.

Cheers

MayorBug · 2022-09-24T18:02:26Z

@stich86 I flashed your latest build via sysupgrade with the keep settings flag. Booted right up and seems to be working. Can't comment on stability yet. The previous build was rock solid for me. Also the issue with the 80 mhz setting went away when I ran linux on my pc, that rules out router firmware problems.

stich86 · 2022-09-24T18:21:57Z

Hi, thanks for adding support for that device.

I've found only a small issue on my device (Vodafone device, AT2))

The led-status is not gpio controlled (at least on my device) . To me it looks like it's directly connected to the power supply The led-status and led-wlan nodes are looking like a copy & paste from the MF286F, however the wlan-led works fine though.

Probably it's better to rm the led-status node add the board-led (the blue one on the board, gpio 35) as a default led to see the boot/sysupgrade status.

In addition it would be good to add a note, that the 3rd led (network led) seems controlled by the wwan card.

Cheers

uh thanks for that feedback.

I'm rebuilding the led-status with correct GPIO, after tested i'll push new commit
Regardig the name i will not change it, in the older PR @Leo-PL approved this name, so I want to avoid another discussion about this nomenclature ;)

let you know in the next few minutes :)

stich86 · 2022-09-25T12:05:50Z

hmm, looks like I merged an older version there :(.

If the test LED is something worthwhile, can you please do a follow-up?

(Also, I likely messed up some stuff with the led nodes/function renames)

Uhm... so what's next? Do you prefer already DSA converted?

This won't work at the moment as robimarkos dsa pr isn't merge yet.

I think we need to wait for a rebase of the pr #4721 and we can open a pr for the MF289F regarding dsa conversion.

What are advantages of DSA conversion?

@chunkeey regarding you last commit, only change was related to wrong GPIO of internal status led. How do you want to proceed?

Thx

kirdesde · 2022-09-25T12:11:12Z

hmm, looks like I merged an older version there :(.

If the test LED is something worthwhile, can you please do a follow-up?

(Also, I likely messed up some stuff with the led nodes/function renames)

Uhm... so what's next? Do you prefer already DSA converted?

This won't work at the moment as robimarkos dsa pr isn't merge yet.
I think we need to wait for a rebase of the pr #4721 and we can open a pr for the MF289F regarding dsa conversion.

What are advantages of DSA conversion?

DSA is the successor of the legacy OpenWrt switchdev. robimarko has added a DSA compatible driver + a newer Ethernet driver for IPQ40xx and all IPQ40xx devices needs to be converted to DSA logic.

chunkeey · 2022-09-25T19:11:42Z

@chunkeey regarding you last commit, only change was related to wrong GPIO of internal status led. How do you want to proceed?

the LED that we talk about is now led-0, right?

From what I understand, you could just make a separate patch that replaces the GPIO 10 with 35.
I can merge that ~ next weekend.

Cheers,
Christian

stich86 · 2022-09-25T19:18:05Z

@chunkeey regarding you last commit, only change was related to wrong GPIO of internal status led. How do you want to proceed?

the LED that we talk about is now led-0, right?

From what I understand, you could just make a separate patch that replaces the GPIO 10 with 35.

I can merge that ~ next weekend.

Cheers,

Christian

Should I need to open another PR?

stich86 · 2022-09-26T10:13:48Z

@chunkeey

now the PR has some conflicts because device was added on master branch.
So what i've to do with this PR?

Some people also told me to swap eth0 with eth1 and viceversa to match the labeling on back cover. At the moment i've used eth0 as LAN1/WAN and eth1 as LAN, but on OpenWRT are LAN and WAN respectivly.

@Leo-PL What do you think? I'm referring about thread on eko.one

thx

Leo-PL · 2022-09-26T18:17:09Z

@stich86 I would swap the interfaces, so 'wan' is at least on that has WAN label, so WAN/LAN1, and thus 'lan' on LAN2.
Regarding the changes of the LED mapping, I would just open new PR with two separate conmits (one for WAN/LAN mapping) and second to fix the LED - they touch different areas, so are two separate logical changes. All that on top of current master - no need to rebase this branch on it.

stich86 · 2022-09-26T19:34:28Z

@stich86 I would swap the interfaces, so 'wan' is at least on that has WAN label, so WAN/LAN1, and thus 'lan' on LAN2. Regarding the changes of the LED mapping, I would just open new PR with two separate conmits (one for WAN/LAN mapping) and second to fix the LED - they touch different areas, so are two separate logical changes. All that on top of current master - no need to rebase this branch on it.

ok so to recap:

this PR will be closed (because if i'm sync to current master all files are already in palce)
open new PR with: dts modified for status LED and swapped interface

on the last one, how to do it? Just change label on DTS or I need to modify custom configuration?

thx!

Leo-PL · 2022-09-26T22:28:00Z

@stich86 I looked here:
https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/base-files/etc/board.d/02_network#L167

Mapping of ports to the (virtual) Ethernet links inside chip is done in the device tree.
From what I read on eko.one.pl topic, that LAN/WAN1 is port 2 on the switch, and LAN2 is port 5? Is this correct?

If so, then the device tree will need two new properties:

		ess-switch@c000000 {
			switch_lan_bmp = <0x20>;
			switch_wan_bmp = <0x2>;
		}

to actually swap the mapping between LAN (eth0) which now covers ports 1-4, and WAN (eth1) which covers port 5.
With this change in mind, the new mapping in 02_network should be
"0u@eth0" "5:lan" "0u@eth1" "2:wan"
if that's the case, then the logical interfaces will be created correctly.
@chunkeey please correct me if I'm wrong.

stich86 · 2022-09-27T07:10:47Z

@stich86 I looked here: https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/base-files/etc/board.d/02_network#L167

Mapping of ports to the (virtual) Ethernet links inside chip is done in the device tree. From what I read on eko.one.pl topic, that LAN/WAN1 is port 2 on the switch, and LAN2 is port 5? Is this correct?

If so, then the device tree will need two new properties:
		ess-switch@c000000 {
			switch_lan_bmp = <0x20>;
			switch_wan_bmp = <0x2>;
		}
to actually swap the mapping between LAN (eth0) which now covers ports 1-4, and WAN (eth1) which covers port 5. With this change in mind, the new mapping in 02_network should be "0u@eth0" "5:lan" "0u@eth1" "2:wan" if that's the case, then the logical interfaces will be created correctly. @chunkeey please correct me if I'm wrong.

thx for the hints.

I'll try this week on my unit, if it works i'll open new PR with both fixes (LED+eth swap)

stich86 · 2022-09-27T14:08:02Z

@chunkeey can I close this PR?
when i'll sync my repo only the two files that should be modified will be match

let me know thx!

stich86 · 2022-09-27T19:14:55Z

@Leo-PL

I take a look at original DTS, switch is configured in this way:

                ess-switch@c000000 {
                        compatible = "qcom,ess-switch";
                        reg = <0xc000000 0x80000>;
                        switch_access_mode = "local bus";
                        resets = <0x02 0x1d 0x02 0x4e 0x02 0x4f 0x02 0x50 0x02 0x51 0x02 0x52>;
                        reset-names = "ess_rst\0ess_mac1_clk_dis\0ess_mac2_clk_dis\0ess_mac3_clk_dis\0ess_mac4_clk_dis\0ess_mac5_clk_dis";
                        clocks = <0x02 0x23>;
                        clock-names = "ess_clk";
                        switch_cpu_bmp = <0x01>;
                        switch_lan_bmp = <0x3a>;
                        switch_wan_bmp = <0x04>;
                        switch_mac_mode = <0x00>;

So i've added to my DTS these one and configured 02_network as suggested:

                        switch_lan_bmp = <0x3a>;
                        switch_wan_bmp = <0x04>;

But booting the image doesn't work. I see that at OS level eth0 is still LAN1/WAN and eth1 LAN, but no more traffic pass on these interfaces

Same problem also using your data.

Any suggestion?

Thx

kirdesde · 2022-09-28T06:09:31Z

@Leo-PL

I take a look at original DTS, switch is configured in this way:

                ess-switch@c000000 {
                        compatible = "qcom,ess-switch";
                        reg = <0xc000000 0x80000>;
                        switch_access_mode = "local bus";
                        resets = <0x02 0x1d 0x02 0x4e 0x02 0x4f 0x02 0x50 0x02 0x51 0x02 0x52>;
                        reset-names = "ess_rst\0ess_mac1_clk_dis\0ess_mac2_clk_dis\0ess_mac3_clk_dis\0ess_mac4_clk_dis\0ess_mac5_clk_dis";
                        clocks = <0x02 0x23>;
                        clock-names = "ess_clk";
                        switch_cpu_bmp = <0x01>;
                        switch_lan_bmp = <0x3a>;
                        switch_wan_bmp = <0x04>;
                        switch_mac_mode = <0x00>;

So i've added to my DTS these one and configured 02_network as suggested:

                        switch_lan_bmp = <0x3a>;
                        switch_wan_bmp = <0x04>;

But booting the image doesn't work. I see that at OS level eth0 is still LAN1/WAN and eth1 LAN, but no more traffic pass on these interfaces

Same problem also using your data.

Any suggestion?

Thx

According to the stock firmware (etc/init.d/zte_init.sh) they using vlan's to separate wan/lan and assigning the eth ports.

So if you are using the stock wan/lan switch BMP you would also need the same vlan config I guess.

Can you try that bitmask?

switch_lan_bmp = <0x20>;
switch_wan_bmp = <0x2>;

stich86 · 2022-09-28T16:02:55Z

@Leo-PL
I take a look at original DTS, switch is configured in this way:
                ess-switch@c000000 {
                        compatible = "qcom,ess-switch";
                        reg = <0xc000000 0x80000>;
                        switch_access_mode = "local bus";
                        resets = <0x02 0x1d 0x02 0x4e 0x02 0x4f 0x02 0x50 0x02 0x51 0x02 0x52>;
                        reset-names = "ess_rst\0ess_mac1_clk_dis\0ess_mac2_clk_dis\0ess_mac3_clk_dis\0ess_mac4_clk_dis\0ess_mac5_clk_dis";
                        clocks = <0x02 0x23>;
                        clock-names = "ess_clk";
                        switch_cpu_bmp = <0x01>;
                        switch_lan_bmp = <0x3a>;
                        switch_wan_bmp = <0x04>;
                        switch_mac_mode = <0x00>;
So i've added to my DTS these one and configured 02_network as suggested:
                        switch_lan_bmp = <0x3a>;
                        switch_wan_bmp = <0x04>;
But booting the image doesn't work. I see that at OS level eth0 is still LAN1/WAN and eth1 LAN, but no more traffic pass on these interfaces
Same problem also using your data.
Any suggestion?
Thx
According to the stock firmware (etc/init.d/zte_init.sh) they using vlan's to separate wan/lan and assigning the eth ports.

So if you are using the stock wan/lan switch BMP you would also need the same vlan config I guess.

Can you try that bitmask?
switch_lan_bmp = <0x20>;
switch_wan_bmp = <0x2>;

using that bitmask (same suggested by @Leo-PL), eth0\eth1 still the same on booted image but there is no more traffic passing..

kirdesde · 2022-09-29T05:47:14Z

@Leo-PL
I take a look at original DTS, switch is configured in this way:
                ess-switch@c000000 {
                        compatible = "qcom,ess-switch";
                        reg = <0xc000000 0x80000>;
                        switch_access_mode = "local bus";
                        resets = <0x02 0x1d 0x02 0x4e 0x02 0x4f 0x02 0x50 0x02 0x51 0x02 0x52>;
                        reset-names = "ess_rst\0ess_mac1_clk_dis\0ess_mac2_clk_dis\0ess_mac3_clk_dis\0ess_mac4_clk_dis\0ess_mac5_clk_dis";
                        clocks = <0x02 0x23>;
                        clock-names = "ess_clk";
                        switch_cpu_bmp = <0x01>;
                        switch_lan_bmp = <0x3a>;
                        switch_wan_bmp = <0x04>;
                        switch_mac_mode = <0x00>;
So i've added to my DTS these one and configured 02_network as suggested:
                        switch_lan_bmp = <0x3a>;
                        switch_wan_bmp = <0x04>;
But booting the image doesn't work. I see that at OS level eth0 is still LAN1/WAN and eth1 LAN, but no more traffic pass on these interfaces
Same problem also using your data.
Any suggestion?
Thx
According to the stock firmware (etc/init.d/zte_init.sh) they using vlan's to separate wan/lan and assigning the eth ports.
So if you are using the stock wan/lan switch BMP you would also need the same vlan config I guess.
Can you try that bitmask?
switch_lan_bmp = <0x20>;
switch_wan_bmp = <0x2>;
using that bitmask (same suggested by @Leo-PL), eth0\eth1 still the same on booted image but there is no more traffic passing..

Without a documentation of the possible bit-masks it's hard to tell which would be the correct one.

BTW with my mentioned DSA change the eth ports are in the right order (matching the silkscreen)

Leo-PL · 2022-10-03T17:35:41Z

@kirdesde the DSA conversion for ipq40xx finally landed. Could you post your conversion for MF289F somewhere, as it got disabled?
DSA conversion should also fix all port mapping woes by itself.

kirdesde · 2022-10-03T19:22:04Z

@kirdesde the DSA conversion for ipq40xx finally landed. Could you post your conversion for MF289F somewhere, as it got disabled? DSA conversion should also fix all port mapping woes by itself.

Yes I can create a PR later this week.

From bf3f255a17329e367c041b0e0b314408fd3c3093 Mon Sep 17 00:00:00 2001
From: Dirk Buchwalder <buchwalder@posteo.de>
Date: Sun, 25 Sep 2022 12:22:03 +0200
Subject: [PATCH] add dsa support

---
 .../ipq40xx/base-files/etc/board.d/02_network |  4 +--
 .../arch/arm/boot/dts/qcom-ipq4019-mf289f.dts | 32 +++++++++++--------
 2 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/target/linux/ipq40xx/base-files/etc/board.d/02_network b/target/linux/ipq40xx/base-files/etc/board.d/02_network
index 26842945b8..863829ae41 100644
--- a/target/linux/ipq40xx/base-files/etc/board.d/02_network
+++ b/target/linux/ipq40xx/base-files/etc/board.d/02_network
@@ -58,9 +58,7 @@ ipq40xx_setup_interfaces()
 		ucidef_set_interfaces_lan_wan "lan2 lan3 lan4" "wan"
 		;;
 	zte,mf289f)
-		ucidef_set_interfaces_lan_wan "eth0" "eth1"
-		ucidef_add_switch "switch0" \
-			"0u@eth0" "0u@eth1" "2:lan:1" "5:lan:2"
+		ucidef_set_interfaces_lan_wan "lan" "wan"
 		;;
 	*)
 		echo "Unsupported hardware. Network interfaces not initialized"
diff --git a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-mf289f.dts b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-mf289f.dts
index 820d175962..9d86fc3543 100644
--- a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-mf289f.dts
+++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-mf289f.dts
@@ -50,7 +50,7 @@
 			gpios = <&tlmm 61 GPIO_ACTIVE_LOW>;
 			linux,default-trigger = "phy0tpt";
 		};
-
+		
 	};
 
 	keys {
@@ -98,14 +98,6 @@
 			reg = <0x1957000 0x100>;
 			qcom,wifi_noc_memtype_m0_m2 = <TCSR_WIFI_NOC_MEMTYPE_M0_M2>;
 		};
-
-		ess-switch@c000000 {
-			status = "okay";
-		};
-
-		edma@c080000 {
-			status = "okay";
-		};
 	};
 };
 
@@ -317,20 +309,34 @@
 	status = "okay";
 };
 
-&gmac0 {
+&qpic_bam {
+	status = "okay";
+};
+
+&gmac {
+	status = "okay";
 	nvmem-cell-names = "mac-address";
 	nvmem-cells = <&macaddr_config_0>;
 };
 
-&gmac1 {
+&switch {
+	status = "okay";
+};
+
+&swport2 {
+	status = "okay";
+
+	label = "wan";
+
 	nvmem-cell-names = "mac-address";
 	nvmem-cells = <&macaddr_config_0>;
 	mac-address-increment = <1>;
 };
 
-
-&qpic_bam {
+&swport5 {
 	status = "okay";
+
+	label = "lan";
 };
 
 &tlmm {
-- 
2.37.2

Leo-PL · 2022-10-03T19:56:16Z

After quick look, LGTM. I think you can drop &ess_psgmii node as well, please see ZTE MF286D conversion.

stich86 · 2022-10-03T20:01:06Z

After quick look, LGTM. I think you can drop &ess_psgmii node as well, please see ZTE MF286D conversion.

So we will avoid swap on original switch?
Just to understand...

I'll open just a PR to fix led DTS

Thx!

kirdesde · 2022-10-03T20:05:34Z

After quick look, LGTM. I think you can drop &ess_psgmii node as well, please see ZTE MF286D conversion.

So we will avoid swap on original switch? Just to understand...

I'm not sure that you mean, with my DSA patch the LAN/WAN ports are matching the silk print on the case.

I'll open just a PR to fix led DTS

Thx!

stich86 · 2022-10-04T21:17:53Z

After quick look, LGTM. I think you can drop &ess_psgmii node as well, please see ZTE MF286D conversion.

So we will avoid swap on original switch? Just to understand...

I'm not sure that you mean, with my DSA patch the LAN/WAN ports are matching the silk print on the case.

I'll open just a PR to fix led DTS

Thx!

Yes I understand
What I mean is: now that DSA is official, fix "old" switch DTS LAN/WAN swap has sense?

@Leo-PL what do you think?

Leo-PL · 2022-10-04T22:10:54Z

@stich86 no need to bother, swconfig is gone, and good riddance. Converting the device to DSA with right mapping will take care of that. I believe patch from @kirdesde should do just that.

kirdesde · 2022-10-06T16:34:31Z

DSA-PR: #10908

hauke · 2022-10-09T21:35:34Z

The following changes were already merged:
0de6a33
579ea6b

Could you please rebase your change on top of current master if it still contains some changes which are missing in master.

stich86 · 2022-10-10T10:21:37Z

@hauke I think this can be close, device is now on master

i've openend new one #10936 that fix wrong GPIO for statis led

@Leo-PL @chunkeey @robimarko let me know if it's ok and can be merged :)

github-actions bot added core packages pull request/issue for core (in-tree) packages kernel pull request/issue with Linux kernel related changes target/ipq40xx pull request/issue for ipq40xx target labels Sep 14, 2022

This was referenced Sep 14, 2022

[DELETED] ipq40xx: Add ZTE MF289F #10708

Closed

[DELETED] ipq40xx: Add support for ZTE MF289F #10418

Closed