[U-Boot-Users] CONFIG_MII, 83xx, no MII device?

[U-Boot-Users] CONFIG_MII, 83xx, no MII device?

[Russell McGuire]

All,

Trying to figure out how to enable the MII debugging, query commands in
u-boot so I can debug a Gigabit national DP83865 PHY chip on a MPC8360E
board.

I have enabled the CONFIG_MII and CONFIG_CMD_II, along with PHY address and
CONFIG_PHY_GIGE.

I have 'added' the DP83865 to the list of detected PHY's inside the
uec_phy.c file, <copied from the standard MII stuff>.

I am able to boot U-boot and see the device is detected. As well it works up
to 100BaseTX. However, I cannot get it to work in 1000BaseT mode. So I KNOW
the MII bus is operational and working correctly.

How can I enable full MII commands? Currently it just says there are NO MII
devices available, i.e. a blank list will appear.

Is there a registration command that needs to be added to our custom board
files? More or less I have cloned the MPC8360E-MDS board files.

-Russ

[U-Boot-Users] CONFIG_MII, 83xx, no MII device?

[Kim Phillips]

On Fri, 30 Nov 2007 03:22:37 -0800
"Russell McGuire" <rmcguire@videopresence.com> wrote:

> How can I enable full MII commands? Currently it just says there are NO MII
> devices available, i.e. a blank list will appear.

try this:

diff --git a/drivers/qe/uec.c b/drivers/qe/uec.c
index 9bd80e7..7fa4246 100644
--- a/drivers/qe/uec.c
+++ b/drivers/qe/uec.c
@@ -21,6 +21,7 @@
 
 #include "common.h"
 #include "net.h"
+#include "miiphy.h"
 #include "malloc.h"
 #include "asm/errno.h"
 #include "asm/io.h"
@@ -69,6 +70,9 @@ static uec_info_t eth2_uec_info = {
 };
 #endif
 
+/* needed for the u-boot mii command interface */
+static struct eth_device	*eth_devs[2];
+
 static int uec_mac_enable(uec_private_t *uec, comm_dir_e mode)
 {
 	uec_t		*uec_regs;
@@ -1202,6 +1206,50 @@ static int uec_recv(struct eth_device* dev)
 	return 1;
 }
 
