Debugging using T32 on a Multi cores/cpus

Contemporary processors are multi core/cpus. This has made life of a developer bit tougher. For eg, for the break point to hit, you need to set it on all the cpus, because you never know where the code is going to run. Another instance is to stop all the core at the same time.

Below is a set of scritps which helps you to make your job easier.

For eg we will consider working on a 4 core processor.

You need to create few cmm files. Contents and file names as shown below,

1) main.cmm
=========
GLOBAL &ScriptPath &vmlinuxPath

&ScriptPath="Z:\deleteme\T32"
&vmlinuxPath="Z:\kdevs\3.18\kdev\kobj"

globalon cmd i do &ScriptPath\initcore_all.cmm
globalon cmd pos do &ScriptPath\pos.cmm
globalon cmd load do &ScriptPath\load_all.cmm
globalon cmd ball do &ScriptPath\break_all.cmm

==========

2) initcore_all.cmm

============

intercom.execute localhost:15370 do &ScriptPath\initcore.cmm

intercom.execute localhost:15371 do &ScriptPath\initcore.cmm

intercom.execute localhost:15372 do &ScriptPath\initcore.cmm

intercom.execute localhost:15373 do &ScriptPath\initcore.cmm

============

3) initcore.cmm

==========

sys.m.a

snoop.pc ON

b.d

b.s die  /Onchip

b.s panic  /Onchip

===========

4) loadall.cmm

=========

intercom.execute localhost:15370 do &ScriptPath\load.cmm &vmlinuxPath

intercom.execute localhost:15371 do &ScriptPath\load.cmm &vmlinuxPath

intercom.execute localhost:15372 do &ScriptPath\load.cmm &vmlinuxPath

intercom.execute localhost:15373 do &ScriptPath\load.cmm &vmlinuxPath

==========

5) load.cmm

========

ENTRY &vmlinuxPath

d.load.elf &vmlinuxPath\vmlinux /NOCODE

========

6) pos.cmm
=======
intercom.execute localhost:15370 framepos 0 0 65 13
intercom.execute localhost:15371 framepos 75 0 65 13
intercom.execute localhost:15372 framepos 0 25 65 13
intercom.execute localhost:15373 framepos 75 25 65 13
========

7) break_all.cmm
===========
intercom.execute localhost:15370 break
intercom.execute localhost:15371 break
intercom.execute localhost:15372 break
intercom.execute localhost:15373 break

===========

Open four instances of T32. run main.cmm on T32 associated with core 0.

then type the i in the command line to run intercore_all.cmm

T32 Simulator

We use simulator to debug ramdumps

To view a memory as structure,
var.view (struct rcu_dynticks*)0xC162A228

To view core 1 register,
register /CORE 1

To view core 1 stack frame,
var.frame /core 1

Trace 32

Trace 32 is an amazing tool for run time intrusive debugging. It has a good support for Linux also. To see the register dumps, where 0xFA50_0000 is the physical register address.
d.dump 0xFA500000

The above access is through processor. For that you need to stop the processor. If you want to access the registers while processor running, you have to access through DAP(Debug Acces Port). Here is the command,
d.dump EDAP:0xFA500000

To save contents to a file,
For eg save data in RAM from 0x96000000 to 0x96004000,
data.save.binary c:\D_drive\file.bin 0x96000000--0x96004000

or to save 1MB from 0x96900000,
data.save.binary c:\D_drive\ptms\notwrapped.bin 0x96900000++0x100000

similarly, to save using EDAP,
data.save.binary c:\D_drive\ptms\notwrapped.bin EDAP:0x96900000++0x100000

You must be thinking now why am I reading through EDAP. what's the difference. Consider the following scenario.
1. memset RAM address from 0x96000000(This will create cache entries for this region)
2. Now this memory is over written by a hardware eg:dma
3. Now if you try to access the RAM through processor, there is a high probabilty that you will see the old value in RAM(the one which you write with memset) and not the updated value written by hardware(eg dma). This is because of cache. When JTAG access through processor if there is a cache hit, it give the value in the cache.

So in these scenarios we have to access through DAP.

To draw the image at frame buffer ram address 0x4f80_0000 with RGB888 format
d.IMAGE a:0x4f800000 480. 992. /RGBX888

Type sys, you will get the window for attach option. Saving page layout, Windows->Store windows to. This will store the windows open as .cmm file. Next time when you want this windows, run the saved cmm file. To add the source, View-> Symbols->Source search path->Add dir To get online help, Type the command on the command line, leave a space blank and press F1. To take Register Dumps us the following scripts,
=======================
printer.filetype ascii
printer.open dump.txt
wp.d a:0xe0100000--a:0xe010700c /WIDTH 4
printer.close
=========================

For loading vmlinux:
data.load.elf Z:\projects\mobcom_andrwks_ext8\users\arunks\common-android\kernel\hawaii\3.4.5\vmlinux /nocode /noclear

    NoClear: Existing symbols are not deleted. This option is necessary if more programs
must be loaded (Tasks, Overlays, Banking).
    NoCODE: Suppress the code download. Only loads symbolic information.

More info

For loading a binary,
data.load.binary filename A:RamStart--A:RamEnd /noclear

For typcasting any memory:
For eg task_struct,
var.view (struct task_struct*)0xc094d8f0

To view stack frame:
var.frame /core 0

To disassemble a location,
data.list

STRIPPART
===========
Sometimes T32 might complain saying cannot find the path to file, when you try to map to source code.
Lets say for example,
"Z:\projects\mobcom\users\arunks\eos\br-eos-4.4-2b\android\kernel\init\main.c cannot find"

Our source is at location Y:\br-eos-4.4-2b\android\kernel\init\main.c

So our source path is different till br-eos-4.4-2b, so we need to strip till there,
ie 6 elements. so the command is
d.load.elf Y:\br-eos-4.4-2b\vmlinux /nocode /StripPART 6 /PATH Y:\br-eos-4.4-2b

Use command  "symbol.list.source" to easily find out how many patch to strip. Before this command you have to load elf without any /Strippart argument.

Sometimes vmlinux might get compiled in different folder, another way of doing it is copy the vmlinux to the kernel source folder. Then load from there and strip using /strippart

Data.LOAD.elf Z:\autotrees\LA.HB.1.1.5_RB1.07.00.00.310.033\kernel\msm-4.4\vmlinux /stripPart "/local/mnt/workspace/autotrees/LA.HB.1.1.5_RB1.07.00.00.310.033/kernel/msm-4.4" /nocode /gnu

CO-Processor registers
=================
http://www2.lauterbach.com/pdf/debugger_arm.pdf
page 32

For all Lauterbach T32 Manual, vist here.