[U-Boot-Users] RTC required for network support on OCOTEA?
Hello everyone,
We are in the process of porting ocotea-based U-Boot 1.1.1 to custom ppc440gx hardware. Everything is pretty much working except for the network interface. We can send out a ping but never process the reply. Ethereal does see both the ping and reply packets!
In debugging the network component of U-Boot, someone mentioned that a RTC might be required for proper operation. Unlike the OCOTEA board, we do NOT have a RTC. After examining all the READMEs and looking at source code, I don't see any dependency on a RTC. Can anyone confirm this?
Thanks, Andy
On Wed, 2004-11-10 at 11:30, Andrew Wozniak wrote:
Hello everyone,
In debugging the network component of U-Boot, someone mentioned that a RTC might be required for proper operation. Unlike the OCOTEA board, we do NOT have a RTC. After examining all the READMEs and looking at source code, I don't see any dependency on a RTC. Can anyone confirm this?
Hunh???
Are you using the Cicada/Vitesse phy that is on the ocotea?
There is a gotcha with that phy. IIRC, our in house board doesn't have the 13" of trace, so I had to set a bit.
From 440gx_enet.c /* Note: slightly hacked for use with our metrobox
system */
#if defined(CONFIG_440_GX) #if defined(CONFIG_CIS8201_PHY) /* * Cicada 8201 PHY needs to have an extended register whacked * for RGMII mode. */ if ( ((devnum == 2) || (devnum ==3)) && (4 == ethgroup) ) { #if defined(CONFIG_METROBOX) miiphy_write (reg, 23, 0x1300); #else miiphy_write (reg, 23, 0x1200); #endif
This is just above the vsc8201/cis8201 errata code.
Specifically, bit 8 enables RGMII skew timing compensation.
As for requiring an RTC, I _*REALLY*_ don't see how one has to do with the other.
Good luck,
Travis
Hello again,
Travis Sawyer wrote:
On Wed, 2004-11-10 at 11:30, Andrew Wozniak wrote:
Hello everyone,
In debugging the network component of U-Boot, someone mentioned that a RTC might be required for proper operation. Unlike the OCOTEA board, we do NOT have a RTC. After examining all the READMEs and looking at source code, I don't see any dependency on a RTC. Can anyone confirm this?
Hunh???
Are you using the Cicada/Vitesse phy that is on the ocotea?
No we do not use them. We have a direct connect from 440gx to a Quad 10/100 PHY (AMD AM79C875). I have stripped out all ocotea PHY related code.
The RX buffer is getting filled via enetInt() but it is NOT getting emptied. NetLoop() is being called but it never propagates, via eth_rx() and eth_current->recv(eth_current), down to ppc_440x_eth_rx() where the buffer should be marked empty.
The RTC question is probably a non-issue.
I am now investigating the meaning of CONFIG_NET_MULTI - we have this set and seems to affect NetLoop() processing. Here's a small trace of netboot_common as called via 'dhcp' command.
...netboot_common() ...NetLoop() ...eth_halt() ...ppc_440x_eth_halt() disable ints, EMAC_IER: 0x00000000 eth_set_current() ...NetLoop() 2 eth_init(), eth_current: 0x0ffa3180 ...ppc_440x_eth_init() msr: 0x00029000 disable ints msr: 0x00021000 About preceeding transfer (eth0): - Sent packet number 0 - Received packet number 0 - Handled packet number 0
Thanks for all your suggestions, Andy
There is a gotcha with that phy. IIRC, our in house board doesn't have the 13" of trace, so I had to set a bit.
From 440gx_enet.c /* Note: slightly hacked for use with our metrobox
system */
#if defined(CONFIG_440_GX) #if defined(CONFIG_CIS8201_PHY) /* * Cicada 8201 PHY needs to have an extended register whacked * for RGMII mode. */ if ( ((devnum == 2) || (devnum ==3)) && (4 == ethgroup) ) { #if defined(CONFIG_METROBOX) miiphy_write (reg, 23, 0x1300); #else miiphy_write (reg, 23, 0x1200); #endif
This is just above the vsc8201/cis8201 errata code.
Specifically, bit 8 enables RGMII skew timing compensation.
As for requiring an RTC, I _*REALLY*_ don't see how one has to do with the other.
Good luck,
Travis
In message 4192423C.3010908@mc.com you wrote:
We are in the process of porting ocotea-based U-Boot 1.1.1 to custom ppc440gx hardware. Everything is pretty much working except for the network interface. We can send out a ping but never process the reply. Ethereal does see both the ping and reply packets!
In debugging the network component of U-Boot, someone mentioned that a RTC might be required for proper operation. Unlike the OCOTEA board, we do NOT have a RTC. After examining all the READMEs and looking at source code, I don't see any dependency on a RTC. Can anyone confirm this?
Neither U-Boot nor Linux does need any RTC for network operation.
Best regards,
Wolfgang Denk
participants (3)
-
Andrew Wozniak -
Travis Sawyer -
Wolfgang Denk