net: dsa: mt7530: explain exposing MDIO bus of MT7531AE better
net: dsa: mt7530: do not pass port variable to mt7531_rgmii_setup()
net: dsa: mt7530: use priv->ds->num_ports instead of MT7530_NUM_PORTS
net: dsa: mt7530: get rid of mac_port_validate member of mt753x_info
net: dsa: mt7530: refactor MT7530_PMEEECR_P()
net: dsa: mt7530: get rid of function sanity check
net: dsa: mt7530: define MAC speed capabilities per switch model
net: dsa: mt7530: return mt7530_setup_mdio & mt7531_setup_common on error
net: dsa: mt7530: move MT753X_MTRAP operations for MT7530
net: dsa: mt7530: refactor MT7530_HWTRAP and MT7530_MHWTRAP
net: dsa: mt7530: refactor MT7530_MFC and MT7531_CFC, add MT7531_QRY_FFP
net: dsa: mt7530: rename mt753x_bpdu_port_fw enum to mt753x_to_cpu_fw
net: dsa: mt7530: rename p5_intf_sel and use only for MT7530 switch
net: dsa: mt7530: refactor MT7530_PMCR_P()
net: dsa: mt7530: disable EEE abilities on failure on MT7531 and MT7988
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Import patches for the MT7530 DSA driver from net-next tree:
cae425cb43fe net: dsa: allow DSA switch drivers to provide their own phylink mac ops
dd0c9855b413 net: dsa: introduce dsa_phylink_to_port()
7c5e37d7ee78 net: dsa: mt7530: simplify core operations
868ff5f4944a net: dsa: mt7530-mdio: read PHY address of switch from device tree
2c606d138518 net: dsa: mt7530: fix port mirroring for MT7988 SoC switch
d59cf049c837 net: dsa: mt7530: fix mirroring frames received on local port
62d6d91db98a net: dsa: mt7530: provide own phylink MAC operations
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
For all boards currently working with the mt7530 DSA driver we can
be sure that the address of the switch on the MDIO bus is 31 --
simply because that address is hard-coded in the driver and the
address from the Device Tree is being ignore.
An upcoming patch will add support for MT753x ICs which are programmed
to addresses different from 0x1f using bootstrap pins. As a result the
address from the Device Tree will then be taken into account, which
will break currently working boards which got the address set to
anything else than 31.
While at it also unify the syntax in Device Tree to always us a decimal
value for the 'reg' property.
* mt7622-buffalo-wsr-3200ax4s.dts
Cosmetic change 'reg = <0x1f>' -> 'reg = <31>'
* mt7622-dlink-eagle-pro-ai-ax3200-a1.dtsi
Wrong address: 0 -> 31
* mt7622-elecom-wrc-x3200gst3.dts
Wrong address: 0 -> 31
* mt7622-linksys-e8450.dtsi
Wrong address: 0 -> 31
* mt7622-ruijie-rg-ew3200.dtsi
Wrong address: 0 -> 31
* mt7622-xiaomi-redmi-router-ax6s.dts
Wrong address: 0 -> 31
* mt7629-iptime-a6004mx.dts
Wrong address: 2 -> 31
* mt7981b-zbtlink-zbt-z8102ax.dts
Cosmetic change 'reg = <0x1f>' -> 'reg = <31>'
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The Upstream Linux community has discontinued support for the target.
Maintaining support for it downstream would require too much effort.
Moreover, it seems that the supported hardware is no longer deemed worthy
of it.
Signed-off-by: Nick Hainke <vincent@systemli.org>
Use 'mediatek,mt7988a' instead of 'mediatek,mt7988' as compatible
string to be in-sync with upstream and no longer break the cpufreq
driver which was also kept in sync with upstream.
Fixes: 56dd6b473b ("mediatek: sync cpufreq support with changed compatible string")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Kernel 6.6 checks for orphan sections and prints a warning about them,
which in turn will make CI fails as we have Werror enabled there.
Issue is that cache-v7-min.S produces .init.text section which is an
orphan section since it is not being handled by the vmlinux.lds.S linker
script.
So, lets put the generated .init.text section under .text.
Fixes: f0d8ce4f48 ("bcm53xx: add testing support for kernel 6.6")
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use ath11k_patch_mac and ath11k_set_macflag functions for RAX120v2 (pre-caldata does not contain valid MAC addresses)
Signed-off-by: Paweł Owoc <frut3k7@gmail.com>
Use ath11k_patch_mac, ath11k_remove_regdomain and ath11k_set_macflag functions for MX4200
(only v2 variant requires MAC patching)
Signed-off-by: Paweł Owoc <frut3k7@gmail.com>
Spectrum SAX1V1K is a AX WIFI router with 3 1G and 1 2.5G ports.
The router is provided to Spectrum customers.
It is OEM of Askey RT5010W
https://forum.openwrt.org/t/spectrum-sax1v1k-askey-rt5010w-openwrt-support/149923
It continues the original work by @MeisterLone to get this device supported.
Specifications:
```
• CPU: Qualcomm IPQ8072A Quad core Cortex-A53 2.2GHz
• RAM: 2048MB of DDR3
• Storage: 1024MB eMMC
• Ethernet: 3x 1G RJ45 ports (QCA8075) + 1 2.5G Port (QCA8081)
• WLAN:
• 2.4GHz: Qualcomm QCN5024 4x4 802.11b/g/n/ax 1174 Mbps PHY rate
• 5GHz: Qualcomm QCN5054 4x4 802.11a/b/g/n/ac/ax 2402 PHY rate
• LED: 1 gpio-controlled dual color led (blue/red)
• Buttons: 1x reset
• Power: 12V DC jack
```
Notes:
```
• This commit adds only single partition support, that means
sysupgrade is upgrading the current rootfs partition.
• Installation can be done by serial connection only.
• A poulated serial header is onboard
https://forum.openwrt.org/t/spectrum-sax1v1k-askey-rt5010w-openwrt-support/149923/6
• RX/TX is working, u-boot bootwait is active, secure boot is enabled.
```
Installation Instructions:
**Most part of the installation is performed from an initramfs image.**
Boot initramfs : Using serial connection
1. Boot up the device and wait till it displays "VERIFY_IB: Success. verify IB ok"
2. Once that message appears,
login with username 'root'
password serial number of your router in uppercase.
3. Use vi to paste the 'open.sh' script from @MeisterLone github on your device
https://github.com/MeisterLone/Askey-RT5010W-D187-REV6/blob/master/Patch/open.sh
4. chmod 755 open.sh
5. ./open.sh
6. Set your ip to 192.168.0.1
7. Run a TFTP server and host the initramfs image on the TFTP server and name it "recovery.img"
8. Reboot device. On boot it will try TFTP.
Install OpenWrt from initramfs image:
1. Use SCP (or other way) to transfer OpenWrt factory image
2. Connect to device using SSH (on a LAN port)
3. Flash firmware: sysupgrade
# sysupgrade -n -v /tmp/openwrt_sysupgrade.bin
4. Set U-boot env variable: bootcmd
# fw_setenv bootcmd "run fix_uboot; run setup_and_boot"
5. Reboot the device
# reboot
6. Once device is booted, residue of previous firmware will prevent openwrt to work properly.
Factory Reset is MUST required
# Once serial console is displaying to login, hold reset button for 10 sec
7. Now everything should be operational.
Note: this PR adds only single partition support, that means sysupgrade is
upgrading the current rootfs partition
Signed-off-by: Connor Yoon <j_connor@taliaent.com>
Fix broken BoHong bh25q128as patch that used wrong define for kernel
5.15.
Fixes: 4cb814d403 ("generic: 5.15: Make support for BoHong bh25q128as generic")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Fixes error in the form of [0]:
drivers/pinctrl/pinctrl-at91.c:1668:12: error: 'at91_gpio_resume' defined but not used [-Werror=unused-function]
1668 | static int at91_gpio_resume(struct device *dev)
| ^~~~~~~~~~~~~~~~
drivers/pinctrl/pinctrl-at91.c:1650:12: error: 'at91_gpio_suspend' defined but not used [-Werror=unused-function]
1650 | static int at91_gpio_suspend(struct device *dev)
| ^~~~~~~~~~~~~~~~~
[0] - https://lore.kernel.org/all/20221215164301.934805-1-arnd@kernel.org/
Signed-off-by: Nick Hainke <vincent@systemli.org>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Nick Hainke <vincent@systemli.org>
Fixes no communication with tethered iOS devices in CDC NCM mode.
Freshly booted iOS devices start in legacy mode, but are put into
NCM mode by the official Apple driver.
[1] a2d274c62eFixes: #12566
Tested-by: Georgi Valkov <gvalkov@gmail.com>
Signed-off-by: Foster Snowhill <forst@pen.gy>
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
[ better reference fixed issue ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Move the patch for BoHong bh25q128as out of ramips to make it
generic. Not including 6.1.y since the mtd subsystem has changed,
and does not need these changes.
Patch was dropped with ramips updating to 6.1, hence we reintroudce it
here for 5.15 generic.
5.15.y functionality was verified on a Wavlink WL-WN586X3 Rev.a.
Signed-off-by: R Maru <deviantmaru@gmail.com>
[ rebase and add extra info in commit description ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Backport patches for support of generic spi-nor from SFDP data for
kernel 6.1.
Kernel 5.15 have major rework of the info flags and it's not trustable
to backport this amount of changes and expect correct function of it.
All affected patches automatically refreshed using make
target/linux/refresh.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
As preparation for the arm926ej-s support which has a different
load address, move the KERNEL_LOADADDR into the subtargets.
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
This is an automatically generated commit.
During a `git bisect` session, `git bisect --skip` is recommended.
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
For the ARM arch on 6.6, DTS files are moved into their vendor directories,
mimicking arm64. Reflect this in the image Makefile.
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
Add support for kernel 6.1 as testing kernel for qoriq. Refresh config
using `make kernel_oldconfig`.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
It's the A13-based Olinuxino Micro which has only wireless interfaces. The
A20-based board is a fully-fledged one which has an ethernet interface.
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
This device supports channel ranges 36-64 and 100-165, just like
others based on the same reference design, but its current DTS is
unnecessarily restricting these ranges to 36-48 and 149-165.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
In preparation for supporting kernel 6.6, where the DTS files are grouped into
vendors - similarly to what arm64 has been doing all along -, update the
SUNXI_DTS var of this board to prepend it with SUNXI_DTS_DIR.
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
Kernel 6.1.83 allows to select CONFIG_GPIO_VF610, deactivate it by
default.
This fixes compilation of the armsr/armv8 target.
Fixes: 2ad898e091 ("kernel: bump 6.1 to 6.1.83")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This adds support for the A1 hardware revision of the DIR-3040.
It is an exact copy of the DIR-3060 save for some cosmetic changes to the housing.
Even going so far as having the same FCC ID.
Hardware specification:
SoC: MediaTek MT7621AT
Flash: Winbond W29N01HVSINA 128MB
RAM: Micron MT41K128M16JT-125 256MB
Ethernet: 5x 10/100/1000 Mbps
WiFi1: MT7615DN 2.4GHz N 2x2:2
WiFi2: MT7615DN 5GHz AC 2x2:2
WiFi3: MT7615N 5GHz AC 4x4:4
Button: WPS, Reset
Flash instructions:
OpenWrt can be installed via D-Link Recovery GUI:
NOTE: Seems to only work in Firefox on Windows.
Tried with Chrome on Windows, Firefox in Linux, and Chromium in Linux.
None of these other browsers worked.
1. Push and hold reset button (on the bottom of the device) until power led
starts flashing (about 10 secs or so) while plugging in the power cable.
2. Give it ~30 seconds, to boot the recovery mode GUI
3. Connect your client computer to LAN1 of the device
4. Set your client IP address manually to 192.168.0.2 / 255.255.255.0.
5. Call the recovery page for the device at http://192.168.0.1/
6. Use the provided emergency web GUI to upload and flash a new firmware to the device
Thanks to @Lucky1openwrt and @iivailo for creating the DIR-3060 DTS file and related changes,
so it was possible for me to adapt them to the DIR-3040, build images,
test and fix minor issues.
MAC Addresses:
| use | address | example |
| --- | --- | --- |
| LAN | label | f4:*:61 |
| WAN | label + 4 | f4:*:65 |
| WI1/2g | label + 2 | f4:*:63 |
| WI1/5g | label + 1 | f4:*:62 |
| WI2/5g | label + 3 | f4:*:64 |
The label MAC address was found in Factory, 0xe000
Checklist:
✓ nand
✓ ethernet
✓ button
✓ wifi2g
✓ wifi5g
✓ wifi5g
✓ mac
✓ led
Signed-off-by: Vince McKinsey <vincemckinsey@gmail.com>
On IIJ SA-W2, some multiple LEDs have no "function" property and only
"color" property is available for the newer binding of LED on Linux
Kernel.
9d93b6d091 ("mvebu: drop redundant label with new LED color/function
format") removes "label" property from LEDs, then, multiple "<color>:"
(ex.: "green:"/"red:") will be appeared and renamed to "<color>:_<num>"
(ex.: "green:_1", "green:_2", ...) by kernel.
log:
[ 1.911118] leds-gpio leds: Led green: renamed to green:_1 due to name collision
[ 1.918600] leds-gpio leds: Led red: renamed to red:_1 due to name collision
[ 1.925727] leds-gpio leds: Led green: renamed to green:_2 due to name collision
[ 1.933202] leds-gpio leds: Led red: renamed to red:_2 due to name collision
[ 1.940321] leds-gpio leds: Led green: renamed to green:_3 due to name collision
[ 1.947797] leds-gpio leds: Led red: renamed to red:_3 due to name collision
[ 1.954939] leds-gpio leds: Led green: renamed to green:_4 due to name collision
[ 1.962456] leds-gpio leds: Led green: renamed to green:_5 due to name collision
/sys/class/leds:
root@OpenWrt:/# ls /sys/class/leds/
green: green:_3 green:status red:_2
green:_1 green:_4 red: red:_3
green:_2 green:_5 red:_1 red:status
Fix this issue by adding missing "function" (and "function-enumerator")
property to those LEDs on IIJ SA-W2.
Fixes: 9d93b6d091 ("mvebu: drop redundant label with new LED color/function format")
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
On Fortinet FortiGate 30E/50E, some multiple LEDs have no "function"
property and only "color" property is available for the new binding of
LED on Linux Kernel.
9d93b6d091 ("mvebu: drop redundant label with new LED color/function
format") removes "label" property from LEDs, then, multiple "<color>:"
(ex.: "green:"/"red:"/"amber:") will be appeared as LED names and
renamed to "<color>:_<num>" (ex.: "green:_1", "green:_2", ...) by
kernel.
log:
[ 12.425170] leds-gpio gpio-leds: Led green: renamed to green:_1 due to name collision
[ 12.520390] leds-gpio gpio-leds: Led amber: renamed to amber:_1 due to name collision
[ 12.614931] leds-gpio gpio-leds: Led green: renamed to green:_2 due to name collision
[ 12.709895] leds-gpio gpio-leds: Led green: renamed to green:_3 due to name collision
[ 12.804439] leds-gpio gpio-leds: Led amber: renamed to amber:_2 due to name collision
[ 12.898969] leds-gpio gpio-leds: Led green: renamed to green:_4 due to name collision
[ 12.993504] leds-gpio gpio-leds: Led amber: renamed to amber:_3 due to name collision
[ 13.088033] leds-gpio gpio-leds: Led green: renamed to green:_5 due to name collision
[ 13.182570] leds-gpio gpio-leds: Led green: renamed to green:_6 due to name collision
[ 13.277103] leds-gpio gpio-leds: Led amber: renamed to amber:_4 due to name collision
[ 13.371636] leds-gpio gpio-leds: Led green: renamed to green:_7 due to name collision
/sys/class/leds:
root@OpenWrt:/# ls /sys/class/leds/
amber: amber:_4 green:_2 green:_6 red:alarm
amber:_1 amber:alarm green:_3 green:_7 red:status
amber:_2 green: green:_4 green:status
amber:_3 green:_1 green:_5 red:
Fix this issue by adding missing "function" (and "function-enumerator")
property those to LEDs on Fortinet FortiGate devices.
Note: there is no appropriate function for "ha" LEDs in
dt-bindings/leds/common.h, so use the hardcoded string for them instead.
Fixes: 9d93b6d091 ("mvebu: drop redundant label with new LED color/function format")
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Add pending patches to add LED_FUNCTION_MOBILE and LED_FUNCTION_SPEED_*
definitions for Fortinet FortiGate devices and IIJ SA-W2.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Specifications:
Qualcomm/Atheros QCA9531
2x 10/100 Mbps Ethernet, with 48v PoE
2T2R 2.4 GHz, 802.11b/g/n
128MB RAM
16MB SPI Flash
4x LED (Always On Power, LAN, WAN, WLAN)
Flashing instructions:
The original firmware is based on OpenWrt, so flashing the sysupgrade image over the factory firmware is sufficient.
The bootloader has a built-in recovery web-ui. This is the method I used to flash OpenWrt. You can get to the recovery web-ui by holding down the reset button for a few seconds (~5s) while pluggin in the router. The LEDs should start blinking fast and the router should be available on 192.168.1.1 for the recovery.
Tested: Reset button, WAN LED, LAN LED, Power LED (always on, not much to test), WLAN LED, MAC addresses (same as factory firmware).
Signed-off-by: Felix Golatofski <git@xdfr.de>
This reordering was done using these commands:
./scripts/kconfig.pl '+' target/linux/generic/config-6.1 /dev/null > target/linux/generic/config-6.1-new
mv target/linux/generic/config-6.1-new target/linux/generic/config-6.1
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Change the RGB indicator LED color for the running state from green to
blue. There are various reasons for this change:
- In stock firmware, green means internet connection is up, red means it
is down, and blue means indeterminate. To track stock behavior as
closely as possible, OpenWrt should indicate blue by default.
- In the current 23.x OpenWrt releases for this router, the led glows
blue all the time -not green- because the bootloader sets it blue
and there is an OpenWrt bug that makes it unable to control the LED.
The bug is fixed in master, so without this commit there would be an
unexpected change of behavior for this device in the next release.
- The ports other closely related Linksys devices (such as EA8300 and
MR8300) get this right and use blue for the running state.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
The RGB LED should glow green in the 'running' state, but it
was glowing cyan because the blue component defaulted to 'on'.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
The upstream solution to define the MDIO bus in DT is a bit
more strict than our previous downstream solution doing the same thing
and now requires switch PHYs to be referenced in DT as well.
Arınç Ünal told us in #15141:
"With [the now upstream patch written by him which we backported], the
switch MDIO bus won't be assigned to ds->user_mii_bus when the switch
MDIO bus is defined on the device tree anymore. This was not the case
with the downstream patch.
When ds->user_mii_bus is populated, DSA will 1:1 map the port with
PHY. Meaning port with address 1 will be mapped to PHY with address 1.
Because that ds->user_mii_bus is not populated when the switch MDIO
bus is defined on the device tree, on every port node, the PHY address
must be supplied by the phy-handle property."
Add those phy-handles to affected devices' DT.
Fixes: 4354b34f6f ("generic: 6.6: sync mt7530 DSA driver with upstream")
Fixes: 401a6ccfaf ("generic: 6.1: sync mt7530 DSA driver with upstream")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
TP-Link EC220-G5 v2 is a dual band router with 4 GbE ports
Advertised as AC1200 for its 867Mbps (2x2) 5GHz band
and 300 Mbps (2x2) 2.4GHz band.
Specs:
- SoC: MediaTek MT7620A
- Ethernet: 4x GbE ports (Realtek RTL8367S)
- Wireless 2.4GHz: MediaTek MT7620A
- Wireless 5GHz: MediaTek MT7612E
- RAM: 64MiB
- ROM: 8MiB (W25Q64BV)
- 2 Buttons (WPS and reset)
- 7 LEDs
Flash instructions via serial console:
1. Rename the factory.bin to to test.bin
2. start a TFTP server from IP address 192.168.0.225 and serve the image named test.bin
3. connect your device to the LAN port
4. power up the router and press 4 on the console to stop the boot process.
5. enter the following commands on the router console
tftp 0x80060000 test.bin
erase tplink 0x20000 0x7a0000
cp.b 0x80060000 0x20000 0x7a0000
reset
Flash instructions via TFTP:
1. Update orginal firmware of the router to the latest one.
2. Rename openwrt-ramips-mt7620-tplink_ec220-g5-v2-squashfs-tftp-recovery.bin to tp_recovery.bin
3. Change computer IP to 192.168.0.66
4. Run TFTP serwer
5. Start the router with the reset button pressed, the file will be automatically downloaded and after a while the router will restart.
6. After updating, set your computer's IP to DHCP
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Change the name mt7620a_tplink_archer.dtsi to mt7620a_tplink_8m.dtsi because it will also be a base for TP-Link non-Archer routers.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
The function introduced in commit 7cbfe5654d is named
filter_port_list_reverse, not filter_port_list_reversed.
Fixes the following error on hpe,1920-8g-poe-65w and
hpe,1920-8g-poe-180w.
/bin/board_detect: /etc/board.d/02_network: line 84: filter_port_list_reversed: not found
Fixes: 7cbfe5654d ("realtek: move port filtering out of uci_set_poe()")
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: Sander Vanheule <sander@svanheule.net>
Fix also some Chinese GB18030 -> UTF-8 encoding problems
(translated the Chinese strings to English):
修改 -> modification
port8~port10的设置在另外一个register ->
port8~port10 setup is done in a separate register
You are in the correct (UTF-8) encoding when you see:
* $Date: 2017-03-08 15:13:58 +0800 (週三, 08 三月 2017) $
e.g. week 3, 08 third month, 2017
But not if you see:
* $Date: 2017-03-08 15:13:58 +0800 (閫变笁, 08 涓夋湀 2017) $
rtl8367c/rtl8367c_asicdrv_lut.c should be read as UTF-8, despite having
some earlier Chinese text lost to GB18030 encoding.
Improves indexing and searches
Signed-off-by: Paul Donald <newtwen+github@gmail.com>
We have defaulted to 6.6 for a while so its time to completely drop 6.1
so new devices dont have to include patches for 6.1.
Signed-off-by: Robert Marko <robimarko@gmail.com>
HW specifications:
* Mediatek MT7981A
* 256MB SPI-NAND
* 512MB DRAM
* Uplink: 1 x 10/100/1000Base-T Ethernet, Auto MDIX, RJ-45 with 802.3at
PoE (Built-in GBe PHY)
* LAN: 1 x 10/100/1000Base-T Ethernet, Auto MDIX, RJ-45 (Airoha EN8801SC)
* 1 Tricolor LED
* Reset button
* 12V/2.0A DC input
Installation:
Board comes with OpenWifi/TIP which is OpenWrt based, so sysupgrade can
be used directly over SSH.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Airoha EN8801SC PHY is a gigabit PHY used on Edgecore EAP111 so, include
the MTK driver with some cleanups.
Unfortunatelly, there is no specification sheet nor datasheet available
in order to demistify the magic PBUS writes and work on upstreaming
this driver.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
First patch allows to inquire and modify Energy-Efficient-Ethernet
(EEE) settings via ethtool and thereby override the default setting of
a board done via bootstrap pins.
The second patch fixes a long-standing issue with STP (and similar
protocols) when using boards (or SoCs) governed by the mt7530 DSA
driver.
Both patches could also be (dirty-)applied to Linux 5.15, but I'd
rather just wait for that to happen via linux-stable to avoid the
mess.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Backport lots upstream changes, many of them fixes, for the mt7530 DSA
driver, similar to how it was done for Linux 6.1 in the previous commit.
The remaining differences compared to the upstream driver are only
the 'slave' -> 'user', 'master' -> 'conduit' language change in DSA
and the rename of 'struct ethtool_eee' to 'struct ethtool_keee' as
well as tree-wide replacement of ethtool_sprintf with ethtool_puts,
all of them do not have any functional impact.
Apart from some minor bug fixes and style improvements the switch
should now behave more conformant when it comes to link-local frames,
and we will again be able to cleanly pick patches from upstream.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Backport lots upstream changes, many of them fixes, for the mt7530 DSA
driver. Some of them may or may not find they way into Linux 6.1
stable, some certainly won't because they are fixes for backported
commits which aren't even present in Linux 6.1 upstream.
Apart from adding new patches, also remove mutated patch
723-net-mt7531-ensure-all-MACs-are-powered-down-before-r.patch
which should never have been added for Linux 6.1 -- it was applied
already upstream but coincidentally would fuzzy-apply in the wrong
place as well (for MT7530 instead of MT7531). While that didn't really
hurt anyone it is just unneeded.
The other deleted patch
795-mt7530-register-OF-node-for-internal-MDIO-bus.patch
has been replaced by an equivalent commit with a more complete patch
description by upstream maintainer Arınç Ünal.
The remaining differences compared to the upstream driver are:
* C22/C45 MDIO ops aren't split
Upstream did that, backporting it would require making changes to
*all* DSA drivers
* 'slave' -> 'user', 'master' -> 'conduit' language change in DSA
* support for selecting preferred CPU port on MT7531
Also this would require too many DSA framework changes potentially
affecting other devices. If we ever really use Linux 6.1 in a
release (I hope not) we can still reconsider to make the effort to
backport that.
In addition to some minor bug fixes and style improvements the switch
should now behave more conformant when it comes to link-local frames,
and we will again be able to cleanly pick patches from upstream.
MAINTAIERS NOTE:
Three patches are already part of Linux stable and should be removed with
the next minor kernel version bump:
789-STABLE-01-net-dsa-mt7530-prevent-possible-incorrect-XTAL-frequ.patch
789-STABLE-02-net-dsa-mt7530-fix-link-local-frames-that-ingress-vl.patch
789-STABLE-03-net-dsa-mt7530-fix-handling-of-all-link-local-frames.patch
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Make sure all patches can be applied to a git tree using 'git am'
by adding missing patch headers where needed.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The sysupgrade formware of the Puzzle series is a slightly strange
dual-boot approach while remaining compatible with Marvell's SDK
firmware upgrade binary format -- which happens to be a full-disk
image with GPT partition table. Hence that /lib/upgrade/emmc-puzzle.sh
script is like an exotic disease which results from those decisions,
and as we also want to somehow stay compatible with the IEI-World
stock firmware we got to use it in that same way (we are not
compatible with the QNAP-branded identical hardware device anyway).
Currently, on sysupgrade the result is that one ends up with the old
content of rootfs_data (a GPT partition on those devices) as nothing
ever wipes or in any way re-creates the filesystem there. As a simple
work-around, let's kill the filesystem on rootfs_data so fstools
re-formats it on the next boot.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Trying to link certain kernel modules like dahdi-linux when building with
the OpenWrt SDK will fail with:
openwrt-sdk-apm821xx-sata_gcc-13.2.0_musl.Linux-x86_64/staging_dir/toolchain-powerpc_464fp_gcc-13.2.0_musl/bin/powerpc-openwrt-linux-musl-ld: cannot find arch/powerpc/lib/crtsavres.o: No such file or directory
Previously this worked with the PowerPC SDK since we carried a hack that
was passing --save-restore-funcs to module LDFLAGS so the linker provided
the required functions automatically as without --save-restore-funcs it
doesnt do so automatically on relocatable links and as a sideffect did not
require the kernel provided crtsaves.o to link against.
Now that hack has been removed as upstream kernel now compiles crtsaves.o
by default so it can be linked against but its not included in the SDK.
So, lets include lib/crtsavres.o when SDK is generated for PowerPC.
Fixes: 99c9d8abd6 ("kernel: bump 5.15 to 5.15.148")
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently the compile phase of the kernel builds `Image dtbs modules`.
However, none of the dtbs that get built are used for the final image.
This ends up unnecessarily taking CPU cycles and produces a lot of
`WARNINGS` that can lead users to believe there's cause for concern. I
believe the same principle can be applied to other targets.
```
DTC arch/arm64/boot/dts/qcom/msm8996-mtp.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
DTC arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone-dora.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
DTC arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone-kagura.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
DTC arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone-keyaki.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
DTC arch/arm64/boot/dts/qcom/msm8996-xiaomi-gemini.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
DTC arch/arm64/boot/dts/qcom/msm8996-xiaomi-natrium.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
DTC arch/arm64/boot/dts/qcom/msm8996-xiaomi-scorpio.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
```
Signed-off-by: Sean Khan <datapronix@protonmail.com>
Historically it's possible to leave the `SUBTARGETS` undefined and
automatically fallback to a "generic" subtarget. This however breaks
various downstream scripts which may have expectations around filenames:
While some targets with an explicit generic subtarget contain `generic`
in the filenames of artifacts, implicit "subtargets" don't.
Right now this breaks the CI[1], possibly also scripts using the ImageBuilders.
This commit removes all code that support implicit handling of
subtargets and instead requires every target to define "SUBTARGETS".
[1]: https://github.com/openwrt/openwrt/actions/runs/8592821105/job/23548273630
Signed-off-by: Paul Spooren <mail@aparcar.org>
Historically it's possible to leave the `SUBTARGETS` undefined and
automatically fallback to a "generic" subtarget. This however breaks
various downstream scripts which may have expectations around filenames:
While some targets with an explicit generic subtarget contain `generic`
in the filenames of artifacts, implicit "subtargets" don't.
Right now this breaks the CI[1], possibly also scripts using the ImageBuilders.
Do to the D1 target what's done to other target, explicitly define the
"generic" subtarget.
[1]: https://github.com/openwrt/openwrt/actions/runs/8592821105/job/23548273630
Signed-off-by: Paul Spooren <mail@aparcar.org>
This device is very similar to the GS1900-24E switch (added in b515ad1),
except that the first 12 of 24 ethernet ports are capable of PoE and the
physical jacks are in the right order - unlike for the GS1900-24E, where
even and uneven ports are flipped (up <-> down on panel).
Zyxel version code for this device (-24EP) is: ABTO
Signed-off-by: Mirko Vogt <mirko-openwrt@nanl.de>
Sync 6.1 patches with the RPi foundation.
Since rpi-6.6.y is now the main branch of the RPi foundation, there won't be
any new patches for linux 6.1.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Kernel 6.6 added dynamic SWIOTLB allocation, but with it also started
allocating 64MB of the SWIOTLB bounce buffer by default which is quite a
lot of memory on most OpenWrt devices.
Luckily in kernel 6.7 arm64 received an optimization that reduces that
default size to 1MB per 1GB of RAM if certain criteria was met.
So in order to reclaim back 63MB of RAM which brought some ipq807x devices
close to OOM under load lets backport the upstream commit.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add options removed by `make kernel_oldconfig CONFIG_TARGET=subtarget', missing which causes compilation to stop and cause an error.
Fixes: 2a86425de1 ("x86: 6.6: refresh kernel config")
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Add:
110-pwm-img-fix-clock-lookup.patch
- patch to fix a clock lookup issue from upstream
Update:
401-mtd-nor-support-mtd-name-from-device-tree.patch
- mtd-name lookup hack to reflect the updated spi_nor_scan function
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
refreshed kernel config + patches
otherwise same as 6.1/5.15.
Tested on: WNDAP620, WNDAP660, MyBook Live Single, MR24, MX60, WNDR4700
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
With the default BUILD_BOT configuration on a linux 6.6 kernel,
the WNDR4700's kernel no longer fits into the alloted ~3.5MiB,
even with LZMA compression.
Bigger kernels are possible, but there's a problem with Netgear's
"bootcmd":
> if loadn_dniimg 0 0x180000 0x4e0000 && chk_dniimg 0x4e0000; then nand read 0x800000 0x180000 0x20000;bootm 0x500000 - 0x800040;else fw_recovery; fi"
This loads the dni-image starting offset 0x180000 from the NAND
flash (which is the DTB partition) to 0x4e0000 in the RAM. It then
checks whenever the provided image is "valid". If it is then it
reads the DTB again to 0x800000 in the RAM and starts the extraction
and boot process. (If the image wasn't valid then it starts the
automated firmware recovery).
The issues here are that first: the kernel image gets "squeezed"
between 0x500040 and 0x7fffff... And second, the decompressor
only has area 0x0 - 0x500000 for decompression.
Hence the image now requires to update the bootcmd by providing
new values (which have been successfully tested with the original
Netgear WNDR4700 v1.0.0.56 firmware) for the RAM locations and
make full use of the fact that loadn_dniimg loads the DTB as well.
This needs to be done only once. Just connect a serial adapter to
interface with uboot and overwrite (and save) the new bootcmd.
WARNING: The serial port needs a TTL/RS-232 3.3v level converter!
Steps:
0. Power-off the WNDR4700
1. Connect the serial interface (you need to open the WNDR4700)
2. Power-up the WNDR4700
3. Monitor the boot-sequence and hit "Enter"-key when it says:
"Hit any key to stop autoboot" (Be quick, you have a ~2 second window)
4. in the Prompt enter the following commands (copy & paste)
setenv bootcmd "if loadn_dniimg 0 0x180000 0xce0000 && chk_dniimg 0xce0000; then bootm 0xd00000 - 0xce0040;else fw_recovery; fi"
saveenv
run bootcmd
Note: This new bootcmd will also unbrick devices that were bricked
by the bigger 4.19-6.1 kernels.
Note2: This method was tested with a WNDR4700. A big kernel with most
debug features enabled on v6.6.22 measured 4.30 MiB when compressed
with lzma. The uncompressed kernel is 12.34 MiB. This is over the 3 MiB,
the device reserves for the kernel... But it booted! For bigger kernels,
the device needs repartitioning of the the ubi partition due to the
kernel+dtb not fitting into the partition.
Note3: For initramfs development. I would advice to load the initramfs
images to 0x800000 (or higher). i.e.: tftp 800000 wndr4700.bin
Note4: the fw_recovery uboot command to transfer the factory image to
the flash still works.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Compatiblity with kernel 6.6 for Awinic AW9523B i2c pin controller driver.
It follows the kernel patch: i2c: Drop legacy callback .probe_new() (5eb1e6e459)
and kernel patch: gpiolib: Get rid of not used of_node member (70d0fc4288)
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Fix error: 'struct snd_soc_dai_driver' has no member named 'remove'
It follows the kernel patch: ASoC: soc-dai.h: remove unused call back functions (446b31e894)
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
This is an automatically generated commit.
During a `git bisect` session, `git bisect --skip` is recommended.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
This is an automatically generated commit.
During a `git bisect` session, `git bisect --skip` is recommended.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
This is an automatically generated commit.
During a `git bisect` session, `git bisect --skip` is recommended.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
This is an automatically generated commit.
During a `git bisect` session, `git bisect --skip` is recommended.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
This is an automatically generated commit.
During a `git bisect` session, `git bisect --skip` is recommended.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
With 6.6, all DTSes were moved to their vendor subdirectories. ARM64
DTSes already used this scheme, but 32 bit Cortex A9 did not, prior
to 6.6. Introduce a kernel version check to keep backward compatibility
with 6.1.
Suggested-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
As of 6.6, all upstream DTSes are moved to their respective vendor subdir.
OpenWrt already followed this practice for ARM64, but not yet for 32 bit
ARM (Armada 37x/38x).
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
DTS paths for 32 bit ARM devices changed with 6.6, move files/ to
files-6.1 to prep for kernel 6.6 introduction.
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
Add pending patch fixing nandc with new kerenel due to broken convertion
to new nand API. Patch has been sent upstream and will be backported to
stable kernel if accepted.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Rework kernel patches for new kernel. Mainly adaptation for patch
related to DTS and changes for the downstream div generalize patch that
now use determine_rate.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Since with recent kernel version DTS moved to a dedicated directory,
it's required to split files to per kernel version to follow kernel
version directory structure.
Also makes use of DEVICE_DTS_DIR to target the correct DTS directory
based on the kernel version.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
This is an automatically generated commit.
When doing `git bisect`, consider `git bisect --skip`.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add pending patch fixing mtdcore with MTD OTP with a fragile detection
if Nand supports OTP. Patch has been sent upstream and will be backported
to stable kernel if accepted.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Rework kernel patches for new kernel. Mainly adaptation for patch
related to DTS, OOB Tagger and SDHCI patch.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Fix DTS to use reference for usb node instead of redefining
them since upstream usb node names changed from usb2/3 to usb.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Since with recent kernel version DTS moved to a dedicated directory,
it's required to split files to per kernel version to follow kernel
version directory structure.
Also makes use of DEVICE_DTS_DIR to target the correct DTS directory
based on the kernel version.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
This is an automatically generated commit.
When doing `git bisect`, consider `git bisect --skip`.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Refresh backport patches for kernel 6.1.82 with make target/linux/refresh.
Fixes: 06cdc07f8c ("ath79: add support for Huawei AP5030DN")
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
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>
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>
Huawei AP5030DN is a dual-band, dual-radio 802.11ac Wave 1 3x3 MIMO
enterprise access point with two Gigabit Ethernet ports and PoE
support.
Hardware highlights:
- CPU: QCA9550 SoC at 720MHz
- RAM: 256MB DDR2
- Flash: 32MB SPI-NOR
- Wi-Fi 2.4GHz: QCA9550-internal radio
- Wi-Fi 5GHz: QCA9880 PCIe WLAN SoC
- Ethernet 1: 10/100/1000 Mbps Ethernet through Broadcom B50612E PHY
- Ethernet 2: 10/100/1000 Mbps Ethernet through Marvell 88E1510 PHY
- PoE: input through Ethernet 1 port
- Standalone 12V/2A power input
- Serial console externally available through RJ45 port
- External watchdog: SGM706 (1.6s timeout)
Serial console:
9600n8 (9600 baud, no stop bits, no parity, 8 data bits)
MAC addresses:
Each device has 32 consecutive MAC addresses allocated by
the vendor, which don't overlap between devices.
This was confirmed with multiple devices with consecutive
serial numbers.
The MAC address range starts with the address on the label.
To be able to distinguish between the interfaces,
the following MAC address scheme is used:
- eth0 = label MAC
- eth1 = label MAC + 1
- radio0 (Wi-Fi 5GHz) = label MAC + 2
- radio1 (Wi-Fi 2.4GHz) = label MAC + 3
Installation:
0. Connect some sort of RJ45-to-USB adapter to "Console" port of the AP
1. Power up the AP
2. At prompt "Press f or F to stop Auto-Boot in 3 seconds",
do what they say.
Log in with default admin password "admin@huawei.com".
3. Boot the OpenWrt initramfs from TFTP using the hidden script
"run ramboot". Replace IP address as needed:
> setenv serverip 192.168.1.10
> setenv ipaddr 192.168.1.1
> setenv rambootfile
openwrt-ath79-generic-huawei_ap5030dn-initramfs-kernel.bin
> saveenv
> run ramboot
4. Optional but recommended as the factory firmware cannot
be downloaded publicly:
Back up contents of "firmware" partition using the web interface or ssh:
$ ssh root@192.168.1.1 cat /dev/mtd11 > huawei_ap5030dn_fw_backup.bin
5. Run sysupgrade using sysupgrade image. OpenWrt
shall boot from flash afterwards.
Return to factory firmware (using firmware upgrade package downloaded from
non-public Huawei website):
1. Start a TFTP server in the directory where
the firmware upgrade package is located
2. Boot to u-boot as described above
3. Install firmware upgrade package and format the config partitions:
> update system FatAP5X30XN_SOMEVERSION.bin
> format_fs
Return to factory firmware (from previously created backup):
1. Copy over the firmware partition backup to /tmp,
for example using scp
2. Use sysupgrade with force to restore the backup:
sysupgrade -F huawei_ap5030dn_fw_backup.bin
3. Boot AP to U-Boot as described above
Quirks and known issues
-----------------------
- On initial power-up, the Huawei-modified bootloader suspends both
ethernet PHYs (it sets the "Power Down" bit in the MII control
register). Unfortunately, at the time of the initial port, the kernel
driver for the B50612E/BCM54612E PHY behind eth0 doesn't have a resume
callback defined which would clear this bit. This makes the PHY unusable
since it remains suspended forever. This is why the backported kernel
patches in this commit are required which add this callback and for
completeness also a suspend callback.
- The stock firmware has a semi dual boot concept where the primary
kernel uses a squashfs as root partition and the secondary kernel uses
an initramfs. This dual boot concept is circumvented on purpose to gain
more flash space and since the stock firmware's flash layout isn't
compatible with mtdsplit.
- The external watchdog's timeout of 1.6s is very hard to satisfy
during bootup. This is why the GPIO15 pin connected to the watchdog input
is configured directly in the LZMA loader to output the CPU_CLK/4 signal
which keeps the watchdog happy until the wdt-gpio kernel driver takes
over. Because it would also take too long to read the whole kernel image
from flash, the uImage header only includes the loader which then reads
the kernel image from flash after GPIO15 is configured.
Signed-off-by: Marco von Rosenberg <marcovr@selfnet.de>
[fixed 6.6 backport patch naming]
Signed-off-by: David Bauer <mail@david-bauer.net>
On x86, the build failed while trying to compile tools/lib/string.c because
of a clash with the system provided implementation for strlcpy
Add ifdefs to prevent the conflict.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This device only has 64 MiB RAM and ath10k wireless driver will
consume a lot of memory. Let's move it to the tiny sub-target to
get extra 7 MiB of free space. In this way, we can extend their
lifetime to receive support for the next OpenWrt LTS version. This
patch also trims the duplicate "recovery.bin" image as it's the
same as the "factory.bin".
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
These devices only have 64 MiB RAM and ath10k wireless driver will
consume a lot of memory. Let's move them to the tiny sub-target to
get extra 7 MiB of free space. In this way, we can extend their
lifetime to receive support for the next OpenWrt LTS version. This
patch also trims the USB package for the non-existent USB port.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
The upcoming D-Link devices to the tiny sub-target require it to
parse the u-env MAC address. The kernel size will increase by
about 1 KiB.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Move seama image recipe to the common Makefile in order for some
tiny sub-target D-Link devices can share it.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Hardware specification:
SoC: MediaTek MT7986A 4x A53
Flash: ESMT F50L1G41LB 128MB
RAM: W632GU6NB DDR3 256MB
Ethernet: 1x 2.5G + 4x 1G
WiFi1: MT7975N 2.4GHz 4T4R
WiFi2: MT7975PN 5GHz 4T4R
Button: Reset, WPS
Power: DC 12V 2A
Flash instructions:
1. Connect to the router using ssh or telnet,
username: useradmin, password is the web
login password of the router.
2. Use scp to upload bl31-uboot.fip and flash:
"mtd write xxx-preloader.bin spi0.0"
"mtd write xxx-bl31-uboot.fip FIP"
"mtd erase ubi"
3. Connect to the router via the Lan port,
set a static ip of your PC.
(ip 192.168.1.254, gateway 192.168.1.1)
4. Download initramfs image, reboot router,
waiting for tftp recovery to complete.
5. After openwrt boots up, perform sysupgrade.
Note:
1. Back up all mtd partitions before flashing.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
The image generation would fail, if the target is included from a feed.
To fix this, check if targets is found in the feed directory.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Tested-by: Thomas Richard <thomas.richard@bootlin.com>
Fixes the regression so that targets that were installed via a feed can
also be build again with the Image Builder.
Fixes: 84ec8c4 ("imagebuilder: copy from buildroot only target/linux")
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Tested-by: Thomas Richard <thomas.richard@bootlin.com>
ttyS2 is the default console used for all rockchip boards.
The redundant 'console=tty1' parameter now breaks the console due to
recent procd update.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
We have hardware IOMMU support and this is totally unnecessary.
The given value is also unreasonable, it's too small and causes
kernel panic in some cases:
[ 5706.856473] sdhci-dwcmshc fe310000.mmc: swiotlb buffer is full (sz: 28672 bytes), total 512 (slots), used 498 (slots)
[ 5706.864451] sdhci-dwcmshc fe310000.mmc: swiotlb buffer is full (sz: 65536 bytes), total 512 (slots), used 464 (slots)
This parameter seems to be added by mistake, so remove it.
Fixes: e35c7ab51f ("rockchip: merge bootscript")
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
6.6 has been in testing on qualcommax for a while so it should be in a
good shape, but lets default to it to get a wider audience.
Signed-off-by: Robert Marko <robimarko@gmail.com>
It's required to support NAND controllers with WP pin on boards that
don't have it connected to NAND chip.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Key features:
Allwinner H618 SoC (Quad core Cortex-A53)
1/1.5/2/4 GiB LPDDR4 DRAM
1 USB 2.0 type C port (Power + OTG)
1 USB 2.0 host port
1Gbps Ethernet port
Micro-HDMI port
MicroSD slot
Installation:
Write the image to SD Card with dd.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Backport AXP15060, AXP313a and AXP192 support.
The AXP15060 PMIC is used for starfive boards,
and the AXP313a PMIC is used for sunxi boards.
Remove conflicting patches from starfive target.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Fix issue of transmitting abnormal data which leads to link problems
in 1G and 2.5G SerDes modes (SGMII, 1000Base-X, 2500Base-X) on the
MediaTek MT7988 SoC.
Link: b72d6cba92
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The Zyxel GS1900-8 v2 or Rev.B1 is a newer variant of the GS1900-8, but
otherwise similar to the other GS1900 switches.
Differences
------------
* Front Button labeled RESTORE
* NO Power Switch on rear
* Serial Header next to the barrel power connector
* Part Number ends 0102F
Signed-off-by: Goetz Goerisch <ggoerisch@gmail.com>
Hardware specification:
SoC: MediaTek MT7981B 2x A53
Flash: 8GB eMMC or 128 MB SPI-NAND
RAM: 256MB
Ethernet: 5x 10/100/1000 Mbps
Switch: MediaTek MT7531AE
WiFi: MediaTek MT7976C
Button: Reset
USB: M.2(B-key) for 4G/5G Module
Power: DC 12V 1A
UART: 3.3v, 115200n8
--------------------------
| Layout |
| ----------------- |
| 4 | VCC RX TX GND | <= |
| ----------------- |
--------------------------
The U-boot menu will automatically appear at startup, and then select
the required options through UP/DOWN Key.
NAND Flash and eMMC Flash instructions:
1. Set your computers IP adress to 192.168.1.2.
2. Run a TFTP server providing the sysupgrade.bin image.
3. Power on the router, into the U-Boot menu.
4. Select "2. Upgrade firmware"
5. Update sysupgrade.bin file name, input server IP and input device
IP (if they deviate from the defaults)
6. Wait for automatic startup after burning
Signed-off-by: Allen Zhao <allenzhao@unielecinc.com>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
This is an automatically generated commit.
During a `git bisect` session, `git bisect --skip` is recommended.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
patch 150-arch-powerpc-simpleboot-prevent-overwrite-of-CPU1-sp.patch
was missed durring copy from 5.15 to 6.1.
This patch restore it.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
Add support for Gateworks Venice imx8m family of boards:
- required kernel modules for on-board devices
- image generation
- initial network config
- sysupgrade support
The resulting compressed disk image
(bin/targets/imx/cortexa53/openwrt-imx-cortexa53-gateworks_venice-squashfs-img.gz)
can be installed on a Gateworks venice board via U-Boot:
u-boot=> tftpboot $loadaddr openwrt-imx-cortexa53-gateworks_venice-squashfs-img.gz && \
gzwrite mmc $dev $loadaddr $filesize
WARNING: this will overwrite any boot firmware on the eMMC user hardware
partition which if being used will brick your board requiring JTAG to
re-program boot firmware and recover
The compressed disk image contains the partition table and filesystems only
and that it is expected that boot firmware is installed properly on the
eMMC boot0 hardware partition. The easiest way to ensure this is to
use the Gateworks JTAG adapter/process to install the latest boot firmware
as follows from a Linux host:
wget http://dev.gateworks.com/jtag/jtag_usbv4
chmod +x jtag_usbv4
wget http://dev.gateworks.com/venice/images/firmware-venice-imx8mm.bin
sudo ./jtag_usbv4 -p firmware-venice-imx8mm.bin
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Add imx8m support:
- add a cortexa53 subtarget to imx
- move ARCH and KERNELNAME to subtargets
- account for kernel modules that are not used for cortexa53
No device-specific targets or firmware images are created yet but all
imx8m* dtbs will be built.
enabling CONFIG_TARGET_ROOTFS_INITRAMFS results in
openwrt-imx-cortexa53-imx8m-initramfs-kernel.bin which has been
successfully booted on an imx8mm-evk using the following:
u-boot=> tftpboot $fdt_addr_r image-imx8mm-evk.dtb && \
tftpboot $kernel_addr_r openwrt-imx-cortexa53-imx8m-initramfs-kernel.bin && \
booti $kernel_addr_r - $fdt_addr_r
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Add a hotplug script and add ttyATH1 on ELECOM WAB-I1750-PS to
/etc/inittab while booting for using that console as an OpenWrt console.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Register ttyS0 and ttyATH1 as Linux console on ELECOM WAB-I1750-PS.
ttyS0 provides "SERVICE" port and internal pin header for debugging and
recoverying by maker, ttyATH1 provides "SERIAL" port for configuration
by users.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
The 6.1 kernel has caused another increase in kernel size, and now
it's more than 3MB:
WARNING: Image file iom_ix4-200d-uImage is too big: 3170394 > 3145728
WARNING: Image file iom_ix2-200-uImage is too big: 3171494 > 3145728
WARNING: Image file linksys_e4200-v2-uImage is too big: 3171879 > 3145728
WARNING: Image file linksys_ea4500-uImage is too big: 3171871 > 3145728
WARNING: Image file linksys_ea3500-uImage is too big: 3171651 > 3145728
This causes problems for 5 devices:
- Iomega StorCenter ix2/ix4
- Linksys EA3500/EA4200/EA4500
They have enough resources for proper operation with 6.1, but all of
them had a 3MB kernel size limit. Let's keep them alive and
resize kernel partitions to 4MB.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
6.1 testing version was introduced some time ago. Kernel size issues
are resolved now. Time to bump kernel version.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
When build images with the 6.1 kernel for all devices and all kmods,
there is one dependancy error:
pkg_hash_check_unresolved: cannot find dependency kmod-thermal
for kmod-hwmon-gpiofan
This commit fix that issue.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
Copied from original Andrew's Lunn commit message:
The DSA framework has got more picky about always having a phy-mode
for the CPU port. The Kirkwood Ethernet is an RGMII port. Set the
switch to impose the RGMII delays.
Additionally, the cpu label has never actually been used in the
binding, so remove it.
This commit backport change from upstream and fix downstream EA3500 dts.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
TP-Link RE205 v3 is a wireless range extender with Ethernet and 2.4G and 5G
WiFi with external antennas.
It's based on MediaTek MT7628AN+MT7610EN like the RE200 v3/v4 but with
external antennas.
Specifications
--------------
- MediaTek MT7628AN (580 Mhz)
- 64 MB of RAM
- 8 MB of FLASH
- 2T2R 2.4 GHz and 1T1R 5 GHz
- 1x 10/100 Mbps Ethernet
- 5x LED (GPIO-controlled), 2x button
- UART connection holes on PCB (57600 8n1)
There are 2.4G and 5G LEDs in blue which are controlled separately.
Installation
------------
Installation is identical to RE200 v3 devices as described at
https://openwrt.org/toh/tp-link/re200#installation
Web Interface
-------------
It is possible to upgrade to OpenWrt via the web interface. Simply flash
the -factory.bin from OEM. In contrast to a stock firmware, this will not
overwrite U-Boot.
Recovery
--------
U-Boot seems to be locked on newer versions, if not it can be accessed over
the UART as described in the link above.
Signed-off-by: Steffen Loley <slo-src@web.de>
This service was unfunctional due to not having its executable bit set.
Furthermore, sysupgrade complains about the file being present in images.
Also, the tc654 driver doesn't provide pwm1_enable sysfs file, instead its
now called pwm1_mode.
Please note that the fan was always spinning. It should now turn off, when
there's enough the thermal headroom.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
D-Link DGS-1210-16 hangs when rebooting and has no support for the reset
button.
Fix both by enabling the same GPIOs for reboot and the reset button as
already used for D-Link DGS-1210-20 and D-Link DGS-1210-28.
Signed-off-by: Richard Kunze <kunze@tivano.de>
When rebasing patches on top of 6.1, a change that removed NF_TABLES
from NF_FLOW_TABLE's dependency was dropped accidentally, and iptables
flow offload module can only be built when nftables is selected.
Restore the change to fix it.
Fixes: 19a246bb65 ("generic: 6.1: manually refresh hack patches")
Signed-off-by: Qingfang Deng <dqfext@gmail.com>
Radxa E25 is a network application carrier board for the Radxa CM3
Industrial (CM3I) SoM, which is based on the Rockchip RK3568 SoC.
It has the following features:
- MicroSD card socket, on board eMMC flash
- 2x 2.5GbE Realtek RTL8125B Ethernet transceiver
- 1x USB Type-C port (Power and Serial console)
- 1x USB 3.0 OTG port
- mini PCIe socket (USB or PCIe)
- ngff PCIe socket (USB or SATA)
- 1x User LED and 16x RGB LEDs
- 26-pin expansion header
Installation:
Uncompress the OpenWrt sysupgrade and write it to a micro SD card or
internal eMMC using dd.
Signed-off-by: Marius Durbaca <mariusd84@gmail.com>
Kernel 6.6 has changed the path of WLAN devices as the soc node was updated
to include an adress as well because according to spec it needed one:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/qcom/ipq8074.dtsi?h=v6.6.21&id=da6aa1111a17db11367817ddc10c5a6c188cdc44
So, this will break existing configuration as device path was changed for
example:
"platform/soc/c000000.wifi" to "platform/soc@0/c000000.wifi"
"platform/soc/c000000.wifi+1" to "platform/soc@0/c000000.wifi+1"
PCIe attached devices also have their path changed, so lets add a script
that will migrate the paths based on the detected running kernel version
so returning to kernel 6.1 will work as well.
Co-developed-by: Sean Khan <datapronix@protonmail.com>
Signed-off-by: Robert Marko <robimarko@gmail.com>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Robert Marko <robimarko@gmail.com>
When building MT7629 with ALL_KMODS then we get prompted for
LEDS_SMARTRG_LED and this will break CI and in future buildbot compilation.
It depends on I2C so the symbol is hidden until ALL_KMODS is used and I2C
support is available, so disable the LEDS_SMARTRG_LED symbol in 6.6 config
intentionally as is done in the 6.1 mt7629 config.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Disable CONFIG_CRYPTO_SM4_ARM64_CE_CCM and CONFIG_CRYPTO_SM4_ARM64_CE_GCM
in the generic config like we do with similar CE symbols.
This avoids the need to disable them in individual targets.
Signed-off-by: Robert Marko <robimarko@gmail.com>
* have more defined PWM steps similar to the vendor's shell script doing
the same thing
* replace PWM values with experiencal values provided by forum users
* increase hyteresis to prevent changing fan speed every second
(just because it's annoying to listen to)
* add 'hot' trip point at 75 deg. to warn users that shutdown is imminent
Tested on Puzzle M902 only for now, PWM values for Puzzle M901 might be
slightly different but should quite certainly also be rised.
Suggested-by: Martin Gierschner <martin_gierschner@gmx.de>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The vendor u-boot knows nothing about UBI, and we used to have a
fixed-size kernel partition for vendor u-boot and UBI for rootfs.
However, that fixed partition becomes too small eventually, and
expanding it requires complicated procedure.
This commit changed the flash layout and added a second u-boot
where the kernel supposed to be.
Now the vendor u-boot chainloads our mainline u-boot, and our
u-boot reads kernel+rootfs from UBI, verifies it, and boot
into OpenWrt.
There are two possible ways to convert from the old fw:
Flash the factory image using mtd (provided by @rany2):
mount -o remount,ro /
mount -o remount,ro /overlay
cd /tmp
dd if=factory.bin bs=1M count=4 | mtd write - kernel
dd if=factory.bin bs=1M skip=4 | mtd -r write - ubi
Or, flash the 2nd u-boot via mtd and upload the firmware
to the 2nd u-boot using tftp:
1. prepare a tftp server at 192.168.1.254 to serve the
sysupgrade image:
openwrt-mediatek-mt7622-xiaomi_redmi-router-ax6s-squashfs-sysupgrade.itb
2. upload the ubi-loader.itb to OpenWrt /tmp, and flash it to
the old kernel partition:
mtd -r write openwrt-mediatek-mt7622-xiaomi_redmi-router-ax6s-ubi-loader.itb
3. The router should reboot and flash the sysupgrade image via TFTP.
Procedure for flashing from vendor firmware shouldn't change.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
With kernel 6.1 image size is too large for Edgerouter X current size
limit and is causing the buildbots to fail building so images for other
devices are not updated as well.
So, disable building Edgerouter X images until a workaround is found.
Signed-off-by: Robert Marko <robimarko@gmail.com>
