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>
