Skip to contentSkip to conversation

gdb on a 440GP ELDK

PATCH New Mark Powell 6 participants 8 messages Oct 21, 2004 – Oct 22, 2004 Network drivers

lore
Share & tools
lore
#0 lore raw

I hope this is not a dumb question.
I can't seem to use breakpoints in gdb (application debugging in userland not kernel debugging).
The system is a custom 440GP card, running the kernel from ELDK 3.0, modified for this card. The card is based heavily on the Ebony. I am using the ELDK f/s as NFS root. The system seems to basically run fine apart from the fact that gdb doesn't stop at any breakpoints.
Is there any known issue with this combination of gcc/binutils/gdb ?
Versions are:

GNU gdb Yellow Dog Linux (5.2.1-4b_3)
gcc (GCC) 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a_2) GNU assembler 2.13.90.0.18 20030206

TIA

#1 lore raw
Quoted 2 lines · Mark Powell

The system seems to basically run fine apart from the fact that gdb doesn't stop at any breakpoints.

Can you please provide an example? How are you running the program being debugged? If it's a daemon, are you running it interactively or trying to let it detach itself?

Jon.

#2 lore raw
Quoted 12 lines · Jon Masters
Quoted 4 lines · Mark Powell

The system seems to basically run fine apart from the fact that gdb doesn't stop at any breakpoints.

Can you please provide an example? How are you running the program being debugged? If it's a daemon, are you running it interactively or trying to let it detach itself?

Even the most simple scenario doesn't work, e.g.:

dev245:medp LinuxTestProgs> gcc -g -Wall -o hello hello.c dev245:medp LinuxTestProgs> gdb hello
GNU gdb Yellow Dog Linux (5.2.1-4b_3)
...
(gdb) l
1 #include <stdio.h>
2
3 int main(int argc, char* argv[])
4 {
5 printf ("Hello world\n");
6 return 0;
7 }
(gdb) break 5
Breakpoint 1 at 0x100004a8: file hello.c, line 5. (gdb) run
Starting program:
/central/Build/MEDP/Sentric576/Code/LinuxTestProgs/hello Hello world

Program exited normally.
(gdb)

As you can see, it just doesn't break.
I did some more checking. The same card running a 4xx file system from MontaVista 2.1 behaves the same. A 405GP card running the MVL2.1 behaves properly. So it points to something about the 440. As I said, kernel is 2.4.25 from ELDK3.0. I cloned the basic platform init code from the Ebony pretty closely, just changed the external interrupt configs, RTC type and things like that.

I would appreciate any ideas.
thanks

Signature · 4 lines
Mark Powell, Senior Software Engineer
Curtiss-Wright Controls Embedded Computing
Tel: +44 (0) 1763 852222
Email: [email protected]
#3 lore raw
Quoted 9 lines · Mark Powell
Quoted 6 lines · Jon Masters
Quoted 2 lines · Mark Powell

The system seems to basically run fine apart from the fact that gdb doesn't stop at any breakpoints.

Even the most simple scenario doesn't work, e.g.:

I have been able to borrow an Ebony system to compare and gdb worked fine on that system.
The difference is that kernel debugging (with BDI2000 support) was configured in my kernel but not in the Ebony kernel. I tried disabling the BDI2000 support in my kernel and gdb works again.

Seeing this in ebony_setup_arch():

#if !defined(CONFIG_BDI_SWITCH)
/*
* The Abatron BDI JTAG debugger does not tolerate others
* mucking with the debug registers.
*/
mtspr(SPRN_DBCR0, (DBCR0_TDE | DBCR0_IDM));
#endif

leads me to suspect that the BDI2000 support for kernel debugging stops gdb working in userland. Does that sound likely? If so, I guess it is worth recording so that the info is in the archives.

BTW thanks to you guys for resurrecting the list and recovering the archives.

Signature · 4 lines
Mark Powell, Senior Software Engineer
Curtiss-Wright Controls Embedded Computing
Tel: +44 (0) 1763 852222
Email: [email protected]
#4 lore raw
Quoted 27 lines · Mark Powell
Quoted 10 lines · Mark Powell
Quoted 7 lines · Jon Masters
Quoted 2 lines · Mark Powell

The system seems to basically run fine apart from the fact that gdb doesn't stop at any breakpoints.

Even the most simple scenario doesn't work, e.g.:

I have been able to borrow an Ebony system to compare and gdb worked fine on that system.
The difference is that kernel debugging (with BDI2000 support) was configured in my kernel but not in the Ebony kernel.
I tried disabling the BDI2000 support in my kernel and gdb works again.

Seeing this in ebony_setup_arch():

#if !defined(CONFIG_BDI_SWITCH)
    /*
     * The Abatron BDI JTAG debugger does not tolerate others
     * mucking with the debug registers.
     */
        mtspr(SPRN_DBCR0, (DBCR0_TDE | DBCR0_IDM));
