Hi Everyone,
We are using OMAP-L138on a custom board where it interfaces to LAN8720A through RMII interface.
The PHY output passes through a simple header to connect to the RJ45 connector (with built in magnetics) on a separate board.
The distance between PHY and the RJ45 connector is around 2 inches.
Our setup uses a point-to-point connection between our board and the PC(server).
The problem:
When the UBoot downloads the UImage from the server over Ethernet in 100Mbps mode, we see that the download pauses several times before completion.
But, the download appears very smooth, without any pause, when the PHY has negotiated to 10Mbps mode.
We observe the same behaviour when using LAN8720 on the UI board connected to Zoom board.
On the contrary, the pauses seem to disappear when the connection to the server is through a network switch connected to our office LAN.
Has anyone faced a similar problem?
Kindly suggest.
Harshith
-
Posted by HarshithKasyapProdigy 65points
Further to the above question, below is the U-Boot log showing the problem:
U-Boot 2009.11 (Jul 24 2012 - 15:38:19)
I2C: readyDRAM: 128 MBNAND: 512 MiBMMC: davinci: 0Bad block table found at page 262080, version 0x01Bad block table found at page 262016, version 0x01nand_read_bbt: Bad block at 0x000005460000In: serialOut: serialErr: serialARM Clock : 372000000 HzDDR Clock : 150000000 HzNet: Ethernet PHY: GENERIC @ 0x00
Hit any key to stop autoboot: 0Using deviceTFTP from server 192.168.13.4; our IP address is 192.168.13.158Filename 'uImage_pqab'.Load address: 0xc0700000Loading: ###################################################################################################################################################T #######################################################################################################T #############T ##################################################################################doneBytes transferred = 1765704 (1af148 hex)U-Boot >
Any answers would help.
Harshith -
Posted by JakezExpert 1530points
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
-
Posted by HarshithKasyapProdigy 65points
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
-
Posted by JakezExpert 1530points
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
-
Posted by HarshithKasyapProdigy 65points
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
-
Posted by JakezExpert 1530points
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
-
Posted by Mike LooijmansIntellectual 760points
We have a similar problem with u-boot and a DP83630PHY, 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.
-
Posted by JakezExpert 1530points
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
-
Posted by Mike LooijmansIntellectual 760points
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.
-
Posted by JakezExpert 1530points
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 DP83630PHY 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
-
Posted by Mike LooijmansIntellectual 760points
"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.
-
Posted by Mike LooijmansIntellectual 760points
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).
-
Posted by JakezExpert 1530points
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
-
Posted by Mike LooijmansIntellectual 760points
I have full source code to everything.
RBR contents while in u-boot:
U-Boot > mii read 3 17
0021Only 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.
-
Posted by Mike LooijmansIntellectual 760points
This should be the OINMUX15 value in the kernel:
# devmem 0x01C1415C 32
0x00000080If my interpretation is correct, that's only RMII_CRS_DV activated and all others at '0' (hence, source the 50MHz clock externally).
扫一扫
8962
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
