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

[Russell McGuire]

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 at videopresence.com] 
Sent: Wednesday, December 19, 2007 3:37 PM
To: 'joakim.tjernlund at transmode.se'
Cc: 'Kim Phillips'; 'u-boot-users at 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 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