You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

307 lines
5.2 KiB

#include "vr9.dtsi"
#include <dt-bindings/input/input.h>
#include <dt-bindings/mips/lantiq_rcu_gphy.h>
/ {
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
compatible = "avm,fritz3370-rev2", "lantiq,xway", "lantiq,vr9";
model = "AVM Fritz!Box WLAN 3370 Rev. 2";
chosen {
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
bootargs = "console=ttyLTQ0,115200";
};
aliases {
led-boot = &power_green;
led-failsafe = &power_red;
led-running = &power_green;
led-upgrade = &power_green;
led-dsl = &dsl;
led-internet = &info_green;
led-wifi = &wifi;
};
memory@0 {
reg = <0x0 0x8000000>;
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
gpio-poweroff {
compatible = "gpio-poweroff";
gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
};
gpio-keys-polled {
compatible = "gpio-keys-polled";
#address-cells = <1>;
#size-cells = <0>;
poll-interval = <100>;
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
power {
label = "power";
gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
linux,code = <KEY_POWER>;
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
wifi {
label = "wlan";
gpios = <&gpio 29 GPIO_ACTIVE_HIGH>;
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
linux,code = <KEY_WLAN>;
};
};
gpio-leds {
compatible = "gpio-leds";
power_green: power {
label = "fritz3370:green:power";
gpios = <&gpio 32 GPIO_ACTIVE_LOW>;
default-state = "keep";
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
power_red: power2 {
label = "fritz3370:red:power";
gpios = <&gpio 33 GPIO_ACTIVE_LOW>;
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
info_red {
label = "fritz3370:red:info";
gpios = <&gpio 34 GPIO_ACTIVE_LOW>;
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
wifi: wifi {
label = "fritz3370:green:wlan";
gpios = <&gpio 35 GPIO_ACTIVE_LOW>;
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
dsl: dsl {
label = "fritz3370:green:dsl";
gpios = <&gpio 36 GPIO_ACTIVE_LOW>;
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
lan {
label = "fritz3370:green:lan";
gpios = <&gpio 38 GPIO_ACTIVE_LOW>;
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
info_green: info_green {
label = "fritz3370:green:info";
gpios = <&gpio 47 GPIO_ACTIVE_LOW>;
};
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
usb0_vbus: regulator-usb0-vbus {
compatible = "regulator-fixed";
regulator-name = "USB0_VBUS";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
gpio = <&gpio 14 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
usb1_vbus: regulator-usb1-vbus {
compatible = "regulator-fixed";
regulator-name = "USB1_VBUS";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
gpio = <&gpio 5 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
};
&eth0 {
lan: interface@0 {
compatible = "lantiq,xrx200-pdi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
lantiq,switch;
ethernet@0 {
compatible = "lantiq,xrx200-pdi-port";
reg = <0>;
phy-mode = "rgmii";
phy-handle = <&phy0>;
gpios = <&gpio 37 GPIO_ACTIVE_HIGH>;
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
ethernet@1 {
compatible = "lantiq,xrx200-pdi-port";
reg = <1>;
phy-mode = "rgmii";
phy-handle = <&phy1>;
gpios = <&gpio 44 GPIO_ACTIVE_HIGH>;
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
ethernet@2 {
compatible = "lantiq,xrx200-pdi-port";
reg = <2>;
phy-mode = "gmii";
phy-handle = <&phy11>;
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
ethernet@4 {
compatible = "lantiq,xrx200-pdi-port";
reg = <4>;
phy-mode = "gmii";
phy-handle = <&phy13>;
};
};
mdio@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "lantiq,xrx200-mdio";
reg = <0>;
phy0: ethernet-phy@0 {
reg = <0x0>;
compatible = "lantiq,phy11g", "ethernet-phy-ieee802.3-c22";
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
phy1: ethernet-phy@1 {
reg = <0x1>;
compatible = "lantiq,phy11g", "ethernet-phy-ieee802.3-c22";
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
phy11: ethernet-phy@11 {
reg = <0x11>;
compatible = "lantiq,phy11g", "ethernet-phy-ieee802.3-c22";
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
phy13: ethernet-phy@13 {
reg = <0x13>;
compatible = "lantiq,phy11g", "ethernet-phy-ieee802.3-c22";
};
};
};
&gphy0 {
lantiq,gphy-mode = <GPHY_MODE_GE>;
};
&gphy1 {
lantiq,gphy-mode = <GPHY_MODE_GE>;
};
&gpio {
pinctrl-names = "default";
pinctrl-0 = <&state_default>;
state_default: pinmux {
mdio {
lantiq,groups = "mdio";
lantiq,function = "mdio";
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
nand {
lantiq,groups = "nand cle", "nand ale",
"nand rd", "nand cs1", "nand rdy";
lantiq,function = "ebu";
lantiq,pull = <1>;
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
phy-rst {
lantiq,pins = "io37", "io44";
lantiq,pull = <0>;
lantiq,open-drain = <0>;
lantiq,output = <1>;
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
pcie-rst {
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
lantiq,pins = "io21";
lantiq,pull = <0>;
lantiq,output = <1>;
};
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
pins_spi_default: pins_spi_default {
spi_in {
lantiq,groups = "spi_di";
lantiq,function = "spi";
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
spi_out {
lantiq,groups = "spi_do", "spi_clk",
"spi_cs4";
lantiq,function = "spi";
lantiq,output = <1>;
};
};
};
&pcie0 {
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
gpio-reset = <&gpio 21 GPIO_ACTIVE_HIGH>;
pcie@0 {
reg = <0 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
wifi@0,0 {
compatible = "pci0,0";
reg = <0 0 0 0 0>;
qca,no-eeprom; /* load from ath9k-eeprom-pci-0000:01:00.0.bin */
};
};
};
&spi {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&pins_spi_default>;
m25p80@4 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
reg = <4 0>;
spi-max-frequency = <1000000>;
urlader: partition@0 {
reg = <0x0 0x20000>;
label = "urlader";
read-only;
};
partition@20000 {
reg = <0x20000 0x10000>;
label = "tffs (1)";
read-only;
};
partition@30000 {
reg = <0x30000 0x10000>;
label = "tffs (2)";
read-only;
};
};
};
&usb_phy0 {
status = "okay";
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
};
&usb_phy1 {
status = "okay";
};
&usb0 {
status = "okay";
vbus-supply = <&usb0_vbus>;
};
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
&usb1 {
status = "okay";
vbus-supply = <&usb1_vbus>;
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
8 years ago
};