This commit adds support for netis N6 WiFi 6 router.
Specification
-------------
- SoC : MediaTek MT7621AT, MIPS, 880 MHz
- RAM : 256 MiB
- Flash : NAND 128 MiB (ESMT PSU1GA30DT)
- WLAN : MT7905DAN + MT7975DN
- 2.4 GHz : b/g/n/ax, 574 Mbps, MIMO 2x2
- 5 GHz : a/n/ac/ax, 1201 Mbps, MIMO 2x2
- Ethernet : 10/100/1000 Mbps x5 (1x WAN, 4x LAN)
- USB : 1x 3.0
- UART : 3.3V, 115200n8
- Buttons : 1x Reset
1x WPS
- LEDs : 1x Power (green)
1x System (green)
1x WAN (green)
1x WiFi 2.4 GHz (green), controlled by phy
1x WiFi 5 GHz (green), controlled by phy
1x WPS (green)
1x USB (green)
5x ethernet leds (green), controlled by switch
- Power : 12 VDC, 1.5 A
Installation
------------
1. Update the router using stock firmware web interface and OpenWrt
factory.bin image.
Recovery and return to stock
----------------------------
1. Assign your PC a static IP 192.168.1.2 and connect to the router using
the ethernet cable;
2. Power off the router;
3. Press Reset button, power on the router and wait until ethernet led
start blinking;
4. Release the button;
5. Open http://192.168.1.1/ (N6 System Recovery Mode) in your browser;
6. Upload OpenWrt factory.bin (or stock firmware *.bin) image and proceed
with upgrade.
MAC addresses
-------------
+---------+-------------------+
| | MAC example |
+---------+-------------------+
| LAN | dc:xx:xx:49:xx:04 |
| WAN | dc:xx:xx:49:xx:05 |
| WLAN 2g | dc:xx:xx:19:xx:06 |
| WLAN 5g | dc:xx:xx:79:xx:06 |
+---------+-------------------+
The WLAN MAC prototype was found in 'Factory', 0x4
The LAN MAC was found in 'Factory', 0x7ef20
The WAN MAC was found in 'Factory', 0x7ef26
Known issue
-----------
2.4 GHz WLAN doesn't start with mt76 driver.
Probable reason:
Original Netis N6 EEPROM contains wrong MT_EE_WIFI_CONF value (0xd2).
Other routers with the same WLAN hardware (e.g., Routerich AX1800)
have MT_EE_WIFI_CONF = 0x92.
Workaround (already included in this commit):
Extract EEPROM to a file at the first time boot and change
MT_EE_WIFI_CONF (offset 0x190) value from 0xd2 to 0x92. See
/etc/hotplug.d/firmware/11-mt76-caldata for details.
Signed-off-by: Mikhail Zhilkin <csharper2005@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16322
(cherry picked from commit f368e2d5ec)
[ Fix merging onflicts in mt7621.mk, 10_fix_wifi_mac, platform.sh ]
[ Change ðphy4 -> &mdio in dts file ]
Signed-off-by: Mikhail Zhilkin <csharper2005@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16436
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
...conversion.
Commit 20736013e9 ("kernel: backport nvmem v6.6 fixes and v6.7 changes")
has caused dthe device to no longer correctly read MAC address from its
onboard 24c64 EEPROM, because "at24" driver doesn't support legacy
nvmem-cell bindings [1] - and there was an explicit config option added
to mandate that behaviour in the following patch:
820-v6.7-0002-nvmem-add-explicit-config-option-to-read-old-syntax-.patch
But some of the devices, MR33 and MR74 included, weren't converted with
that as well.
Convert the definition to use proper fixed-layout binding to fix it.
The offending change was introduced between v23.05.0 and v23.05.1, and
found by bisection:
git bisect start
# status: waiting for both good and bad commits
# good: [bd4f415efa] OpenWrt v23.05.0: adjust config defaults
git bisect good bd4f415efa
# status: waiting for bad commit, 1 good commit known
# bad: [a58a86693f] OpenWrt v23.05.1: adjust config defaults
git bisect bad a58a86693f
# good: [3d0a78add2] qualcommax: only build initramfs if CONFIG_TARGET_ROOTFS_INITRAMFS is set
git bisect good 3d0a78add2
# bad: [21e5db97c4] build: add CycloneDX SBOM JSON support
git bisect bad 21e5db97c4
# good: [89184b15cf] mediatek: add build for MT7981 RFB
git bisect good 89184b15cf
# bad: [41f27bbb6d] bcm53xx: add the latest fix version of brcm_nvram
git bisect bad 41f27bbb6d
# good: [b649b0bf71] kernel: nvmem: fix "fixed-layout" & support "mac-base"
git bisect good b649b0bf71
# bad: [20736013e9] kernel: backport nvmem v6.6 fixes and v6.7 changes
git bisect bad 20736013e9
# good: [066971615f] kernel: backport v6.6 nvmem changes
git bisect good 066971615f
# first bad commit: [20736013e9] kernel: backport nvmem v6.6 fixes and v6.7 changes
Link: [1] https://github.com/openwrt/openwrt/issues/15393#issuecomment-2212300849
Fixes: 20736013e9 ("kernel: backport nvmem v6.6 fixes and v6.7 changes")
Fixes: https://github.com/openwrt/openwrt/issues/15393
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
(cherry picked from commit ccbffad1ad0ce444bc2497098a1d3d3a086a5f44)
[replace mac-address-increment with #nvmem-cell-cells]
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16624
Signed-off-by: Robert Marko <robimarko@gmail.com>
er is missing from platform_copy_config() and octeon_move_config(), so
config is lost on every sysupgrade.
(cherry-picked from commit 77037b09f3)
Signed-off-by: Jakob Haufe <sur5r@sur5r.net>
Link: https://github.com/openwrt/openwrt/pull/16518
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The MAC address of the GMAC is contained inside the CWMP-Account
number on the label.
The label MAC address alias was defined previously, but it has been
removed with the switch to IPQESS / DSA.
Restore the label MAC address alias.
Fixes: 27b441cbaf ("ipq40xx: drop ESSEDMA + AR40xx DTS nodes")
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Reviewed-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit b22d382ae4)
Signed-off-by: Tom Herbers <mail@tomherbers.de>
Link: https://github.com/openwrt/openwrt/pull/16459
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
With commit a22d359fa5 VLAN handling was fixed for kernel 6.6.
This restored network connectivity of the devices. For easy testing
backport the fix for 5.15 too.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/16391
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 35e13244aa)
Signed-off-by: Goetz Goerisch <ggoerisch@gmail.com>
The sysupgrade-tar image build is not defined for this target, do not
add a build instruction for it. The build system will use the definition
from the dna_valokuitu-plus-ex400 board and the build will fail.
This fixes the build of the ramips target.
Fixes: 665c2154ef ("ramips: add basic support for tp-link er605-v2")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 746e894877)
Add the GPIO pin of the PoE passthrough switch on the Aruba AP-303H.
Power is activated when the pin is low. It enables a PSE chip, so power
is only supplied to downstream devices when they are 802.3af/at
compliant devices.
Ensure you use a sufficient power supply when chaining a consuming
device after the AP.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit b40cc46cc8)
configure 2.5G PHY LEDs to:
2500/1000: green with blink on TX/RX
100/10: green+yellow with blink on TX/RX
which is similar to other 1G PHY LEDs, which are:
1000: green with blink on TX/RX
100/10: green+yellow with blink on TX/RX
Fixes: 6cc14bf66a ("filogic: support Telenor branded ZyXEL EX5700")
Signed-off-by: Yan Cangang <nalanzeyu@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16082
(cherry picked from commit 3de653a0af)
Link: https://github.com/openwrt/openwrt/pull/16390
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Ubiquiti has a set of UniFi 802.11ax (Wi-Fi 6) AP devices. All models
include "U6" in their names and also have code names with no special
characters (including spaces).
Examples:
1. U6 Lite (codename U6-Lite)
2. U6 Long-Range (codename U6-LR)
3. U6+ (codename U6-PLUS)
4. U6 Pro (codename U6-Pro)
5. U6 Mesh (codename U6-Mesh)
6. U6 Mesh Pro (codename U6-Mesh-Pro)
7. U6 Enterprise (codename U6-Enterprise)
Use proper full names for those devices. Names in OpenWrt/DTS code may
need updating too but it can be handled later.
Cc: Elbert Mai <code@elbertmai.com>
Cc: Daniel Golle <daniel@makrotopia.org>
Cc: Henrik Riomar <henrik.riomar@gmail.com>
Cc: David Bauer <mail@david-bauer.net>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 74879140a1)
Aruba boards now ship with multiple DTS and image-configurations per
image. Newer apboot revs expect a configuration for their hardware to be
present.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit c7ba5574f5)
Some devices lock up on PCIe initialization:
[ 64.309697] PCIe: Port 0 in endpoint mode, skipping.
[ 64.320496] PCIe: Initializing port 1
[ 64.325257] PCIe: BIST FAILED for port 1 (0xffffffffffffffff)
(system hangs here)
Given the ER contains no PCIe peripherals, has no way to attach any
and the stock kernel doesn't have PCIe support either, just disable it.
(cherry picked from commit 308630aea6)
Signed-off-by: Jakob Haufe <sur5r@sur5r.net>
Link: https://github.com/openwrt/openwrt/pull/16223
Signed-off-by: Robert Marko <robimarko@gmail.com>
Sometimes the mmc deivce may come up later than kernel attempts to
mount rootfs, resulting kernel panic. Enable rootwait to fix it.
Reported-by: Yangyu Chen <cyy@cyyself.name>
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Link: https://github.com/openwrt/openwrt/pull/15077
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
According to RTL8221B's datasheet, the PHY requires at least 10ms
for assert and 68ms (recommended) for de-assert. So increase the
assert/de-assert time to 15ms and 68ms respectively.
Fixes: c0c3234e17 ("mediatek: add support for JDCloud RE-CP-03")
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Link: https://github.com/openwrt/openwrt/pull/16106
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit d1954aa535)
The vendor U-Boot on the Cudy M3000 and the Yuncore AX835 assign random
mac addresses on boot and set the 'local-mac-address' property which
prevents Openwrt from assigning the correct address from evmem.
This patch removes the alias for ethernet0 so that U-Boot doesn't add the
property, removes the workaround from 02_network, and adds back the nvmem
definition for the M3000.
Signed-off-by: Leon M. Busch-George <leon@georgemail.eu>
(cherry picked from commit a55ab9e134)
Hardware:
SoC: MT7981b
RAM: 256 MB
Flash: 128 MB SPI NAND
Ethernet:
1x 2.5Gbps (rtl8221b)
1x 1Gbps (integrated phy)
WiFi: 2x2 MT7981
Buttons: Reset, WPS
LED: 1x multicolor
Solder on UART:
- remove rubber ring on the bottom
- remove screws
- pull up the cylinder, maybe help by push on an ethernet socket with a screwdriver
- remove the (3) screws holding the board in the frame
- remove the board from the frame to get to the screws for the silver, flat heat shield
- remove the (3) screws holding the heat shield
- solder UART pins to the back of the board
- make sure to have the pins point out on side with the black, finned heat spread
- the markings for the pins are going to be below the silver heat shield
- Vcc is not needed
If you don't intend on using the UART outside of the installation process, you might not
want to solder:
- carefully scrape off the thin layer of epoxy on the holes (not the copper)
- place your pin header with the UART attached in the holes
- the pins, starting with the one closest to the socket:
- Vcc (not required)
- GND
- RX
- TX
- either wedge the header or hold it with your fingers so that the pins stay in contact with the board
Installation (UART):
- attach an Ethernet cable to the 1Gbps port (black) on the router
- hold the reset button while powering the router
- press CTRL-C or wait for the timeout to get to the U-Boot prompt
- prepare a TFTP server on the network to supply ..-initramfs-kernel.bin
- use 'tftpboot' in the U-Boot shell to pull the image
- boot the image using 'bootm'
- push the ..-sysupgrade to the router using your preferred method
- perform the upgrade with 'sysupgrade -n'
There is a recovery mechanism that involves fetching a file called 'recovery.bin' but that is not understood yet.
Signed-off-by: Leon M. Busch-George <leon@georgemail.eu>
(cherry picked from commit 20e4a18feb)
The MAC address assigned to lan/wan was reversed.
Fixes: 6e51ff88b0 ("mediatek: add support for JDCloud RE-CP-03")
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
With upstream accepted "mac-base" binding there is no need for a
downstream "mac-address-ascii" workaround anymore.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit daaa0c1b25)
Link: https://github.com/openwrt/openwrt/pull/15917
In the past few years, we have received several reports about SPI
Flash not working properly. This is caused by excessively fast
clock frequency. It's really annoying to fix them one by one. Let's
reduce these aggressive frequencies to 50 MHz. This is a safe and
suggested value in the vendor SDK.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
(cherry picked from commit 73eeac49be)
Link: https://github.com/openwrt/openwrt/pull/15919
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The WLAN + WED reset sequence relies on being able to receive interrupts from
the card, in order to synchronize individual steps with the firmware.
When WED is stopped, leave interrupts running and rely on the driver turning
off unwanted ones.
WED DMA also needs to be disabled before resetting.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry picked from commit 2c5b3bee38)
Add patch implementing operations to get and set flow-control link
parameters of mtk_eth_soc via ethtool.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cherry picked from commit 4a2f712f85)
Import patch accepted upstream.
Initial import:
- net: ethernet: mtk_ppe: Change PPE entries number to 16K
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cherry picked from commit 27b6838afa)
In preparation to update mtk_eth_soc move accepted patches from mediatek
target to backport folder, so other patches on top can be applied more
easily.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cherry picked from commit 8730f9e536)
Specifications:
- Device: Edimax BR-6208AC V2
- SoC: MT7620A
- Flash: 16 MiB
- RAM: 64 MiB
- Switch: 1 WAN, 3 LAN (10/100 Mbps)
- WiFi: MT7620 2.4 GHz + MT7610E 5 GHz
- LEDs: 1x POWER (green, not configurable)
1x Firmware (green, configurable)
1x Internet (green, configurable)
1x VPN (green, configurable)
1x 2.4G (green, not configurable)
1x 5G (green, not configurable)
Normal installation:
- Upload the sysupgrade image via the default web interface
Installation with U-Boot and TFTP:
- Requires a TFTP server which provides the sysupgrade image
- Requires a connection to the serial port of the device, rate 57600
Signed-off-by: Stefan Weil <sw@weilnetz.de>
(cherry picked from commit 8d06bc1751)
Netgear EAX12, EAX11v2, EAX15v2 are wall-plug 802.11ax (Wi-Fi 6)
extenders that share the SoC, WiFi chip, and image format with the
WAX202.
Specifications:
* MT7621, 256 MiB RAM, 128 MiB NAND
* MT7915: 2.4/5 GHz 2x2 802.11ax (DBDC)
* Ethernet: 1 port 10/100/1000
* UART: 115200 baud (labeled on board)
All LEDs and buttons appear to work without state_default.
Installation:
* Flash the factory image through the stock web interface, or TFTP to
the bootloader. NMRP can be used to TFTP without opening the case.
Revert to stock firmware:
* Flash the stock firmware to the bootloader using TFTP/NMRP.
References in GPL source:
https://www.downloads.netgear.com/files/GPL/EAX12_EAX11v2_EAX15v2_GPL_V1.0.3.34_src.tar.gz
* target/linux/ramips/dts/mt7621-rfb-ax-nand.dts
DTS file for this device.
Signed-off-by: Wenli Looi <wlooi@ucalgary.ca>
(cherry picked from commit 32ea8a9a7e)
The PHY of the wan2 port on MQmaker WiTi is wired to the second MAC of the
SoC. Rename the wan interface to wan1 and define it under the switch node,
effectively disabling the PHY muxing of the MT7530 switch's phy4.
Define the PHY of the wan2 port and adjust the gmac1 node accordingly. Now
that the PHY muxing feature is not being used anymore, the wan2 port can be
used to achieve 2 Gbps total bandwidth to the CPU.
Tested-by: Demetris Ierokipides <ierokipides.dem@gmail.com>
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
(cherry picked from commit 8bf9a8a5e6)
General specification:
SoC Type: MediaTek MT7620A (580MHz)
ROM: 8 MB SPI-NOR (MX25L6406E)
RAM: 64 MB DDR (W9751G6KB-25)
Switch: MediaTek MT7530
Ethernet: 5 ports - 5×100MbE (WAN, LAN1-4)
Wireless: 2.4 GHz (MediaTek RT5390): b/g/n
Wireless: 5 GHz (MediaTek MT7610EN): ac/n
Buttons: 2 button (POWER, WPS/RESET)
Bootloader: U-Boot 1.1.3
Power: 12 VDC, 0.5 A
MACs:
| LAN | [Factory + 0x04] - 2 |
| WLAN 2.4g | [Factory + 0x04] - 1 |
| WLAN 5g | [Factory + 0x8004] - 3 |
| WAN | [Factory + 0x04] - 2 |
OEM easy installation:
1. Use a PC to browse to http://192.168.0.1.
2. Go to the System section and open the Firmware Update section.
3. Under the Local Update at the right, click on the CHOOSE FILE...
4. When a modal window appears, choose the firmware file and click on
the Open.
5. Next click on the UPDATE FIRMWARE button and upload the firmware image.
Wait for the router to flash and reboot.
OEM installation using the TFTP method (need level converter):
1. Download the latest firmware image.
2. Set up a Tftp server on a PC (e.g. Tftpd32) and place the firmware
image to the root directory of the server.
3. Power off the router and use a twisted pair cable to connect the PC
to any of the router's LAN ports.
4. Configure the network adapter of the PC to use IP address 192.168.0.180
and subnet mask 255.255.255.0.
5. Connect serial port (57600 8N1) and turn on the router.
6. Then interrupt "U-Boot Boot Menu" by hitting 2 key (select "2: Load
system code then write to Flash via TFTP.").
7. Press Y key when show "Warning!! Erase Linux in Flash then burn new
one. Are you sure? (Y/N)"
Input device IP (192.168.0.1) ==:192.168.0.1
Input server IP (192.168.0.180) ==:192.168.0.180
Input Linux Kernel filename () ==:firmware_name
The router should download the firmware via TFTP and complete flashing in
a few minutes.
After flashing is complete, use the PC to browse to http://192.168.1.1 or
ssh to proceed with the configuration.
Signed-off-by: Alexey Bartenev <41exey@proton.me>
(cherry picked from commit ce998cb6e1)
Specification:
- MT7981 CPU using 2.4GHz and 5GHz WiFi (both AX)
- MT7531 switch
- 512MB RAM
- 128MB NAND flash with two UBI partitions with identical size
- 1 multi color LED (red, green, blue, white) connected via GCA230718
- 3 buttons (WPS, reset, LED on/off)
- 1 1Gbit WAN port
- 4 1Gbit LAN ports
Disassembly:
- There are four screws at the bottom: 2 under the rubber feets, 2 under the label.
- After removing the screws, the white plastic part can be shifted out of the blue part.
- Be careful because the antennas are mounted on the side and the top of the white part.
Serial Interface
- The serial interface can be connected to the 4 pin holes on the side of the board.
- Pins (from front to rear):
- 3.3V
- RX
- TX
- GND
- Settings: 115200, 8N1
MAC addresses:
- WAN MAC is stored in partition "Odm" at offset 0x81
- LAN (as printed on the device) is WAN MAC + 1
- WLAN MAC (2.4 GHz) is WAN MAC + 2
- WLAN MAC (5GHz) is WAN MAC + 3
Flashing via Recovery Web Interface:
- The recovery web interface always flashes to the currently active partition.
- If OpenWrt is flahsed to the second partition, it will not boot.
- Ensure that you have an OEM image available (encrypted and decrypted version). Decryption is described in the end.
- Set your IP address to 192.168.200.10, subnetmask 255.255.255.0
- Press the reset button while powering on the device
- Keep the reset button pressed until the LED blinks red
- Open a Chromium based and goto http://192.168.200.1 (recovery web interface)
- Download openwrt-mediatek-filogic-dlink_aquila-pro-ai-m30-a1-squashfs-recovery.bin
- The recovery web interface always reports successful flashing, even if it fails
- After flashing, the recovery web interface will try to forward the browser to 192.168.0.1 (can be ignored)
- If OpenWrt was flashed to the first partition, OpenWrt will boot (The status LED will start blinking white and stay white in the end). In this case you're done and can use OpenWrt.
- If OpenWrt was flashed to the second partition, OpenWrt won't boot (The status LED will stay red forever). In this case, the following steps are reuqired:
- Start the web recovery interface again and flash the **decrypted OEM image**. This will be flashed to the second partition as well. The OEM firmware web interface is afterwards accessible via http://192.168.200.1.
- Now flash the **encrypted OEM image** via OEM firmware web interface. In this case, the new firmware is flashed to the first partition. After flashing and the following reboot, the OEM firmware web interface should still be accessible via http://192.168.200.1.
- Start the web recovery interface again and flash the OpenWrt recovery image. Now it will be flashed to the first partition, OpenWrt will boot correctly afterwards and is accessible via 192.168.1.1.
Flashing via U-Boot:
- Open the case, connect to the UART console
- Set your IP address to 192.168.200.2, subnet mask 255.255.255.0. Connect to one of the LAN interfaces of the router
- Run a tftp server which provides openwrt-mediatek-filogic-dlink_aquila-pro-ai-m30-a1-initramfs-kernel.bin.
- Power on the device and select "7. Load image" in the U-Boot menu
- Enter image file, tftp server IP and device IP (if they differ from the default).
- TFTP download to RAM will start. After a few seconds OpenWrt initramfs should start
- The initramfs is accessible via 192.168.1.1, change your IP address accordingly (or use multiple IP addresses on your interface)
- Perform a sysupgrade using openwrt-mediatek-filogic-dlink_aquila-pro-ai-m30-a1-squashfs-sysupgrade.bin
- Reboot the device. OpenWrt should start from flash now
Revert back to stock using the Recovery Web Interface:
- Set your IP address to 192.168.200.2, subnetmask 255.255.255.0
- Press the reset button while powering on the device
- Keep the reset button pressed until the LED blinks red
- Open a Chromium based and goto http://192.168.200.1 (recovery web interface)
- Flash a decrypted firmware image from D-Link. Decrypting an firmware image is described below.
Decrypting a D-Link firmware image:
- Download https://github.com/RolandoMagico/firmware-utils/blob/M32/src/m32-firmware-util.c
- Compile a binary from the downloaded file, e.g. gcc m32-firmware-util.c -lcrypto -o m32-firmware-util
- Run ./m32-firmware-util M30 --DecryptFactoryImage <OriginalFirmware> <OutputFile>
- Example for firmware M30A1_FW101B05: ./m32-firmware-util M30 --DecryptFactoryImage M30A1_FW101B05\(0725091522\).bin M30A1_FW101B05\(0725091522\)_decrypted.bin
Flashing via OEM web interface is not possible, as it will change the active partition and OpenWrt is only running on the first UBI partition.
Controlling the LEDs:
- The LEDs are controlled by a chip called "GCA230718" which is connected to the main CPU via I2C (address 0x40)
- I didn't find any documentation or driver for it, so the information below is purely based on my investigations
- If there is already I driver for it, please tell me. Maybe I didn't search enough
- I implemented a kernel module (leds-gca230718) to access the LEDs via DTS
- The LED controller supports PWM for brightness control and ramp control for smooth blinking. This is not implemented in the driver
- The LED controller supports toggling (on -> off -> on -> off) where the brightness of the LEDs can be set individually for each on cycle
- Until now, only simple active/inactive control is implemented (like when the LEDs would have been connected via GPIO)
- Controlling the LEDs requires three sequences sent to the chip. Each sequence consists of
- A reset command (0x81 0xE4) written to register 0x00
- A control command (for example 0x0C 0x02 0x01 0x00 0x00 0x00 0xFF 0x01 0x00 0x00 0x00 0xFF 0x87 written to register 0x03)
- The reset command is always the same
- In the control command
- byte 0 is always the same
- byte 1 (0x02 in the example above) must be changed in every sequence: 0x02 -> 0x01 -> 0x03)
- byte 2 is set to 0x01 which disables toggling. 0x02 would be LED toggling without ramp control, 0x03 would be toggling with ramp control
- byte 3 to 6 define the brightness values for the LEDs (R,G,B,W) for the first on cycle when toggling
- byte 7 defines the toggling frequency (if toggling enabled)
- byte 8 to 11 define the brightness values for the LEDs (R,G,B,W) for the second on cycle when toggling
- byte 12 is constant 0x87
Comparison to M32/R32:
- The algorithms for decrypting the OEM firmware are the same for M30/M32/R32, only the keys differ
- The keys are available in the GPL sources for the M32
- The M32/R32 contained raw data in the firmware images (kernel, rootfs), the R30 uses a sysupgrade tar instead
- Creation of the recovery image is quite similar, only the header start string changes. So mostly takeover from M32/R32 for that.
- Turned out that the bytes at offset 0x0E and 0x0F in the recovery image header are the checksum over the data area
- This checksum was not checked in the recovery web interface of M32/R32 devices, but is now active in R30
- I adapted the recovery image creation to also calculate the checksum over the data area
- The recovery image header for M30 contains addresses which don't match the memory layout in the DTS. The same addresses are also present in the OEM images
- The recovery web interface either calculates the correct addresses from it or has it's own logic to determine where which information must be written
Signed-off-by: Roland Reinl <reinlroland+github@gmail.com>
(cherry picked from commit 29cca6cfee)
The recovery image is reqired for D-Link M30 as well. So I moved it to include/image-commands.mk to be able to use it for MT7622 and filogic devices.
Signed-off-by: Roland Reinl <reinlroland+github@gmail.com>
(cherry picked from commit 0e2b7e3bd6)
Rename network devices to their label set in DT without invocation of
a sub-shell.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cherry picked from commit 983222605c)
Implement the functionality of
target/linux/ramips/patches-5.15/700-net-ethernet-mediatek-support-net-labels.patch
in userspace, since the driver patch has been rejected as a generic solution:
https://github.com/openwrt/openwrt/pull/11435
Signed-off-by: Bjørn Mork <bjorn@mork.no>
(cherry picked from commit 1dd1ac2c35)
The option CONFIG_SND_DRIVERS is activated by default in the generic
configuration, do not deactivate it for tegra. This fixes the build of
the kmod-sound-dummy package on tegra.
(cherry picked from commit 21213c8156)
Link: https://github.com/openwrt/openwrt/pull/15898
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
