OMAP-L138 RMII with LAN8720 (Pauses in ethernet download)

Further to the above question, below is the U-Boot log showing the problem:

Hello,

Summarizing:

- You connect a custom board to an office network: transmission problems at 100M, no more at 10M (assuming 'T' in log stand for timeout / packet loss).

- You connect a custom board to a (probably near) switch : no more problem.

To my opinion, it's more probably an electrical problem, ie impedance mismatch or noise. You say using an intermediate header to connect the PHY to the RJ45; if there is some impedance mismatch, for example, reflected signals will cause more problems with a long cable (to the office central switch) rather than with a short one (to the intermediate switch). You may use a long cable between the switch and the board to see if the problem arises again.

Jakez

Thanks Jakez for your reply.

I think I was not very specific with my explanation of the problem. Please find the below summary to slightly modify your understanding:

- We connect custom board to office network: No problem at both 10M and 100M.

- We connect custom board directly to a PC (No switch in between) using a cable not more than 2 metres: No problem at 10M. Transmission problems are found at 100M, for which the log was posted.

Harshith

Hello,

Some little inversion of the problem data... Another suggestions, focusing on PC - board direct link:

- Have you tried with another PC ?

- Is the 2-meters cable the same than when connected to the office network ? (Try another ?)

- You can use a network sniffer (for exemple open source Wireshark) to follow network packets / events.

- With an emulator, you can check the EMAC statistics, to see if receive errors counter raises

Jakez

Hi Jakez,

Yes, we have tried with four different PCs and found the same issue everywhere.

Yes, We have tried with same cable with these four PCs and have changed cables as well (Cross and straight).

We used Wireshark and found that on some occasions, our custom board (and Zoom board + UI board as well) takes time to send acknowledgement to the PC for some of the packets. These are the time duration for which we find the 'T' in the posted log.

We also noted (In Wireshark) that there are no packet losses and re-transmissions.

We suspect that there may be limited support for RMII Phys in the UBoot for OMAP-L138.

What is your take on this?

Harshith

Harshith,

If no reception error (even on board side), back to software problem. As the transfer is ok with the office network, I would search on network configuration side rather than RMII.

Sorry, I don't use U-boot; however, another last suggestions:

- Is there any packet out of TFTP protocol before  the pauses ?

- Are the pauses quite periodic in time ?

- Perhaps the U-boot need answer to some network request (DHCP,...) not managed by the PC ?

- Perhaps the U-boot manages some other tasks (flash programming,...) while downloading ?

Jakez

We have a similar problem with u-boot and a DP83630 PHY, also connected via RMII.

Our symptoms are different in one aspect: Either the ~8MB download finishes in a few seconds, or the first data packet from the TFTP server is lost, timeout, retry, lost again, and so on, which sometimes repeats for 10 minutes in a row. In all cases, the DHCP negotiation runs smoothly, and when you request a file that isn't there, you always get an immediate error response from the TFTP server. Only the (bigger) data packets are subject to loss. It's always the first data packet lost, or none at all.

In both u-boot and Linux we're using the "generic" PHY driver, which runs just fine. There are no problems at all under Linux, only u-boot does this.

My suspicion is that the "built in" PHY on the SoM board (connected to MII) is doing something nasty. The Linux kernel might disable this PHY some way, I could not find it though, which explains why the kernel isn't bothered with unexplicable packet loss. It should be possible to tell the chip to shut up and never touch the MII bus at all, but I haven't found how to do that in u-boot.

Very similar to your problem is that there's a relation to the connection hardware being used. On some switches I get 1/10 success rate, while on another switch I get about 6/10 success rate.

Hello,

Another suggestion for this last case, more specific to RMII mode:

Does the U-boot correctly configure the RMII_MHZ_50_CLK pin and corresponding clock pin on PHY ? ie the PHY should output a 50 MHz clock (master mode) if the CPU pin is input, and vice-versa. In a misconfiguration, both could be outputs with unpredictable results, depending on reference clocks shifts or internal starting phases.

Jakez

