[U-Boot] Ethernet problem on A20 Lime2

[Hans de Goede <hdegoede@redhat.com>]

Hi Tom,

On 21-04-15 16:57, Tom Rini wrote:
> On Tue, Apr 21, 2015 at 04:11:34PM +0200, Hans de Goede wrote:
>> Hi Tom,
>>
>> On 21-04-15 16:03, Tom Rini wrote:
>>> Hey,
>>>
>>> I've run into a problem with ethernet on the A20 Lime2:
>>> sunxi# setenv autoload no
>>> sunxi# dhcp
>>> Speed: 1000, full duplex
>>> BOOTP broadcast 1
>>> DHCP client bound to address 192.168.0.185 (13 ms)
>>> sunxi# tftp test/u-boot-sunxi-with-spl.bin
>>> Speed: 1000, full duplex
>>> Using dwmac.1c50000 device
>>> TFTP from server 192.168.0.3; our IP address is 192.168.0.185
>>> Filename 'test/u-boot-sunxi-with-spl.bin'.
>>> Load address: 0x42000000
>>> Loading: #################################################################
>>>           #########
>>>           23.4 KiB/s
>>> done
>>> Bytes transferred = 377028 (5c0c4 hex)
>>> sunxi# crc32 $fileaddr $filesize
>>> CRC32 for 42000000 ... 4205c0c3 ==> afa0edfb
>>> $ rhash -C /tftpboot/test/u-boot-sunxi-with-spl.bin
>>> ; Generated by RHash v1.2.8 on 2015-04-21 at 10:01.53
>>> ; Written by Aleksey (Akademgorodok) - http://rhash.sourceforge.net/
>>> ;
>>> ;       377028  09:52.08 2015-04-21 /tftpboot/test/u-boot-sunxi-with-spl.bin
>>> /tftpboot/test/u-boot-sunxi-with-spl.bin A16F5564
>>>
>>> So a non-crc32 match.  If I load that same file off of SD card:
>>> sunxi# mmc read 43000000 10 400
>>>
>>> MMC read: dev # 0, block # 16, count 1024 ... 1024 blocks read: OK
>>> sunxi# cmp 42000000 43000000 $filesize
>>> word at 0x42001544 (0x605a0200) != word at 0x43001544 (0x605a0201)
>>> Total of 1361 word(s) were the same
>>>
>>> I haven't had a chance to bisect this but it might have been around for
>>> a little while.
>>
>> Chances are this has never worked 100% reliable, on most boards some
>> tweaking of the GMAC clk delays is necessary.
>>
>> Try setting
>>
>> CONFIG_GMAC_TX_DELAY=1
>>
>> In the defconfig for your board, that helps with similar issues on
>> the Cubietruck (which also has gbit ethernet) Valid values are
>> 0 - 3.
>
> 1 2 and 3 all failed :(

Bummer.

There also is an rx delay, which is something which we've never had to use
but you could try that, e.g. do something like this:

--- a/board/sunxi/gmac.c
+++ b/board/sunxi/gmac.c
@@ -25,7 +25,7 @@ int sunxi_gmac_initialize(bd_t *bis)
         setbits_le32(&ccm->gmac_clk_cfg, CCM_GMAC_CTRL_TX_CLK_SRC_INT_RGMII |
                 CCM_GMAC_CTRL_GPIT_RGMII);
         setbits_le32(&ccm->gmac_clk_cfg,
-                CCM_GMAC_CTRL_TX_CLK_DELAY(CONFIG_GMAC_TX_DELAY));
+              CCM_GMAC_CTRL_RX_CLK_DELAY(1));
  #else
         setbits_le32(&ccm->gmac_clk_cfg, CCM_GMAC_CTRL_TX_CLK_SRC_MII |
                 CCM_GMAC_CTRL_GPIT_MII);

And then play with 1 - 3 in the place of the 1, although since things do
mostly work I would expect 1 to be the best candidate to make things
better.

Regards,

Hans