Quoted 6 lines

#endif

leads me to suspect that the BDI2000 support for kernel debugging stops gdb working in userland.
Does that sound likely? If so, I guess it is worth recording so that the info is in the archives.

That's absolutely true. As the comment suggests, the BDI2000 insists on full control of the DBCR0, so configuring for IDM mode will screw it up. Not configuring for IDM mode doesn't allow kgdb/gdb to work. Since we are out of the early development phase, I'll update the defconfigs to disable the BDI config option by default.

-Matt

#5 lore raw
In reply to Mark Powell
Quoted 5 lines · Mark Powell

I hope this is not a dumb question.
I can't seem to use breakpoints in gdb (application debugging in userland not kernel debugging).
The system is a custom 440GP card, running the kernel from ELDK 3.0, modified for this card.

Which kernel is it (I have no idea what ELDK uses)?

--
Eugene

#6 lore raw
Quoted 8 lines · Eugene Surovegin
Quoted 5 lines · Mark Powell

I hope this is not a dumb question.
I can't seem to use breakpoints in gdb (application debugging in userland not kernel debugging).
The system is a custom 440GP card, running the kernel from ELDK 3.0, modified for this card.

Which kernel is it (I have no idea what ELDK uses)?

It's the Denx 2_4_devel kernel tree.

-Matt

#7 lore raw

PATCH 1/1 IBM-EMAC fixes

This patch fixes problems with a Gigabit PHY being connected via GMII interface. It seems, that the RGMII port needs to be setup again after the EMAC has been reset. It causes also some troubles to enable RX & TX without having a link. Tested on PPC440GP, GX and PPC405 boards.

drivers/net/ibm_emac/ibm_emac_core.c renamed from drivers/net/ibm_emac/ibm_emac_core.c.orig +58 -38
@@ -476,7 +476,7 @@ void emac_phy_write(struct net_device *d
 	out_be32(&emacp->em0stacr, stacr);
 
 	while (((stacr = in_be32(&emacp->em0stacr) & EMAC_STACR_OC) == 0)
-					&& (count++ < 5000))
+					&& (count++ < MDIO_DELAY))
 		udelay(1);
 	MDIO_DEBUG((" (count was %d)\n", count));
 
@@ -1018,31 +1018,49 @@ static int emac_start_xmit(struct sk_buf
 	return 0;
 }
 
