KumiSystems/openwrtv4
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
openwrtv4/target/linux/mpc85xx/base-files/etc/uci-defaults/02_network

34 lines
709 B
Text
Raw Normal View History

mpc85xx: add user-space support for the TL-WDR4900 v1 Signed-off-by: Gabor Juhos <juhosg@openwrt.org> SVN-Revision: 35733
2013-02-21 19:20:34 +00:00
#!/bin/sh
mpc85xx: fix WAN/LAN-MAC for TP-LINK TL-WDR4900 v1 This works around a bootloader issue where every device has the same lan/wan-mac 00:04:9f:ef:01:01 - with this patch we read the macs from config-partition during initial network setup. We have 9 valid macs stored in the partition, the 1st two are used for the radios, 3 and 4 are now used for WAN/LAN. on an already setup / running device we can get the real macs with . /lib/functions.sh . /lib/functions/system.sh echo "LAN = $(mtd_get_mac_binary config 338)" echo "WAN = $(mtd_get_mac_binary config 344)" see: https://dev.openwrt.org/ticket/14714 from the ticket / user klondike: U-Boot passed this commit https://gitorious.org/0xlab-kernel/u-boot/commit/ecd1a09b81f2ed6e6ba7bd1d0bfb0cc3d0ea2ad0 http://u-boot.10912.n7.nabble.com/U-Boot-PATCH-mpc83xx-remove-hardcoded-network-addresses-from-config-files-td44372.html I suppose to prevent this particular issue, but the WDR4900 may be using an old bootloader still affected. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I have been checking the contents of the dtb on the flash, this particular bit is quite revealing: ethernet@b0000 { #address-cells = <0x1>; #size-cells = <0x1>; device_type = "network"; model = "eTSEC"; compatible = "fsl,etsec2"; fsl,num_rx_queues = <0x8>; fsl,num_tx_queues = <0x8>; local-mac-address = [00 00 00 00 00 00]; ^^^^^^^^^^^^^^^^^ interrupt-parent = <0x2>; phy-handle = <0x3>; phy-connection-type = "rgmii-id"; ptimer-handle = <0x4>; queue-group@0 { #address-cells = <0x1>; #size-cells = <0x1>; reg = <0xb0000 0x1000>; rx-bit-map = <0xff>; tx-bit-map = <0xff>; interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>; }; }; I also have been checking the live device map to find this: root@GHS-AP3:~# hexdump -C /proc/device-tree/soc@ffe00000/ethernet@b0000/local-mac-address 00000000 00 04 9f ef 01 01 |......| 00000006 root@GHS-AP3:~# hexdump -C /proc/device-tree/soc@ffe00000/ethernet@b1000/local-mac-address * root@GHS-AP3:~# hexdump -C /proc/device-tree/soc@ffe00000/ethernet@b2000/local-mac-address * My conclussion is that U-Boot most likely finds the device and (as no valid MAC-address is provided) falls back to the default MAC provided by the old code, the kernel then receives thee modified device map from U-Boot and assumes this is the correct MAC for the device despite it obviously isn't. This can be seen at target/linux/mpc85xx/patches-3.10/140-powerpc-85xx-tl-wdr4900-v1-support.patch The enetaddr is filled up by using the device tree data by the process_boot_dtb function and used by the platform_fixups function to set the eth0 address (by calling dt_fixup_mac_address_by_alias("ethernet0", enetaddr); ). But instead we should be used the device address which to my understanding is provided in the mtd. Signed-off-by: Bastian Bittorf <bittorf@bluebottle.com> SVN-Revision: 43074
2014-10-26 17:58:53 +00:00
# Copyright (C) 2014 OpenWrt.org
mpc85xx: add user-space support for the TL-WDR4900 v1 Signed-off-by: Gabor Juhos <juhosg@openwrt.org> SVN-Revision: 35733
2013-02-21 19:20:34 +00:00
[ -e /etc/config/network ] && exit 0
touch /etc/config/network
. /lib/functions/uci-defaults.sh
. /lib/mpc85xx.sh
mpc85xx: fix WAN/LAN-MAC for TP-LINK TL-WDR4900 v1 This works around a bootloader issue where every device has the same lan/wan-mac 00:04:9f:ef:01:01 - with this patch we read the macs from config-partition during initial network setup. We have 9 valid macs stored in the partition, the 1st two are used for the radios, 3 and 4 are now used for WAN/LAN. on an already setup / running device we can get the real macs with . /lib/functions.sh . /lib/functions/system.sh echo "LAN = $(mtd_get_mac_binary config 338)" echo "WAN = $(mtd_get_mac_binary config 344)" see: https://dev.openwrt.org/ticket/14714 from the ticket / user klondike: U-Boot passed this commit https://gitorious.org/0xlab-kernel/u-boot/commit/ecd1a09b81f2ed6e6ba7bd1d0bfb0cc3d0ea2ad0 http://u-boot.10912.n7.nabble.com/U-Boot-PATCH-mpc83xx-remove-hardcoded-network-addresses-from-config-files-td44372.html I suppose to prevent this particular issue, but the WDR4900 may be using an old bootloader still affected. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I have been checking the contents of the dtb on the flash, this particular bit is quite revealing: ethernet@b0000 { #address-cells = <0x1>; #size-cells = <0x1>; device_type = "network"; model = "eTSEC"; compatible = "fsl,etsec2"; fsl,num_rx_queues = <0x8>; fsl,num_tx_queues = <0x8>; local-mac-address = [00 00 00 00 00 00]; ^^^^^^^^^^^^^^^^^ interrupt-parent = <0x2>; phy-handle = <0x3>; phy-connection-type = "rgmii-id"; ptimer-handle = <0x4>; queue-group@0 { #address-cells = <0x1>; #size-cells = <0x1>; reg = <0xb0000 0x1000>; rx-bit-map = <0xff>; tx-bit-map = <0xff>; interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>; }; }; I also have been checking the live device map to find this: root@GHS-AP3:~# hexdump -C /proc/device-tree/soc@ffe00000/ethernet@b0000/local-mac-address 00000000 00 04 9f ef 01 01 |......| 00000006 root@GHS-AP3:~# hexdump -C /proc/device-tree/soc@ffe00000/ethernet@b1000/local-mac-address * root@GHS-AP3:~# hexdump -C /proc/device-tree/soc@ffe00000/ethernet@b2000/local-mac-address * My conclussion is that U-Boot most likely finds the device and (as no valid MAC-address is provided) falls back to the default MAC provided by the old code, the kernel then receives thee modified device map from U-Boot and assumes this is the correct MAC for the device despite it obviously isn't. This can be seen at target/linux/mpc85xx/patches-3.10/140-powerpc-85xx-tl-wdr4900-v1-support.patch The enetaddr is filled up by using the device tree data by the process_boot_dtb function and used by the platform_fixups function to set the eth0 address (by calling dt_fixup_mac_address_by_alias("ethernet0", enetaddr); ). But instead we should be used the device address which to my understanding is provided in the mtd. Signed-off-by: Bastian Bittorf <bittorf@bluebottle.com> SVN-Revision: 43074
2014-10-26 17:58:53 +00:00
. /lib/functions.sh
. /lib/functions/system.sh
mpc85xx: add user-space support for the TL-WDR4900 v1 Signed-off-by: Gabor Juhos <juhosg@openwrt.org> SVN-Revision: 35733
2013-02-21 19:20:34 +00:00
ucidef_set_interface_loopback
board=$(mpc85xx_board_name)
case "$board" in
tl-wdr4900-v1)
ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
ucidef_add_switch "switch0" "1" "1"
ucidef_add_switch_vlan "switch0" "1" "0t 2 3 4 5"
ucidef_add_switch_vlan "switch0" "2" "0t 1"
mpc85xx: fix WAN/LAN-MAC for TP-LINK TL-WDR4900 v1 This works around a bootloader issue where every device has the same lan/wan-mac 00:04:9f:ef:01:01 - with this patch we read the macs from config-partition during initial network setup. We have 9 valid macs stored in the partition, the 1st two are used for the radios, 3 and 4 are now used for WAN/LAN. on an already setup / running device we can get the real macs with . /lib/functions.sh . /lib/functions/system.sh echo "LAN = $(mtd_get_mac_binary config 338)" echo "WAN = $(mtd_get_mac_binary config 344)" see: https://dev.openwrt.org/ticket/14714 from the ticket / user klondike: U-Boot passed this commit https://gitorious.org/0xlab-kernel/u-boot/commit/ecd1a09b81f2ed6e6ba7bd1d0bfb0cc3d0ea2ad0 http://u-boot.10912.n7.nabble.com/U-Boot-PATCH-mpc83xx-remove-hardcoded-network-addresses-from-config-files-td44372.html I suppose to prevent this particular issue, but the WDR4900 may be using an old bootloader still affected. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I have been checking the contents of the dtb on the flash, this particular bit is quite revealing: ethernet@b0000 { #address-cells = <0x1>; #size-cells = <0x1>; device_type = "network"; model = "eTSEC"; compatible = "fsl,etsec2"; fsl,num_rx_queues = <0x8>; fsl,num_tx_queues = <0x8>; local-mac-address = [00 00 00 00 00 00]; ^^^^^^^^^^^^^^^^^ interrupt-parent = <0x2>; phy-handle = <0x3>; phy-connection-type = "rgmii-id"; ptimer-handle = <0x4>; queue-group@0 { #address-cells = <0x1>; #size-cells = <0x1>; reg = <0xb0000 0x1000>; rx-bit-map = <0xff>; tx-bit-map = <0xff>; interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>; }; }; I also have been checking the live device map to find this: root@GHS-AP3:~# hexdump -C /proc/device-tree/soc@ffe00000/ethernet@b0000/local-mac-address 00000000 00 04 9f ef 01 01 |......| 00000006 root@GHS-AP3:~# hexdump -C /proc/device-tree/soc@ffe00000/ethernet@b1000/local-mac-address * root@GHS-AP3:~# hexdump -C /proc/device-tree/soc@ffe00000/ethernet@b2000/local-mac-address * My conclussion is that U-Boot most likely finds the device and (as no valid MAC-address is provided) falls back to the default MAC provided by the old code, the kernel then receives thee modified device map from U-Boot and assumes this is the correct MAC for the device despite it obviously isn't. This can be seen at target/linux/mpc85xx/patches-3.10/140-powerpc-85xx-tl-wdr4900-v1-support.patch The enetaddr is filled up by using the device tree data by the process_boot_dtb function and used by the platform_fixups function to set the eth0 address (by calling dt_fixup_mac_address_by_alias("ethernet0", enetaddr); ). But instead we should be used the device address which to my understanding is provided in the mtd. Signed-off-by: Bastian Bittorf <bittorf@bluebottle.com> SVN-Revision: 43074
2014-10-26 17:58:53 +00:00
ucidef_set_interface_macaddr lan "$(mtd_get_mac_binary config 338)"
ucidef_set_interface_macaddr wan "$(mtd_get_mac_binary config 344)"
mpc85xx: add user-space support for the TL-WDR4900 v1 Signed-off-by: Gabor Juhos <juhosg@openwrt.org> SVN-Revision: 35733
2013-02-21 19:20:34 +00:00
;;
*)
ucidef_set_interfaces_lan_wan "eth0" "eth1"
;;
esac
uci commit network
exit 0
Reference in a new issue Copy permalink