Commit 93d05b53 authored by blogic's avatar blogic

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/
. /lib/functions/
echo "LAN = $(mtd_get_mac_binary config 338)"
echo "WAN = $(mtd_get_mac_binary config 344)"


from the ticket / user klondike:
U-Boot passed this commit
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                                 |......|
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

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: default avatarBastian Bittorf <>

Backport of r43074

git-svn-id: svn:// 3c298f89-4303-0410-b956-a3cf2f4a3e73
parent 2ed9535b
# Copyright (C) 2013
local cfg=$1
local offset=$2
local mac
. /lib/
mac=$(mtd_get_mac_binary u-boot 326656)
mac=$(macaddr_add $mac $offset)
ucidef_set_interface_macaddr $cfg $mac
# Copyright (C) 2014
[ -e /etc/config/network ] && exit 0
......@@ -24,6 +7,8 @@ touch /etc/config/network
. /lib/functions/
. /lib/
. /lib/
. /lib/functions/
......@@ -35,10 +20,9 @@ tl-wdr4900-v1)
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"
tplink_set_mac lan -2
tplink_set_mac wan 1
ucidef_set_interface_macaddr lan "$(mtd_get_mac_binary config 338)"
ucidef_set_interface_macaddr wan "$(mtd_get_mac_binary config 344)"
ucidef_set_interfaces_lan_wan "eth0" "eth1"
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment