Update...
I guess to answer one of Kim's question, I am using U-boot 1.3.0 with patches. Also everything is based on the ELDK 4.0 tool chain, using ARCH=ppc for U-boot. I assume that is correct, and U-boot hasn't changed over to ARCH=powerpc yet.
So the first problem was I had a straggling call to phy_change(), before the eth device was being initiated at the top of uec_init(), that has corrected the 'first usage' error. Apparently left over from all the patches.
Anyway, that being removed, the device will now come up and work on the first try. However, issuing a 2nd ping command or similar will crash it.
It always dies on the call to: curphy->read_status(uec->mii_info); near the end of uec_init();
It results in a Bad Trap message from U-boot at vector 400
Anybody got a flow chart on how they expect this to work? Lol. I'll keep plugging away.
-Russ
-----Original Message----- From: Russell McGuire [mailto:rmcguire@videopresence.com] Sent: Wednesday, December 19, 2007 3:37 PM To: 'joakim.tjernlund@transmode.se' Cc: 'Kim Phillips'; 'u-boot-users@lists.sourceforge.net' Subject: RE: 83xx, FSL_UEC reducing boot latency, printf causing crash
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