Skip to contentSkip to conversation

Ethernet problem on A20 Lime2

U-Boot Tom Rini 2 participants 4 messages Apr 21, 2015 – Apr 22, 2015 Arm/Allwinner sunXi SoC support

lore
Share & tools
lore

Tom Rini

author
#0 lore raw

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.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150421/f0f0e975/attachment.sig>
#1 lore raw

Hi Tom,

Quoted 31 lines · Tom Rini

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

Quoted 7 lines

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.

Regards,

Hans

author
#2 lore raw
Quoted 45 lines · Hans de Goede

Hi Tom,

Quoted 31 lines · Tom Rini

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

Quoted 7 lines

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.

Quoted 7 lines

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 :(

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150421/6af9d3c3/attachment.sig>
#3 lore raw

Hi Tom,

Quoted 48 lines · Tom Rini
Quoted 47 lines · Hans de Goede

Hi Tom,

Quoted 31 lines · Tom Rini

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

Quoted 7 lines

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

Quoted 7 lines
Quoted 5 lines

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:

board/sunxi/gmac.c +1 -1
@@ -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