target configuration import utility can not create SMP Linux Kernel debug operation

You may want to follow the following blog by colleague Stephen Theobald: Porting Linux made easy with DS-5

The problem you're seemingly having is you've stopped the target in HYP mode (probably a bootloader) and loaded the kernel symbols. As soon as you do this, the OS Awareness is instructed to attempt to verify the OS is initialized by reading memory pointed to by the symbols themselves.

However, until a little way into the Linux boot process, the MMU is off (and it is a different MMU context than the one in HYP mode, too) and therefore the addresses are different. Accessing addresses 0xCxxxxxxx (Linux's virtual address space for the kernel, with a 3GB/1GB "vmsplit") before the kernel has configured the MMU will send your cores off "into the weeds."

The blog attempts to walk you through the process of incrementally loading symbols at a different address (where they are either physically or virtually located in HYP mode's context when loaded by the bootloader) until you reach a particular place in the kernel, then loading symbols again at the 0xCxxxxxxx address. While this is happening, OS Awareness is needfully turned off, but once that virtual address mapping is in place, it can be turned on to pick up the ability to detect an initialized OS kernel.

There is a slightly easier way to go through the process with the commands:

    interrupt

    set os enabled off

You can then load kernel and start it, and halt kernel manually once you see it is printing to the console UART or screen. This isn't as precise as using breakpoints and intimate knowledge of the kernel boot process, but it works. You can then load the symbols, enable OS awareness and continue:

    symbol-file /my/kernel/vmlinux

    set os enabled on

    continue

Things should work better from this point in. Let us know how you get on, and please read Stephen's blog, it is awesome

Ta,

Matt

You may want to follow the following blog by colleague Stephen Theobald: Porting Linux made easy with DS-5

The problem you're seemingly having is you've stopped the target in HYP mode (probably a bootloader) and loaded the kernel symbols. As soon as you do this, the OS Awareness is instructed to attempt to verify the OS is initialized by reading memory pointed to by the symbols themselves.

However, until a little way into the Linux boot process, the MMU is off (and it is a different MMU context than the one in HYP mode, too) and therefore the addresses are different. Accessing addresses 0xCxxxxxxx (Linux's virtual address space for the kernel, with a 3GB/1GB "vmsplit") before the kernel has configured the MMU will send your cores off "into the weeds."

The blog attempts to walk you through the process of incrementally loading symbols at a different address (where they are either physically or virtually located in HYP mode's context when loaded by the bootloader) until you reach a particular place in the kernel, then loading symbols again at the 0xCxxxxxxx address. While this is happening, OS Awareness is needfully turned off, but once that virtual address mapping is in place, it can be turned on to pick up the ability to detect an initialized OS kernel.

There is a slightly easier way to go through the process with the commands:

    interrupt

    set os enabled off

You can then load kernel and start it, and halt kernel manually once you see it is printing to the console UART or screen. This isn't as precise as using breakpoints and intimate knowledge of the kernel boot process, but it works. You can then load the symbols, enable OS awareness and continue:

    symbol-file /my/kernel/vmlinux

    set os enabled on

    continue

Things should work better from this point in. Let us know how you get on, and please read Stephen's blog, it is awesome

Ta,

Matt