Skip to content
  • blogic's avatar
    mpc85xx: fix WAN/LAN-MAC for TP-LINK TL-WDR4900 v1 · 93d05b53
    blogic authored
    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: default avatarBastian Bittorf <bittorf@bluebottle.com>
    
    Backport of r43074
    
    git-svn-id: svn://svn.openwrt.org/openwrt/branches/barrier_breaker@43077 3c298f89-4303-0410-b956-a3cf2f4a3e73
    93d05b53