+/*
+ * Read a MII PHY register.
+ *
+ * Returns:
+ *  0 on success
+ */
+static int uec_miiphy_read(char *devname, unsigned char addr,
+			    unsigned char reg, unsigned short *value)
+{
+	unsigned short	ret;
+	int		index;
+	struct eth_device	*dev;
+
+	/* devname is 'FSL UECn', so generate an index from that */
+	index = devname[7] - '0';
+	dev = eth_devs[index];
+
+	ret = (unsigned short)uec_read_phy_reg(dev, addr, reg);
+	*value = ret;
+
+	return 0;
+}
+
+/*
+ * Write a MII PHY register.
+ *
+ * Returns:
+ *  0 on success
+ */
+static int uec_miiphy_write(char *devname, unsigned char addr,
+			     unsigned char reg, unsigned short value)
+{
+	int		index;
+	struct eth_device	*dev;
+
+	/* devname is 'FSL UECn', so generate an index from that */
+	index = devname[7] - '0';
+	dev = eth_devs[index];
+
+	uec_write_phy_reg(dev, addr, reg, value);
+
+	return 0;
+}
+
 int uec_initialize(int index)
 {
 	struct eth_device	*dev;
@@ -1252,12 +1300,17 @@ int uec_initialize(int index)
 
 	eth_register(dev);
 
+	eth_devs[index] = dev;
+
 	err = uec_startup(uec);
 	if (err) {
 		printf("%s: Cannot configure net device, aborting.",dev->name);
 		return err;
 	}
 
+#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) && !defined(BITBANGMII)
+	miiphy_register(dev->name, uec_miiphy_read, uec_miiphy_write);
+#endif
 	err = init_phy(dev);
 	if (err) {
 		printf("%s: Cannot initialize PHY, aborting.\n", dev->name);
---

you might have to 

mii device 'FSL UEC1'

first.

I'll submit a proper patch if it works for you.

Kim

[U-Boot-Users] CONFIG_MII, 83xx, no MII device?

[Joakim Tjernlund]

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Kim Phillips
> Sent: den 4 december 2007 23:04
> To: rmcguire at videopresence.com
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] CONFIG_MII, 83xx, no MII device?
> 
> On Fri, 30 Nov 2007 03:22:37 -0800
> "Russell McGuire" <rmcguire@videopresence.com> wrote:
> 
> > How can I enable full MII commands? Currently it just says 
> there are NO MII
> > devices available, i.e. a blank list will appear.

Hi Kim

Perhaps you can have a look at "MPC83xx Ethernet bug"
while you are at it?

 Jocke

[U-Boot-Users] CONFIG_MII, 83xx, no MII device?

[Kim Phillips]

On Wed, 5 Dec 2007 00:50:48 +0100
"Joakim Tjernlund" <joakim.tjernlund@transmode.se> wrote:

> > -----Original Message-----
> > From: u-boot-users-bounces at lists.sourceforge.net 
> > [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> > Of Kim Phillips
> > Sent: den 4 december 2007 23:04
> > To: rmcguire at videopresence.com
> > Cc: u-boot-users at lists.sourceforge.net
> > Subject: Re: [U-Boot-Users] CONFIG_MII, 83xx, no MII device?
> > 
> > On Fri, 30 Nov 2007 03:22:37 -0800
> > "Russell McGuire" <rmcguire@videopresence.com> wrote:
> > 
> > > How can I enable full MII commands? Currently it just says 
> > there are NO MII
> > > devices available, i.e. a blank list will appear.
> 
> Hi Kim
> 
> Perhaps you can have a look at "MPC83xx Ethernet bug"
> while you are at it?
> 
<sigh>

Hi Jocke,

not completely tested yet; perhaps you can help? :

Subject: [PATCH] net: reduce boot latency on QE UEC based boards

actually polling for PHY autonegotiation to finish enables us to remove the
paranoid (and horrid) 5 second boot prompt latency present on QE based boards.

autonegotiation wait code shamelessly stolen from tsec driver.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
 drivers/qe/uec.c     |   17 ++++-------------
 drivers/qe/uec_phy.c |   49 ++++++++++++++++++++++++++++++++++---------------
 2 files changed, 38 insertions(+), 28 deletions(-)

diff --git a/drivers/qe/uec.c b/drivers/qe/uec.c
index dc2765b..9bd80e7 100644
--- a/drivers/qe/uec.c
+++ b/drivers/qe/uec.c
@@ -562,21 +562,12 @@ static void adjust_link(struct eth_device *dev)
 static void phy_change(struct eth_device *dev)
 {
 	uec_private_t	*uec = (uec_private_t *)dev->priv;
-	uec_t		*uec_regs;
-	int		result = 0;
-
-	uec_regs = uec->uec_regs;
-
-	/* Delay 5s to give the PHY a chance to change the register state */
-	udelay(5000000);
 
 	/* Update the link, speed, duplex */
-	result = uec->mii_info->phyinfo->read_status(uec->mii_info);
+	uec->mii_info->phyinfo->read_status(uec->mii_info);
 
 	/* Adjust the interface according to speed */
-	if ((0 == result) || (uec->mii_info->link == 0)) {
-		adjust_link(dev);
-	}
+	adjust_link(dev);
 }
 
 static int uec_set_mac_address(uec_private_t *uec, u8 *mac_addr)
@@ -1103,6 +1094,8 @@ static int uec_init(struct eth_device* dev, bd_t *bd)
 	uec_private_t		*uec;
 	int			err;
 
+	phy_change(dev);
+
 	uec = (uec_private_t *)dev->priv;
 
 	if (uec->the_first_run == 0) {
@@ -1271,8 +1264,6 @@ int uec_initialize(int index)
 		return err;
 	}
 
-	phy_change(dev);
-
 	return 1;
 }
 #endif /* CONFIG_QE */
diff --git a/drivers/qe/uec_phy.c b/drivers/qe/uec_phy.c
index ca6faa6..f3382f2 100644
--- a/drivers/qe/uec_phy.c
+++ b/drivers/qe/uec_phy.c
@@ -270,20 +270,41 @@ static int genmii_update_link (struct uec_mii_info *mii_info)
 {
 	u16 status;
 
-	/* Do a fake read */
-	phy_read (mii_info, PHY_BMSR);
-
-	/* Read link and autonegotiation status */
-	status = phy_read (mii_info, PHY_BMSR);
-	if ((status & PHY_BMSR_LS) == 0)
-		mii_info->link = 0;
-	else
+	/*
+	 * Wait if the link is up, and autonegotiation is in progress
+	 * (ie - we're capable and it's not done)
+	 */
+	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");
+		while (!(status & PHY_BMSR_AUTN_COMP)) {
+			/*
+			 * Timeout reached ?
+			 */
+			if (i > UGETH_AN_TIMEOUT) {
+				puts(" TIMEOUT !\n");
+				mii_info->link = 0;
+				return 0;
+			}
+
+			if ((i++ % 1000) == 0) {
+				putc('.');
+			}
+			udelay(1000);	/* 1 ms */
+			status = phy_read(mii_info, PHY_BMSR);
+		}
+		puts(" done\n");
 		mii_info->link = 1;
-
-	/* If we are autonegotiating, and not done,
-	 * return an error */
-	if (mii_info->autoneg && !(status & PHY_BMSR_AUTN_COMP))
-		return -EAGAIN;
+		udelay(500000);	/* another 500 ms (results in faster booting) */
+	} else {
+		if (status & PHY_BMSR_LS)
+			mii_info->link = 1;
+		else
+			mii_info->link = 0;
+	}
 
 	return 0;
 }
