* gdb on a 440GP ELDK
@ 2004-10-21 9:10 Mark Powell
2004-10-21 13:30 ` Jon Masters
2004-10-21 17:52 ` Eugene Surovegin
0 siblings, 2 replies; 8+ messages in thread
From: Mark Powell @ 2004-10-21 9:10 UTC (permalink / raw)
To: linuxppc-embedded
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: gdb on a 440GP ELDK 2004-10-21 9:10 gdb on a 440GP ELDK Mark Powell @ 2004-10-21 13:30 ` Jon Masters 2004-10-21 14:43 ` Mark Powell 2004-10-21 17:52 ` Eugene Surovegin 1 sibling, 1 reply; 8+ messages in thread From: Jon Masters @ 2004-10-21 13:30 UTC (permalink / raw) To: Mark Powell; +Cc: linuxppc-embedded On Thu, 21 Oct 2004 10:10:44 +0100, Mark Powell <medp@primagraphics•com> wrote: > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb on a 440GP ELDK 2004-10-21 13:30 ` Jon Masters @ 2004-10-21 14:43 ` Mark Powell 2004-10-22 9:40 ` Mark Powell 0 siblings, 1 reply; 8+ messages in thread From: Mark Powell @ 2004-10-21 14:43 UTC (permalink / raw) To: jonathan; +Cc: linuxppc-embedded Jon Masters wrote: >On Thu, 21 Oct 2004 10:10:44 +0100, Mark Powell <medp@primagraphics•com> wrote: > > >>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 -- Mark Powell, Senior Software Engineer Curtiss-Wright Controls Embedded Computing Tel: +44 (0) 1763 852222 Email: medp@primagraphics•com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb on a 440GP ELDK 2004-10-21 14:43 ` Mark Powell @ 2004-10-22 9:40 ` Mark Powell 2004-10-22 17:20 ` Matt Porter 0 siblings, 1 reply; 8+ messages in thread From: Mark Powell @ 2004-10-22 9:40 UTC (permalink / raw) To: linuxppc-embedded Mark Powell wrote: > Jon Masters wrote: > >> On Thu, 21 Oct 2004 10:10:44 +0100, Mark Powell >> <medp@primagraphics•com> wrote: >> >>> 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. -- Mark Powell, Senior Software Engineer Curtiss-Wright Controls Embedded Computing Tel: +44 (0) 1763 852222 Email: medp@primagraphics•com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb on a 440GP ELDK 2004-10-22 9:40 ` Mark Powell @ 2004-10-22 17:20 ` Matt Porter 0 siblings, 0 replies; 8+ messages in thread From: Matt Porter @ 2004-10-22 17:20 UTC (permalink / raw) To: Mark Powell; +Cc: linuxppc-embedded On Fri, Oct 22, 2004 at 10:40:33AM +0100, Mark Powell wrote: > > Mark Powell wrote: > > > Jon Masters wrote: > > > >> On Thu, 21 Oct 2004 10:10:44 +0100, Mark Powell > >> <medp@primagraphics•com> wrote: > >> > >>> 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. 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb on a 440GP ELDK 2004-10-21 9:10 gdb on a 440GP ELDK Mark Powell 2004-10-21 13:30 ` Jon Masters @ 2004-10-21 17:52 ` Eugene Surovegin 2004-10-21 18:39 ` Matt Porter 1 sibling, 1 reply; 8+ messages in thread From: Eugene Surovegin @ 2004-10-21 17:52 UTC (permalink / raw) To: Mark Powell; +Cc: linuxppc-embedded On Thu, Oct 21, 2004 at 10:10:44AM +0100, Mark Powell wrote: > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb on a 440GP ELDK 2004-10-21 17:52 ` Eugene Surovegin @ 2004-10-21 18:39 ` Matt Porter 2004-10-22 9:09 ` [PATCH][PPC32] IBM-EMAC fixes Gerhard Jaeger 0 siblings, 1 reply; 8+ messages in thread From: Matt Porter @ 2004-10-21 18:39 UTC (permalink / raw) To: Mark Powell, linuxppc-embedded On Thu, Oct 21, 2004 at 10:52:08AM -0700, Eugene Surovegin wrote: > On Thu, Oct 21, 2004 at 10:10:44AM +0100, Mark Powell wrote: > > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH][PPC32] IBM-EMAC fixes 2004-10-21 18:39 ` Matt Porter @ 2004-10-22 9:09 ` Gerhard Jaeger 0 siblings, 0 replies; 8+ messages in thread From: Gerhard Jaeger @ 2004-10-22 9:09 UTC (permalink / raw) To: linuxppc-embedded 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. Signed-off-by: Gerhard Jaeger <gjaeger@sysgo•com> --- linux-ppc-2.6.9/drivers/net/ibm_emac/ibm_emac_core.c.orig 2004-10-18 23:53:06.000000000 +0200 +++ linux-ppc-2.6.9/drivers/net/ibm_emac/ibm_emac_core.c 2004-10-22 08:43:12.000000000 +0200 @@ -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); ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-10-22 17:20 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-10-21 9:10 gdb on a 440GP ELDK Mark Powell 2004-10-21 13:30 ` Jon Masters 2004-10-21 14:43 ` Mark Powell 2004-10-22 9:40 ` Mark Powell 2004-10-22 17:20 ` Matt Porter 2004-10-21 17:52 ` Eugene Surovegin 2004-10-21 18:39 ` Matt Porter 2004-10-22 9:09 ` [PATCH][PPC32] IBM-EMAC fixes Gerhard Jaeger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox