• 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)"
    from the ticket / user klondike:
    U-Boot passed this commit https://gitorious.org/0xlab-kernel/u-boot/commit/ecd1a09b81f2ed6e6ba7bd1d0bfb0cc3d0ea2ad0
    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 <bittorf@bluebottle.com>
    Backport of r43074
    git-svn-id: svn://svn.openwrt.org/openwrt/branches/barrier_breaker@43077 3c298f89-4303-0410-b956-a3cf2f4a3e73
02_network 709 Bytes