@@ -397,8 +418,6 @@ static int dm9161_init (struct uec_mii_info *mii_info)
 	config_genmii_advert (mii_info);
 	/* Start/restart aneg */
 	genmii_config_aneg (mii_info);
-	/* Delay to wait the aneg compeleted */
-	udelay (3000000);
 
 	return 0;
 }
-- 
1.5.2.2

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

[Russell McGuire]

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
________________________________

> > Hi Kim
> >
> > Perhaps you can have a look at "MPC83xx Ethernet bug"
> > while you are at it?
> >
> <sigh>
> 
> Hi Jocke,
> 
> not completely tested yet; perhaps you can help? :
> 
> Subject: [PATCH] net: reduce boot latency on QE UEC based boards
> 
> actually polling for PHY autonegotiation to finish enables us to remove
> the
> paranoid (and horrid) 5 second boot prompt latency present on QE based
> boards.
> 
> autonegotiation wait code shamelessly stolen from tsec driver.
> 
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
>  drivers/qe/uec.c     |   17 ++++-------------
>  drivers/qe/uec_phy.c |   49 ++++++++++++++++++++++++++++++++++-----------
> ----
>  2 files changed, 38 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/qe/uec.c b/drivers/qe/uec.c
> index dc2765b..9bd80e7 100644
> --- a/drivers/qe/uec.c
> +++ b/drivers/qe/uec.c
> @@ -562,21 +562,12 @@ static void adjust_link(struct eth_device *dev)
>  static void phy_change(struct eth_device *dev)
>  {
>  	uec_private_t	*uec = (uec_private_t *)dev->priv;
> -	uec_t		*uec_regs;
> -	int		result = 0;
> -
> -	uec_regs = uec->uec_regs;
> -
> -	/* Delay 5s to give the PHY a chance to change the register state */
> -	udelay(5000000);
> 
>  	/* Update the link, speed, duplex */
> -	result = uec->mii_info->phyinfo->read_status(uec->mii_info);
> +	uec->mii_info->phyinfo->read_status(uec->mii_info);
> 
>  	/* Adjust the interface according to speed */
> -	if ((0 == result) || (uec->mii_info->link == 0)) {
> -		adjust_link(dev);
> -	}
> +	adjust_link(dev);
>  }
> 
>  static int uec_set_mac_address(uec_private_t *uec, u8 *mac_addr)
> @@ -1103,6 +1094,8 @@ static int uec_init(struct eth_device* dev, bd_t
> *bd)
>  	uec_private_t		*uec;
>  	int			err;
> 
> +	phy_change(dev);
> +
>  	uec = (uec_private_t *)dev->priv;
> 
>  	if (uec->the_first_run == 0) {
> @@ -1271,8 +1264,6 @@ int uec_initialize(int index)
>  		return err;
>  	}
> 
> -	phy_change(dev);
> -
>  	return 1;
>  }
>  #endif /* CONFIG_QE */
> diff --git a/drivers/qe/uec_phy.c b/drivers/qe/uec_phy.c
> index ca6faa6..f3382f2 100644
> --- a/drivers/qe/uec_phy.c
> +++ b/drivers/qe/uec_phy.c
> @@ -270,20 +270,41 @@ static int genmii_update_link (struct uec_mii_info
> *mii_info)
>  {
>  	u16 status;
> 
> -	/* Do a fake read */
> -	phy_read (mii_info, PHY_BMSR);
> -
> -	/* Read link and autonegotiation status */
> -	status = phy_read (mii_info, PHY_BMSR);
> -	if ((status & PHY_BMSR_LS) == 0)
> -		mii_info->link = 0;
> -	else
> +	/*
> +	 * Wait if the link is up, and autonegotiation is in progress
> +	 * (ie - we're capable and it's not done)
> +	 */
> +	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");
> +		while (!(status & PHY_BMSR_AUTN_COMP)) {
> +			/*
> +			 * Timeout reached ?
> +			 */
> +			if (i > UGETH_AN_TIMEOUT) {
> +				puts(" TIMEOUT !\n");
> +				mii_info->link = 0;
> +				return 0;
> +			}
> +
> +			if ((i++ % 1000) == 0) {
> +				putc('.');
> +			}
> +			udelay(1000);	/* 1 ms */
> +			status = phy_read(mii_info, PHY_BMSR);
> +		}
> +		puts(" done\n");
>  		mii_info->link = 1;
> -
> -	/* If we are autonegotiating, and not done,
> -	 * return an error */
> -	if (mii_info->autoneg && !(status & PHY_BMSR_AUTN_COMP))
> -		return -EAGAIN;
> +		udelay(500000);	/* another 500 ms (results in faster
> booting) */
> +	} else {
> +		if (status & PHY_BMSR_LS)
> +			mii_info->link = 1;
> +		else
> +			mii_info->link = 0;
> +	}
> 
>  	return 0;
>  }
> @@ -397,8 +418,6 @@ static int dm9161_init (struct uec_mii_info *mii_info)
>  	config_genmii_advert (mii_info);
>  	/* Start/restart aneg */
>  	genmii_config_aneg (mii_info);
> -	/* Delay to wait the aneg compeleted */
> -	udelay (3000000);
> 
>  	return 0;
>  }
> --
> 1.5.2.2

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

