openwrt/target/linux/ramips/dts/mt7621_dlink_dir-853-a3.dts

227 lines
3.7 KiB
Plaintext
Raw Normal View History

ramips: add support for D-Link DIR-853 A3 Specifications: * SoC: MT7621AT * RAM: 256MB * Flash: 128MB NAND flash * WiFi: MT7615DN (2.4GHz+5Ghz) with DBDC * LAN: 5x1000M * Firmware layout is Uboot with extra 96 bytes in header * Base PCB is DIR-1360 REV1.0 * LEDs Power Blue+Orange,Wan Blue+Orange,WPS Blue,"2.4G"Blue, "5G" Blue, USB Blue * Buttons Reset,WPS, Wifi MAC addresses on OEM firmware: lan factory 0xe000 f4:*:*:a8:*:65 (label) wan factory 0xe006 f4:*:*:a8:*:68 2.4 GHz [not on flash] f6:*:*:c8:*:66 5.0 GHz factory 0x4 f4:*:*:a8:*:66 The increment of the 4th byte for the 2.4g address appears to vary. Reported cases: 5g 2.4g increment f4:XX:XX:a8:XX:66 f6:XX:XX:c8:XX:66 +0x20 x0:xx:xx:68:xx:xx x2:xx:xx:48:xx:xx -0x20 x4:xx:xx:6a:xx:xx x6:xx:xx:4a:xx:xx -0x20 Since increment is inconsistent and there is no obvious pattern in swapping bytes, and the 2.4g address has local bit set anyway, it seems safer to use the LAN address with flipped byte here in order to prevent collisions between OpenWrt devices and OEM devices for this interface. This way we at least use an address as base that is definitely owned by the device at hand. Flashing instruction: The Dlink "Emergency Room" cannot be accessed through the reset button on this device. You can either use console or use the encrypted factory image availble in the openwrt forum. Once the encrypted image is flashed throuh the stock Dlink web interface, the sysupgrade images can be used. Header pins needs to be soldered near the WPS and Wifi buttons. The layout for the pins is (VCC,RX,TX,GND). No need to connect the VCC. the settings are: Bps/Par/Bits : 57600 8N1 Hardware Flow Control : No Software Flow Control : No Connect your client computer to LAN1 of the device Set your client IP address manually to 192.168.0.101 / 255.255.255.0. Call the recovery page or tftp for the device at http://192.168.0.1 Use the provided emergency web GUI to upload and flash a new firmware to the device At the time of adding support the wireless config needs to be set up by editing the wireless config file: * Setting the country code is mandatory, otherwise the router loses connectivity at the next reboot. This is mandatory and can be done from luci. After setting the country code the router boots correctly. A reset with the reset button will fix the issue and the user has to reconfigure. * This is minor since the 5g interface does not come up online although it is not set as disabled. 2 options here: 1- Either run the "wifi" command. Can be added from LUCI in system - startup - local startup and just add wifi above "exit 0". 2- Or add the serialize option in the wireless config file as shown below. This one would work and bring both interfaces automatically at every boot: config wifi-device 'radio0' option serialize '1' config wifi-device 'radio1' option serialize '1' Signed-off-by: Karim Dehouche <karimdplay@gmail.com> [rebase, improve MAC table, update wireless config comment, fix 2.4g macaddr setup] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-08-18 07:19:16 +00:00
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
#include "mt7621.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
/ {
compatible = "dlink,dir-853-a3", "mediatek,mt7621-soc";
model = "D-Link DIR-853 A3";
aliases {
label-mac-device = &gmac0;
ramips: add support for D-Link DIR-853 A3 Specifications: * SoC: MT7621AT * RAM: 256MB * Flash: 128MB NAND flash * WiFi: MT7615DN (2.4GHz+5Ghz) with DBDC * LAN: 5x1000M * Firmware layout is Uboot with extra 96 bytes in header * Base PCB is DIR-1360 REV1.0 * LEDs Power Blue+Orange,Wan Blue+Orange,WPS Blue,"2.4G"Blue, "5G" Blue, USB Blue * Buttons Reset,WPS, Wifi MAC addresses on OEM firmware: lan factory 0xe000 f4:*:*:a8:*:65 (label) wan factory 0xe006 f4:*:*:a8:*:68 2.4 GHz [not on flash] f6:*:*:c8:*:66 5.0 GHz factory 0x4 f4:*:*:a8:*:66 The increment of the 4th byte for the 2.4g address appears to vary. Reported cases: 5g 2.4g increment f4:XX:XX:a8:XX:66 f6:XX:XX:c8:XX:66 +0x20 x0:xx:xx:68:xx:xx x2:xx:xx:48:xx:xx -0x20 x4:xx:xx:6a:xx:xx x6:xx:xx:4a:xx:xx -0x20 Since increment is inconsistent and there is no obvious pattern in swapping bytes, and the 2.4g address has local bit set anyway, it seems safer to use the LAN address with flipped byte here in order to prevent collisions between OpenWrt devices and OEM devices for this interface. This way we at least use an address as base that is definitely owned by the device at hand. Flashing instruction: The Dlink "Emergency Room" cannot be accessed through the reset button on this device. You can either use console or use the encrypted factory image availble in the openwrt forum. Once the encrypted image is flashed throuh the stock Dlink web interface, the sysupgrade images can be used. Header pins needs to be soldered near the WPS and Wifi buttons. The layout for the pins is (VCC,RX,TX,GND). No need to connect the VCC. the settings are: Bps/Par/Bits : 57600 8N1 Hardware Flow Control : No Software Flow Control : No Connect your client computer to LAN1 of the device Set your client IP address manually to 192.168.0.101 / 255.255.255.0. Call the recovery page or tftp for the device at http://192.168.0.1 Use the provided emergency web GUI to upload and flash a new firmware to the device At the time of adding support the wireless config needs to be set up by editing the wireless config file: * Setting the country code is mandatory, otherwise the router loses connectivity at the next reboot. This is mandatory and can be done from luci. After setting the country code the router boots correctly. A reset with the reset button will fix the issue and the user has to reconfigure. * This is minor since the 5g interface does not come up online although it is not set as disabled. 2 options here: 1- Either run the "wifi" command. Can be added from LUCI in system - startup - local startup and just add wifi above "exit 0". 2- Or add the serialize option in the wireless config file as shown below. This one would work and bring both interfaces automatically at every boot: config wifi-device 'radio0' option serialize '1' config wifi-device 'radio1' option serialize '1' Signed-off-by: Karim Dehouche <karimdplay@gmail.com> [rebase, improve MAC table, update wireless config comment, fix 2.4g macaddr setup] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-08-18 07:19:16 +00:00
led-boot = &led_power_orange;
led-failsafe = &led_power_blue;
led-running = &led_power_blue;
led-upgrade = &led_net_orange;
};
keys {
compatible = "gpio-keys";
reset {
label = "reset";
gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
linux,code = <KEY_RESTART>;
};
wps {
label = "wps";
gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
linux,code = <KEY_WPS_BUTTON>;
};
wifi {
label = "wifi";
gpios = <&gpio 7 GPIO_ACTIVE_LOW>;
linux,code = <KEY_RFKILL>;
};
};
leds {
compatible = "gpio-leds";
led_power_orange: power_orange {
label = "orange:power";
gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
};
led_power_blue: power_blue {
label = "blue:power";
gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
};
led_net_orange: net_orange {
label = "orange:net";
gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
};
net_blue {
label = "blue:net";
gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
};
usb_blue {
label = "blue:usb";
gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
trigger-sources = <&xhci_ehci_port1>;
linux,default-trigger = "usbport";
};
wlan2g {
label = "blue:wlan2g";
gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
linux,default-trigger = "phy0radio";
};
wlan5g {
label = "blue:wlan5g";
gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
linux,default-trigger = "phy1radio";
};
};
};
&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 = "config";
reg = <0x80000 0x80000>;
read-only;
};
factory: partition@100000 {
label = "factory";
reg = <0x100000 0x40000>;
read-only;
};
partition@140000 {
label = "config2";
reg = <0x140000 0x40000>;
read-only;
};
partition@180000 {
label = "firmware";
compatible = "openwrt,uimage", "denx,uimage";
openwrt,padding = <96>;
reg = <0x180000 0x2800000>;
};
partition@2980000 {
label = "private";
reg = <0x2980000 0x2000000>;
read-only;
};
partition@4980000 {
label = "firmware2";
reg = <0x4980000 0x2800000>;
};
partition@7180000 {
label = "mydlink";
reg = <0x7180000 0x600000>;
read-only;
};
partition@7780000 {
label = "reserved";
reg = <0x7780000 0x880000>;
read-only;
};
};
};
&pcie {
status = "okay";
};
&pcie0 {
wifi@0,0 {
compatible = "mediatek,mt76";
reg = <0x0000 0 0 0 0>;
mediatek,mtd-eeprom = <&factory 0x0>;
/* 5 GHz (phy1) does not take the address from calibration data,
but setting it manually here works */
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_4>;
nvmem-cell-names = "mac-address";
ramips: add support for D-Link DIR-853 A3 Specifications: * SoC: MT7621AT * RAM: 256MB * Flash: 128MB NAND flash * WiFi: MT7615DN (2.4GHz+5Ghz) with DBDC * LAN: 5x1000M * Firmware layout is Uboot with extra 96 bytes in header * Base PCB is DIR-1360 REV1.0 * LEDs Power Blue+Orange,Wan Blue+Orange,WPS Blue,"2.4G"Blue, "5G" Blue, USB Blue * Buttons Reset,WPS, Wifi MAC addresses on OEM firmware: lan factory 0xe000 f4:*:*:a8:*:65 (label) wan factory 0xe006 f4:*:*:a8:*:68 2.4 GHz [not on flash] f6:*:*:c8:*:66 5.0 GHz factory 0x4 f4:*:*:a8:*:66 The increment of the 4th byte for the 2.4g address appears to vary. Reported cases: 5g 2.4g increment f4:XX:XX:a8:XX:66 f6:XX:XX:c8:XX:66 +0x20 x0:xx:xx:68:xx:xx x2:xx:xx:48:xx:xx -0x20 x4:xx:xx:6a:xx:xx x6:xx:xx:4a:xx:xx -0x20 Since increment is inconsistent and there is no obvious pattern in swapping bytes, and the 2.4g address has local bit set anyway, it seems safer to use the LAN address with flipped byte here in order to prevent collisions between OpenWrt devices and OEM devices for this interface. This way we at least use an address as base that is definitely owned by the device at hand. Flashing instruction: The Dlink "Emergency Room" cannot be accessed through the reset button on this device. You can either use console or use the encrypted factory image availble in the openwrt forum. Once the encrypted image is flashed throuh the stock Dlink web interface, the sysupgrade images can be used. Header pins needs to be soldered near the WPS and Wifi buttons. The layout for the pins is (VCC,RX,TX,GND). No need to connect the VCC. the settings are: Bps/Par/Bits : 57600 8N1 Hardware Flow Control : No Software Flow Control : No Connect your client computer to LAN1 of the device Set your client IP address manually to 192.168.0.101 / 255.255.255.0. Call the recovery page or tftp for the device at http://192.168.0.1 Use the provided emergency web GUI to upload and flash a new firmware to the device At the time of adding support the wireless config needs to be set up by editing the wireless config file: * Setting the country code is mandatory, otherwise the router loses connectivity at the next reboot. This is mandatory and can be done from luci. After setting the country code the router boots correctly. A reset with the reset button will fix the issue and the user has to reconfigure. * This is minor since the 5g interface does not come up online although it is not set as disabled. 2 options here: 1- Either run the "wifi" command. Can be added from LUCI in system - startup - local startup and just add wifi above "exit 0". 2- Or add the serialize option in the wireless config file as shown below. This one would work and bring both interfaces automatically at every boot: config wifi-device 'radio0' option serialize '1' config wifi-device 'radio1' option serialize '1' Signed-off-by: Karim Dehouche <karimdplay@gmail.com> [rebase, improve MAC table, update wireless config comment, fix 2.4g macaddr setup] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-08-18 07:19:16 +00:00
};
};
&gmac0 {
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_e000>;
nvmem-cell-names = "mac-address";
ramips: add support for D-Link DIR-853 A3 Specifications: * SoC: MT7621AT * RAM: 256MB * Flash: 128MB NAND flash * WiFi: MT7615DN (2.4GHz+5Ghz) with DBDC * LAN: 5x1000M * Firmware layout is Uboot with extra 96 bytes in header * Base PCB is DIR-1360 REV1.0 * LEDs Power Blue+Orange,Wan Blue+Orange,WPS Blue,"2.4G"Blue, "5G" Blue, USB Blue * Buttons Reset,WPS, Wifi MAC addresses on OEM firmware: lan factory 0xe000 f4:*:*:a8:*:65 (label) wan factory 0xe006 f4:*:*:a8:*:68 2.4 GHz [not on flash] f6:*:*:c8:*:66 5.0 GHz factory 0x4 f4:*:*:a8:*:66 The increment of the 4th byte for the 2.4g address appears to vary. Reported cases: 5g 2.4g increment f4:XX:XX:a8:XX:66 f6:XX:XX:c8:XX:66 +0x20 x0:xx:xx:68:xx:xx x2:xx:xx:48:xx:xx -0x20 x4:xx:xx:6a:xx:xx x6:xx:xx:4a:xx:xx -0x20 Since increment is inconsistent and there is no obvious pattern in swapping bytes, and the 2.4g address has local bit set anyway, it seems safer to use the LAN address with flipped byte here in order to prevent collisions between OpenWrt devices and OEM devices for this interface. This way we at least use an address as base that is definitely owned by the device at hand. Flashing instruction: The Dlink "Emergency Room" cannot be accessed through the reset button on this device. You can either use console or use the encrypted factory image availble in the openwrt forum. Once the encrypted image is flashed throuh the stock Dlink web interface, the sysupgrade images can be used. Header pins needs to be soldered near the WPS and Wifi buttons. The layout for the pins is (VCC,RX,TX,GND). No need to connect the VCC. the settings are: Bps/Par/Bits : 57600 8N1 Hardware Flow Control : No Software Flow Control : No Connect your client computer to LAN1 of the device Set your client IP address manually to 192.168.0.101 / 255.255.255.0. Call the recovery page or tftp for the device at http://192.168.0.1 Use the provided emergency web GUI to upload and flash a new firmware to the device At the time of adding support the wireless config needs to be set up by editing the wireless config file: * Setting the country code is mandatory, otherwise the router loses connectivity at the next reboot. This is mandatory and can be done from luci. After setting the country code the router boots correctly. A reset with the reset button will fix the issue and the user has to reconfigure. * This is minor since the 5g interface does not come up online although it is not set as disabled. 2 options here: 1- Either run the "wifi" command. Can be added from LUCI in system - startup - local startup and just add wifi above "exit 0". 2- Or add the serialize option in the wireless config file as shown below. This one would work and bring both interfaces automatically at every boot: config wifi-device 'radio0' option serialize '1' config wifi-device 'radio1' option serialize '1' Signed-off-by: Karim Dehouche <karimdplay@gmail.com> [rebase, improve MAC table, update wireless config comment, fix 2.4g macaddr setup] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-08-18 07:19:16 +00:00
};
&switch0 {
ports {
port@0 {
status = "okay";
label = "lan4";
};
port@1 {
status = "okay";
label = "lan3";
};
port@2 {
status = "okay";
label = "lan2";
};
port@3 {
status = "okay";
label = "lan1";
};
port@4 {
status = "okay";
label = "wan";
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_e006>;
nvmem-cell-names = "mac-address";
ramips: add support for D-Link DIR-853 A3 Specifications: * SoC: MT7621AT * RAM: 256MB * Flash: 128MB NAND flash * WiFi: MT7615DN (2.4GHz+5Ghz) with DBDC * LAN: 5x1000M * Firmware layout is Uboot with extra 96 bytes in header * Base PCB is DIR-1360 REV1.0 * LEDs Power Blue+Orange,Wan Blue+Orange,WPS Blue,"2.4G"Blue, "5G" Blue, USB Blue * Buttons Reset,WPS, Wifi MAC addresses on OEM firmware: lan factory 0xe000 f4:*:*:a8:*:65 (label) wan factory 0xe006 f4:*:*:a8:*:68 2.4 GHz [not on flash] f6:*:*:c8:*:66 5.0 GHz factory 0x4 f4:*:*:a8:*:66 The increment of the 4th byte for the 2.4g address appears to vary. Reported cases: 5g 2.4g increment f4:XX:XX:a8:XX:66 f6:XX:XX:c8:XX:66 +0x20 x0:xx:xx:68:xx:xx x2:xx:xx:48:xx:xx -0x20 x4:xx:xx:6a:xx:xx x6:xx:xx:4a:xx:xx -0x20 Since increment is inconsistent and there is no obvious pattern in swapping bytes, and the 2.4g address has local bit set anyway, it seems safer to use the LAN address with flipped byte here in order to prevent collisions between OpenWrt devices and OEM devices for this interface. This way we at least use an address as base that is definitely owned by the device at hand. Flashing instruction: The Dlink "Emergency Room" cannot be accessed through the reset button on this device. You can either use console or use the encrypted factory image availble in the openwrt forum. Once the encrypted image is flashed throuh the stock Dlink web interface, the sysupgrade images can be used. Header pins needs to be soldered near the WPS and Wifi buttons. The layout for the pins is (VCC,RX,TX,GND). No need to connect the VCC. the settings are: Bps/Par/Bits : 57600 8N1 Hardware Flow Control : No Software Flow Control : No Connect your client computer to LAN1 of the device Set your client IP address manually to 192.168.0.101 / 255.255.255.0. Call the recovery page or tftp for the device at http://192.168.0.1 Use the provided emergency web GUI to upload and flash a new firmware to the device At the time of adding support the wireless config needs to be set up by editing the wireless config file: * Setting the country code is mandatory, otherwise the router loses connectivity at the next reboot. This is mandatory and can be done from luci. After setting the country code the router boots correctly. A reset with the reset button will fix the issue and the user has to reconfigure. * This is minor since the 5g interface does not come up online although it is not set as disabled. 2 options here: 1- Either run the "wifi" command. Can be added from LUCI in system - startup - local startup and just add wifi above "exit 0". 2- Or add the serialize option in the wireless config file as shown below. This one would work and bring both interfaces automatically at every boot: config wifi-device 'radio0' option serialize '1' config wifi-device 'radio1' option serialize '1' Signed-off-by: Karim Dehouche <karimdplay@gmail.com> [rebase, improve MAC table, update wireless config comment, fix 2.4g macaddr setup] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-08-18 07:19:16 +00:00
};
};
};
&state_default {
gpio {
groups = "i2c", "uart2", "uart3", "jtag", "wdt";
function = "gpio";
};
};
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_4: macaddr@4 {
reg = <0x4 0x6>;
};
macaddr_factory_e000: macaddr@e000 {
reg = <0xe000 0x6>;
};
macaddr_factory_e006: macaddr@e006 {
reg = <0xe006 0x6>;
};
};