On Tue, Jun 19, 2012 at 07:43:08AM -0500, jim norris wrote: > Hi Frank, > > > >Ok. Do you think the stepping problems I've discovered is due to that > >limitation? > > > >I'm doing the following when debugging: > > > >1) Start openocd > > > >2) Telnet to openocd and halt both cpus. It seems that I need to halt > >at least one of the cores in order to be able to establish contact > >from gdb (ie. tar rem :3333 don't work if I don't..). Is this normal? > > > >3) Start gdb (currently use the newest arm linaro version). > Here's where the problems start. When you do something via the > telnet connection, the gdb connection doesn't explicitly know. The > data structures that are used for the telnet connection and the gdb > connection are separate. In other words, what you do in the telnet > session isn't reflected within the gdb session. It is only coincidence > that things 'appear to be working'. >
Oh ok. I'm now doing the required steps as commands when launching openocd, so now there's no need for the telnet session anymore. > > > >4) Halt both cpus (again) and check via "mon targets" > > > >5) c/continue and observe that U-Boot is alive > Aha u-boot. It is probably the case where u-boot is running on a > single processor. Therefore, it may be possible to debug u-boot > via gdb. I would have to look at the gdb code within openocd to > see if it would address only the first processor in the complex. At least for this port, U-Boot only uses one core (and the MMU for the running core is on). I don't need to debug U-boot just yet. That would require a more advanced reset configuration. So we cannot debug out of reset yet.. my main goal for now is to debug Linux and kernel modules. Ok. I'll try to check whether the gdbserver part in openocd tries to access the second core. Reg. multicore: As mentioned, I'm starting the system by halting both cores, and when i resume only the first (coreid 0) is used. If I continue booting Linux, it's still only one core enabled. For instance, cat /proc/cpuinfo now only lists one CPU. > > > >6) Resume from gdb via Ctrl-C works, but I noticed now that I also get > >a STICKY error when doing so. However, the resume operation works.. so > >it seems that the transition from "halted" to "running" is correlated > >to the problem with stepping. > Typo. I meant to say "Resume from gdb via 'continue' works". Ctrl-C => halt :) > > > >7) If I now run "targets" from the telnet session, I only see one of > >the cores running. This is as intended, since I assume that most > >operation are applied to the current selected target. > And I also think u-boot should only need to run on a single processor. > In effect, u-boot is the operating system until the 'real' operating system > is loaded. > > > >Since only one of the cores are "selected" and running during the > >debugging session, I assume that the single core limitation in gdb > >wouldn't be a problem. Are my assumptions correct? > You might get lucky, if you only need to debug u-boot. However, > if you're going to debug the operating system, then you're going > to run into the limitations I stated earlier. > > Again, u-boot debugging is not required (yet). I can halt/single step/resume in U-boot, but not debug "out of reset". Our system uses a three stage boot, starting from iROM, loading first part of U-Boot from SD into iSRAM, etc... I'll dive into this later on. For now only Linux debugging is prioritized. If I start openocd with adapter_khz=10, then connect via gdb, then reset via gdb, then halt both cpus, then set breakpoint at __start_kernel, then set adapter_khz=1000, then continue... gdb breaks at kernel start, and I can step through the kernel boot! I have some issues due to gcc optimizations, but we're close. OpenOCD still complains about invalid memory reads and STICKY ERRORs, but it seems to work somehow :) Except for the stability issues, it seems the only remaining problem is getting gdb 'load' to work for larger files (such as a zImage). A few seconds after loading the .text section I loose the gdb session and OpenOCD dies. Last msg is "Warn: negative acknowledgement, but no packet pending". Any clues? Cheers, Frank ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
