openwrt/target/linux/ramips/dts/rt5350_asiarf_awm002-evb.dtsi

115 lines
1.8 KiB
Plaintext
Raw Normal View History

#include "rt5350.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
/ {
compatible = "asiarf,awm002-evb", "ralink,rt5350-soc";
leds {
compatible = "gpio-leds";
tx {
label = "green:tx";
gpios = <&gpio0 15 GPIO_ACTIVE_LOW>;
};
rx {
label = "green:rx";
gpios = <&gpio0 16 GPIO_ACTIVE_LOW>;
};
wps {
label = "green:wps";
gpios = <&gpio0 21 GPIO_ACTIVE_LOW>;
};
};
keys {
compatible = "gpio-keys-polled";
poll-interval = <20>;
reset_wps {
label = "reset_wps";
gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
linux,code = <KEY_RESTART>;
};
mode {
label = "mode";
gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
linux,code = <BTN_0>;
};
};
};
ramips: convert most mtd-mac-address cases in DTSI to nvmem Convert most of the cases from mtd-mac-address to nvmem where MAC addresses are set in the DTSI, but the partitions are only located in the device DTS. This posed some problems earlier, since in these cases we are using partitions before they are defined, and the nvmem system did not seem to like that. There have been a few different resolution approaches, based on the different tradeoffs of deduplication vs. maintainability: 1. In many cases, the partition tables were identical except for the firmware partition size, and the firmware partition was the last in the table. In these cases, the partition table has been moved to the DTSI, and only the firmware partition's "reg" property has been kept in the DTS files. So, the updated nvmem definition could stay in the DTSI files as well. 2. For all other cases, splitting up the partition table would have introduced additional complexity. Thus, the nodes to be converted to nvmem have been moved to the DTS files where the partitioning was defined. 3. For Netgear EX2700 and WN3000RP v3, the remaining DTSI file was completely dissolved, as it was quite small and the name was not really nice either. 4. The D-Link DIR-853 A3 was converted to nvmem as well, though it is just a plain DTS file not taken care of in the first wave. In addition, some minor rearrangements have been made for tidyness. Not covered (yet) by this patch are: * Various unielec devices * The D-Link DIR-8xx family Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2021-08-17 18:53:27 +00:00
&spi0 {
status = "okay";
flash@0 {
reg = <0>;
compatible = "jedec,spi-nor";
spi-max-frequency = <10000000>;
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "u-boot";
reg = <0x0 0x30000>;
read-only;
};
partition@30000 {
label = "u-boot-env";
reg = <0x30000 0x10000>;
read-only;
};
factory: partition@40000 {
label = "factory";
reg = <0x40000 0x10000>;
read-only;
};
firmware: partition@50000 {
compatible = "denx,uimage";
label = "firmware";
/* reg property is set based on flash size in DTS files */
};
};
};
};
&ethernet {
ramips: convert most mtd-mac-address cases in DTSI to nvmem Convert most of the cases from mtd-mac-address to nvmem where MAC addresses are set in the DTSI, but the partitions are only located in the device DTS. This posed some problems earlier, since in these cases we are using partitions before they are defined, and the nvmem system did not seem to like that. There have been a few different resolution approaches, based on the different tradeoffs of deduplication vs. maintainability: 1. In many cases, the partition tables were identical except for the firmware partition size, and the firmware partition was the last in the table. In these cases, the partition table has been moved to the DTSI, and only the firmware partition's "reg" property has been kept in the DTS files. So, the updated nvmem definition could stay in the DTSI files as well. 2. For all other cases, splitting up the partition table would have introduced additional complexity. Thus, the nodes to be converted to nvmem have been moved to the DTS files where the partitioning was defined. 3. For Netgear EX2700 and WN3000RP v3, the remaining DTSI file was completely dissolved, as it was quite small and the name was not really nice either. 4. The D-Link DIR-853 A3 was converted to nvmem as well, though it is just a plain DTS file not taken care of in the first wave. In addition, some minor rearrangements have been made for tidyness. Not covered (yet) by this patch are: * Various unielec devices * The D-Link DIR-8xx family Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2021-08-17 18:53:27 +00:00
nvmem-cells = <&macaddr_factory_28>;
nvmem-cell-names = "mac-address";
};
&wmac {
ralink,mtd-eeprom = <&factory 0x0>;
};
&state_default {
gpio {
groups = "i2c", "jtag";
function = "gpio";
};
};
&esw {
mediatek,portmap = <0x3f>;
};
ramips: convert most mtd-mac-address cases in DTSI to nvmem Convert most of the cases from mtd-mac-address to nvmem where MAC addresses are set in the DTSI, but the partitions are only located in the device DTS. This posed some problems earlier, since in these cases we are using partitions before they are defined, and the nvmem system did not seem to like that. There have been a few different resolution approaches, based on the different tradeoffs of deduplication vs. maintainability: 1. In many cases, the partition tables were identical except for the firmware partition size, and the firmware partition was the last in the table. In these cases, the partition table has been moved to the DTSI, and only the firmware partition's "reg" property has been kept in the DTS files. So, the updated nvmem definition could stay in the DTSI files as well. 2. For all other cases, splitting up the partition table would have introduced additional complexity. Thus, the nodes to be converted to nvmem have been moved to the DTS files where the partitioning was defined. 3. For Netgear EX2700 and WN3000RP v3, the remaining DTSI file was completely dissolved, as it was quite small and the name was not really nice either. 4. The D-Link DIR-853 A3 was converted to nvmem as well, though it is just a plain DTS file not taken care of in the first wave. In addition, some minor rearrangements have been made for tidyness. Not covered (yet) by this patch are: * Various unielec devices * The D-Link DIR-8xx family Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2021-08-17 18:53:27 +00:00
&factory {
compatible = "nvmem-cells";
#address-cells = <1>;
#size-cells = <1>;
macaddr_factory_28: macaddr@28 {
reg = <0x28 0x6>;
};
};