Hi everyone,
I have a DSTREAM and want to use it for a kernel bug. I have a target board with chip Annapurna Labs alpine al-314.I created a configuration file (attached) by Debug Hardware Configuration utility. Then I used target configuration Import utility to create debug operations. But I don’t see SMP Linux Kernel debug operation after adding configuration database in the Eclipse.Please see below screenshot. Only see operation for single core. Can anyone tell me how to fix it? Thanks in advance.
Hi Tony,
Problems like this can happen when DS-5 can't read all the topology information it needs from the target. To create SMP functionality, DS-5 needs to know which cores are part of the coherent cluster and it also needs to know how the CTIs are connected to the cores. Some targets don't make this information as visible as we would like, so there can be problems reading it.
From the RVC file you attached, it looks like you might have been using the dbghwconfig utility. That's a nice utility but we have a much better method for platform bring-up now: we now ship a revised utility called Platform Configuration Editor (PCE) with DS-5. PCE includes all the functionality of dbghwconfig and much more, also with much better usability and a greater level of success on challenging targets: PCE is the way forward for platform bring-up. In a future release we'll remove dbghwconfig from DS-5, but we recommend that everybody uses PCE today.
I've run your RVC file through PCE and re-generated the platform configuration. Note that I don't have the Annapurna platform here so I've not been able to test, and I had to make a few reasonable assumptions about topology as the information wasn't in the RVC file. You will need to be on DS-5 v5.24 or later, I'm hoping that the revised platform config should give you the SMP functionality you need.
Hi Paul,
I used both your platform configuration file and my configuration file generated by PCE. Now I see the SMP operation. But I encounter below error. I am not sure if it's related to configuration file. Would you help to take a look? Thanks.
---------------------------------------------------------
connected to running target Annapurna - AL314 on USB:002273
cd "/home/tonyhe/DS-5-Workspace"
Working directory "/home/tonyhe/DS-5-Workspace"
directory "/home/tonyhe/DS-5-Workspace/AL314-kernel"
Source directories searched: /home/tonyhe/DS-5-Workspace/AL314-kernel:$cdir:$cwd:$idir
interrupt
add-symbol-file "AL314-kernel\vmlinux"
Execution stopped in HYP mode at H:0x03F9D67A
On core Cortex-A15_0 (ID 0)
H:0x03F9D67A MOV r0,r4
Target Message: Memory access caused imprecise abort.
WARNING(ROS60): Could not enable OS support as the OS does not appear to be initialized. This might be caused by a mismatch between the loaded symbols and the code on the target or because the OS is not up and running. Enabling OS support will be re-attempted when the target next stops.
wait
continue
Target has been reset
Execution stopped in SVC mode at N:0xC00158A8
N:0xC00158A8 MOV pc,lr
Target Message: Could not determine target state
core 0
Current core is Cortex-A15_0 (ID 0)
core 1
Current core is Cortex-A15_1 (ID 1)
It looks like the debugger is trying to access memory that doesn’t exist, maybe because the OS isn’t yet established. As a test, it might be worth turning off OS support in DS-5 until your OS is established.
There might also be a symbol mis-match: DS-5 will look at the loaded symbols and use those to locate memory areas on the target. If the symbols don’t match the image on the target, DS-5 could be guided to incorrect areas of memory. It’s certainly something to check out.
Overall, this doesn’t look like a problem with the config: DS-5 seems connected to the target and ready for debug. This looks more like a problem accessing memory on the target.
Regards,
Paul.
Hi tonyhe,
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:
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
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
Hi Matt,
Yes, you are right. This is the root cause. The blog solves my problem and makes me understand more about DS-5 Debugger. Thanks!
Best regards,
Tony