[U-Boot-Users] 83xx, FSL_UEC reducing boot latency, printf causing crash

[Russell McGuire <rmcguire@videopresence.com>]

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 at transmode.se]
> Sent: Wednesday, December 19, 2007 12:07 AM
> To: rmcguire at videopresence.com
> Cc: 'Kim Phillips'; u-boot-users at 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