[Joakim Tjernlund]

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.

Kim sent me an updated patch after some feedback from me. I did two
more updates, one of them removes the AN for each transfer. The printf()
crash sounds familiar, perhaps it is gone now?

Patches attached.

The last 2 patches are on top of Kims.

   Jocke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-net-support-MII-commands-on-QE-UEC.patch
Type: application/mbox
Size: 2566 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071219/59330107/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-net-reduce-boot-latency-on-QE-UEC-based-boards.patch
Type: application/mbox
Size: 9983 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071219/59330107/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0012-NET-Proper-return-code-handling-in-eth_init-funct.patch
Type: application/mbox
Size: 1300 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071219/59330107/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Move-call-to-qe_set_mii_clk_src-into-uec_read_phy_.patch
Type: application/mbox
Size: 1967 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071219/59330107/attachment-0003.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Only-config-restart-ANEG-the-first-time-ethernet-is.patch
Type: application/mbox
Size: 1799 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071219/59330107/attachment-0004.bin 

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

[Joakim Tjernlund]

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 

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

[Russell McGuire]

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

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

[Kim Phillips]

On Wed, 19 Dec 2007 15:36:42 -0800
"Russell McGuire" <rmcguire@videopresence.com> wrote:

> Any ideas?

depends on your toolchain, but try reverting commit
928fe33b24cdf382a8dc8687fed24b1961cdb5d6.

Kim

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

[Russell McGuire]

All,

Maybe somebody can help me understand what I am seeing.

Dealing with the printf causing crashes problem.

This only occurs if printfs are caleed from within the uec_phy.c file, and
only them within functions that are mapped as part of a phy specific call,
i.e. a function that was within a specific part, marvell, national, etc... 

So when a read_status call is called, of course depending on your
configuration it might get redirected to call genmii_read_status or
equivlant.

However, this once inside the phy mapped functions, printfs are illegal.
And causing BAD trap errors, in this case it is causing an unhandled
exception on Vector 400 on my system, which is a static storage handler
error. Not entirely sure on WHY, but looking at the back trace and several
pointers, I have noticed this.

Up till the call to any phy specific function, U-boot is happily running
from the top of DDR Ram, but as soon as we traverse into phy specific
handlers, it jumps BACK INTO FLASH! and starts executing! On my system this
means the backtrace will contain a lot of calls around the 256MB boundary
i.e. 0x0ffxxxxx and then suddently I will see return address being pushed at
0xE00xxxxx.  My guess is that when printf or similar gets called, it tries
to do a relative pop/push to the stack or something or tries to relatively
access RAM and BOMBS.

