2022-12-15 01:26:38 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
|
|
|
|
#include "mt7621.dtsi"
|
|
|
|
|
|
|
|
#include <dt-bindings/gpio/gpio.h>
|
|
|
|
#include <dt-bindings/input/input.h>
|
|
|
|
#include <dt-bindings/leds/common.h>
|
|
|
|
|
|
|
|
/ {
|
|
|
|
model = "TP-Link ER605 v2";
|
|
|
|
compatible = "tplink,er605-v2", "mediatek,mt7621-soc";
|
|
|
|
|
|
|
|
chosen {
|
|
|
|
bootargs = "console=ttyS0,115200 noinitrd";
|
ramips: Fix root volume for tplink-er605-v2
This device has two sets of volumes: main ones (`kernel`, `rootfs`, etc) and
'backup' (`kernel.b`, `rootfs.b`, etc). Bootloader tries to determine which set of
volumes to use by looking at contens of `extra-para` and `extra-para.b` volumes.
These volumes contain JSON that looks like this:
```
{
"dbootFlag": "1",
"integerFlag": "1",
"fwFlag": "GOOD",
"score":1
}
```
It looks like the bootloader looks for `"fwFlag": "GOOD"` (as opposed to `BAD`)
then it compares `score` field - whichever 'good' volume has bigger score wins.
This determines which set of volumes to use to boot.
So for example if `extra-para` is good and has bigger score then `kernel`,
`rootfs`, etc volumes are used. This means bootloader needs to explain to the
kernel which volume to use for the rootfs. After looking at bootloader code with
disassembler I think it contains a bug. Relevant part of code looks something
like this:
```
if (image_id == 0) {
rootfs_volume_id = 8;
rootfs_volume_name = "rootfs";
}
else {
rootfs_volume_id = 0xf;
rootfs_volume_name = "rootfs.b";
}
sprintf(
&buffer,
0x800,
"console=ttyS0,115200 noinitrd ubi.mtd=3,2048 ubi.block=0,%s
root=/dev/ubiblock0_%d DKMGT_IMAGE_ID=%d DKMGT_IMAGE_TYPE=ubi",
rootfs_volume_name,
rootfs_volume_id,
image_id
);
```
Where `image_id == 0` if 'normal' (not '*.b' set of volumes is used).
However from device dumps we know that from the factory `rootfs.b` has id 8 and
`rootfs` has id 15.
So from above we can see that ids and names of rootfs volumes do not match. More
over - they are hardcoded in the bootloader.
Both things are problematic for OpwnWRT which completely removes volumes on
update meaning that volume ids may actually change.
So instead of relying on bootloader to provide the kernel with root device this
patch forces kernel to determine root automatically - and it defaults to
`rootfs` volume which is correct for our purposes.
Overall this makes image boot fine from flash after sysupgrade from inirams.
assuming `extra-para*` volumes make bootloader use non-'*.b' set of volumes.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
2023-01-07 03:44:10 +00:00
|
|
|
// Override bootargs because u-boot passes wrong root parameter.
|
|
|
|
// Instead allow kernel determine root automatically by looking for rootfs volume
|
|
|
|
bootargs-override = "console=ttyS0,115200 noinitrd ubi.mtd=3,2048";
|
2022-12-15 01:26:38 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
aliases {
|
|
|
|
led-boot = &led_system;
|
|
|
|
led-failsafe = &led_system;
|
|
|
|
led-running = &led_system;
|
|
|
|
led-upgrade = &led_system;
|
|
|
|
label-mac-device = &gmac0;
|
|
|
|
};
|
|
|
|
|
|
|
|
leds {
|
|
|
|
compatible = "gpio-leds";
|
|
|
|
|
|
|
|
led_usb: usb {
|
|
|
|
color = <LED_COLOR_ID_GREEN>;
|
2024-10-05 06:56:43 +00:00
|
|
|
function = LED_FUNCTION_USB;
|
2022-12-15 01:26:38 +00:00
|
|
|
gpios = <&gpio 11 GPIO_ACTIVE_HIGH>;
|
|
|
|
};
|
|
|
|
|
|
|
|
led_power: power {
|
|
|
|
color = <LED_COLOR_ID_GREEN>;
|
2024-10-05 06:56:43 +00:00
|
|
|
function = LED_FUNCTION_POWER;
|
2022-12-15 01:26:38 +00:00
|
|
|
gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
|
|
|
|
default-state = "on";
|
|
|
|
};
|
|
|
|
|
|
|
|
led_system: system {
|
|
|
|
color = <LED_COLOR_ID_GREEN>;
|
|
|
|
function = LED_FUNCTION_STATUS;
|
|
|
|
gpios = <&gpio 7 GPIO_ACTIVE_HIGH>;
|
|
|
|
default-state = "keep";
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
keys {
|
|
|
|
compatible = "gpio-keys";
|
|
|
|
|
|
|
|
reset {
|
|
|
|
label = "reset button";
|
|
|
|
gpios = <&gpio 8 GPIO_ACTIVE_HIGH>;
|
|
|
|
linux,code = <KEY_RESTART>;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
reg_usb_vbus: regulator-usb {
|
|
|
|
compatible = "regulator-fixed";
|
|
|
|
regulator-name = "usb_vbus";
|
|
|
|
regulator-min-microvolt = <5000000>;
|
|
|
|
regulator-max-microvolt = <5000000>;
|
2024-06-10 23:49:29 +00:00
|
|
|
gpios = <&gpio 10 GPIO_ACTIVE_HIGH>;
|
2022-12-15 01:26:38 +00:00
|
|
|
enable-active-high;
|
|
|
|
};
|
|
|
|
|
|
|
|
reg_3p3v: regulator-3p3v {
|
|
|
|
compatible = "regulator-fixed";
|
|
|
|
regulator-name = "fixed-3.3V";
|
|
|
|
regulator-min-microvolt = <3300000>;
|
|
|
|
regulator-max-microvolt = <3300000>;
|
|
|
|
regulator-boot-on;
|
|
|
|
regulator-always-on;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
&gmac0 {
|
|
|
|
label = "dsa";
|
|
|
|
};
|
|
|
|
|
|
|
|
&gmac1 {
|
|
|
|
status = "okay";
|
2024-07-04 03:21:52 +00:00
|
|
|
label = "wan1";
|
2022-12-15 01:26:38 +00:00
|
|
|
phy-handle = <ðphy0>;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
&switch0 {
|
|
|
|
ports {
|
|
|
|
port@0 {
|
|
|
|
status = "disabled";
|
|
|
|
};
|
|
|
|
|
|
|
|
port@1 {
|
|
|
|
status = "okay";
|
2024-07-04 03:21:52 +00:00
|
|
|
label = "lan2";
|
2022-12-15 01:26:38 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
port@2 {
|
|
|
|
status = "okay";
|
2024-07-04 03:21:52 +00:00
|
|
|
label = "lan3";
|
2022-12-15 01:26:38 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
port@3 {
|
|
|
|
status = "okay";
|
2024-07-04 03:21:52 +00:00
|
|
|
label = "lan4";
|
2022-12-15 01:26:38 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
port@4 {
|
|
|
|
status = "okay";
|
2024-07-04 03:21:52 +00:00
|
|
|
label = "lan5";
|
2022-12-15 01:26:38 +00:00
|
|
|
};
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
&nand {
|
|
|
|
status = "okay";
|
|
|
|
|
|
|
|
partitions {
|
|
|
|
compatible = "fixed-partitions";
|
|
|
|
#address-cells = <1>;
|
|
|
|
#size-cells = <1>;
|
|
|
|
|
|
|
|
partition@0 {
|
|
|
|
label = "u-boot";
|
|
|
|
reg = <0x0 0x80000>;
|
|
|
|
read-only;
|
|
|
|
};
|
|
|
|
|
|
|
|
partition@80000 {
|
|
|
|
label = "u-boot-env";
|
|
|
|
reg = <0x80000 0x80000>;
|
|
|
|
read-only;
|
|
|
|
};
|
|
|
|
|
2024-02-17 14:10:10 +00:00
|
|
|
partition@100000 {
|
2022-12-15 01:26:38 +00:00
|
|
|
label = "factory";
|
|
|
|
reg = <0x100000 0x40000>;
|
|
|
|
read-only;
|
|
|
|
};
|
|
|
|
|
|
|
|
partition@140000 {
|
|
|
|
label = "firmware";
|
|
|
|
reg = <0x140000 0x7cc0000>;
|
|
|
|
};
|
|
|
|
|
|
|
|
partition@7e00000 {
|
|
|
|
label = "panic-ops";
|
|
|
|
reg = <0x7e00000 0x200000>;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
ramips: mt7621-dts: describe switch PHYs and adjust PHY muxing
Currently, the MT7530 DSA subdriver configures the MT7530 switch to provide
direct access to switch PHYs, meaning, the switch PHYs listen on the MDIO
bus the switch listens on. The PHY muxing feature makes use of this.
This is problematic as the PHY may be attached before the switch is
initialised, in which case, the PHY will fail to be attached.
Since commit 91374ba537bd ("net: dsa: mt7530: support OF-based registration
of switch MDIO bus") on mainline Linux, we can describe the switch PHYs on
the MDIO bus of the switch on the device tree.
When the PHY is described this way, the switch will be initialised first,
then the switch MDIO bus will be registered. Only after these steps, the
PHY will be attached.
Describe the switch PHYs on mt7621.dtsi and remove defining the switch PHY
on the SoC's mdio bus node. When the PHY muxing is in use, the interrupts
for the muxed PHY won't work, therefore delete the "interrupts" property on
the devices where the PHY muxing feature is in use.
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
2024-04-28 19:52:51 +00:00
|
|
|
ðphy0 {
|
|
|
|
/delete-property/ interrupts;
|
2022-12-15 01:26:38 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
&state_default {
|
|
|
|
gpio {
|
|
|
|
groups = "uart2", "uart3", "pcie", "jtag";
|
|
|
|
function = "gpio";
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
&spi0 {
|
|
|
|
status = "disabled";
|
|
|
|
};
|
|
|
|
|
|
|
|
&xhci {
|
|
|
|
vusb33-supply = <®_3p3v>;
|
|
|
|
vbus-supply = <®_usb_vbus>;
|
|
|
|
};
|
|
|
|
|