So I have patched up all the files and running with it.
The system boots up great, but any attempt to access the Ethernet after boot causes U-boot to reset. I did some debugging and have found that it is hosing itself over in the drivers/qe/uec.c: phy_change() function.
Calling: uec->mii_info->phyinfo->read_status(uec->mii_info); causes the crash.
I added some debug output to the pointers being used here, are we sure the structures are being initialized prior to usage?
Example Code with output:
static void phy_change(struct eth_device *dev) { uec_private_t *uec = (uec_private_t *)dev->priv;
printf("%s:%d\n", __FUNCTION__, __LINE__); //RWM DEBUG printf("uec = %x08\n", uec); //RWM DEBUG printf("uec->mii_info = %x08\n", uec->mii_info); //RWM DEBUG printf("uec->mii_info->phyinfo = %x08\n", uec->mii_info->phyinfo); //All works up to this point.
/* Update the link, speed, duplex */ uec->mii_info->phyinfo->read_status(uec->mii_info); //This line causes the crash
printf("%s:%d\n", __FUNCTION__, __LINE__); //RWM DEBUG, never gets to here /* Adjust the interface according to speed */ adjust_link(dev); }
Output form this looks like the following:
UBOOT> ping 192.168.1.1 phy_change:586 uec = 1ffa320008 //seems ok, as I am running with 512MB RAM uec->mii_info = 008 //Seems odd uec->mii_info->phyinfo = feffffdf08 //really seems odd Machine check in kernel mode. Caused by (from msr): regs 1ffa0b10 Unknown values in msr NIP: 0000111C XER: 00000000 LR: 1FFD2484 REGS: 1ffa0b10 TRAP: 0200 DAR: 00000000 MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 1FFD2484 1FFA0C00 00000080 00000000 00000001 00000010 00000001 00000008 GPR08: 00000000 FEFFFFDF 00000000 1FFA09B6 1FFA09B8 8AA7F71E 1FFFC000 3FFC3000 GPR16: 92A3B06C 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 1FFA95F0 1FFA31C0 1FFF57B0 1FFED660 1FFA3200 1FFA0F54 1FFFC630 1FFA31C0 Call backtrace: 1FFD2484 1FFD2664 1FFCADBC 1FFC9484 1FFDB7A4 1FFE2B70 1FFE2268 1FFE2478 1FFD5504 1FFE2B70 1FFE2268 1FFE23C4 1FFD47BC 1FFC7CFC 1FFC673C 00086002 machine check Resetting the board.
Any ideas?
-Russ
-----Original Message----- From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] Sent: Wednesday, December 19, 2007 12:07 AM To: rmcguire@videopresence.com Cc: 'Kim Phillips'; u-boot-users@lists.sourceforge.net Subject: Re: 83xx, FSL_UEC reducing boot latency, printf causing crash
On Tue, 2007-12-18 at 19:58 -0800, Russell McGuire wrote:
Kim,
I am getting around to helping test out this reduced latency patch.
Interesting I have found the boot cycle times are MUCH faster, however,
is
it supposed to continuously restart the auto-negotiation each time a ethernet access is performed? i.e. a new ping, or tftp download? For
example
if I issue a tftp load three times in a row, the 2nd time it will tear
down
the link and restart it. The third time it will crash, though I believe
this
is to do with the below mentioned printf issue.
I am looking into ways to optimize this, are there any updates to the
patch
before I start modifying things?
Another bug?? Not sure this is Ethernet specific but perhaps U-boot
generic.
Is that if I add printf() statements throughout the uec code I get total crashes of u-boot, i.e. bad traps that result in a back trace and board resets.
-Russ ________________________________
[SNIP]
- status = phy_read(mii_info, PHY_BMSR);
- if ((status & PHY_BMSR_LS) && (status & PHY_BMSR_AUTN_ABLE)
&& !(status & PHY_BMSR_AUTN_COMP)) {int i = 0;puts("Waiting for PHY auto negotiation to complete");This printout never happens for me, even though AN is restarted.
I am not really sure that AN needs to be restarted on the first access either. An AN restart adds a 2 seconds delay for me that I didn't have before. Maybe it would be enough to check if AN needs to be restarted and only perform an restart if needed?
Jocke