My base system has the following setup
DDR2 RAM: 0x00000000 - 0x1FFFFFFF (512MB)
FLASH: 0xE0000000 - 0xEFFFFFFF (128MB physical, 128MB reserved for future)
SOCL: 0xF0000000 - 0xF1000000 (IMMR SPACE)

When I get the error, I see the PC register is pointing at 0xFBFe7ee4????

This would make perfect sense, if the stack were placed at the top of ram,
and I was executing 'accidently' from flash, i.e. it the PC was assumed to
be at 0x0fxxxxxx and it somehow got shifted to the 0xE0xxxxxx block, and
then tried to relatively add 256MB to get to the stack. It would end up at
the 0xFxxxxxxx area??? 

Am I way off base here??  WHY is the UEC_Driver accessing flash after U-boot
is running from RAM?


-Russ

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

[Joakim Tjernlund]

> -----Original Message-----
> From: Russell McGuire [mailto:rmcguire at videopresence.com] 
> Sent: den 21 december 2007 11:46
> To: u-boot-users at lists.sourceforge.net
> Cc: 'Kim Phillips'; joakim.tjernlund at transmode.se
> Subject: RE: 83xx, FSL_UEC reducing boot latency, printf causing crash
> 
> All,
> 
> Maybe somebody can help me understand what I am seeing
> Dealing with the printf causing crashes problem.
> 
> This only occurs if printfs are caleed from within the 
> uec_phy.c file, and
> only them within functions that are mapped as part of a phy 
> specific call,
> i.e. a function that was within a specific part, marvell, 
> national, etc... 
> 
> So when a read_status call is called, of course depending on your
> configuration it might get redirected to call genmii_read_status or
> equivlant.

Just to add, as I recall, it is the use of function pointers that
is the probem. These doesn't get relocated with normal u-boot
relocation. Full relocation adds stuff to __fixup_entries 
which will relocate function ptrs that normal relocation doesn't do.

 Jocke  

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

[Joakim Tjernlund]

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Joakim Tjernlund
> Sent: den 21 december 2007 13:35
> To: rmcguire at videopresence.com; u-boot-users at lists.sourceforge.net
> Cc: 'Kim Phillips'
> Subject: Re: [U-Boot-Users] 83xx, FSL_UEC reducing boot 
> latency,printf causing crash
> 
> > -----Original Message-----
> > From: Russell McGuire [mailto:rmcguire at videopresence.com] 
> > Sent: den 21 december 2007 11:46
> > To: u-boot-users at lists.sourceforge.net
> > Cc: 'Kim Phillips'; joakim.tjernlund at transmode.se
> > Subject: RE: 83xx, FSL_UEC reducing boot latency, printf 
> causing crash
> > 
> > All,
> > 
> > Maybe somebody can help me understand what I am seeing
> > Dealing with the printf causing crashes problem.
> > 
> > This only occurs if printfs are caleed from within the 
> > uec_phy.c file, and
> > only them within functions that are mapped as part of a phy 
> > specific call,
> > i.e. a function that was within a specific part, marvell, 
> > national, etc... 
> > 
> > So when a read_status call is called, of course depending on your
> > configuration it might get redirected to call genmii_read_status or
> > equivlant.
> 
> Just to add, as I recall, it is the use of function pointers that
> is the probem. These doesn't get relocated with normal u-boot
> relocation. Full relocation adds stuff to __fixup_entries 
> which will relocate function ptrs that normal relocation doesn't do.
> 
>  Jocke  

BTW, the marwell entry looks bad:
static struct phy_info phy_info_marvell = {
        .phy_id = 0x01410c00,
        .phy_id_mask = 0xffffff00,
        .name = "Marvell 88E11x1",
        .features = MII_GBIT_FEATURES,
        .config_aneg = &marvell_config_aneg,
        .read_status = &marvell_read_status,
        .ack_interrupt = &marvell_ack_interrupt,
        .config_intr = &marvell_config_intr,
};

Those & should not be there I think.

Futhermore I think each specific PHY type should have its own CONFIG_ #define
to reduce code.

  Jocke

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

[Ben Warren]