If I understand correctly, when an external 50MHz clock is present, RMII_MHZ_50_CLK must be made configured as input. From the documentation I understand that this translates to PINMUX15_3_0 function 0 ("Selects Function PRU0_R31[23]. Enables sourcing of the 50 MHz reference clock
from an external source on the RMII_MHZ_50_CLK pin to the EMAC.")

I added

{ pinmux(15), 0, 0 }, /* RMII_MHZ_50_CLK */

to the bootloader code. So far, this resulted in no difference, same behaviour as before.

Hello,

OK for PINMUX with external clock (I have the same).

Other checks for a little more hope:

- The 50 MHz is provided by an external clock, which drives the PHY too: check if PHY is programmed in slave mode.

- The 50 MHz is provided by the PHY (from a 25 MHz clock at X1 pin): check if PHY is programmed in master mode.

The DP83630 PHY mode can be (re)programmed by software (U-boot ?); if unmodified, its power-on value depends on pin TxD3/RMII-MAS at power-up (pull-up required to master mode, pull-down or NC for slave mode), refer to your hardware.

Jakez

"check if PHY is programmed in master mode."

How do I check that?

I did notice that there's a 50MHz signal on the CLK_OUT of the PHY while it is in RESET, when I set the RESET high to take the chip out of reset, the signal changes into a 25MHz clock. From the documentation, this should be a 50MHz signal in RMII Master mode. On the other hand, I see the same when running under linux and there the PHY (seems to?) work just fine.

There are pull-ups on RX_DV, RXD_3, GPIO1, hence the chip is in slave mode. Which looks correct to me, as the 50MHz clock is externally provided (and putting the chip in master mode made it fail to operate).

Hello,

"check if PHY is programmed in master mode." : for sure it's not easy if no access to U-boot source code (have to read MDIO register RBR).

Some data required from your hardware:

Is the CPU pin RMII_MHZ_50_CLK connected to the PHY ?

What is the frequency of the crystal/oscillator connected to the X1 pin ?

If 25 MHz: master RMII intended, the CPU must be fed with the CLK_OUT 50 MHz clock in RMII_MHZ_50_CLK (or any other 50 MHz clock synchronous to it).

If 50 MHz: slave RMII intended, the CPU must be fed with the same clock as the X1 pin in RMII_MHZ_50_CLK (or any other 50 MHz clock synchronous to it). A variation is to use the RMII_MHZ_50_CLK pin as an output pin, which would be then used to feed the PHY X1 pin.

Alternate question: what is the PINMUX15 register value while in linux ?

Jakez

I have full source code to everything.

RBR contents while in u-boot:

U-Boot > mii read 3 17
0021

Only bits 0 and 5 set, which is "all default", except using RMII mode (bit 5).

We're using RMII Slave Mode, there's 50MHz signal feeding X1 and the OMAP.

"what is the PINMUX15 register value while in linux"

I'd welcome a tip on how to obtain this.

FYI all pinmuxing is done by the bootloader, if the kernel changes anything (through normal channels) it will output a warning message about that, which is currently not the case. I cannot see it when a driver just bitbangs the pinux registers though.

This should be the OINMUX15 value in the kernel:

# devmem 0x01C1415C  32
0x00000080

If my interpretation is correct, that's only RMII_CRS_DV activated and all others at '0' (hence, source the 50MHz clock externally).

Mike,

Summarizing:

- PHY in slave mode (from PHY RBR register), external 50MHz feeding PHY's X1 and OMAP's RMII_MHZ_50_CLK

- OMAP's RMII_MHZ_50_CLK is input, in U-boot and Linux

=> Master/slave and clock configurations are fine

Sorry, I don't see other potential problem from hardware configuration (assuming RMII PINMUX ok, clock precision ok, >=1.1V CPU core).

Last chance try: you may compare the EMAC MACCONTROL register between U-boot and Linux (some last PHY controls).

As the RMII / MII interface type is no more of concern after CPU initialization, the U-boot should then work same in both cases (no specific RMII bug for longer frames). If the driver code is the same between U-boot and Linux, it must be some configuration difference somewhere.

Free suggestions: problems in long frames transmission only may arise from:

- big shift in clocks (+-50 ppm absolute shift required): would be the same in Linux (except if programmable external clock)

- different use of jumbo (oversized) frames in U-boot / Linux ?

-...?

Jakez

Because of all the debugging, I did get more insight into the symptoms.

The problem isn't so much triggered by the size of a single packet, but by the total amount of traffic received. For example, if I set an extremely small blocksize like 128 bytes for tftp, the first few packets always make it though, and then a time-out occurs at the 4rth packet, give or take a few.

So typically, the DHCP and TFTP ACK packets always arrive, but usually it will stop working after a few kB of traffic.

Sometimes there's a "lucky" hit (e.g. start before lunch, and just keep it running) and it transfers the whole 8M image in single go. If you start another transmission quickly after that, it will usually be okay as well.

I did not have these problems with the same u-boot version but using the da850evm board (which uses the internal PHY).

Hi Jakez,

Thanks for your suggestions.

The pauses are not periodic and the U-boot handles only TFTP during this time.

We checked that the 50 MHz clock pin is configured as output from PHY and the MAC pin is configured as input.

While investigating the U-boot, we added a delay of 0.5mS before the transmission of each packet begins from our board.

With this addition, our problem is resolved and we do not find the pauses at 100Mbps now.

Thanks for your time.

Harshith