Linux Kernel Debugging

[deans]

Let me preface this with a few things about Debug Configurations & Remote Systems I've had some trouble with and/or found confusing:

- The nomenclature, especially connect vs. attach. Attach leaves the target state intact, but connect does some kind of initialization?

- Having to define a project just to attach to target is kind of strange. Especially when you just want to poke around the hardware.

- I still haven't found a way to get into the system at PBL time, before the processor core starts executing. In general how can I just do low-level h/w access/check-out? Guess I'll have to mess w/ the rcw in flash to break after PBL?

Anyway, I'm trying to use CodeWarrior (through JTAG) to step through some of the kernel initialization code. Seems like the best way to approach this is to download everything through CW/JTAG. (although loading w/ u-boot & breaking @ _start would be a lot faster - suggestions on that welcome)

Misc background:

- Running on P5020DS

- Built kernel on linux w/ SDK 1.2 (no changes)

- Running CW on Win7

So I followed the instructions "Tutorial: Debugging the Linux® Kernel." I found step b confusing:

• From the left panel, open the attach launch configuration.

I took "attach" literally at fist, which doesn't download anything. So then I went w/ download. U-boot got a significant way through loading out of flash (after reset) before CW took over -- not sure if that matters. At any rate linux took a machine check early on (in MMU init) & didn't boot.

A couple things in the instructions that I'm assuming a correct, but caught my eye:

• In the Initialize target column, check the check box for core 0. (both cores targeted & being run out of reset)
• Left "Enable Command Line Settings" unchecked (not sure if this means linux command line or if the init script is smart enough to set this it)

Something else that bothers me a little is that CW only shows core 0. Coming back after the fact, looks like core 1 is off running where u-boot left it, which seems harmless, but at some point the linux debug session needs to pick up core 1.

I also seem to often get in a state where the USB JTAG is stuck w/ errors. (possibly when connecting instead of attaching?)

Note: I can attach my linux kernel project to a target system w/ linux already running (via uBoot).

Thanks in advance for any help.

[lunminliang · Accepted solution]

- The nomenclature, especially connect vs. attach. Attach leaves the target state intact, but connect does some kind of initialization?

Yes, "Attach" doesn't disturbed the state of the running target. "Connect" runs init script per debugger Global Setting panel.

- Having to define a project just to attach to target is kind of strange. Especially when you just want to poke around the hardware.

"Attach" is to debug a target system without modifying its state at all initially, but allow use of symbolics during actual debug.Useful for debugging a system that is already up and running.

- I still haven't found a way to get into the system at PBL time, before the processor core starts executing. In general how can I just do low-level h/w access/check-out? Guess I'll have to mess w/ the rcw in flash to break after PBL?

If I understand you correctly, maybe you can use "Connect" for checking rcw. Note there is not any software or symbolics using "conenct".

There is detail descrption about the three different kindly of connection type in the document "Targeting_PA_Processors.pdf".

- Anyway, I'm trying to use CodeWarrior (through JTAG) to step through some of the kernel initialization code. Seems like the best way to approach this is to download everything through CW/JTAG. (although loading w/ u-boot & breaking @ _start would be a lot faster - suggestions on that welcome)

For stepping through kernel, both "download kernel debug scenario" or "attach kernel debug scenario" are ok. Also refer to "Targeting_PA_Processors.pdf".

- Something else that bothers me a little is that CW only shows core 0. Coming back after the fact, looks like core 1 is off running where u-boot left it, which seems harmless, but at some point the linux debug session needs to pick up core 1.

You need to use SMP not AMP for multicore project.

[deans]

Thanks for the reply.

1) Any suggestions on what to get past my problem or further diagnose what's going wrong?

AFAIK, I'm set up for SMP (both cores are checked). I followed the set-up described in the docs.

2) I don't think connect is what I want to break in at PBL time - I want to break in before any of the processors cores are out of reset. I definitely don't want to change the h/w state.

3) And OK, RTFM, I get it - that's what I did to get as far as I got! I do tend to use the html docs before pdfs - let me know if that's a bad idea. I was just voicing some frustration & confusion over the user interface (the multiple targets & connections required in remote systems, having to create projects, debug configuration nomenclature). Lots of users just want to attach to the h/w without any high-level symbolic debug.