On 26 July 2017 at 09:38, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote:
> Hello Mathieu, Mike
>
>
Good day,
>
> I have a few questions about perf and decoder road maps and bug fixes. Here
> is a list of issues that
>
> I have found out. I like to know if these are known problems and what is the
> process to get them resolved.
>
>
>
> 1) Snapshot mode (option –S) does not work. Ideally we need to run perf
> record with options –a and –S
>
> to trace in snapshot mode on all the cores
That shouldn't be hard to fix - I'll open a card for this.
>
>
>
> 2) Perf record with option –C also does not work. We want, in some cases,
> limit the trace to a subset of cores
I've been trying to fix this for a while but have failed completely.
To address the issue I don't see any other way than to change the perf
ABI between user and kernel space, something that has been rejected by
the community in no uncertain terms. I will sit down with Peter Z. at
Linux Plumbers in September to see how best to move forward.
This is very high on my list of priorities. It is also the first step
in supporting a multi-sink topology.
>
>
>
> 3) Time and cycle information is in the raw trace but perf decoder cannot
> decode it
That one is for Mike. It will also require modifications to the perf tools.
>
>
>
> Thanks for all your help.
Any time,
Mathieu
>
>
>
> Regards, Reza
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,
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
>
Hi Mathieu,
I'm trying to make Coresight along with perf and OpenCSD working in
some internal project of Spreadtrum recently. As the kernel we're
using in-house is v4.4.49 which doesn't support using CoreSight with
perf tools, so I got the internal kernel merged with LSK4.4 [1].
Now I can collect trace with the command
'perf record -e cs_etm/(a)10003000.etb/ --per-thread uname'
on an our *ARM64* platform, the 'perf' was compiled from perf-opencsd-4.12 [2].
But after operated in this way on our *32-bit ARM* platform, I
received the following error:
perf record -e cs_etm/(a)10003000.etb/ --per-thread uname
event syntax error: 'cs_etm/(a)10003000.etb/'
\___ parser error
As I mentioned above the perf tool was compiled from perf-opencsd-4.12
with a 32-bit arm toolchain and kernel source code was also the same.
The only possible reason I can think out is that I have to backport
some patchs for supporting using ETMv3 with perf tools?
Thanks,
Chunyan
[1] https://git.linaro.org/kernel/linux-linaro-stable.git/commit/?h=linux-linar…
[2] https://github.com/Linaro/OpenCSD/commits/perf-opencsd-4.12
