Hi Mike,
I see the following text in https://github.com/Linaro/OpenCSD
Current support:
ETMv4 (v4.1) instruction trace - packet processing and packet decode.
Are there plans to support ETM v4.2 in the OpenCSD decoder?
Thanks,
Sebastian
Hi Chunyan.
There is plenty of documentation for DS-5, but the path from snapshot
to trace dump is not obvious so I will give you a few pointers.
1) first you need to create a DS-5 configuration that will load your snapshot.
a) On the menu choose "run->debug configurations" which will open the
debug configurations dialog.
b) Click the "new configuration button" - leftmost button above the
left pane to create a new configuration.
c) In the Name: edit box type a new name for this configuration
d) on the "connection" tab in the right hand pane navigate to
Generic->Snapshot->View Snapshot->ViewSnapshot.
e) below this browse for the snapshot.ini file you want to use in the
configuration by clicking the File... button and select a file.
See attached ds-5-debug-config.png for picture of above dialog.
f) On the "debugger" tab, select the "connect only" radio button in
the Run Control area.
Hit "Apply" and "close" and you new "Snapshot connection" should be
visible in the "debug Control" tab in DS-5. Right click, hit connect
and DS-5 should load the snapshot.
2) Creating a dump text.
a) Now select a core in the left panel to see trace for that core.
b) Hit the export trace button to open the export trace report dialog.
Look at export-trace.png
>From here just choose what you want to dump and hit OK
Regards
Mike
On 4 September 2017 at 09:29, Chunyan Zhang <zhang.chunyan(a)linaro.org> wrote:
> Hi Mike,
>
> On 16 August 2017 at 00:07, Mike Leach <mike.leach(a)linaro.org> wrote:
>> Hi Maryem,
>>
>> The output you have above is a mix of raw trace packets and the
>> decoded generic output packets.
>> i.e. I_ATOM_F3 is a raw trace packet from the ETMv4 protocol,
>> OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec ) is the generic output packet
>> from the decoder after processing a number of raw trace packets.
>> In this case the OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec ) packet
>> indicates that the decoder does not have the memory image for address
>> 0x40c4ec and therefore cannot decode correctly.
>>
>> If you are not using perf to capture trace data then I assume you are
>> using some other custom method. e.g. sysfs scripts / programs.
>> Once you have captured a buffer full of data, if you are not using a
>> debugger such as DS-5 then it will be necessary to write a custom
>
> I used sysfs to capture trace data, and have decoded them with
> 'trc_pkt_lister' which compiled from opencsd (the .ini files under
> snapshots were modified from TC2's, since I was decoding etmv3
> traces).
>
> From what you mentioned here, I guess DS-5 can decode the data further
> to make it readable in assemble language? I hope that the traces can
> look like this:
> https://github.com/Linaro/OpenCSD/blob/master/decoder/tests/snapshots/TC2/d…
>
> Could you tell me what should I do? Is there some documentation
> introducing how to operate DS-5 to get this kind of decoded data? I
> have a DStream, but haven't used it ever :)
>
> Thanks,
> Chunyan
>
>> program or script to do the following:-
>> a) using the OpenCSD library, create a decoder instance and use the
>> API to pass in the ETM settings used during the trace capture session.
>> b) further use the API to pass in any memory images of the traced code
>> / kernel memory you wish to decode.
>> c) Pass the trace data through the decoder instance and process the
>> output generic packets that represent executed instruction ranges by
>> passing them to a disassembly tool/library to create the output you
>> require.
>>
>> Best Regards
>>
>> Mike
>>
>>
>> On 15 August 2017 at 15:56, Mathieu Poirier <mathieu.poirier(a)linaro.org> wrote:
>>> Good morning Maryem,
>>>
>>> I am enlisting Mike's help on this one. When looking for support on
>>> CoreSight I suggest you CC the mailing list - there is a lot of
>>> knowledgeable people on there that can help you.
>>>
>>> Mathieu
>>>
>>>
>>> On 11 August 2017 at 08:57, Maryem Ayadi <maryem.ayady(a)gmail.com> wrote:
>>>> Hi mathieu,
>>>>
>>>> I am working with the Opencsd library under linux in order to collect and
>>>> decode the trace.
>>>> I am using the Snapshots directory and I already decoded the trace packets
>>>> from ETB_0 using ETM and captured from juno_r1_1 using the following
>>>> command: ./tests/bin/linux64/dbg/trc_pkt_lister -ss_dir
>>>> tests/snapshots/juno_r1_1/ -decode -src_name ETB_0 . This is an extract of
>>>> the generic output packets:
>>>>
>>>>
>>>> Idx:65507; ID:15; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c5dc )
>>>> Idx:65508; ID:15; [0x95 0x3b ]; I_ADDR_S_IS0 : Address, Short, IS0.;
>>>> Addr=0x000000000040C4EC ~[0xEC]
>>>> Idx:65510; ID:15; [0xfe ]; I_ATOM_F3 : Atom format 3.; NEE
>>>> Idx:65510; ID:15; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec )
>>>> Idx:65475; ID:10; OCSD_GEN_TRC_ELEM_EO_TRACE()
>>>>
>>>>
>>>> Now I want to generate trace data captured with ETM and coded in assembly
>>>> language. Is that possible without using any debugger tool such as ARM's
>>>> DS-5 debugger tool ?
>>>> It would be helpful to send me any steps I should follow.
>>>>
>>>> Best regards,
>>>> Maryem Ayadi
>>>>
>>
>>
>>
>> --
>> Mike Leach
>> Principal Engineer, ARM Ltd.
>> Blackburn Design Centre. UK
>> _______________________________________________
>> CoreSight mailing list
>> CoreSight(a)lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/coresight
--
Mike Leach
Principal Engineer, ARM Ltd.
Blackburn Design Centre. UK
Hello Mathieu,
Thank you for your help.
>If you want to experiment with a platform that works I suggest purchasing a dragonboard 410c. I test with that platform on a regular basis.
Already bought, just waiting for the delivery -should be this week :D
Regards
Marek
W dniu 2017-09-05 16:37:28 użytkownik Mathieu Poirier <mathieu.poirier(a)linaro.org> napisał:
> On 4 September 2017 at 04:35, marekzmyslowski
> <marekzmyslowski(a)poczta.onet.pl> wrote:
> > Hello Mathieu,
> >
> > Thank for the config file. It works. I was able to build the OpenCSD kernel (form the perf-opencsd-master branch) and install on the USB (I used the ArchLinuxARM-aarch64-latest.tar.gz). I also built the perf tool (make -C tools/perf). Everything is booting but the perf has some issues:
> >
> > [root@alarm home]# ./perf record -vvv -e cs_etm/(a)20070000.etr/u --per-thread uname
> > map_groups__set_modules_path_dir: cannot open /lib/modules/4.13.0-rc1-ge565ad6 dir
> > Problems setting modules path maps, continuing anyway...
> > ------------------------------------------------------------
> > perf_event_attr:
> > type 8
> > size 112
> > { sample_period, sample_freq } 1
> > sample_type IP|TID|IDENTIFIER
> > read_format ID
> > disabled 1
> > exclude_kernel 1
> > exclude_hv 1
> > enable_on_exec 1
> > sample_id_all 1
> > ------------------------------------------------------------
> > sys_perf_event_open: pid 2242 cpu -1 group_fd -1 flags 0x8 = 4
> > ------------------------------------------------------------
> > perf_event_attr:
> > type 1
> > size 112
> > config 0x9
> > { sample_period, sample_freq } 1
> > sample_type IP|TID|IDENTIFIER
> > read_format ID
> > disabled 1
> > exclude_kernel 1
> > exclude_hv 1
> > mmap 1
> > comm 1
> > enable_on_exec 1
> > task 1
> > sample_id_all 1
> > mmap2 1
> > comm_exec 1
> > ------------------------------------------------------------
> > sys_perf_event_open: pid 2242 cpu -1 group_fd -1 flags 0x8 = 5
> > mmap size 528384B
> > AUX area mmap length 4194304
> > perf event ring buffer mmapped per thread
> > failed to mmap AUX area
> > failed to mmap with 12 (Cannot allocate memory)
>
> This is a classic problem and _usually_ related to something going
> wrong when calling kernel function etm_setup_aux() - that is where I'd
> start looking. The bad news is that you will have to debug this on
> your own as this is likely to be platform specific. If you want to
> experiment with a platform that works I suggest purchasing a
> dragonboard 410c. I test with that platform on a regular basis.
>
> [1].http://elixir.free-electrons.com/linux/latest/source/drivers/hwtracing/c…
>
> >
> > I fixed the "map_groups__set_modules_path_dir: cannot open /lib/modules/4.13.0-rc1-ge565ad6 dir" issue by adding appropriate symbolic link but I still have an issue with the mmap. Any idea what can be wrong here (below limits that I have on my Juno)?
>
> Forget about that error message - that is just perf being pugnacious.
> The CoreSight infrastructure has nothing to do with modules.
>
> Mathieu
>
> >
> > [root@alarm ~]# ulimit -a
> > core file size (blocks, -c) unlimited
> > data seg size (kbytes, -d) unlimited
> > scheduling priority (-e) 0
> > file size (blocks, -f) unlimited
> > pending signals (-i) 31798
> > max locked memory (kbytes, -l) 64
> > max memory size (kbytes, -m) unlimited
> > open files (-n) 1024
> > pipe size (512 bytes, -p) 8
> > POSIX message queues (bytes, -q) 819200
> > real-time priority (-r) 0
> > stack size (kbytes, -s) 8192
> > cpu time (seconds, -t) unlimited
> > max user processes (-u) 31798
> > virtual memory (kbytes, -v) unlimited
> > file locks (-x) unlimited
> > [root@alarm ~]#
> >
> > Regards
> > Marek
> >
> > W dniu 2017-08-18 16:54:42 użytkownik Mathieu Poirier <mathieu.poirier(a)linaro.org> napisał:
> >> On 18 August 2017 at 04:22, marekzmyslowski
> >> <marekzmyslowski(a)poczta.onet.pl> wrote:
> >> > Hello Mathieu,
> >> >
> >> > I've decided that currently I don't need Android. The Linux is enough.
> >>
> >> That is probably a better place to start.
> >>
> >> > However I have another issue. I've downloaded the perf-opencsd-master branch. I run the config with the ARCH=arm64 and CROSS_COMPLIE=aarch64-linux-gnu- and added support for Versatile board. Then I compiled kernel - everything was OK. Next I built the USB using the following instruction:
> >> > https://archlinuxarm.org/platforms/armv8/arm/juno (it works fine. The linux boot on the Juno).
> >> > Next I copied the Image file and juno.dtb into the USB but it doesn't boot. It hangs here:
> >> >
> >> > initrd: address 0x0
> >> > initrd: length 0x0
> >> > PEI 1132 ms
> >> > DXE 1695 ms
> >> > BDS 368934875444 ms
> >> > BDS 368934873448 ms
> >> > BDS 1535 ms
> >> > Total Time = 368934871781 ms
> >> >
> >> > linux: address 0x80080000
> >> > linux: length 0x1150200
> >> > fdt: address 0x9FE00000
> >> > fdt: length 0x5F54
> >> >
> >> > Any idea what I'm doing wrong? Any help will be appreciated (I'm so close to have Juno + CoreSight + perf :) )
> >>
> >> I can't help you with booting the board itself. The best I can do is
> >> advise to use u-boot instead of UEFI and give you my kernel .config
> >> file (attached). For the rest there is plenty of documentation out
> >> there.
> >>
> >> >
> >> > Regards
> >> > Marek
> >> >
> >> > W dniu 2017-08-16 23:08:04 użytkownik Mathieu Poirier <mathieu.poirier(a)linaro.org> napisał:
> >> >> Hello Marek,
> >> >>
> >> >> Please CC the CoreSight mailing list when asking questions as someone
> >> >> else may also be able to answer.
> >> >>
> >> >> First and foremost I advise using the official CoreSight kernel found
> >> >> on the openCSD site [1] rather than my personal branch [2] - you
> >> >> never know what you'll get with the latter.
> >> >>
> >> >> That being said the CoreSight kernel on the openCSD site is not an
> >> >> Android kernel - it is simply a mainline kernel supplemented with
> >> >> patches that haven't made their way to mainline yet. You will have to
> >> >> either add the android patches to the CoreSight kernel or the other
> >> >> way around (CoreSight patches on android kernel).
> >> >>
> >> >> Android user space is also different and does not include the
> >> >> perf-tools. You will have to add them manually along with the
> >> >> dependencies they require. I haven't gone through that process and as
> >> >> such can't advise more on that portion.
> >> >>
> >> >> Get back to me with your questions if the above isn't sufficient.
> >> >>
> >> >> Best regards,
> >> >> Mathieu
> >> >>
> >> >> [1]. https://github.com/Linaro/OpenCSD/tree/perf-opencsd-master
> >> >> [2]. https://git.linaro.org/people/mathieu.poirier/coresight.git/
> >> >>
> >> >> On 16 August 2017 at 14:32, marekzmyslowski
> >> >> <marekzmyslowski(a)poczta.onet.pl> wrote:
> >> >> > Hello Mathieu,
> >> >> >
> >> >> > I'm sorry for bothering but I think you may be person that can help me. I'm trying to install and run Android on Juno Board r0. I tested Android 17.05 from Linaro and it works. Now I'm trying to have a perf using Coresight but I'm little confused. Do I need to build Android from Linaro and the kernel from here https://git.linaro.org/people/mathieu.poirier/coresight.git/ or here https://github.com/Linaro/OpenCSD/tree/perf-opencsd-4.12.
> >> >> > Any help with this will be appreciated :)
> >> >> >
> >> >> > Regards
> >> >> > Marek Zmysłowski
> >> >>
> >> >
> >> >
> >> >
> >>
> >
> >
> >
>
Hi,
I'm trying to work with CoreSight and perf tool on my Juno r0 box. I was able to build the OpenCSD kernel (form the perf-opencsd-master branch) and install on the USB (I used the ArchLinuxARM-aarch64-latest.tar.gz). I also built the perf tool (make -C tools/perf). Everything is booting but the perf has some issues:
[root@alarm home]# ./perf record -vvv -e cs_etm/(a)20070000.etr/u --per-thread uname
map_groups__set_modules_path_dir: cannot open /lib/modules/4.13.0-rc1-ge565ad6 dir
Problems setting modules path maps, continuing anyway...
------------------------------------------------------------
perf_event_attr:
type 8
size 112
{ sample_period, sample_freq } 1
sample_type IP|TID|IDENTIFIER
read_format ID
disabled 1
exclude_kernel 1
exclude_hv 1
enable_on_exec 1
sample_id_all 1
------------------------------------------------------------
sys_perf_event_open: pid 2242 cpu -1 group_fd -1 flags 0x8 = 4
------------------------------------------------------------
perf_event_attr:
type 1
size 112
config 0x9
{ sample_period, sample_freq } 1
sample_type IP|TID|IDENTIFIER
read_format ID
disabled 1
exclude_kernel 1
exclude_hv 1
mmap 1
comm 1
enable_on_exec 1
task 1
sample_id_all 1
mmap2 1
comm_exec 1
------------------------------------------------------------
sys_perf_event_open: pid 2242 cpu -1 group_fd -1 flags 0x8 = 5
mmap size 528384B
AUX area mmap length 4194304
perf event ring buffer mmapped per thread
failed to mmap AUX area
failed to mmap with 12 (Cannot allocate memory)
I fixed the "map_groups__set_modules_path_dir: cannot open /lib/modules/4.13.0-rc1-ge565ad6 dir" issue by adding appropriate symbolic link but I still have an issue with the mmap. Any idea what can be wrong here (below limits that I have on my Juno)?
[root@alarm ~]# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 31798
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 31798
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
[root@alarm ~]#
Regards
Marek
Hi Maryem,
On 31 August 2017 at 13:07, Maryem Ayadi <maryem.ayady(a)gmail.com> wrote:
> Hi Mike,
>
> I just build a Linux Image and I want to know if it is necessary to
> integrate the Coresight Access Library in the Kernel Space and what are the
> necessary steps to follow ? Or is there any other solutions ?
There are instructions in the readme_demos.md file regarding
requirements for using the CSAL with linux. Essentially you do not
need to integrate with the kernel, but do need to enable mmap() access
to the kernel memory by building your kernel with the configuration
set as CONFIG_DEVMEM=y
You can use the example programs to look at the coresight ROM table
(using csls) or dump trace using tracedemo. Again please read the
documentation as you will have to write a CoreSight configuration
routine for your system to use tracedemo.
Please also ensure that on your system the Coresight components are
powered up, otherwise the demo programs will hang.
> And how can we use this library in a bare-metal environment to identify and
> configure all Coresight components ?
>
For bare metal you will need to link the library to the software you
are running on your baremetal system an write routines to program and
operate the Coresight components as you require. You will need to know
the base address of the CoreSight ROM table and use the
cs_register_romtable() call to read the ROM table and register your
components with the library. See csls.c for an example of this.
Regards
Mike
> Best regards,
> Maryem
>
>
> 2017-08-11 14:11 GMT+01:00 Mike Leach <mike.leach(a)linaro.org>:
>>
>> Hi Maryem,
>>
>> CSTMC_TRACE_FIFI.bin is a buffer of coresight trace data - not a
>> program binary that will work with objdump.
>>
>> The snapshots directories are the results of trace capture runs - some
>> using the CSAL test programs. The format of the .ini files is
>> described in the decoder/docs/specs/ARM Trace and Debug Snapshot file
>> format 0v2.pdf document
>>
>> Regards
>>
>> Mike
>>
>> On 11 August 2017 at 10:18, Maryem Ayadi <maryem.ayady(a)gmail.com> wrote:
>> > Hi Mike,
>> >
>> > I got the difference between the libraries, thank you. So I'll be
>> > working
>> > with both soon.
>> > One more thing! I tried to output a disassembled sequence with objdump
>> > from
>> > the binary files within the directory snapshots ( i.e:
>> > snapshots/a57_single_step/CSTMC_TRACE_FIFO.bin) and it didn't work. The
>> > file
>> > format is not recognized. Any solution for that?
>> >
>> > Best regards,
>> > Maryem Ayadi
>> >
>> > 2017-08-10 15:13 GMT+01:00 Mike Leach <mike.leach(a)linaro.org>:
>> >>
>> >> Hi Maryem,
>> >>
>> >> CSAL is a library can be used to program up CoreSight trace components
>> >> and subsequently extract the trace data through the register
>> >> interface. This library principally manipulates the register sets of
>> >> Coresight components. This can be used in bare metal systems or on
>> >> Linux by mmaping the hardware memory locations of the components. The
>> >> library provides a few worked example programs illustrating the
>> >> programming and extraction of trace data.
>> >>
>> >> OpenCSD is a library that will process captured trace data into a
>> >> generic output format - this is usually a list of instruction address
>> >> ranges representing executed code.
>> >> OpenCSD does not have the capability to program trace hardware for
>> >> capture, nor convert the processed trace data into assembly language.
>> >> This must be done using client programs. The DS-5 dumps you refer to
>> >> were created using ARM's DS-5 debugger tool.
>> >>
>> >> The key point here is that both CSAL and OpenCSD are libraries that
>> >> are to be used as part of a larger program.
>> >>
>> >> For example in the perf-opencsd-master Linux kernel tree we provide
>> >> extensions to perf (which does not use CSAL, but uses the linux
>> >> CoreSight drivers directly) that will capture trace data, and
>> >> subsequently use the OpenCSD library to process that data. Using the
>> >> 'perf script' command, and an appropriate python script (also supplied
>> >> in the perf-opencsd-master), it is possible to process the trace data
>> >> captured by perf, through the OpenCSD library to generate traced
>> >> instruction ranges and then passthe traced instruction ranges to
>> >> objdump to output a disassembled sequence.
>> >>
>> >> Best Regards
>> >>
>> >> Mike
>> >>
>> >>
>> >>
>> >> On 10 August 2017 at 14:49, Maryem Ayadi <maryem.ayady(a)gmail.com>
>> >> wrote:
>> >> > Hi Mark,
>> >> >
>> >> > I am working with the Opencsd library under linux in order to collect
>> >> > and
>> >> > decode the trace.
>> >> > I just discovered The CoreSight Access Library (CSAL) and I want to
>> >> > know
>> >> > what's the difference between both libraries.
>> >> > Besides, is it possible to work only with the opencsd library to
>> >> > collect
>> >> > and
>> >> > decode traces on-target?
>> >> >
>> >> > I am also trying to generate trace data coded in assembly language
>> >> > like
>> >> > the
>> >> > contents of the files existing within
>> >> > decoder/tests/snapshots/juno_r1_1/ds-5-dumps in the Opencsd library.
>> >> > It
>> >> > would be helpful to send me any steps I should follow.
>> >> >
>> >> > Best regards,
>> >> > Maryem Ayadi
>> >>
>> >>
>> >>
>> >> --
>> >> Mike Leach
>> >> Principal Engineer, ARM Ltd.
>> >> Blackburn Design Centre. UK
>> >
>> >
>>
>>
>>
>> --
>> Mike Leach
>> Principal Engineer, ARM Ltd.
>> Blackburn Design Centre. UK
>
>
--
Mike Leach
Principal Engineer, ARM Ltd.
Blackburn Design Centre. UK
Hi,
Following my previous email (which you might not have received yet, because the attached snapshot was slightly over the size limit), I have written a small patch to address the issue I found with ETMv4 decoding.
For clarity, the issue I encountered was that in EtmV4ITrcPkt::updateShortAddress, when the v_addr field is computed, it uses the old value (which is supposed to be the last broadcast address, according to the documentation).
However, when an Exact Match packet is output, the specification says that the matched address is pushed at the front of the address queue.
The v_addr field looks to me like it is the top of the address queue, so should be updated in EtmV4ITrcPacket::setAddressExactMatch, which is currently not done.
The patch I wrote replicates the address queue in the EtmV4ITrcPacket class, to update the last broadcast address accordingly when reading an exact match.
There is a bit of redundancy, because it is also done in the TrcPktDecodeEtmV4I class, but it seems to fix the problem.
You will find the patch attached to this email.
Below is the output for the section that showed an incorrect output.
Idx:4248; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DC2DC ~[0xDC]
Idx:4250; ID:12; I_ATOM_F3 : Atom format 3.; EEN
Idx:4251; ID:12; I_ATOM_F2 : Atom format 2.; EE
Idx:4252; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004D004C ~[0x1004C]
Idx:4256; ID:12; I_ATOM_F1 : Atom format 1.; E
Idx:4257; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DCC6C ~[0x1CC6C]
Idx:4260; ID:12; I_ATOM_F3 : Atom format 3.; EEN
Idx:4261; ID:12; I_ATOM_F3 : Atom format 3.; NNE
Idx:4262; ID:12; I_ATOM_F3 : Atom format 3.; EEN
Idx:4263; ID:12; I_ATOM_F2 : Atom format 2.; EE
Idx:4264; ID:12; I_ADDR_MATCH : Exact Address Match., [1]
Idx:4265; ID:12; I_ATOM_F1 : Atom format 1.; E
Idx:4266; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004D00F4 ~[0xF4]
The last address is constructed from 0x004D004C, which is at the top of the address queue after the Exact Match.
Before the patch, it was constructed from 0x004DCC6C, which was at the top of the address queue *before* the Exact Match, and at index 1 after.
I hope you can add this patch to the library at some point, or a modified version of it.
Best regards,
Thierry Laviron
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi,
I think we have discovered a bug in the ETMv4 decoder, when there is an 'exact match' packet followed by an address packet that is not 64 bit long.
Here is a faulty sample:
Idx:4248; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DC2DC ~[0xDC]
Idx:4250; ID:12; I_ATOM_F3 : Atom format 3.; EEN
Idx:4251; ID:12; I_ATOM_F2 : Atom format 2.; EE
Idx:4252; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004D004C ~[0x1004C]
Idx:4256; ID:12; I_ATOM_F1 : Atom format 1.; E
Idx:4257; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DCC6C ~[0x1CC6C]
Idx:4260; ID:12; I_ATOM_F3 : Atom format 3.; EEN
Idx:4261; ID:12; I_ATOM_F3 : Atom format 3.; NNE
Idx:4262; ID:12; I_ATOM_F3 : Atom format 3.; EEN
Idx:4263; ID:12; I_ATOM_F2 : Atom format 2.; EE
Idx:4264; ID:12; I_ADDR_MATCH : Exact Address Match., [1]
Idx:4265; ID:12; I_ATOM_F1 : Atom format 1.; E
Idx:4266; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DCCF4 ~[0xF4]
We have 3 addresses output before the exact match; at that point the state of the address queue is
0: 0x004DCC6C
1: 0x004D004C
2: 0x004DC2DC
After the exact match packet, it should be
0: 0x004D004C
1: 0x004DCC6C
2: 0x004D004C
This means that the next address value should be compared to 0x004D004C
The next address packet is a short address, with one byte of data. It tells us bits[8:0] of the next address are 0x0F4
This means the next executed address is 0x004D00F4.
However the decoder is interpreting it as 0x004DCCF4, as if it did not update the queue.
Looking at the code, it appears the address queue does get properly updated on an exact match packet, however when reconstructing addresses, it uses an ocsd_etmv4_i_pkt::v_addr field; documentation says this is the "most recently broadcast address packet".
This v_addr field does not get updated on an exact match packet, but if I am reading the specifications right it should.
Am I right in assuming this is a bug?
I have attached the snapshot that produces the bug, and the executable that produced the trace so you can check the assembly code.
Best regards,
Thierry
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello Mathieu,
I've decided that currently I don't need Android. The Linux is enough.
However I have another issue. I've downloaded the perf-opencsd-master branch. I run the config with the ARCH=arm64 and CROSS_COMPLIE=aarch64-linux-gnu- and added support for Versatile board. Then I compiled kernel - everything was OK. Next I built the USB using the following instruction:
https://archlinuxarm.org/platforms/armv8/arm/juno (it works fine. The linux boot on the Juno).
Next I copied the Image file and juno.dtb into the USB but it doesn't boot. It hangs here:
initrd: address 0x0
initrd: length 0x0
PEI 1132 ms
DXE 1695 ms
BDS 368934875444 ms
BDS 368934873448 ms
BDS 1535 ms
Total Time = 368934871781 ms
linux: address 0x80080000
linux: length 0x1150200
fdt: address 0x9FE00000
fdt: length 0x5F54
Any idea what I'm doing wrong? Any help will be appreciated (I'm so close to have Juno + CoreSight + perf :) )
Regards
Marek
W dniu 2017-08-16 23:08:04 użytkownik Mathieu Poirier <mathieu.poirier(a)linaro.org> napisał:
> Hello Marek,
>
> Please CC the CoreSight mailing list when asking questions as someone
> else may also be able to answer.
>
> First and foremost I advise using the official CoreSight kernel found
> on the openCSD site [1] rather than my personal branch [2] - you
> never know what you'll get with the latter.
>
> That being said the CoreSight kernel on the openCSD site is not an
> Android kernel - it is simply a mainline kernel supplemented with
> patches that haven't made their way to mainline yet. You will have to
> either add the android patches to the CoreSight kernel or the other
> way around (CoreSight patches on android kernel).
>
> Android user space is also different and does not include the
> perf-tools. You will have to add them manually along with the
> dependencies they require. I haven't gone through that process and as
> such can't advise more on that portion.
>
> Get back to me with your questions if the above isn't sufficient.
>
> Best regards,
> Mathieu
>
> [1]. https://github.com/Linaro/OpenCSD/tree/perf-opencsd-master
> [2]. https://git.linaro.org/people/mathieu.poirier/coresight.git/
>
> On 16 August 2017 at 14:32, marekzmyslowski
> <marekzmyslowski(a)poczta.onet.pl> wrote:
> > Hello Mathieu,
> >
> > I'm sorry for bothering but I think you may be person that can help me. I'm trying to install and run Android on Juno Board r0. I tested Android 17.05 from Linaro and it works. Now I'm trying to have a perf using Coresight but I'm little confused. Do I need to build Android from Linaro and the kernel from here https://git.linaro.org/people/mathieu.poirier/coresight.git/ or here https://github.com/Linaro/OpenCSD/tree/perf-opencsd-4.12.
> > Any help with this will be appreciated :)
> >
> > Regards
> > Marek Zmysłowski
>
Hello Marek,
Please CC the CoreSight mailing list when asking questions as someone
else may also be able to answer.
First and foremost I advise using the official CoreSight kernel found
on the openCSD site [1] rather than my personal branch [2] - you
never know what you'll get with the latter.
That being said the CoreSight kernel on the openCSD site is not an
Android kernel - it is simply a mainline kernel supplemented with
patches that haven't made their way to mainline yet. You will have to
either add the android patches to the CoreSight kernel or the other
way around (CoreSight patches on android kernel).
Android user space is also different and does not include the
perf-tools. You will have to add them manually along with the
dependencies they require. I haven't gone through that process and as
such can't advise more on that portion.
Get back to me with your questions if the above isn't sufficient.
Best regards,
Mathieu
[1]. https://github.com/Linaro/OpenCSD/tree/perf-opencsd-master
[2]. https://git.linaro.org/people/mathieu.poirier/coresight.git/
On 16 August 2017 at 14:32, marekzmyslowski
<marekzmyslowski(a)poczta.onet.pl> wrote:
> Hello Mathieu,
>
> I'm sorry for bothering but I think you may be person that can help me. I'm trying to install and run Android on Juno Board r0. I tested Android 17.05 from Linaro and it works. Now I'm trying to have a perf using Coresight but I'm little confused. Do I need to build Android from Linaro and the kernel from here https://git.linaro.org/people/mathieu.poirier/coresight.git/ or here https://github.com/Linaro/OpenCSD/tree/perf-opencsd-4.12.
> Any help with this will be appreciated :)
>
> Regards
> Marek Zmysłowski
Good morning Maryem,
I am enlisting Mike's help on this one. When looking for support on
CoreSight I suggest you CC the mailing list - there is a lot of
knowledgeable people on there that can help you.
Mathieu
On 11 August 2017 at 08:57, Maryem Ayadi <maryem.ayady(a)gmail.com> wrote:
> Hi mathieu,
>
> I am working with the Opencsd library under linux in order to collect and
> decode the trace.
> I am using the Snapshots directory and I already decoded the trace packets
> from ETB_0 using ETM and captured from juno_r1_1 using the following
> command: ./tests/bin/linux64/dbg/trc_pkt_lister -ss_dir
> tests/snapshots/juno_r1_1/ -decode -src_name ETB_0 . This is an extract of
> the generic output packets:
>
>
> Idx:65507; ID:15; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c5dc )
> Idx:65508; ID:15; [0x95 0x3b ]; I_ADDR_S_IS0 : Address, Short, IS0.;
> Addr=0x000000000040C4EC ~[0xEC]
> Idx:65510; ID:15; [0xfe ]; I_ATOM_F3 : Atom format 3.; NEE
> Idx:65510; ID:15; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec )
> Idx:65475; ID:10; OCSD_GEN_TRC_ELEM_EO_TRACE()
>
>
> Now I want to generate trace data captured with ETM and coded in assembly
> language. Is that possible without using any debugger tool such as ARM's
> DS-5 debugger tool ?
> It would be helpful to send me any steps I should follow.
>
> Best regards,
> Maryem Ayadi
>