+static int emac_set_mii_devs(struct ocp_enet_private *fep )
+{
+	/* set speed (default is 10Mb) */
+	switch (fep->phy_mii.speed) {
+	case SPEED_1000:
+		if (fep->rgmii_dev)
+			emac_rgmii_port_speed(fep->rgmii_dev, fep->rgmii_input,
+					      1000);
+		break;
+	case SPEED_100:
+		if (fep->rgmii_dev)
+			emac_rgmii_port_speed(fep->rgmii_dev, fep->rgmii_input,
+					      100);
+		if (fep->zmii_dev)
+			emac_zmii_port_speed(fep->zmii_dev, fep->zmii_input,
+					     100);
+		break;
+	case SPEED_10:
+	default:
+		if (fep->rgmii_dev)
+			emac_rgmii_port_speed(fep->rgmii_dev, fep->rgmii_input,
+					      10);
+		if (fep->zmii_dev)
+			emac_zmii_port_speed(fep->zmii_dev, fep->zmii_input,
+					     10);
+	}
+	return 0;
+}
+
 static int emac_adjust_to_link(struct ocp_enet_private *fep)
 {
 	emac_t *emacp = fep->emacp;
 	struct ibm_ocp_rgmii *rgmii;
 	unsigned long mode_reg;
-	int full_duplex, speed;
-
-	full_duplex = 0;
-	speed = SPEED_10;
 
 	/* set mode register 1 defaults */
 	mode_reg = EMAC_M1_DEFAULT;
 
-	/* Read link mode on PHY */
-	if (fep->phy_mii.def->ops->read_link(&fep->phy_mii) == 0) {
-		/* If an error occurred, we don't deal with it yet */
-		full_duplex = (fep->phy_mii.duplex == DUPLEX_FULL);
-		speed = fep->phy_mii.speed;
-	}
-
 	if (fep->rgmii_dev)
 		rgmii = RGMII_PRIV(fep->rgmii_dev);
 
 	/* set speed (default is 10Mb) */
-	switch (speed) {
+	switch (fep->phy_mii.speed) {
 	case SPEED_1000:
 		mode_reg |= EMAC_M1_JUMBO_ENABLE | EMAC_M1_RFS_16K;
 		if ((rgmii->mode[fep->rgmii_input] == RTBI)
@@ -1050,40 +1068,28 @@ static int emac_adjust_to_link(struct oc
 			mode_reg |= EMAC_M1_MF_1000GPCS;
 		else
 			mode_reg |= EMAC_M1_MF_1000MBPS;
-		if (fep->rgmii_dev)
-			emac_rgmii_port_speed(fep->rgmii_dev, fep->rgmii_input,
-					      1000);
 		break;
 	case SPEED_100:
 		mode_reg |= EMAC_M1_MF_100MBPS | EMAC_M1_RFS_4K;
-		if (fep->rgmii_dev)
-			emac_rgmii_port_speed(fep->rgmii_dev, fep->rgmii_input,
-					      100);
-		if (fep->zmii_dev)
-			emac_zmii_port_speed(fep->zmii_dev, fep->zmii_input,
-					     100);
 		break;
 	case SPEED_10:
 	default:
 		mode_reg = (mode_reg & ~EMAC_M1_MF_100MBPS) | EMAC_M1_RFS_4K;
-		if (fep->rgmii_dev)
-			emac_rgmii_port_speed(fep->rgmii_dev, fep->rgmii_input,
-					      10);
-		if (fep->zmii_dev)
-			emac_zmii_port_speed(fep->zmii_dev, fep->zmii_input,
-					     10);
 	}
 
-	if (full_duplex)
+	if (fep->phy_mii.duplex == DUPLEX_FULL)
 		mode_reg |= EMAC_M1_FDE | EMAC_M1_EIFC | EMAC_M1_IST;
 	else
 		mode_reg &= ~(EMAC_M1_FDE | EMAC_M1_EIFC | EMAC_M1_ILE);
 
 	LINK_DEBUG(("%s: adjust to link, speed: %d, duplex: %d, opened: %d\n",
-		    fep->ndev->name, speed, full_duplex, fep->opened));
+		    fep->ndev->name, fep->phy_mii.speed,
+		    fep->phy_mii.full_duplex, fep->opened));
 
 	printk(KERN_INFO "%s: Speed: %d, %s duplex.\n",
-	       fep->ndev->name, speed, full_duplex ? "Full" : "Half");
+	       fep->ndev->name, fep->phy_mii.speed,
+	       (fep->phy_mii.duplex == DUPLEX_FULL) ? "Full" : "Half");
+
 	if (fep->opened)
 		out_be32(&emacp->em0mr1, mode_reg);
 
@@ -1311,18 +1317,26 @@ static void emac_reset_configure(struct 
 	 * soft reset without a PHY clock present.
 	 */
 	if (fep->phy_mii.def->ops->poll_link(&fep->phy_mii)) {
+
+		/* Read link mode on PHY */
+		fep->phy_mii.def->ops->read_link(&fep->phy_mii);
+
 		/* Reset the EMAC */
 		out_be32(&emacp->em0mr0, EMAC_M0_SRST);
-		udelay(20);
+
+		/* it seems, that this is necessary for some configs
+		 * to come out of the reset
+		 */
+		emac_set_mii_devs( fep );
+
 		for (i = 0; i < 100; i++) {
 			if ((in_be32(&emacp->em0mr0) & EMAC_M0_SRST) == 0)
 				break;
 			udelay(10);
 		}
-
 		if (i >= 100) {
-			printk(KERN_ERR "%s: Cannot reset EMAC\n",
-			       fep->ndev->name);
+			printk(KERN_ERR "%s: Cannot reset EMAC (0x%08x)\n",
+			       fep->ndev->name, in_be32(&emacp->em0mr0));
 			return;
 		}
 	}
@@ -1583,14 +1597,17 @@ static struct ethtool_ops emac_ethtool_o
 static int emac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 {
 	struct ocp_enet_private *fep = dev->priv;
-	uint *data = (uint *) & rq->ifr_ifru;
+	ushort *data = (ushort *) & rq->ifr_ifru;
+	uint    tmp;
+
 
 	switch (cmd) {
 	case SIOCGMIIPHY:
 		data[0] = fep->mii_phy_addr;
 		/* Fall through */
 	case SIOCGMIIREG:
-		data[3] = emac_phy_read(dev, fep->mii_phy_addr, data[1]);
+		tmp = emac_phy_read(dev, fep->mii_phy_addr, data[1]);
+		data[3] = (ushort)(tmp & 0xffff);
 		return 0;
 	case SIOCSMIIREG:
 		if (!capable(CAP_NET_ADMIN))
@@ -1626,7 +1643,10 @@ static int emac_open(struct net_device *
 	}
 	/* Kick the chip rx & tx channels into life */
 	spin_lock_irq(&fep->lock);
-	emac_kick(fep);
+
+	/* no link, no need to kick the interface */
+	if (netif_carrier_ok(fep->ndev))
+		emac_kick(fep);
 	spin_unlock_irq(&fep->lock);
 
 	netif_start_queue(dev);