[U-Boot] UEC phy not working on first try
Hi all-
I am using u-boot.2010.09 on a MPC8568-based board.
When trying to boot over one of the UEC network interfaces, it is not working instantly. The cable is connected from the beginning, but I have to issue a manual 'boot' command, sometimes even multiple times before the link is correct. This is the output:
[----------------------------- snip -----------------------------] Net: UEC0, UEC1, UEC3 [PRIME], eTSEC0, eTSEC1 Hit any key to stop autoboot: 0 UEC: PHY is Generic MII (70431) UEC3: Full Duplex switching to rgmii 100 UEC3: Speed 100BT UEC3: Link is up UEC3: Link is down WARNING: adjusting available memory to 30000000 Wrong Image Format for bootm command ERROR: can't get kernel image! => boot UEC3: Full Duplex switching to rgmii 100 UEC3: Speed 100BT UEC3: Link is up Using UEC3 device TFTP from server 10.169.15.10; our IP address is 10.169.15.9 Filename 'uImage'. Load address: 0x20000000 Loading: T ################################################################# ################################################################# ########################### done [...] [----------------------------- snip -----------------------------]
Booting over the TSEC interfaces works without problems. Any idea what might be the problem?
Thanks Matthias
Hi,
Hi all-
I am using u-boot.2010.09 on a MPC8568-based board.
When trying to boot over one of the UEC network interfaces, it is not working instantly. The cable is connected from the beginning, but I have to issue a manual 'boot' command, sometimes even multiple times before the link is correct. This is the output:
Do all the UEC interfaces show the same symptoms?
[----------------------------- snip -----------------------------] Net: UEC0, UEC1, UEC3 [PRIME], eTSEC0, eTSEC1 Hit any key to stop autoboot: 0 UEC: PHY is Generic MII (70431) UEC3: Full Duplex switching to rgmii 100 UEC3: Speed 100BT UEC3: Link is up UEC3: Link is down
^^^^^^^^^^^^^^^^^^^^
The driver "thinks" the link went away again. When the cable is connected all the time, then this is an indication of something going wrong. You should try to diagnose, why the software gets this link change and if it really is an information that the phy provides, if the physical path to the phy is stable.
Best wishes Detlev Zundel
I am using u-boot.2010.09 on a MPC8568-based board.
When trying to boot over one of the UEC network interfaces, it is not working instantly. The cable is connected from the beginning, but I have to issue a manual 'boot' command, sometimes even multiple times before the link is correct. This is the output:
Do all the UEC interfaces show the same symptoms?
Yes, this happens for all UECs. And I think it worked until we switched from u-boot 2009.11.1 to 2010.09 - but there's so much change that I didn't find the reason for it, yet.
The driver "thinks" the link went away again. When the cable is connected all the time, then this is an indication of something going wrong. You should try to diagnose, why the software gets this link change and if it really is an information that the phy provides, if the physical path to the phy is stable.
Well, the software runs though uec_init (the_first_run is zero) and gets a positive link state in the do-while-loop instantly. Afterwards adjust_link is called - and there it fails. Strange thing - I guess I need to dig a little deeper...
Code hints are very appreciated! ;-)
Best wishes Detlev Zundel
Thanks! Matthias
Hi Matthias,
I am using u-boot.2010.09 on a MPC8568-based board.
When trying to boot over one of the UEC network interfaces, it is not working instantly. The cable is connected from the beginning, but I have to issue a manual 'boot' command, sometimes even multiple times before the link is correct. This is the output:
Do all the UEC interfaces show the same symptoms?
Yes, this happens for all UECs. And I think it worked until we switched from u-boot 2009.11.1 to 2010.09 - but there's so much change that I didn't find the reason for it, yet.
Ah! I didn't realize that you are in the excellent position to have one good and one bad commit. Simply use git bisect to find the problematic commit and show that to us.
Best wishes Detlev
Hi Detlef,
I am using u-boot.2010.09 on a MPC8568-based board.
Ah! I didn't realize that you are in the excellent position to have one good and one bad commit. Simply use git bisect to find the problematic commit and show that to us.
so far I traced it down to the adjust_link call in uec_init from file uec.c (line 1234 in release 2011.03).
This call wasn't there in release 2009.11.1 and removing that line solves the issue here.
I don't know, why this went in and what the drawbacks are without it. Maybe someone on this list knows... (Sorry, I didn't search for a specific commit in git, yet. I just diffed pertinent files around the qe|uec|net drivers first.)
Happy sunny Easter all! 8-) Matthias
Hi Matthias,
I am using u-boot.2010.09 on a MPC8568-based board.
Ah! I didn't realize that you are in the excellent position to have one good and one bad commit. Simply use git bisect to find the problematic commit and show that to us.
so far I traced it down to the adjust_link call in uec_init from file uec.c (line 1234 in release 2011.03).
This call wasn't there in release 2009.11.1 and removing that line solves the issue here.
git blame shows this commit to be responsible:
commit 582c55a0274f38e6e7e35b95e7ab81d3e912f700 Author: Heiko Schocher hs@denx.de Date: Wed Jan 20 09:04:28 2010 +0100
83xx, uec: split enet_interface in two variables
There's no sensible reason to unite speed and interface type into one variable. So split this variable enet_interface into two vars: enet_interface_type, which hold the interface type and speed.
Also: add the possibility for switching between 10 and 100 MBit interfaces on the fly, when running in FAST_ETH mode.
Signed-off-by: Heiko Schocher hs@denx.de Signed-off-by: Ben Warren biggerbadderben@gmail.com
I don't know, why this went in and what the drawbacks are without it. Maybe someone on this list knows... (Sorry, I didn't search for a specific commit in git, yet. I just diffed pertinent files around the qe|uec|net drivers first.)
Hm, looking at adjust_link code, it seems that for you someone set mii_info->link to 0 which gets you into the else clause of this function. On a quick grep, I cannot find any place where this happens, but I guess this is your problem (or at least one of them) ;)
Maybe Heiko can contribute some more insights?
Happy sunny Easter all! 8-)
Same to you, thanks! Detlev
Hmmm. I'm not seeing a delayed link behaviour at all and I am using the latest u-boot-2011.03 on an 8323ERDB which has two UEC's. On Apr 19, 2011 11:07 PM, "DUNDA Matthias" Matthias.DUNDA@thalesgroup.com wrote:
I am using u-boot.2010.09 on a MPC8568-based board.
When trying to boot over one of the UEC network interfaces, it is not working instantly. The cable is connected from the beginning, but I have to issue a manual 'boot' command, sometimes even multiple times before the link is correct. This is the output:
Do all the UEC interfaces show the same symptoms?
Yes, this happens for all UECs. And I think it worked until we switched
from u-boot 2009.11.1 to 2010.09 - but there's so much change that I didn't find the reason for it, yet.
The driver "thinks" the link went away again. When the cable is connected all the time, then this is an indication of something going wrong. You should try to diagnose, why the software gets this link change and if it really is an information that the phy provides, if the physical path to the phy is stable.
Well, the software runs though uec_init (the_first_run is zero) and gets a
positive link state in the do-while-loop instantly. Afterwards adjust_link is called - and there it fails. Strange thing - I guess I need to dig a little deeper...
Code hints are very appreciated! ;-)
Best wishes Detlev Zundel
Thanks! Matthias
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
participants (3)
-
Charles Krinke -
Detlev Zundel -
DUNDA Matthias