CONFIG_MII, 83xx, no MII device?

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

-----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?

Quoted 1 line · On Fri, 30 Nov 2007 03:22:37 -0800 "Russell McGuire"…

How can I enable full MII commands? Currently it just says

there are NO MII

Quoted 1 line

devices available, i.e. a blank list will appear.

Quoted 12 lines

-----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" <[email protected]> wrote:

Quoted 3 lines

Quoted 1 line

How can I enable full MII commands? Currently it just says

there are NO MII

Quoted 1 line

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?

Quoted 5 lines

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 <[email protected]>

---
 drivers/qe/uec.c     |   17 ++++-------------
 drivers/qe/uec_phy.c |   49 ++++++++++++++++++++++++++++++++++-----------
----
 2 files changed, 38 insertions(+), 28 deletions(-)

drivers/qe/uec.c +4 -11

index dc2765b..9bd80e7 100644
@@ -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;
 

drivers/qe/uec.c +0 -2

 	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 */

drivers/qe/uec_phy.c +28 -13

index ca6faa6..f3382f2 100644
@@ -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) */

drivers/qe/uec_phy.c +6 -3

+	} 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

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,

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
________________________________

drivers/qe/uec_phy.c static int genmii_update_link (struct uec_mii_info *mii_info) · line 282

Quoted 6 lines

drivers/qe/uec_phy.c +6 -0

+	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");

-----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

Quoted 5 lines · 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

Quoted 2 lines

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

Quoted 1 line

if I issue a tftp load three times in a row, the 2nd time it will tear

down

Quoted 1 line

the link and restart it. The third time it will crash, though I believe

this

Quoted 3 lines

is to do with the below mentioned printf issue.

I am looking into ways to optimize this, are there any updates to the

patch

Quoted 3 lines

before I start modifying things?

Another bug?? Not sure this is Ethernet specific but perhaps U-boot

generic.

Quoted 6 lines

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]

Quoted 6 lines

drivers/qe/uec_phy.c static int genmii_update_link (struct uec_mii_info *mii_info) · line 282

Quoted 6 lines

drivers/qe/uec_phy.c +6 -0

+	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

Any ideas?

-----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.

-----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

Quoted 6 lines

-----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

Quoted 13 lines

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...

Quoted 3 lines

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

Quoted 36 lines

-----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

Quoted 7 lines

-----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

Quoted 12 lines

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...

Quoted 4 lines

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.

Quoted 7 lines

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

-------------------------------------------------------------------------
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

-----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?