Joakim Tjernlund wrote:
>> -----Original Message-----
>> From: u-boot-users-bounces at lists.sourceforge.net 
>> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
>> Of Joakim Tjernlund
>> Sent: den 21 december 2007 13:35
>> To: rmcguire at videopresence.com; u-boot-users at lists.sourceforge.net
>> Cc: 'Kim Phillips'
>> Subject: Re: [U-Boot-Users] 83xx, FSL_UEC reducing boot 
>> latency,printf causing crash
>>
>>     
>>> -----Original Message-----
>>> From: Russell McGuire [mailto:rmcguire at videopresence.com] 
>>> Sent: den 21 december 2007 11:46
>>> To: u-boot-users at lists.sourceforge.net
>>> Cc: 'Kim Phillips'; joakim.tjernlund at transmode.se
>>> Subject: RE: 83xx, FSL_UEC reducing boot latency, printf 
>>>       
>> causing crash
>>     
>>> All,
>>>
>>> Maybe somebody can help me understand what I am seeing
>>> Dealing with the printf causing crashes problem.
>>>
>>> This only occurs if printfs are caleed from within the 
>>> uec_phy.c file, and
>>> only them within functions that are mapped as part of a phy 
>>> specific call,
>>> i.e. a function that was within a specific part, marvell, 
>>> national, etc... 
>>>
>>> So when a read_status call is called, of course depending on your
>>> configuration it might get redirected to call genmii_read_status or
>>> equivlant.
>>>       
>> Just to add, as I recall, it is the use of function pointers that
>> is the probem. These doesn't get relocated with normal u-boot
>> relocation. Full relocation adds stuff to __fixup_entries 
>> which will relocate function ptrs that normal relocation doesn't do.
>>
>>  Jocke  
>>     
>
> BTW, the marwell entry looks bad:
> static struct phy_info phy_info_marvell = {
>         .phy_id = 0x01410c00,
>         .phy_id_mask = 0xffffff00,
>         .name = "Marvell 88E11x1",
>         .features = MII_GBIT_FEATURES,
>         .config_aneg = &marvell_config_aneg,
>         .read_status = &marvell_read_status,
>         .ack_interrupt = &marvell_ack_interrupt,
>         .config_intr = &marvell_config_intr,
> };
>
> Those & should not be there I think.
>
> Futhermore I think each specific PHY type should have its own CONFIG_ #define
> to reduce code.
>
>   Jocke
>
>   
In the much-talked-about-but-little-seen upcoming PHY library, each 
manufacturer has its own source file (and of course CONFIG_), just like 
Linux
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>   

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

[Russell McGuire]

Update,

So by following the back trace after reset I was able to remove all
references to functions like, printf, putc, puts, etc... From within any
function that was executing from FLASH, all of the Bad trap errors have been
removed. 

Is there a chance I have the wrong values setup for my internal memory
controller, that might be cuasing this? 

I am guessing maybe other people who use Freescale boards don't see this
problem because their memory ranges are wrapping around, i.e. their flash is
at 0xFE000000 and when they wrap memory, they are still accessing RAM. 

However, I can't map my flash to this address, since I need expansion room
for massive quantities.

So how can we fix this execution from flash issue?

-Russ

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

[Joakim Tjernlund]

 

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Russell McGuire
> Sent: den 21 december 2007 12:03
> To: joakim.tjernlund at transmode.se
> Cc: u-boot-users at lists.sourceforge.net; 'Kim Phillips'
> Subject: Re: [U-Boot-Users] 83xx, FSL_UEC reducing boot 
> latency,printf causing crash
> 
> Update,
> 
> So by following the back trace after reset I was able to remove all
> references to functions like, printf, putc, puts, etc... From 
> within any
> function that was executing from FLASH, all of the Bad trap 
> errors have been
> removed. 
> 
> Is there a chance I have the wrong values setup for my internal memory
> controller, that might be cuasing this? 
> 
> I am guessing maybe other people who use Freescale boards 
> don't see this
> problem because their memory ranges are wrapping around, i.e. 
> their flash is
> at 0xFE000000 and when they wrap memory, they are still 
> accessing RAM. 
> 
> However, I can't map my flash to this address, since I need 
> expansion room
> for massive quantities.
> 
> So how can we fix this execution from flash issue?

Ahh, this is most likely depending on the manual relocation of
pointers/global data that u-boot does, only partial relocation is
performed. To get full relocation you must revert commit 
928fe33b24cdf382a8dc8687fed24b1961cdb5d6 or some variation
thereof. Grant Likely knows more, but I think full relocation
was reverted due to some toolchains had problems with it.

I once tried an early version of full relocation and it worked
for me.
I am using gcc 3.4.6, softfloat and ld 2.16.1 built with
gentoo's crossdev.

I am gone in a few hours and won't return until a few days after
X-mas. Access to E-mail will be limited.

 Jocke
 

[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