ramips: mt7621: Move common DNA EX400 defs to dtsi
Move common definitions for DNA Valokuitu Plus EX400 to a dtsi include. This is in preparation of adding the non-branded variant of the device produced by Genexis / Inteno in the next commit. The device with DNA branding differs in the LED labling on the device.
ramips: Add support for Genexis / Inteno Pulse EX400
Add support for Genexis Pulse EX400 / Inteno Pulse EX400. A branded variant for the Finnish ISP DNA has already been added in fea2264d9fdd (ramips: mt7621: Add DNA Valokuitu Plus EX400, 2023-07-31). This commit adds support for the generic variants with Inteno and Genexis branding. Inteno changed its name to Genexis and both brandings exist.
In terms of electronics, there is no difference between the DNA-branded version and other brandings. LED markings on the case are different, though. While the DNA-version has a "software-update" LED, the other versions have a WPS LED. To reduce user confusion, create a separate image.
Add the different device-tree with the different LED and rename things to work the same way for both variants.
Firmware: The vendor firmware is a fork of OpenWrt (Reboot) with a kernel version 4.4.93. The flash is arranged as below and there is a dual boot mechanism alternating between rootfs_0 and rootfs_1.
In OpenWrt rootfs_0 will be used as a boot partition that will contain the kernel and the dtb. The squashfs rootfs and overlay are standard OpenWrt behaviour.
U-boot: With proper serial access, booting can be halted to U-boot by pressing any key. TFTP and flash writes are available, but only the first one has been tested.
NOTE: Recovery mode can be accessed by holding down the reset button while powering on the device. The led 'Update' will show a solid green light once ready. A web server will be running at 192.168.1.1:80 and it will allow flashing a firmware package. You can cycle between rootfs_0 and rootfs_1 by pressing the reset button once.
Root password: With the vendor web UI create a backup of your settings and download the archive to your computer. Within the archive in the file /etc/shadow replace the password hash for root with that of a password you know. Restore the configuration with the vendor web UI and you will have changed the root password.
SSH access: You might need to enable the SSH service for LAN interface as by default it's enabled for WAN only.
Installing OpenWrt: With the vendor web UI, or from the U-Boot recovery UI, install the OpenWrt factory image. Alternatively, ssh to the device and use sysupgrade -n from cli.
Finalize by installing the OpenWrt sysupgrade image to get a fully functioning system.
Reverting to the vendor firmware:
Boot with OpenWrt initramfs image - Remove volumes rootfs_0, rootfs and rootfs_data and create vendor volumes.
local access. - Mitigations for INTEL-SA-01079 (CVE-2024-23918) Potential security vulnerabilities in some Intel Xeon processors using Intel SGX may allow escalation of privilege. Intel disclosed that some processor models were already fixed by a previous microcode update. - Updated mitigations for INTEL-SA-01097 (CVE-2024-24968) Improper finite state machines (FSMs) in hardware logic in some Intel Processors may allow an privileged user to potentially enable a denial of service via local access. - Mitigations for INTEL-SA-01103 (CVE-2024-23984) A potential security vulnerability in the Running Average Power Limit (RAPL) interface for some Intel Processors may allow information disclosure. Added mitigations for more processor models. * Updated Microcodes: sig 0x000806f8, pf_mask 0x87, 2024-06-20, rev 0x2b000603, size 588800 sig 0x000806f7, pf_mask 0x87, 2024-06-20, rev 0x2b000603 sig 0x000806f6, pf_mask 0x87, 2024-06-20, rev 0x2b000603 sig 0x000806f5, pf_mask 0x87, 2024-06-20, rev 0x2b000603 sig 0x000806f4, pf_mask 0x87, 2024-06-20, rev 0x2b000603 sig 0x00090672, pf_mask 0x07, 2024-05-29, rev 0x0037, size 224256 sig 0x00090675, pf_mask 0x07, 2024-05-29, rev 0x0037 sig 0x000b06f2, pf_mask 0x07, 2024-05-29, rev 0x0037 sig 0x000b06f5, pf_mask 0x07, 2024-05-29, rev 0x0037 sig 0x000906a3, pf_mask 0x80, 2024-06-03, rev 0x0435, size 223232 sig 0x000906a4, pf_mask 0x80, 2024-06-03, rev 0x0435 sig 0x000a06a4, pf_mask 0xe6, 2024-08-02, rev 0x0020, size 138240 sig 0x000b06a2, pf_mask 0xe0, 2024-05-29, rev 0x4123, size 220160 sig 0x000b06a3, pf_mask 0xe0, 2024-05-29, rev 0x4123 sig 0x000b06a8, pf_mask 0xe0, 2024-05-29, rev 0x4123 sig 0x000c06f2, pf_mask 0x87, 2024-06-20, rev 0x21000283, size 560128 sig 0x000c06f1, pf_mask 0x87, 2024-06-20, rev 0x21000283 * source: update symlinks to reflect id of the latest release, 20241112 * Update changelog for 3.20240910.1 and 3.20240813.1 with new information: INTEL-SA-1103 was addressed by 3.20240813.1 for some processor models, and not by 3.20240910. INTEL-SA-1079 was addressed by 3.20240910.1 for some processor models.
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 14 Nov 2024 15:37:40 -0300
* New upstream microcode datafile 20241029 - Not relevant for operating system microcode updates - Only when loaded from firmware, this update fixes the critical, potentially hardware-damaging errata RPL061: Incorrect Internal Voltage Request on Raptor Lake (Core 13th/14th gen) Intel processors. * Updated Microcodes: sig 0x000b0671, pf_mask 0x32, 2024-08-29, rev 0x012b, size 211968
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 14 Nov 2024 14:49:03 -0300
* New upstream microcode datafile 20240910 (closes: #1081363) - Mitigations for INTEL-SA-01097 (CVE-2024-24968) Improper finite state machines (FSMs) in hardware logic in some Intel Processors may allow an privileged user to potentially enable a denial of service via local access. - Fixes for unspecified functional issues on several processor models - The processor voltage limit issue on Core 13rd/14th gen REQUIRES A FIRMWARE UPDATE. It is present in this release for sig 0xb0671, but THE VOLTAGE ISSUE FIX ONLY WORKS WHEN THE MICROCODE UPDATE IS LOADED THROUGH THE FIT TABLE IN FIRMWARE. Contact your system vendor for a firmware update that includes the appropriate microcode update for your processor. * Updated Microcodes: sig 0x00090672, pf_mask 0x07, 2024-02-22, rev 0x0036, size 224256 sig 0x00090675, pf_mask 0x07, 2024-02-22, rev 0x0036 sig 0x000b06f2, pf_mask 0x07, 2024-02-22, rev 0x0036 sig 0x000b06f5, pf_mask 0x07, 2024-02-22, rev 0x0036 sig 0x000906a3, pf_mask 0x80, 2024-02-22, rev 0x0434, size 222208 sig 0x000906a4, pf_mask 0x80, 2024-02-22, rev 0x0434 sig 0x000a06a4, pf_mask 0xe6, 2024-06-17, rev 0x001f, size 137216 sig 0x000b0671, pf_mask 0x32, 2024-07-18, rev 0x0129, size 215040 sig 0x000b06a2, pf_mask 0xe0, 2024-02-22, rev 0x4122, size 220160 sig 0x000b06a3, pf_mask 0xe0, 2024-02-22, rev 0x4122 sig 0x000b06a8, pf_mask 0xe0, 2024-02-22, rev 0x4122 sig 0x000b06e0, pf_mask 0x19, 2024-03-25, rev 0x001a, size 138240 * Update changelog for 3.20240813.1 with new information * Update changelog for 3.20240514.1 with new information * source: update symlinks to reflect id of the latest release, 20240910
* New upstream microcode datafile 20240813 (closes: #1078742) - Mitigations for INTEL-SA-01083 (CVE-2024-24853) Incorrect behavior order in transition between executive monitor and SMI transfer monitor (STM) in some Intel Processors may allow a privileged user to potentially enable escalation of privilege via local access. - Mitigations for INTEL-SA-01118 (CVE-2024-25939) Mirrored regions with different values in 3rd Generation Intel Xeon Scalable Processors may allow a privileged user to potentially enable denial of service via local access. - Mitigations for INTEL-SA-01100 (CVE-2024-24980) Protection mechanism failure in some 3rd, 4th, and 5th Generation Intel Xeon Processors may allow a privileged user to potentially enable escalation of privilege via local access. - Mitigations for INTEL-SA-01038 (CVE-2023-42667) Improper isolation in the Intel Core Ultra Processor stream cache mechanism may allow an authenticated user to potentially enable escalation of privilege via local access. Intel disclosed that some processor models were already fixed by the previous microcode update. - Mitigations for INTEL-SA-01046 (CVE-2023-49141) Improper isolation in some Intel Processors stream cache mechanism may allow an authenticated user to potentially enable escalation of privilege via local access. Intel disclosed that some processor models were already fixed by the previous microcode update. - Mitigations for INTEL-SA-01079 (CVE-2024-23918) Potential security vulnerabilities in some Intel Xeon processors using Intel SGX may allow escalation of privilege. Intel released this information during the full disclosure for the 20241112 update. Processor signatures 0x606a6 and 0x606c1. - Mitigations for INTEL-SA-01103 (CVE-2024-23984) A potential security vulnerability in the Running Average Power Limit (RAPL) interface for some Intel Processors may allow information disclosure. Intel released this information during the full disclosure for the 20240910 update. Processor signatures 0x5065b, 0x606a6, 0x606c1. - Fix for unspecified functional issues on several processor models - Fix for errata TGL068/ADL075/ICL088/... "Processor may hang during a microcode update". It is not clear which processors were fixed by this release, or by one of the microcode updates from 2024-05. - Mitigations for INTEL-SA-01213 (CVE-2024-36293) Improper access control in the EDECCSSA user leaf function for some Intel Processors with Intel SGX may allow an authenticated user to potentially enable denial of service via local access. Intel released this information during the full disclosure for the 20250211 update. Processor signature 0x906ec (9th Generation Intel Core processor). * Updated microcodes: sig 0x00050657, pf_mask 0xbf, 2024-03-01, rev 0x5003707, size 39936 sig 0x0005065b, pf_mask 0xbf, 2024-04-01, rev 0x7002904, size 30720 sig 0x000606a6, pf_mask 0x87, 2024-04-01, rev 0xd0003e7, size 308224 sig 0x000606c1, pf_mask 0x10, 2024-04-03, rev 0x10002b0, size 300032 sig 0x000706e5, pf_mask 0x80, 2024-02-15, rev 0x00c6, size 114688 sig 0x000806c1, pf_mask 0x80, 2024-02-15, rev 0x00b8, size 112640 sig 0x000806c2, pf_mask 0xc2, 2024-02-15, rev 0x0038, size 99328 sig 0x000806d1, pf_mask 0xc2, 2024-02-15, rev 0x0052, size 104448 sig 0x000806e9, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 106496 sig 0x000806e9, pf_mask 0x10, 2024-02-01, rev 0x00f6, size 106496 sig 0x000806ea, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 105472 sig 0x000806eb, pf_mask 0xd0, 2024-02-01, rev 0x00f6, size 106496 sig 0x000806ec, pf_mask 0x94, 2024-02-05, rev 0x00fc, size 106496 sig 0x00090661, pf_mask 0x01, 2024-04-05, rev 0x001a, size 20480 sig 0x000906ea, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 105472 sig 0x000906eb, pf_mask 0x02, 2024-02-01, rev 0x00f6, size 106496 sig 0x000906ec, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 106496 sig 0x000906ed, pf_mask 0x22, 2024-02-05, rev 0x0100, size 106496 sig 0x000a0652, pf_mask 0x20, 2024-02-01, rev 0x00fc, size 97280 sig 0x000a0653, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 98304 sig 0x000a0655, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 97280 sig 0x000a0660, pf_mask 0x80, 2024-02-01, rev 0x00fe, size 97280 sig 0x000a0661, pf_mask 0x80, 2024-02-01, rev 0x00fc, size 97280 sig 0x000a0671, pf_mask 0x02, 2024-03-07, rev 0x0062, size 108544 sig 0x000a06a4, pf_mask 0xe6, 2024-04-15, rev 0x001e, size 137216 * source: update symlinks to reflect id of the latest release, 20240813 * postinst, postrm: switch to dpkg-trigger to run update-initramfs
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 15 Aug 2024 14:41:50 -0300
The code can be made more efficient by not extracting the sysupgrade.tar but rather just querying for the filesize within the archive. Resorting to manual update of UBI volume is extra work too, setting CI_KERNPART=rootfs_0 is enough.
Suggested-by: Andreas Gnau <andreas.gnau@iopsys.eu> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi> Link: https://github.com/openwrt/openwrt/pull/17806 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (commit: a53417c)
Rename 852-stable-bus-mhi-host-pci_generic-constify-modem_telit_fn980_.patch to 852-v6.9-stable-bus-mhi-host-pci_generic-constify-modem_telit_fn980.patch because it is used since kernel 6.9-rc1 (https://lore.kernel.org/lkml/Zfwv2y7P7BneKqMZ@kroah.com/).
rockchip: show boot stages on nanopi R6 system LED
Set up openwrt to show boot progress on the nanopi R6S or R6C system LED.
The LED blinking states indicate the boot stage. The LED is defined as a power LED, but can still be set to heartbeat in /etc/config/system after the system is done booting.
rockchip: set network IRQ affinity to fast CPU cores
The nanopi R6S, R6C and nanopc T6 platforms are based on rk3588(s) SoC, which has fast and slow CPU cores. Set up network interrupt affinity to be on the fast CPU cores by default. This is similar to the way this was already configured on nanopi R4S.
This allows the network interface naming to be stable, free from any possible interaction from external USB network devices that might claim usb* interface names.
(This was a real problem I encountered with a nanopi R6S device and an external rtl8152 usb3 network controller - the USB controller would claim the eth1 name, causing much confusion).
MAC Addresses: - There is one on the label, e.g. xx:xx:xx:xx:xx:A4 - LAN (bottom connector) is the same as the label, e.g. xx:xx:xx:xx:xx:A4 - WAN (top connector) is label + 1, e.g. xx:xx:xx:xx:xx:A5 - WLAN (2.4G) is the same as the label, e.g. xx:xx:xx:xx:xx:A4 - WLAN (5G) is label + 2, e.g. xx:xx:xx:xx:xx:A6
UART: - is available via the pin holes on the board - The pinout is printed to the board: P: VCC, G: GND, R: RX, T:TX - RX and TX require solder bridges to be installed - Do NOT connect VCC - Settings: 3.3V, 115200, 8N1
GPIO: - There are two LEDs: Red (GPIO 4) and White (GPIO 0) - There are two buttons: Reset (GPIO 11) and WPS (GPIO 5)
Migration to OpenWrt: - Download the migration image from the Cudy website (it should be available as soon as OpenWrt officially supports the device) - Connect computer to LAN (bottom connector) and flash the migration image via OEM web interface - OpenWrt is now accessible via 192.168.1.1
Revert back to OEM firmware: - Set up a TFTP server on IP 192.168.1.88 and connect to the WAN port (upper port) - Provide the Cudy firmware as recovery.bin in the TFTP server - Press the reset button while powering on the device - Recovery process is started now - When recovery process is done, OEM firmware is accessible via 192.168.10.1 again
General information: - No possibility to load a initramfs image via U-Boot because there is no option to interrupt U-Boot
uboot-mediatek: move custom uart config symbol to board defconfigs
This helps to solve the issue of waiting for "SERIAL_RX_BUFFER_SIZE" input when enabling verbose log output option (V=s).
Fixes: https://github.com/openwrt/openwrt/issues/18036 Signed-off-by: Shiji Yang <yangshiji66@qq.com> Link: https://github.com/openwrt/openwrt/pull/18043 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: 3d8d807)
Forum discussion : https://forum.openwrt.org/t/aps-256va-help-for-identification/143653/52
Specification: Power: 12-36V input via 5,5/2,1 DC barrel jack, or 5V Micro USB-B CPU: Atheros AR9344 rev 2 RAM: 128MB Flash: 16MB WI-Fi: 2.4GHz Fast Ethernet: 1 WAN and 2 LAN USB: 2 x USB-A, 1 x micro-USB-B (for power input) WWAN: 3G modem via extended mini-PCIE form factor (can be replaced with Wifi 5GHz card)
The device come with custom openwrt BB an CC.
Because of limited LAN port, I disable GMAC0, so the WAN port can be connected to GMAC1 and function as LAN port as well.
Enable ssh access and Backup:
1. open router admin page via LAN cable 2. browse 192.168.111.1:8000 3. login with password 123456 4. click wifi icon on top menu 5. change the path at the end of the url (after random hash) with /admin/system/flashops it will looks like this: http://192.168.111.1:8000/cgi-bin/luci/;stok=29698152cf64c980177a04f86c99ea0d/admin/system/flashops (the hash after "stok=" will be different) 6. restore the config with this modified backup (can be created manually by changing dropbear config to allow ssh) https://drive.google.com/file/d/1Vs-k7DHBSRZFfkxv1cMOmgAPZfB-RUen/view?usp=sharing 7. now you can login to ssh with root user and 123456 password, and backup all partition and upgrade firmware
!!! BACKUP EVERY PARTITION !!!
Flashing instructions: - Flash directly from factory web interface accessed from "Enable ssh access" step 5
Signed-off-by: Roy H <roy@altbytes.com> Link: https://github.com/openwrt/openwrt/pull/17939 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (commit: 3961b71)
The Zyxel LTE7490-M904 is an 802.3at PoE powered LTE outdoor (IP68) CPE with integrated directional antennas.
Specifications:
- SoC: MediaTek MT7621AT - RAM: 256 MB - Flash: 128 MB MB NAND (MX30LF1G18AC) - WiFi: MediaTek MT7603E 802.11b/g/n - Switch: 1 LAN port (1 Gbps) - LTE/3G/2G: Quectel EG18-EA LTE-A Cat. 18 connected by USB3 to SoC - SIM: 1 micro-SIM slots under transparent cover - Buttons: Reset, WLAN under same cover - LEDs: Multicolour green/red/amber under same cover (visible) - Power: 802.3at PoE via LAN port
The device is built as an outdoor ethernet to LTE bridge or router. The wifi interface is intended for installation and/or temporary management purposes only.
Remove the SIM/button/LED cover and 12 screws holding the back plate and antenna cover together. Be careful with the cables.
Installation from OEM web GUI:
- Log in as "admin" on OEM web GUI - Upload OpenWrt initramfs-recovery.bin image on the Maintenance -> Firmware page - Wait for OpenWrt to boot and ssh to root@192.168.1.1 - Sysupgrade to the OpenWrt sysupgrade image and reboot
For more details about flashing see: 2449a63208 (ramips: mt7621: Add support for ZyXEL NR7101, 2021-04-19)
Main porting work done by Ernesto Castellotti <ernesto@castellotti.net>: bf1c12f68b (ramips: add support for ZyXEL LTE7490-M904, 2023-12-20)
optee-os.mk: override default PATH to not use hostpkg python
In some cases hostpkg python from packages feed is used (hostpkg has higher priority in PATH) which causes build failure (cryptography module is missing). So override PATH to not use hostpkg python.
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com> Link: https://github.com/openwrt/openwrt/pull/18102 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (commit: 8c3a43b)
The next commit converts the firmware used by this driver to a package. Due to the fact that the driver is shipped as a package the firmware is already available.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Link: https://github.com/openwrt/openwrt/pull/17669 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (commit: 62bf028)
This has several advantages: * reduction in the size of the kernel and the complete image. Individual devices only need two of the four binaries. In combination with the second commit it reduces kernel size by 64.2 kB and image size by 22.8 kB, * the option to extend this package with firmware for future SoCs, * combining the kernel and binary blobs with another licence may not be fully compatible with the licence used by Linux. The current PHY firmware is built into the kernel. This comit converts it to a package.
Tested on AVM 5490 and BT Home Hub 5A.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Link: https://github.com/openwrt/openwrt/pull/17669 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (commit: a18d95f)
kernel: Activate CONFIG_NET_SWITCHDEV in generic config
The CONFIG_NET_SWITCHDEV option is needed by CONFIG_DSA and some other options. It is boolean, we have to compile it into the kernel it self. Activate it for all targets in the generic configuration, it is already activated for most of them. This allows to install DSA drivers as a module.
On the ramips/mt7620 target the kernel would grown by 4.5kB.
For some small targets which do not support a DSA switch by default the option is deactivated.
Adds latest 6.6 patches from the Raspberry Pi repository.
These patches were generated from: https://github.com/raspberrypi/linux/commits/rpi-6.6.y/ With the following command: git format-patch -N v6.6.83..HEAD (HEAD -> 08d4e8f52256bd422d8a1f876411603f627d0a82)
SoC: MediaTek MT7621 Flash: 16 MB SPI Flash RAM: 128 MB RAM Ethernet: 2x 1G RJ45 ports WLAN: 2.4GHz: MediaTek MT7603E 5GHz: MediaTek MT7613BE LEDs: Red and blue status lights Power: 12V DC UART: 3.3V, 115200 baud, 8N1, like printed on silkscreen (GND,TX,RX,3.3V)
MAC addresses ------------- +---------+-------------------+ | | MAC example | +---------+-------------------+ | LAN | 80:3F:5D:xx:xx:72 | | WAN | 80:3F:5D:xx:xx:73 | | WLAN 2g | 80:3F:5D:xx:xx:74 | | WLAN 5g | 80:3F:5D:xx:xx:75 | +---------+-------------------+
Installation:
The firmware can be flashed via the U-Boot recovery web interface. To access it, hold the reset button while powering on the device. U-Boot recovery web interface is then avaiable at 192.168.10.1.
Alternatively, the image can be loaded using the U-Boot serial interface and TFTP.
ath79: ZTE MF286A: use specific board definition file for qca9888
Using board definition file extracted from stock firmware yields 50% throughput improvement in RX direction under iperf3 test. Make the device use temporary files from firmware_qca-wireless.git temporarily, as well as select the specific variant in the device tree files.
ZTE MF286 is an indoor LTE category 12 CPE router with simultaneous dual-band 802.11ac plus 802.11n Wi-Fi radios and quad-port gigabit Ethernet switch, FXS and external USB 2.0 port.
Software-wise it's compatible with previous MF286A, save for different 5GHz Wi-Fi board definition file, requiring a separate image.
Hardware highlights: - CPU: QCA9563 SoC at 775MHz, - RAM: 128MB DDR2, - NOR Flash: MX25L1606E 2MB SPI Flash, for U-boot only, - NAND Flash: W25N01GV 128MB SPI NAND-Flash, for all other data, - Wi-Fi 5GHz: QCA9886 2x2 MIMO 802.11ac Wave2 radio, - WI-Fi 2.4GHz: QCA9563 3x3 MIMO 802.11n radio, - Switch: QCA8337v2 4-port gigabit Ethernet, with single SGMII CPU port, - WWAN: MDM9250-based category 12 internal LTE modem in extended mini-PCIE form factor, with 5 internal antennas and 2 external antenna connections, single mini-SIM slot. - FXS: one external ATA port (handled entirely by modem part) with two physical connections in parallel, - USB: Single external USB 2.0 port, - Switches: power switch, WPS, Wi-Fi and reset buttons, - LEDs: Wi-Fi, Test (internal). Rest of LEDs (Phone, WWAN, Battery, Signal state) handled entirely by modem. 4 link status LEDs handled by the switch on the backside. - Label MAC device: eth0
Internal modem of MF286C is supported via uqmi.
Console connection: connector X2 is the console port, with the following pinout, starting from pin 1, which is the topmost pin when the board is upright: - VCC (3.3V). Do not use unless you need to source power for the converer from it. - TX - RX - GND Default port configuration in U-boot as well as in stock firmware is 115200-8-N-1.
Installation: Due to different flash layout from stock firmware, sysupgrade from within stock firmware is impossible, despite it's based on QSDK which itself is based on OpenWrt.
STEP 0: Stock firmware update: As installing OpenWrt cuts you off from official firmware updates for the modem part, it is recommended to update the stock firmware to latest ath79: support ZTE MF286C
STEP 1: Booting initramfs image:
Method 1: using serial console (RECOMMENDED): - Have TFTP server running, exposing the OpenWrt initramfs image, and set your computer's IP address as 192.168.0.22. This is the default expected by U-boot. You may wish to change that, and alter later commands accordingly. - Connect the serial console if you haven't done so already, - Interrupt boot sequence by pressing any key in U-boot when prompted - Use the following commands to boot OpenWrt initramfs through TFTP:
(Replace server IP and router IP as needed). There is no emergency TFTP boot sequence triggered by buttons, contrary to MF283+. - When OpenWrt initramfs finishes booting, proceed to actual installation.
STEP 2: Backing up original software: As the stock firmware may be customized by the carrier and is not officially available in the Internet, IT IS IMPERATIVE to back up the stock firmware, if you ever plan to returning to stock firmware. It is highly recommended to perform backup using both methods, to avoid hassle of reassembling firmware images in future, if a restore is needed.
Method 1: after booting OpenWrt initramfs image via TFTP: - Connect your USB-UART adapter - Dump stock firmware located on stock kernel and ubi partitions:
And keep them in a safe place, should a restore be needed in future.
Method 2: using stock firmware: - Connect an external USB drive formatted with FAT or ext4 to the USB port. - The drive will be auto-mounted to /var/usb_disk - Check the flash layout of the device:
Differences might indicate that this is NOT a MF286C device but one of other variants. - Copy over all MTD partitions, for example by executing the following:
for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do cat /dev/mtd$i > \ /var/usb_disk/mtd$i; done
"Firmware" partition can be skipped, it is a concatenation of "kernel" and "rootfs".
- If the count of MTD partitions is different, this might indicate that this is not a MF286C device, but one of its other variants. - (optionally) rename the files according to MTD partition names from /proc/mtd - Unmount the filesystem:
umount /var/usb_disk; sync
and then remove the drive. - Store the files in safe place if you ever plan to return to stock firmware. This is especially important, because stock firmware for this device is not available officially, and is usually customized by the mobile providers.
STEP 3: Actual installation: - Set your computer IP to 192.168.1.22/24 - scp the sysupgrade image to the device:
STEP 4: WAN connection establishment Since the router is equipped with LTE modem as its main WAN interface, it might be useful to connect to the Internet right away after installation. To do so, please put the following entries in /etc/config/network, replacing the specific configuration entries with one needed for your ISP:
config interface 'wan' option proto 'qmi' option device '/dev/cdc-wdm0' option auth '<auth>' # As required, usually 'none' option pincode '<pin>' # If required by SIM option apn '<apn>' # As required by ISP option pdptype '<pdp>' # Typically 'ipv4', or 'ipv4v6' or 'ipv6'
For example, the following works for most polish ISPs config interface 'wan' option proto 'qmi' option device '/dev/cdc-wdm0' option auth 'none' option apn 'internet' option pdptype 'ipv4'
The required minimum is: config interface 'wan' option proto 'qmi' option device '/dev/cdc-wdm0' In this case, the modem will use last configured APN from stock firmware - this should work out of the box, unless your SIM requires PIN which can't be switched off.
If you have build with LuCI, installing luci-proto-qmi helps with this task.
Restoring the stock firmware:
- Boot to initramfs as in step 3: - Completely detach ubi0 partition using ubidetach /dev/ubi0_0 - Copy over the stock kernel image using scp to /tmp - Erase kernel and restore stock kernel: (scp mtd4_kernel.bin root@192.168.1.1:/tmp/) mtd write kernel /tmp/mtd4_kernel.bin rm /tmp/mtd4_kernel.bin - Copy over the stock partition backups one-by-one using scp to /tmp, and restore them individually. Otherwise you might run out of space in tmpfs:
- If the write was correct, force a device reboot with
reboot -f
Quirks and known issues - It was observed, that CH340-based USB-UART converters output garbage during U-boot phase of system boot. At least CP2102 is known to work properly. - Kernel partition size is increased to 4MB compared to stock 3MB, to accomodate future kernel updates - at this moment OpenWrt 5.10 kernel image is at 2.5MB which is dangerously close to the limit. This has no effect on booting the system - but keep that in mind when reassembling an image to restore stock firmware. - uqmi seems to be unable to change APN manually, so please use the one you used before in stock firmware first. If you need to change it, please use protocok '3g' to establish connection once, or use the following command to change APN (and optionally IP type) manually: echo -ne 'AT+CGDCONT=1,"IP","<apn>' > /dev/ttyUSB0 - The only usable LED as a "system LED" is the blue debug LED hidden inside the case. All other LEDs are controlled by modem, on which the router part has some influence only on Wi-Fi LED. - GPIO5 used for modem reset is a suicide switch, causing a hardware reset of whole board, not only the modem. It is attached to gpio-restart driver, to restart the modem on reboot as well, to ensure QMI connectivity after reboot, which tends to fail otherwise. - Modem, as in MF283+, exposes root shell over ADB - while not needed for OpenWrt operation at all - have fun lurking around. The same modem module is used as in older MF286.
ath79: ZTE MF281: use specific board definition file for qca9888
Using board definition file extracted from stock firmware yields 50% throughput improvement in RX direction under iperf3 test. Make the device use temporary files from firmware_qca-wireless.git temporarily, as well as select the specific variant in the device tree files. The device uses same board file as the MF286C.
kernel: modules: reorder i40e, mlx4, and mlx5 load priorities
Sets the boot flag for the i40e network device driver to load it at a more early stage of the boot process.
With commit 0a47d518df0d758e8d3b31264cb0428d57c362c3, I added a boot priority for the mlx4 and mlx5 drivers.
Also, increase those priorities because I think they are too low since there is currently no "room" for built-in network device drivers. That can cause interface order, i.e., name inconsistencies, when Mellanox ConnectX cards are inserted or removed.
Signed-off-by: Til Kaiser <mail@tk154.de> Link: https://github.com/openwrt/openwrt/pull/17990 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (commit: ad106a3)
This adds a default network configuration for the Supermicro SuperServer SYS-E302-9D by adding all onboard network ports to the default `lan` interface.
The network ports `eth0` till `eth3` use the `igb` driver, whereas `eth4` till `eth7` use `i40e`.
Like #15865, it seems that gmac0 does not rename eth0 to dsa until after the switch ports are initialized, leading to a name collision (error -17 = EEXIST).
This patch follows #17062 by using openwrt,netdev-name to fix the collision.
Signed-off-by: J. S. Seldenthuis <jseldenthuis@lely.com> Link: https://github.com/openwrt/openwrt/pull/18082 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (commit: 4fed462)
Apparently U-Boot will discard whole node if requested pin function is unknown to the driver. This resulted in inability to interact with U-Boot on the said board, as U-Boot always assumed the recovery key pressed and issued recovery procedure. Log snippet:
Recovery procedure also booted recovery image, which didn't affect much the 23.05.x release, since the root fs argument was valid, so changes persisted. But as 24.10.x hit with fitblk, the board will boot only recovery image (initramfs) because of default bootargs will reset on each boot and U-Boot provided bootargs took precedence.
Fixes: 42eeb22450f2 ("uboot-mediatek: fix factory/reset button") Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com> Link: https://patchwork.ozlabs.org/project/openwrt/patch/20250304164507.60511-1-tmn505@terefe.re/ Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (commit: f8a2e1c)
With upstream changes hitting kernel 6.4 the dtb for u7623 ends up with both mac (gmac) disabled, since this is now the default status in mt7623.dtsi. Fix this by including mt7623a.dtsi (which already has all necessary bits) and enabling all revlevant ports. This will also do a side hustle of assigning proper clocks for power controller and specifying proper power domain for few devices.
Link: https://lore.kernel.org/all/20230210182505.24597-1-arinc.unal@arinc9.com Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com> Link: https://patchwork.ozlabs.org/project/openwrt/patch/20250304164507.60511-2-tmn505@terefe.re/ Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (commit: adc4d95)
![[Jenkins]](/jenkins/static/87a4db1b/images/svgs/logo.svg){kind=logo}
