No network in U-boot when moving from C6A8168 to AM3892

Emil Ohlsson

Other Parts Discussed in Thread: AM3892

I am currently evaulating a move from the C6A8168, rev 1.1, processor to the AM3892, rev 2.0. I have been told that these two should be drop in replacable. However, on the board with the AM3892 U-boot seem to have trouble with network communication. The processor successfully loads and boots U-boot via BOOTP/TFTPBOOT, but when trying to download the linux kernel U-boot freezes. I'm using the exact same software running on the C6A8168 and trying to run it on the AM3892

The log below is from u-boot trying to boot on the AM3892 processor. Everything seems to work fine until trying to acquire IP address, where u-boot freezes (on the line 'trying DaVinci EMAC'.

U-Boot 2010.06 (Nov 02 2012 - 16:21:34)

U-Boot code: 80700000 -> 8072DF10 BSS: -> 80766310
TI8168-GP rev 2.0

ARM clk: 1152MHz
DDR clk: 398MHz

I2C:   ready
RAM Configuration:
Bank #0: 80000000 512 MiB
NAND: HW ECC Hamming Code selected
256 MiB
*** Warning - bad CRC or NAND, using default environment

MMC:   OMAP SD/MMC: 0
Net:   <ethaddr> not set. Reading from E-fuse
Detected MACID:84:7e:40:11:14:b4
DaVinci EMAC
### main_loop entered: bootdelay=3

### main_loop: bootcmd="dhcp;tftp /srv/tftp/tftpboot/installscript.bin;source"
Trying DaVinci EMAC

U-boot is based on u-boot-2010.06-psp04.00.01.13.patch1, but with modified default environment. Any tips on where to troubleshoot this problem? It seems to me that the PHY should be working fine, since the ROM successfully boots u-boot using TFTPBOOT.

All help is appreciated
/Emil

over 12 years ago

0 Vladimir-XID over 12 years ago

TI__Genius 11470 points

Hello,

Is this the guide you are following?

http://processors.wiki.ti.com/index.php?title=DM816x_AM389x_EMAC_Boot

Is everything on your side as described here?

And how is the ping?

You check your connection by loading some u-boot and then see how is the ping between the board and the host.

Vladimir

0 Emil Ohlsson over 12 years ago in reply to Vladimir-XID

Intellectual 410 points

Thanks for the fast answer

I've not seen that guide before, but that is more or less what we are doing, but the problem comes later. We are using BOOTP to load u-boot to RAM. And this works fine, so the network seems to be correct set up. But we are having problem using the network in u-boot. The ping, dhcp and tftp command all result in a freeze of u-boot. Since I don't get any IP address using dhcp I can't use ping either.

The setup we are using consists of one development computer running linux (using VirtualBox) and a target board that is connected to the development computer using an Ethernet connection. The development computer is running bootpd and tcpdump. We have two kinds of target board, one using the C6A8168 processor and one using the AM3892 processor. Apart from the processor the two boards are identical. Same PCB, same PHY, same everything.

When using the board with The C6A8168 processor the logs something like this

Using C6A8168

U-Boot 2010.06 (Nov 02 2012 - 16:21:34)

U-Boot code: 80700000 -> 8072DF10  BSS: -> 80766310
TI8168-GP rev 1.1

ARM clk: 1152MHz
DDR clk: 398MHz

I2C:   ready
RAM Configuration:
Bank #0: 80000000 512 MiB
NAND:  HW ECC Hamming Code selected
256 MiB
*** Warning - bad CRC or NAND, using default environment

MMC:   OMAP SD/MMC: 0
Net:   <ethaddr> not set. Reading from E-fuse
Detected MACID:d4:94:a1:8f:ed:20
Ethernet PHY: GENERIC @ 0x01
DaVinci EMAC
### main_loop entered: bootdelay=3

### main_loop: bootcmd="dhcp;tftp /srv/tftp/tftpboot/installscript.bin;source"
u-boot# dhcp
Trying DaVinci EMAC
BOOTP broadcast 1
DHCPHandler: got packet: (src=67, dst=68, len=300) state: 3
Filtering pkt = 0
DHCPHandler: got DHCP packet: (src=67, dst=68, len=300) state: 3
DHCP: state=SELECTING bp_file: "/srv/tftp/tftpboot/u-boot.bin"
TRANSITIONING TO REQUESTING STATE
DhcpSendRequestPkt: Sending DHCPREQUEST
Transmitting DHCPREQUEST packet: len = 343
DHCPHandler: got packet: (src=67, dst=68, len=300) state: 4
Filtering pkt = 0
DHCPHandler: got DHCP packet: (src=67, dst=68, len=300) state: 4
DHCP State: REQUESTING
Bootfile: /srv/tftp/tftpboot/u-boot.bin
DHCP client bound to address 172.20.169.8
u-boot# ping 172.20.169.1
Trying DaVinci EMAC
Using DaVinci EMAC device
host 172.20.169.1 is alive
u-boot#

The TCPDUMP log something like this.

BOOTP request
16:13:23.382036 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 364
16:13:23.382799 IP 172.20.169.1.67 > 172.20.169.8.68: UDP, length 300

TFTP file request
16:13:23.385588 ARP, Request who-has 172.20.169.1 tell 172.20.169.8, length 50
16:13:23.385621 ARP, Reply 172.20.169.1 is-at 00:13:3b:00:04:9e, length 28
16:13:23.387747 IP 172.20.169.8.1234 > 172.20.169.1.69: UDP, length 38
16:13:23.411905 IP 172.20.169.1.58111 > 172.20.169.8.1234: UDP, length 516
16:13:23.415686 IP 172.20.169.8.1234 > 172.20.169.1.58111: UDP, length 4
16:13:23.415793 IP 172.20.169.1.58111 > 172.20.169.8.1234: UDP, length 516

..........

# DHCP request in log
16:13:32.605150 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 301
16:13:32.605891 IP 172.20.169.1.67 > 172.20.169.8.68: UDP, length 300
16:13:32.642647 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 301
16:13:32.643407 IP 172.20.169.1.67 > 172.20.169.8.68: UDP, length 300
16:13:37.643514 ARP, Request who-has 172.20.169.8 tell 172.20.169.1, length 28
16:13:38.642109 ARP, Request who-has 172.20.169.8 tell 172.20.169.1, length 28
16:13:39.642131 ARP, Request who-has 172.20.169.8 tell 172.20.169.1, length 28
16:13:43.043804 ARP, Request who-has 172.20.169.1 tell 172.20.169.8, length 46
16:13:43.043926 ARP, Reply 172.20.169.1 is-at 00:13:3b:00:04:9e, length 28

# PING in log.
16:13:43.046377 IP 172.20.169.8 > 172.20.169.1: ICMP echo request, id 0, seq 0, length 8
16:13:43.046411 IP 172.20.169.1 > 172.20.169.8: ICMP echo reply, id 0, seq 0, length 8

Using the same setup with the AM3892 generates the following log.

U-Boot 2010.06 (Nov 02 2012 - 16:21:34)

U-Boot code: 80700000 -> 8072DF10  BSS: -> 80766310
TI8168-GP rev 2.0

ARM clk: 1152MHz
DDR clk: 398MHz

I2C:   ready
RAM Configuration:
Bank #0: 80000000 512 MiB
NAND:  HW ECC Hamming Code selected
256 MiB
*** Warning - bad CRC or NAND, using default environment

MMC:   OMAP SD/MMC: 0
Net:   <ethaddr> not set. Reading from E-fuse
Detected MACID:84:7e:40:11:14:b4
DaVinci EMAC
### main_loop entered: bootdelay=3

### main_loop: bootcmd="dhcp;tftp /srv/tftp/tftpboot/installscript.bin;source"
u-boot# dhcp
Trying DaVinci EMAC
# U-boot freezes here,

And the TCPDUMP looks something like this.

BOOTP request
16:57:04.428367 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 364
16:57:04.428893 IP 172.20.169.1.67 > 172.20.169.8.68: UDP, length 300

TFTP file request
16:57:04.433476 ARP, Request who-has 172.20.169.1 tell 172.20.169.8, length 50
16:57:04.433502 ARP, Reply 172.20.169.1 is-at 00:13:3b:00:04:9e, length 28
16:57:04.434725 IP 172.20.169.8.1234 > 172.20.169.1.69: UDP, length 38
16:57:04.437594 IP 172.20.169.1.40795 > 172.20.169.8.1234: UDP, length 516
16:57:04.439625 IP 172.20.169.8.1234 > 172.20.169.1.40795: UDP, length 4
16:57:04.439802 IP 172.20.169.1.40795 > 172.20.169.8.1234: UDP, length 516
........

As you can see from the log the DHCP request does not appear in the log at all. I've tried to start with using the ping command, but this generates the same result (Trying DaVinci EMAC, and the nothing more). So it looks like u-boot have some problem with using the network. Is there some place in the u-boot tree that I should start checking out?

Thanks
Emil

0 Emil Ohlsson over 12 years ago in reply to Emil Ohlsson

Intellectual 410 points

Still no luck in finding out what the problem is. U-boot simply freezes when doing any network related task. However, I remember that I had a similar problem on my BeagleBone, there the solution was to run "dcache off" before running any network command. But that command does not seem to exist on the version of U-boot I'm using.

Are there any differences between u-boot for C6A8168 and u-boot for AM3892?

Thanks
Emil

0 Vladimir-XID over 12 years ago in reply to Emil Ohlsson

TI__Genius 11470 points

Hi,

Well, I am not familiar with the C6A8168 releases, but definitely it is recommended to use a release for your platform. That is what I was about to suggest you. My guess is that if try a AM3892 PSP and follow the above guide you'll have the EMAC boot. Thank you.

Vladimir

0 Vladimir-XID over 12 years ago in reply to Vladimir-XID

TI__Genius 11470 points

Here is a link:

http://www.ti.com/tool/linuxezsdk-sitara

Vladimir

0 Emil Ohlsson over 12 years ago in reply to Vladimir-XID

Intellectual 410 points

It is not the EMAC boot that is the problem. U-boot boots just fine using EMAC boot. But U-boot freezes when using the network. I've downloaded the EZSDK from the URL above, and I'm going to try to diff u-boot. Since we have applied some modifications to u-boot (not the network parts) I will need to port the changes to the new u-boot before being able to try out the new EZSDK.

Update:

I've been digging into the u-boot source code and found that for some reason u-boot doesn't detect the PHY as active.

0 Emil Ohlsson over 12 years ago in reply to Emil Ohlsson

Intellectual 410 points

I think I have partly solved the problem now, at least partly.

When u-boot starts it checks for alive PHY:s by reading from 0x4A10 0808 (PHY Acknowledge Status Register (ALIVE)). The bit active in that register corrensponds to the address of the active PHY. The value in this register differs between the AM3892 (value is 1) and the C6A8168 (value is 2).

From drivers/net/davinci_emac.c:davinci_emac_initialize():

    for (i = 0; i < 256; i++) {
        if ( readl(&adap_mdio->ALIVE) ) { // read value is 1 for AM3892 and 2 for C6A8168
            break;
        }
        udelay(10);
    }

Then in drivers/net/davinci_emac.c:davinci_eth_phy_detect()

    phy_act_state = readl(&adap_mdio->ALIVE) & EMAC_MDIO_PHY_MASK;
    if (phy_act_state == 0) { // Will evaluate to true for AM3892
        return(0);            /* No active PHYs */
    }

I tried to remove the masking in the above code, and after that the networking started to work in u-boot and I was able to download and start linux. However, my next problem came with linux. Networking does not work in linux either, most likely due to the same problem.

I diffed the source code for u-boot in the EZSDK currently recomended for the AM3892 with the version I'm using, and I couldn't find any differences that would fix this.

Why is that the PHY get different address depending on the processor? I've been told that they should be pin compatible.

Just for clarity if someone else encounters this problem, my fix looks like this:

drivers/net/davinci_emac.c +143: phy_act_state = readl(&adap_mdio->ALIVE); // & EMAC_MDIO_PHY_MASK; fix for making ETH work AM3892

I've searched the code for uses of the macro, and this seems to be the only place that this macro is used.

0 Emil Ohlsson over 12 years ago in reply to Emil Ohlsson

Intellectual 410 points

I think we've discovered the real problem of the changed PHYAD. This was probably caused by a bad soldering on the PHYADx on the PHY, which caused the address to be configured as 0b00000 instead of 0b00001. We discovered this when patching in a pin header to be able to configure the PHYAD, and it suddenly started working without any reconfiguration.

Thanks for all support

0 Vladimir-XID over 12 years ago in reply to Emil Ohlsson

TI__Genius 11470 points

Hi,

I am very glad that you solved this issue. Thank you very much for the feedback.

Vladimir

Processors

Processors forum

No network in U-boot when moving from C6A8168 to AM3892

Using C6A8168

Using the same setup with the AM3892 generates the following log.

Update: