CoreSight July 2023

coresight@lists.linaro.org

11 participants
30 discussions

[PATCH 1/4] perf: cs-etm: Don't duplicate FIELD_GET()

by James Clark

linux/bitfield.h can be included as long as linux/kernel.h is included first, so change the order of the includes and drop the duplicate macro. Signed-off-by: James Clark <james.clark(a)arm.com> --- tools/perf/util/cs-etm.c | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index 1419b40dfbe8..9729d006550d 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -6,10 +6,11 @@ * Author: Mathieu Poirier <mathieu.poirier(a)linaro.org> */ +#include <linux/kernel.h> +#include <linux/bitfield.h> #include <linux/bitops.h> #include <linux/coresight-pmu.h> #include <linux/err.h> -#include <linux/kernel.h> #include <linux/log2.h> #include <linux/types.h> #include <linux/zalloc.h> @@ -281,17 +282,6 @@ static int cs_etm__metadata_set_trace_id(u8 trace_chan_id, u64 *cpu_metadata) return 0; } -/* - * FIELD_GET (linux/bitfield.h) not available outside kernel code, - * and the header contains too many dependencies to just copy over, - * so roll our own based on the original - */ -#define __bf_shf(x) (__builtin_ffsll(x) - 1) -#define FIELD_GET(_mask, _reg) \ - ({ \ - (typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \ - }) - /* * Get a metadata for a specific cpu from an array. * -- 2.34.1

10 months

Re: Linux coresight arm64 : Incorrect data in cstrace.bin

by James Clark

On 06/07/2023 13:47, Pandey, Radhey Shyam wrote: >> -----Original Message----- >> From: Pandey, Radhey Shyam >> Sent: Thursday, July 6, 2023 5:40 PM >> To: James Clark <james.clark(a)arm.com> >> Cc: coresight(a)lists.linaro.org; linux-arm-kernel(a)lists.infradead.org; Suzuki K >> Poulose <suzuki.poulose(a)arm.com>; mathieu.poirier(a)linaro.org; >> mike.leach(a)linaro.org; leo.yan(a)linaro.org; >> alexander.shishkin(a)linux.intel.com; Sarangi, Anirudha >> <anirudha.sarangi(a)amd.com> >> Subject: RE: Linux coresight arm64 : Incorrect data in cstrace.bin >> >>> -----Original Message----- >>> From: James Clark <james.clark(a)arm.com> >>> Sent: Wednesday, July 5, 2023 5:44 PM >>> To: Pandey, Radhey Shyam <radhey.shyam.pandey(a)amd.com> >>> Cc: coresight(a)lists.linaro.org; linux-arm-kernel(a)lists.infradead.org; >>> Suzuki K Poulose <suzuki.poulose(a)arm.com>; mathieu.poirier(a)linaro.org; >>> mike.leach(a)linaro.org; leo.yan(a)linaro.org; >>> alexander.shishkin(a)linux.intel.com; Sarangi, Anirudha >>> <anirudha.sarangi(a)amd.com> >>> Subject: Re: Linux coresight arm64 : Incorrect data in cstrace.bin >>> >>> >>> >>> On 05/07/2023 12:48, Pandey, Radhey Shyam wrote: >>>>> -----Original Message----- >>>>> From: James Clark <james.clark(a)arm.com> >>>>> Sent: Wednesday, July 5, 2023 4:29 PM >>>>> To: Pandey, Radhey Shyam <radhey.shyam.pandey(a)amd.com> >>>>> Cc: coresight(a)lists.linaro.org; >>>>> linux-arm-kernel(a)lists.infradead.org; >>>>> Suzuki K Poulose <suzuki.poulose(a)arm.com>; >>>>> mathieu.poirier(a)linaro.org; mike.leach(a)linaro.org; >>>>> leo.yan(a)linaro.org; alexander.shishkin(a)linux.intel.com >>>>> Subject: Re: Linux coresight arm64 : Incorrect data in cstrace.bin >>>>> >>>>> >>>>> >>>>> On 05/07/2023 10:56, Pandey, Radhey Shyam wrote: >>>>>>> -----Original Message----- >>>>>>> From: Suzuki K Poulose <suzuki.poulose(a)arm.com> >>>>>>> Sent: Wednesday, July 5, 2023 1:57 PM >>>>>>> To: Pandey, Radhey Shyam <radhey.shyam.pandey(a)amd.com>; >>>>>>> mathieu.poirier(a)linaro.org; mike.leach(a)linaro.org; >>>>>>> leo.yan(a)linaro.org; alexander.shishkin(a)linux.intel.com >>>>>>> Cc: coresight(a)lists.linaro.org; >>>>>>> linux-arm-kernel(a)lists.infradead.org >>>>>>> Subject: Re: Linux coresight arm64 : Incorrect data in >>>>>>> cstrace.bin >>>>>>> >>>>>>> Hi Radhe Shyam >>>>>>> >>>>>>> On 05/07/2023 05:38, Pandey, Radhey Shyam wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am using linux 6.1 kernel coresight framework to capture ETM >> trace. >>>>>>>> Enabled coresight driver and added coresight component device >>>>>>>> node in DTS. With that, we could probe all coresight components. >>>>>>>> >>>>>>>> But when we do capture using sysfs and then read the trace.bin >>>>>>>> using ptm2human we see invalid trace data. Trace content >>>>>>>> changes on each capture. Any pointers to help narrow down the >> issue? >>>>>>>> >>>>>>>> Tried: sysfs capture and perf (with OpenCSD enabled) >>>>>>>> >>>>>>>> Development board: VCK190 : >>>>>>>> https://docs.xilinx.com/r/en-US/ug1366-vck190-eval-bd >>>>>>>> https://www.xilinx.com/support/documents/architecture- >>>>>>> manuals/am011-ve >>>>>>>> rsal-acap-trm.pdf >>>>>>>> >>>>>>>> xilinx-vck190-20231:/home/petalinux# dmesg | grep -i amba >>>>>>>> [ 0.301054] Serial: AMBA PL011 UART driver >>>>>>>> [ 0.306226] amba f0c20000.funnel: Fixing up cyclic dependency >> with >>>>>>> f0d70000.etm >>>>>>>> [ 0.313624] amba f0c20000.funnel: Fixing up cyclic dependency >> with >>>>>>> f0d30000.etm >>>>>>>> [ 0.321110] amba f0c30000.etf: Fixing up cyclic dependency with >>>>>>> f0c20000.funnel >>>>>>>> [ 1.470247] Serial: AMBA driver >>>>>>>> xilinx-vck190-20231:/home/petalinux# dmesg | grep -i coresight >>>>>>>> [ 1.865006] cs_system_cfg: CoreSight Configuration manager >>> initialised >>>>>>>> [ 1.876858] coresight etm0: CPU0: etm v4.0 initialized >>>>>>>> [ 1.885666] coresight etm1: CPU1: etm v4.0 initialized >>>>>>>> [ 1.894435] coresight-cpu-debug f0d00000.debug1: Coresight >> debug- >>>>> CPU0 >>>>>>> initialized >>>>>>>> [ 1.902072] coresight-cpu-debug f0d40000.debug1: Coresight >> debug- >>>>> CPU1 >>>>>>> initialized >>>>>>>> >>>>>>>> xilinx-vck190-20231:/home/petalinux# ls >> /sys/bus/coresight/devices/ >>>>>>>> etm0 etm1 funnel0 tmc_etf0 >>>>>>>> >>>>>>>> cd /sys/bus/coresight/devices/ echo 1 > tmc_etf0/enable_sink >>>>>>>> echo 1 > etm0/enable_source echo 0 > etm0/enable_source echo 0 > >>>>>>>> tmc_etf0/enable_sink cd /root/ dd if=/dev/tmc_etf0 >>>>>>>> of=cstrace_28Jun.bin >>>>>>>> >>>>>>>> ./ptm2human/ptm2human -e -i cstrace.bin -d >>>>>>> >>>>>>> Please note that ptm2human is for PTM trace decoding and >>>>>>> ETMv4 uses a different format and thus is not compatible. >>>>>>> >>>>>>>> >>>>>>>> I also tried OpenCSD integration with PERF. >>>>>>> >>>>>>> Have you made sure the perf is "linked" to the opencsd ? >>>>>> >>>>>> Earlier I statically linked but after adding CORESIGHT=1. >>>>>> >>>>>> >>>>>> linux-xlnx$ make ARCH=arm64 NO_LIBELF=1 NO_JVMTI=1 VF=1 >>>>> CORESIGHT=1 -C >>>>>> tools/perf/ >>>>>> make: Entering directory 'linux-xlnx/tools/perf' >>>>>> BUILD: Doing 'make -j24' parallel build >>>>>> >>>>>> Makefile.config:520: *** Error: No libopencsd library found or the >>>>>> version >>>>> is not up-to-date. >>>>>> Please install recent libopencsd to build with CORESIGHT=1. Stop. >>>>>> >>>>>> >>>>>> echo $CSINCLUDES >>>>>> /scratch/development/coresight/my-opencsd/decoder/include >>>>>> radheys@xhdradheys41:/scratch/development/linux-xlnx$ ls >>>>>> /scratch/development/coresight/my-opencsd/decoder/include >>>>>> common i_dec interfaces mem_acc opencsd opencsd.h >>>>>> pkt_printers >>>>>> >>>>>> echo $CSLIBS >>>>>> /scratch/development/coresight/my-opencsd/decoder/lib/builddir >>>>>> radheys@xhdradheys41:/scratch/development/linux-xlnx$ ls >>>>> /scratch/development/coresight/my-opencsd/decoder/lib/builddir >>>>>> libopencsd.a libopencsd_c_api.so libopencsd_c_api.so.1.4.0 >>>>> libopencsd.so.1 >>>>>> libopencsd_c_api.a libopencsd_c_api.so.1 libopencsd.so >>>>> libopencsd.so.1.4.0 >>>>>> >>>>>> Anything I am missing to fix this opencsd lib not found? >>>>> >>>>> There is a minimum version of 1.1.1 but it looks like you are using >>>>> higher than that so that part should be fine. >>>>> >>>>> Personally I "make install" OpenCSD to the system path. I had a >>>>> play around with $CSLIBS it and maybe there is also some stickyness >>>>> to the feature detection so a make clean might help to make sure >>>>> the errors you are seeing are real. >>>>> >>>>> Lastly you can print the output of why the feature test compilation >>>>> failed which might help. I see some linking issues in there if I >>>>> delete my system installed version of OpenCSD, so there might be a >>>>> bug with just using CSINCLUDES and CSLIBS: >>>>> >>>>> $ cat tools/build/feature/test-libopencsd.make.output >>>>> >>>>> /usr/bin/ld: warning: libopencsd.so.1, needed by opencsd- >>>>> local/decoder/lib/builddir//libopencsd_c_api.so, not found (try >>>>> using -rpath or -rpath-link) >>>>> /usr/bin/ld: opencsd-local/decoder/lib/builddir//libopencsd_c_api.so: >>>>> undefined reference to `vtable for StmTrcPacket' >>>>> /usr/bin/ld: opencsd-local/decoder/lib/builddir//libopencsd_c_api.so: >>>>> undefined reference to `DecodeTree::getDecoderStats(unsigned char, >>>>> _ocsd_decode_stats**)' >>>>> /usr/bin/ld: opencsd-local/decoder/lib/builddir//libopencsd_c_api.so: >>>>> undefined reference to >>>>> `DecodeTree::addRawFramePrinter(RawFramePrinter**, unsigned int)' >>>>> >>>>> Can you try the make install and see if that works? If that works >>>>> but the other way doesn't I can try looking into why its not and make a >> fix. >>>> >>>> I tried make install but still it errors out. Looking at make.output >>>> I am seeing multiple undefined references. >>>> >>>> NOTE I have to still set CSINCLUDES and CSLIBS as we are >>>> cross-compiling Perf on a x86 host machine. >>> >>> This should still work if you make install them to the arch specific >>> folder for example /usr/lib/aarch64-linux-gnu/. If do 'apt install >> libopencsd-dev:arm64' >>> I would get the arm ones in there. >>> >>> Then if I cross build like this I get openCSD linked: >>> >>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C tools/perf >>> CORESIGHT=1 >>> >>> So for now you should be able to work around the issue in this way. >> >> I tried copying opencsd libraries to /usr/lib/aarch64-linux-gnu but still I see >> undefined reference. Is it because I am using cross-compiler from server >> (toolchain path set to $PATH variable)? >> >> /proj/<snip>/Vitis/2023.2/gnu/aarch64/lin/aarch64-linux/bin/aarch64-linux- >> gnu-gcc >> I assume CSLIBS and CSINCLUDES should be sufficient to cross compile perf >> with coresight support? > > FYI, I tried with static linking and could proceed to perf compilation. > Static compilation works because the link line is slightly different (it includes -lopencsd rather than just -lopencsd_c_api: ifeq ($(findstring -static,${LDFLAGS}),-static) OPENCSDLIBS += -lopencsd -lstdc++ I think that this is related to the issue and there have been some recent changes around here. So yes I'll look into the fix for the non static and $CSLIBS mode. > make LDFLAGS=-static NO_LIBELF=1 NO_JVMTI=1 VF=1 CORESIGHT=1 -C tools/perf/ > <snip> > ... libbfd-liberty-z: [ OFF ] > ... libopencsd: [ on ] > ... libunwind-x86: [ OFF ] > > But it ended with compilation failure. Seems like OpenCSD version mismatch. > I will try to downgrade opencsd library and see if it fixes. > > util/cs-etm-decoder/cs-etm-decoder.c: In function 'cs_etm_decoder__gen_trace_elem_printer': > util/cs-etm-decoder/cs-etm-decoder.c:567:9: error: enumeration value > 'OCSD_GEN_TRC_ELEM_INSTRUMENTATION' not handled in switch [-Werror=switch-enum] > 567 | switch (elem->elem_type) { > This should be fixed here [1]. Are you building the latest version of Perf? Downgrading OpenCSD would work to fix this, but so would building the latest version of Perf. It's also possible that you are pointing to an old OpenCSD header but new libraries. The OpenCSD version number is pulled out of /usr/include/opencsd/ocsd_if_version.h so it's possible to get out of sync with the .so file. >> >>> >>>> >>>> cat tools/build/feature/test-libopencsd.make.output <snip library >>>> paths> >>>> >>>> aarch64-xilinx-linux-ld.real: warning: libopencsd.so.1, needed by >>>> libopencsd_c_api.so, not found (try using -rpath or -rpath-link) >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `vtable for StmTrcPacket' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `DecodeTree::getDecoderStats(unsigned char, _ocsd_decode_stats**)' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `DecodeTree::addRawFramePrinter(RawFramePrinter**, unsigned int)' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `DecodeTree::logMappedRanges()' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `OcsdLibDcdRegister::deregisterAllDecoders()' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `PtmTrcPacket::toString(std::__cxx11::basic_string<char, >>> std::char_traits<char>, std::allocator<char> >&) const' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `DecodeTree::s_error_logger' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `DecodeTree::addBinFileRegionMemAcc(_ocsd_file_mem_region const*, >> int, >>> _ocsd_mem_space_acc_t, std::__cxx11::basic_string<char, >>> std::char_traits<char>, std::allocator<char> > const&)' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `EtmV4ITrcPacket::~EtmV4ITrcPacket()' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `OcsdLibDcdRegister::getDecoderRegister()' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `typeinfo for TraceComponent' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `EtmV3TrcPacket::~EtmV3TrcPacket()' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `OcsdTraceElement::toString(std::__cxx11::basic_string<char, >>> std::char_traits<char>, std::allocator<char> >&) const' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `DecodeTree::addGenElemPrinter(TrcGenericElementPrinter**)' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `DecodeTree::DestroyDecodeTree(DecodeTree*)' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `ocsdError::getErrorString[abi:cxx11](ocsdError const&)' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `DecodeTree::setGenTraceElemOutI(ITrcGenElemIn*)' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `ocsdError::ocsdError(ocsdError const*)' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `ocsdError::ocsdError(_ocsd_err_severity_t, _ocsd_err_t, unsigned int, >>> unsigned char, std::__cxx11::basic_string<char, >>> std::char_traits<char>, std::allocator<char> > const&)' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `EtmV4ITrcPacket::toString(std::__cxx11::basic_string<char, >>> std::char_traits<char>, std::allocator<char> >&) const' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `DecodeTree::createDecoder(std::__cxx11::basic_string<char, >>> std::char_traits<char>, std::allocator<char> > const&, int, CSConfig const*)' >>>> aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined >>>> reference to >>> `StmTrcPacket::StmTrcPacket()' >>>> >>> >>> Yes this looks like what I see as well. There is probably some issue >>> with CSLIBS not being propagated to all parts of the build. I would >>> recommend using the system library path for now and I will look into a fix >> next week. >>> Unless you are happy to look into it and send a fix that would be great too. >>> >>> James >>> >>>> Thanks, >>>> Radhey >>>> >>>>> >>>>> Thanks >>>>> James >>>>

10 months

[PATCH] perf build: Fix library not found error when using CSLIBS

by James Clark

-L only specifies the search path for libraries directly provided in the link line with -l. Because -lopencsd isn't specified, it's only linked because it's a dependency of -lopencsd_c_api. Dependencies like this are resolved using the default system search paths or -rpath-link=... rather than -L. This means that compilation only works if OpenCSD is installed to the system rather than provided with the CSLIBS (-L) option. This could be fixed by adding -Wl,-rpath-link=$(CSLIBS) but that is less conventional than just adding -lopencsd to the link line so that it uses -L. -lopencsd seems to have been removed in commit ed17b1914978 ("perf tools: Drop requirement for libstdc++.so for libopencsd check") because it was thought that there was a chance compilation would work even if it didn't exist, but I think that only applies to libstdc++ so there is no harm to add it back. libopencsd.so and libopencsd_c_api.so would always exist together. Testing ======= The following scenarios now all work: * Cross build with OpenCSD installed * Cross build using CSLIBS=... * Native build with OpenCSD installed * Native build using CSLIBS=... * Static cross build with OpenCSD installed * Static cross build with CSLIBS=... Reported-by: Radhey Shyam Pandey <radhey.shyam.pandey(a)amd.com> Closes: https://lore.kernel.org/linux-arm-kernel/56905d7a-a91e-883a-b707-9d5f686ba5… Link: https://lore.kernel.org/all/36cc4dc6-bf4b-1093-1c0a-876e368af183@kleine-koe… Fixes: ed17b1914978 ("perf tools: Drop requirement for libstdc++.so for libopencsd check") Signed-off-by: James Clark <james.clark(a)arm.com> --- tools/perf/Makefile.config | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index 0609c19caabd..c5db0de49868 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -155,9 +155,9 @@ FEATURE_CHECK_LDFLAGS-libcrypto = -lcrypto ifdef CSINCLUDES LIBOPENCSD_CFLAGS := -I$(CSINCLUDES) endif -OPENCSDLIBS := -lopencsd_c_api +OPENCSDLIBS := -lopencsd_c_api -lopencsd ifeq ($(findstring -static,${LDFLAGS}),-static) - OPENCSDLIBS += -lopencsd -lstdc++ + OPENCSDLIBS += -lstdc++ endif ifdef CSLIBS LIBOPENCSD_LDFLAGS := -L$(CSLIBS) -- 2.34.1

10 months

Re: Linux coresight arm64 : Incorrect data in cstrace.bin

by James Clark

On 05/07/2023 12:48, Pandey, Radhey Shyam wrote: >> -----Original Message----- >> From: James Clark <james.clark(a)arm.com> >> Sent: Wednesday, July 5, 2023 4:29 PM >> To: Pandey, Radhey Shyam <radhey.shyam.pandey(a)amd.com> >> Cc: coresight(a)lists.linaro.org; linux-arm-kernel(a)lists.infradead.org; Suzuki K >> Poulose <suzuki.poulose(a)arm.com>; mathieu.poirier(a)linaro.org; >> mike.leach(a)linaro.org; leo.yan(a)linaro.org; >> alexander.shishkin(a)linux.intel.com >> Subject: Re: Linux coresight arm64 : Incorrect data in cstrace.bin >> >> >> >> On 05/07/2023 10:56, Pandey, Radhey Shyam wrote: >>>> -----Original Message----- >>>> From: Suzuki K Poulose <suzuki.poulose(a)arm.com> >>>> Sent: Wednesday, July 5, 2023 1:57 PM >>>> To: Pandey, Radhey Shyam <radhey.shyam.pandey(a)amd.com>; >>>> mathieu.poirier(a)linaro.org; mike.leach(a)linaro.org; >>>> leo.yan(a)linaro.org; alexander.shishkin(a)linux.intel.com >>>> Cc: coresight(a)lists.linaro.org; linux-arm-kernel(a)lists.infradead.org >>>> Subject: Re: Linux coresight arm64 : Incorrect data in cstrace.bin >>>> >>>> Hi Radhe Shyam >>>> >>>> On 05/07/2023 05:38, Pandey, Radhey Shyam wrote: >>>>> Hi, >>>>> >>>>> I am using linux 6.1 kernel coresight framework to capture ETM trace. >>>>> Enabled coresight driver and added coresight component device node >>>>> in DTS. With that, we could probe all coresight components. >>>>> >>>>> But when we do capture using sysfs and then read the trace.bin using >>>>> ptm2human we see invalid trace data. Trace content changes on each >>>>> capture. Any pointers to help narrow down the issue? >>>>> >>>>> Tried: sysfs capture and perf (with OpenCSD enabled) >>>>> >>>>> Development board: VCK190 : >>>>> https://docs.xilinx.com/r/en-US/ug1366-vck190-eval-bd >>>>> https://www.xilinx.com/support/documents/architecture- >>>> manuals/am011-ve >>>>> rsal-acap-trm.pdf >>>>> >>>>> xilinx-vck190-20231:/home/petalinux# dmesg | grep -i amba >>>>> [ 0.301054] Serial: AMBA PL011 UART driver >>>>> [ 0.306226] amba f0c20000.funnel: Fixing up cyclic dependency with >>>> f0d70000.etm >>>>> [ 0.313624] amba f0c20000.funnel: Fixing up cyclic dependency with >>>> f0d30000.etm >>>>> [ 0.321110] amba f0c30000.etf: Fixing up cyclic dependency with >>>> f0c20000.funnel >>>>> [ 1.470247] Serial: AMBA driver >>>>> xilinx-vck190-20231:/home/petalinux# dmesg | grep -i coresight >>>>> [ 1.865006] cs_system_cfg: CoreSight Configuration manager initialised >>>>> [ 1.876858] coresight etm0: CPU0: etm v4.0 initialized >>>>> [ 1.885666] coresight etm1: CPU1: etm v4.0 initialized >>>>> [ 1.894435] coresight-cpu-debug f0d00000.debug1: Coresight debug- >> CPU0 >>>> initialized >>>>> [ 1.902072] coresight-cpu-debug f0d40000.debug1: Coresight debug- >> CPU1 >>>> initialized >>>>> >>>>> xilinx-vck190-20231:/home/petalinux# ls /sys/bus/coresight/devices/ >>>>> etm0 etm1 funnel0 tmc_etf0 >>>>> >>>>> cd /sys/bus/coresight/devices/ >>>>> echo 1 > tmc_etf0/enable_sink >>>>> echo 1 > etm0/enable_source >>>>> echo 0 > etm0/enable_source >>>>> echo 0 > tmc_etf0/enable_sink >>>>> cd /root/ dd if=/dev/tmc_etf0 of=cstrace_28Jun.bin >>>>> >>>>> ./ptm2human/ptm2human -e -i cstrace.bin -d >>>> >>>> Please note that ptm2human is for PTM trace decoding and >>>> ETMv4 uses a different format and thus is not compatible. >>>> >>>>> >>>>> I also tried OpenCSD integration with PERF. >>>> >>>> Have you made sure the perf is "linked" to the opencsd ? >>> >>> Earlier I statically linked but after adding CORESIGHT=1. >>> >>> >>> linux-xlnx$ make ARCH=arm64 NO_LIBELF=1 NO_JVMTI=1 VF=1 >> CORESIGHT=1 -C >>> tools/perf/ >>> make: Entering directory 'linux-xlnx/tools/perf' >>> BUILD: Doing 'make -j24' parallel build >>> >>> Makefile.config:520: *** Error: No libopencsd library found or the version >> is not up-to-date. >>> Please install recent libopencsd to build with CORESIGHT=1. Stop. >>> >>> >>> echo $CSINCLUDES >>> /scratch/development/coresight/my-opencsd/decoder/include >>> radheys@xhdradheys41:/scratch/development/linux-xlnx$ ls >>> /scratch/development/coresight/my-opencsd/decoder/include >>> common i_dec interfaces mem_acc opencsd opencsd.h pkt_printers >>> >>> echo $CSLIBS >>> /scratch/development/coresight/my-opencsd/decoder/lib/builddir >>> radheys@xhdradheys41:/scratch/development/linux-xlnx$ ls >> /scratch/development/coresight/my-opencsd/decoder/lib/builddir >>> libopencsd.a libopencsd_c_api.so libopencsd_c_api.so.1.4.0 >> libopencsd.so.1 >>> libopencsd_c_api.a libopencsd_c_api.so.1 libopencsd.so >> libopencsd.so.1.4.0 >>> >>> Anything I am missing to fix this opencsd lib not found? >> >> There is a minimum version of 1.1.1 but it looks like you are using higher >> than that so that part should be fine. >> >> Personally I "make install" OpenCSD to the system path. I had a play around >> with $CSLIBS it and maybe there is also some stickyness to the feature >> detection so a make clean might help to make sure the errors you are seeing >> are real. >> >> Lastly you can print the output of why the feature test compilation failed >> which might help. I see some linking issues in there if I delete my system >> installed version of OpenCSD, so there might be a bug with just using >> CSINCLUDES and CSLIBS: >> >> $ cat tools/build/feature/test-libopencsd.make.output >> >> /usr/bin/ld: warning: libopencsd.so.1, needed by opencsd- >> local/decoder/lib/builddir//libopencsd_c_api.so, not found (try using -rpath >> or -rpath-link) >> /usr/bin/ld: opencsd-local/decoder/lib/builddir//libopencsd_c_api.so: >> undefined reference to `vtable for StmTrcPacket' >> /usr/bin/ld: opencsd-local/decoder/lib/builddir//libopencsd_c_api.so: >> undefined reference to `DecodeTree::getDecoderStats(unsigned char, >> _ocsd_decode_stats**)' >> /usr/bin/ld: opencsd-local/decoder/lib/builddir//libopencsd_c_api.so: >> undefined reference to >> `DecodeTree::addRawFramePrinter(RawFramePrinter**, unsigned int)' >> >> Can you try the make install and see if that works? If that works but the other >> way doesn't I can try looking into why its not and make a fix. > > I tried make install but still it errors out. Looking at make.output > I am seeing multiple undefined references. > > NOTE I have to still set CSINCLUDES and CSLIBS as we are cross-compiling > Perf on a x86 host machine. This should still work if you make install them to the arch specific folder for example /usr/lib/aarch64-linux-gnu/. If do 'apt install libopencsd-dev:arm64' I would get the arm ones in there. Then if I cross build like this I get openCSD linked: make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C tools/perf CORESIGHT=1 So for now you should be able to work around the issue in this way. > > cat tools/build/feature/test-libopencsd.make.output <snip library paths> > > aarch64-xilinx-linux-ld.real: warning: libopencsd.so.1, needed by libopencsd_c_api.so, not found (try using -rpath or -rpath-link) > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `vtable for StmTrcPacket' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `DecodeTree::getDecoderStats(unsigned char, _ocsd_decode_stats**)' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `DecodeTree::addRawFramePrinter(RawFramePrinter**, unsigned int)' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `DecodeTree::logMappedRanges()' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `OcsdLibDcdRegister::deregisterAllDecoders()' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `PtmTrcPacket::toString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) const' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `DecodeTree::s_error_logger' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `DecodeTree::addBinFileRegionMemAcc(_ocsd_file_mem_region const*, int, _ocsd_mem_space_acc_t, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `EtmV4ITrcPacket::~EtmV4ITrcPacket()' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `OcsdLibDcdRegister::getDecoderRegister()' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `typeinfo for TraceComponent' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `EtmV3TrcPacket::~EtmV3TrcPacket()' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `OcsdTraceElement::toString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) const' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `DecodeTree::addGenElemPrinter(TrcGenericElementPrinter**)' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `DecodeTree::DestroyDecodeTree(DecodeTree*)' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `ocsdError::getErrorString[abi:cxx11](ocsdError const&)' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `DecodeTree::setGenTraceElemOutI(ITrcGenElemIn*)' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `ocsdError::ocsdError(ocsdError const*)' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `ocsdError::ocsdError(_ocsd_err_severity_t, _ocsd_err_t, unsigned int, unsigned char, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `EtmV4ITrcPacket::toString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) const' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `DecodeTree::createDecoder(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, CSConfig const*)' > aarch64-xilinx-linux-ld.real: libopencsd_c_api.so: undefined reference to `StmTrcPacket::StmTrcPacket()' > Yes this looks like what I see as well. There is probably some issue with CSLIBS not being propagated to all parts of the build. I would recommend using the system library path for now and I will look into a fix next week. Unless you are happy to look into it and send a fix that would be great too. James > Thanks, > Radhey > >> >> Thanks >> James >

10 months, 1 week

Re: Linux coresight arm64 : Incorrect data in cstrace.bin

by James Clark

On 05/07/2023 10:56, Pandey, Radhey Shyam wrote: >> -----Original Message----- >> From: Suzuki K Poulose <suzuki.poulose(a)arm.com> >> Sent: Wednesday, July 5, 2023 1:57 PM >> To: Pandey, Radhey Shyam <radhey.shyam.pandey(a)amd.com>; >> mathieu.poirier(a)linaro.org; mike.leach(a)linaro.org; leo.yan(a)linaro.org; >> alexander.shishkin(a)linux.intel.com >> Cc: coresight(a)lists.linaro.org; linux-arm-kernel(a)lists.infradead.org >> Subject: Re: Linux coresight arm64 : Incorrect data in cstrace.bin >> >> Hi Radhe Shyam >> >> On 05/07/2023 05:38, Pandey, Radhey Shyam wrote: >>> Hi, >>> >>> I am using linux 6.1 kernel coresight framework to capture ETM trace. >>> Enabled coresight driver and added coresight component device node in >>> DTS. With that, we could probe all coresight components. >>> >>> But when we do capture using sysfs and then read the trace.bin using >>> ptm2human we see invalid trace data. Trace content changes on each >>> capture. Any pointers to help narrow down the issue? >>> >>> Tried: sysfs capture and perf (with OpenCSD enabled) >>> >>> Development board: VCK190 : >>> https://docs.xilinx.com/r/en-US/ug1366-vck190-eval-bd >>> https://www.xilinx.com/support/documents/architecture- >> manuals/am011-ve >>> rsal-acap-trm.pdf >>> >>> xilinx-vck190-20231:/home/petalinux# dmesg | grep -i amba >>> [ 0.301054] Serial: AMBA PL011 UART driver >>> [ 0.306226] amba f0c20000.funnel: Fixing up cyclic dependency with >> f0d70000.etm >>> [ 0.313624] amba f0c20000.funnel: Fixing up cyclic dependency with >> f0d30000.etm >>> [ 0.321110] amba f0c30000.etf: Fixing up cyclic dependency with >> f0c20000.funnel >>> [ 1.470247] Serial: AMBA driver >>> xilinx-vck190-20231:/home/petalinux# dmesg | grep -i coresight >>> [ 1.865006] cs_system_cfg: CoreSight Configuration manager initialised >>> [ 1.876858] coresight etm0: CPU0: etm v4.0 initialized >>> [ 1.885666] coresight etm1: CPU1: etm v4.0 initialized >>> [ 1.894435] coresight-cpu-debug f0d00000.debug1: Coresight debug-CPU0 >> initialized >>> [ 1.902072] coresight-cpu-debug f0d40000.debug1: Coresight debug-CPU1 >> initialized >>> >>> xilinx-vck190-20231:/home/petalinux# ls /sys/bus/coresight/devices/ >>> etm0 etm1 funnel0 tmc_etf0 >>> >>> cd /sys/bus/coresight/devices/ >>> echo 1 > tmc_etf0/enable_sink >>> echo 1 > etm0/enable_source >>> echo 0 > etm0/enable_source >>> echo 0 > tmc_etf0/enable_sink >>> cd /root/ dd if=/dev/tmc_etf0 of=cstrace_28Jun.bin >>> >>> ./ptm2human/ptm2human -e -i cstrace.bin -d >> >> Please note that ptm2human is for PTM trace decoding and >> ETMv4 uses a different format and thus is not compatible. >> >>> >>> I also tried OpenCSD integration with PERF. >> >> Have you made sure the perf is "linked" to the opencsd ? > > Earlier I statically linked but after adding CORESIGHT=1. > > > linux-xlnx$ make ARCH=arm64 NO_LIBELF=1 NO_JVMTI=1 VF=1 CORESIGHT=1 -C tools/perf/ > make: Entering directory 'linux-xlnx/tools/perf' > BUILD: Doing 'make -j24' parallel build > > Makefile.config:520: *** Error: No libopencsd library found or the version is not up-to-date. > Please install recent libopencsd to build with CORESIGHT=1. Stop. > > > echo $CSINCLUDES > /scratch/development/coresight/my-opencsd/decoder/include > radheys@xhdradheys41:/scratch/development/linux-xlnx$ ls /scratch/development/coresight/my-opencsd/decoder/include > common i_dec interfaces mem_acc opencsd opencsd.h pkt_printers > > echo $CSLIBS > /scratch/development/coresight/my-opencsd/decoder/lib/builddir > radheys@xhdradheys41:/scratch/development/linux-xlnx$ ls /scratch/development/coresight/my-opencsd/decoder/lib/builddir > libopencsd.a libopencsd_c_api.so libopencsd_c_api.so.1.4.0 libopencsd.so.1 > libopencsd_c_api.a libopencsd_c_api.so.1 libopencsd.so libopencsd.so.1.4.0 > > Anything I am missing to fix this opencsd lib not found? There is a minimum version of 1.1.1 but it looks like you are using higher than that so that part should be fine. Personally I "make install" OpenCSD to the system path. I had a play around with $CSLIBS it and maybe there is also some stickyness to the feature detection so a make clean might help to make sure the errors you are seeing are real. Lastly you can print the output of why the feature test compilation failed which might help. I see some linking issues in there if I delete my system installed version of OpenCSD, so there might be a bug with just using CSINCLUDES and CSLIBS: $ cat tools/build/feature/test-libopencsd.make.output /usr/bin/ld: warning: libopencsd.so.1, needed by opencsd-local/decoder/lib/builddir//libopencsd_c_api.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: opencsd-local/decoder/lib/builddir//libopencsd_c_api.so: undefined reference to `vtable for StmTrcPacket' /usr/bin/ld: opencsd-local/decoder/lib/builddir//libopencsd_c_api.so: undefined reference to `DecodeTree::getDecoderStats(unsigned char, _ocsd_decode_stats**)' /usr/bin/ld: opencsd-local/decoder/lib/builddir//libopencsd_c_api.so: undefined reference to `DecodeTree::addRawFramePrinter(RawFramePrinter**, unsigned int)' Can you try the make install and see if that works? If that works but the other way doesn't I can try looking into why its not and make a fix. Thanks James

10 months, 1 week

Re: Linux coresight arm64 : Incorrect data in cstrace.bin

by Suzuki K Poulose

On 05/07/2023 10:56, Pandey, Radhey Shyam wrote: >> -----Original Message----- >> From: Suzuki K Poulose <suzuki.poulose(a)arm.com> >> Sent: Wednesday, July 5, 2023 1:57 PM >> To: Pandey, Radhey Shyam <radhey.shyam.pandey(a)amd.com>; >> mathieu.poirier(a)linaro.org; mike.leach(a)linaro.org; leo.yan(a)linaro.org; >> alexander.shishkin(a)linux.intel.com >> Cc: coresight(a)lists.linaro.org; linux-arm-kernel(a)lists.infradead.org >> Subject: Re: Linux coresight arm64 : Incorrect data in cstrace.bin >> >> Hi Radhe Shyam >> >> On 05/07/2023 05:38, Pandey, Radhey Shyam wrote: >>> Hi, >>> >>> I am using linux 6.1 kernel coresight framework to capture ETM trace. >>> Enabled coresight driver and added coresight component device node in >>> DTS. With that, we could probe all coresight components. >>> >>> But when we do capture using sysfs and then read the trace.bin using >>> ptm2human we see invalid trace data. Trace content changes on each >>> capture. Any pointers to help narrow down the issue? >>> >>> Tried: sysfs capture and perf (with OpenCSD enabled) >>> >>> Development board: VCK190 : >>> https://docs.xilinx.com/r/en-US/ug1366-vck190-eval-bd >>> https://www.xilinx.com/support/documents/architecture- >> manuals/am011-ve >>> rsal-acap-trm.pdf >>> >>> xilinx-vck190-20231:/home/petalinux# dmesg | grep -i amba >>> [ 0.301054] Serial: AMBA PL011 UART driver >>> [ 0.306226] amba f0c20000.funnel: Fixing up cyclic dependency with >> f0d70000.etm >>> [ 0.313624] amba f0c20000.funnel: Fixing up cyclic dependency with >> f0d30000.etm >>> [ 0.321110] amba f0c30000.etf: Fixing up cyclic dependency with >> f0c20000.funnel >>> [ 1.470247] Serial: AMBA driver >>> xilinx-vck190-20231:/home/petalinux# dmesg | grep -i coresight >>> [ 1.865006] cs_system_cfg: CoreSight Configuration manager initialised >>> [ 1.876858] coresight etm0: CPU0: etm v4.0 initialized >>> [ 1.885666] coresight etm1: CPU1: etm v4.0 initialized >>> [ 1.894435] coresight-cpu-debug f0d00000.debug1: Coresight debug-CPU0 >> initialized >>> [ 1.902072] coresight-cpu-debug f0d40000.debug1: Coresight debug-CPU1 >> initialized >>> >>> xilinx-vck190-20231:/home/petalinux# ls /sys/bus/coresight/devices/ >>> etm0 etm1 funnel0 tmc_etf0 >>> >>> cd /sys/bus/coresight/devices/ >>> echo 1 > tmc_etf0/enable_sink >>> echo 1 > etm0/enable_source >>> echo 0 > etm0/enable_source >>> echo 0 > tmc_etf0/enable_sink >>> cd /root/ dd if=/dev/tmc_etf0 of=cstrace_28Jun.bin >>> >>> ./ptm2human/ptm2human -e -i cstrace.bin -d >> >> Please note that ptm2human is for PTM trace decoding and >> ETMv4 uses a different format and thus is not compatible. >> >>> >>> I also tried OpenCSD integration with PERF. >> >> Have you made sure the perf is "linked" to the opencsd ? > > Earlier I statically linked but after adding CORESIGHT=1. > > > linux-xlnx$ make ARCH=arm64 NO_LIBELF=1 NO_JVMTI=1 VF=1 CORESIGHT=1 -C tools/perf/ > make: Entering directory 'linux-xlnx/tools/perf' > BUILD: Doing 'make -j24' parallel build > > Makefile.config:520: *** Error: No libopencsd library found or the version is not up-to-date. > Please install recent libopencsd to build with CORESIGHT=1. Stop. > > > echo $CSINCLUDES > /scratch/development/coresight/my-opencsd/decoder/include > radheys@xhdradheys41:/scratch/development/linux-xlnx$ ls /scratch/development/coresight/my-opencsd/decoder/include > common i_dec interfaces mem_acc opencsd opencsd.h pkt_printers > > echo $CSLIBS > /scratch/development/coresight/my-opencsd/decoder/lib/builddir > radheys@xhdradheys41:/scratch/development/linux-xlnx$ ls /scratch/development/coresight/my-opencsd/decoder/lib/builddir > libopencsd.a libopencsd_c_api.so libopencsd_c_api.so.1.4.0 libopencsd.so.1 > libopencsd_c_api.a libopencsd_c_api.so.1 libopencsd.so libopencsd.so.1.4.0 > > Anything I am missing to fix this opencsd lib not found? Have you checked the libopencsd version ? It looks it must be able to pick up the path for lib/headers. Suzuki

10 months, 1 week

Re: Linux coresight arm64 : Incorrect data in cstrace.bin

by Suzuki K Poulose

Hi Radhe Shyam On 05/07/2023 05:38, Pandey, Radhey Shyam wrote: > Hi, > > I am using linux 6.1 kernel coresight framework to capture ETM trace. > Enabled coresight driver and added coresight component device node > in DTS. With that, we could probe all coresight components. > > But when we do capture using sysfs and then read the trace.bin using > ptm2human we see invalid trace data. Trace content changes on each > capture. Any pointers to help narrow down the issue? > > Tried: sysfs capture and perf (with OpenCSD enabled) > > Development board: VCK190 : > https://docs.xilinx.com/r/en-US/ug1366-vck190-eval-bd https://www.xilinx.com/support/documents/architecture-manuals/am011-versal-… > > xilinx-vck190-20231:/home/petalinux# dmesg | grep -i amba > [ 0.301054] Serial: AMBA PL011 UART driver > [ 0.306226] amba f0c20000.funnel: Fixing up cyclic dependency with f0d70000.etm > [ 0.313624] amba f0c20000.funnel: Fixing up cyclic dependency with f0d30000.etm > [ 0.321110] amba f0c30000.etf: Fixing up cyclic dependency with f0c20000.funnel > [ 1.470247] Serial: AMBA driver > xilinx-vck190-20231:/home/petalinux# dmesg | grep -i coresight > [ 1.865006] cs_system_cfg: CoreSight Configuration manager initialised > [ 1.876858] coresight etm0: CPU0: etm v4.0 initialized > [ 1.885666] coresight etm1: CPU1: etm v4.0 initialized > [ 1.894435] coresight-cpu-debug f0d00000.debug1: Coresight debug-CPU0 initialized > [ 1.902072] coresight-cpu-debug f0d40000.debug1: Coresight debug-CPU1 initialized > > xilinx-vck190-20231:/home/petalinux# ls /sys/bus/coresight/devices/ > etm0 etm1 funnel0 tmc_etf0 > > cd /sys/bus/coresight/devices/ > echo 1 > tmc_etf0/enable_sink > echo 1 > etm0/enable_source > echo 0 > etm0/enable_source > echo 0 > tmc_etf0/enable_sink > cd /root/ dd if=/dev/tmc_etf0 of=cstrace_28Jun.bin > > ./ptm2human/ptm2human -e -i cstrace.bin -d Please note that ptm2human is for PTM trace decoding and ETMv4 uses a different format and thus is not compatible. > > I also tried OpenCSD integration with PERF. Have you made sure the perf is "linked" to the opencsd ? $ ldd $(which perf) | grep opencsd With opencsd in, perf report -D should be able to decode the trace packets. Suzuki > > 0x1e0(a)perf.data [0x90]: event: 69 > . > . ... raw event: size 144 bytes > . 0000: 45 00 00 00 00 00 90 00 04 00 00 00 00 00 00 00 E............... > . 0010: 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 H............... > . 0020: 00 00 00 00 00 00 00 00 74 03 00 00 00 00 00 00 ........t....... > . 0030: 49 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 I............... > . 0040: 01 00 00 00 00 00 00 00 74 03 00 00 00 00 00 00 ........t....... > . 0050: 4a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 J............... > . 0060: 00 00 00 00 00 00 00 00 74 03 00 00 00 00 00 00 ........t....... > . 0070: 4b 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 K............... > . 0080: 01 00 00 00 00 00 00 00 74 03 00 00 00 00 00 00 ........t....... > > 0 0 0x1e0 [0x90]: PERF_RECORD_ID_INDEX nr: 4 > ... id: 72 idx: 0 cpu: 0 tid: 884 > ... id: 73 idx: 1 cpu: 1 tid: 884 > ... id: 74 idx: 0 cpu: 0 tid: 884 > ... id: 75 idx: 1 cpu: 1 tid: 884 > > 0x270(a)perf.data [0xc8]: event: 70 > . > . ... raw event: size 200 bytes > . 0000: 46 00 00 00 00 00 c8 00 03 00 00 00 00 00 00 00 F............... > . 0010: 01 00 00 00 00 00 00 00 02 00 00 00 08 00 00 00 ................ > . 0020: 00 00 00 00 00 00 00 00 40 40 40 40 40 40 40 40 ........@@@@@@@@ > . 0030: 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 ................ > . 0040: 40 08 00 00 00 00 00 00 10 00 00 00 00 00 00 00 @............... > . 0050: a1 0e 00 28 00 00 00 00 01 f4 00 41 00 00 00 00 ...(.......A.... > . 0060: 88 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0070: cc 00 00 00 00 00 00 00 40 40 40 40 40 40 40 40 ........@@@@@@@@ > . 0080: 01 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 ................ > . 0090: 40 08 00 00 00 00 00 00 12 00 00 00 00 00 00 00 @............... > . 00a0: a1 0e 00 28 00 00 00 00 01 f4 00 41 00 00 00 00 ...(.......A.... > . 00b0: 88 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 00c0: cc 00 00 00 00 00 00 00 ........ > > 0 0 0x270 [0xc8]: PERF_RECORD_AUXTRACE_INFO type: 3 > - log 58/58 100% > > > Thanks, > Radhey

10 months, 1 week

Re: [PATCH 1/1] arm64: dts: imx8mp: Add coresight trace components

by Suzuki K Poulose

On 05/05/2023 20:51, Frank Li wrote: > Add coresight trace components (ETM, ETF, ETB and Funnel). > > ┌───────┐ ┌───────┐ ┌───────┐ > │ CPU0 ├─►│ ETM0 ├─►│ │ > └───────┘ └───────┘ │ │ > │ │ > ┌───────┐ ┌───────┐ │ ATP │ > │ CPU1 ├─►│ ETM1 ├─►│ │ > └───────┘ └───────┘ │ │ > │ FUNNEL│ > ┌───────┐ ┌───────┐ │ │ > │ CPU2 ├─►│ ETM2 ├─►│ │ > └───────┘ └───────┘ │ │ ┌─────┐ ┌─────┐ > │ │ │ │ │ │ > ┌───────┐ ┌───────┐ │ │ │ M7 │ │ DSP │ > │ CPU3 ├─►│ ETM3 ├─►│ │ │ │ │ │ > └───────┘ └───────┘ └───┬───┘ └──┬──┘ └──┬──┘ AXI > │ │ │ ▲ > ▼ ▼ ▼ │ > ┌───────────────────────────┐ ┌─────┐ ┌─┴──┐ > │ ATP FUNNEL ├──►│ETF ├─► │ETR │ > └───────────────────────────┘ └─────┘ └────┘ > > Signed-off-by: Frank Li <Frank.Li(a)nxp.com> > --- > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 179 ++++++++++++++++++++++ > 1 file changed, 179 insertions(+) > > diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi > index a19224fe1a6a..0fa74477b9e1 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi > @@ -304,6 +304,185 @@ soc: soc@0 { > nvmem-cells = <&imx8mp_uid>; > nvmem-cell-names = "soc_unique_id"; > > + etm0: etm@28440000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0x28440000 0x10000>; > + arm,primecell-periphid = <0xbb95d>; Why is this needed (and for all the ETMs) ? Suzuki

10 months, 1 week

Re: [PATCH] dt-bindings: cleanup DTS example whitespaces

by Mike Leach

On Sun, 2 Jul 2023 at 19:23, Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> wrote: > > The DTS code coding style expects spaces around '=' sign. > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> > > --- > > Rob, > > Maybe this could go via your tree? Rebased on your for-next: > v6.4-rc2-45-gf0ac35049606 > --- > .../bindings/arm/arm,coresight-cti.yaml | 18 +++++++++--------- > .../bindings/arm/keystone/ti,sci.yaml | 8 ++++---- > .../devicetree/bindings/display/msm/gmu.yaml | 2 +- > .../display/panel/samsung,s6e8aa0.yaml | 2 +- > .../display/rockchip/rockchip-vop.yaml | 4 ++-- > .../bindings/iio/adc/ti,adc108s102.yaml | 2 +- > .../bindings/media/renesas,rzg2l-cru.yaml | 4 ++-- > .../devicetree/bindings/media/renesas,vin.yaml | 4 ++-- > .../devicetree/bindings/mtd/mtd-physmap.yaml | 2 +- > .../bindings/net/mediatek-dwmac.yaml | 2 +- > .../bindings/perf/amlogic,g12-ddr-pmu.yaml | 4 ++-- > .../bindings/phy/mediatek,dsi-phy.yaml | 2 +- > .../remoteproc/amlogic,meson-mx-ao-arc.yaml | 2 +- > .../devicetree/bindings/usb/mediatek,mtu3.yaml | 2 +- > .../devicetree/bindings/usb/ti,am62-usb.yaml | 2 +- > 15 files changed, 30 insertions(+), 30 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > index 0c5b875cb654..d6c84b6e7fe6 100644 > --- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > @@ -287,7 +287,7 @@ examples: > arm,trig-in-sigs = <0 1>; > arm,trig-in-types = <PE_DBGTRIGGER > PE_PMUIRQ>; > - arm,trig-out-sigs=<0 1 2 >; > + arm,trig-out-sigs = <0 1 2 >; > arm,trig-out-types = <PE_EDBGREQ > PE_DBGRESTART > PE_CTIIRQ>; > @@ -309,24 +309,24 @@ examples: > > trig-conns@0 { > reg = <0>; > - arm,trig-in-sigs=<0>; > - arm,trig-in-types=<GEN_INTREQ>; > - arm,trig-out-sigs=<0>; > - arm,trig-out-types=<GEN_HALTREQ>; > + arm,trig-in-sigs = <0>; > + arm,trig-in-types = <GEN_INTREQ>; > + arm,trig-out-sigs = <0>; > + arm,trig-out-types = <GEN_HALTREQ>; > arm,trig-conn-name = "sys_profiler"; > }; > > trig-conns@1 { > reg = <1>; > - arm,trig-out-sigs=<2 3>; > - arm,trig-out-types=<GEN_HALTREQ GEN_RESTARTREQ>; > + arm,trig-out-sigs = <2 3>; > + arm,trig-out-types = <GEN_HALTREQ GEN_RESTARTREQ>; > arm,trig-conn-name = "watchdog"; > }; > > trig-conns@2 { > reg = <2>; > - arm,trig-in-sigs=<1 6>; > - arm,trig-in-types=<GEN_HALTREQ GEN_RESTARTREQ>; > + arm,trig-in-sigs = <1 6>; > + arm,trig-in-types = <GEN_HALTREQ GEN_RESTARTREQ>; > arm,trig-conn-name = "g_counter"; > }; > }; for above CTI chagnes Acked-by: Mike Leach <mike.leach(a)linaro.org> > diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml > index 91b96065f7df..86b59de7707e 100644 > --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml > +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml > @@ -96,8 +96,8 @@ examples: > compatible = "ti,k2g-sci"; > ti,system-reboot-controller; > mbox-names = "rx", "tx"; > - mboxes= <&msgmgr 5 2>, > - <&msgmgr 0 0>; > + mboxes = <&msgmgr 5 2>, > + <&msgmgr 0 0>; > reg-names = "debug_messages"; > reg = <0x02921800 0x800>; > }; > @@ -107,8 +107,8 @@ examples: > compatible = "ti,k2g-sci"; > ti,host-id = <12>; > mbox-names = "rx", "tx"; > - mboxes= <&secure_proxy_main 11>, > - <&secure_proxy_main 13>; > + mboxes = <&secure_proxy_main 11>, > + <&secure_proxy_main 13>; > reg-names = "debug_messages"; > reg = <0x44083000 0x1000>; > > diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml > index 029d72822d8b..65b02c7a1211 100644 > --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml > +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml > @@ -225,7 +225,7 @@ examples: > #include <dt-bindings/interrupt-controller/arm-gic.h> > > gmu: gmu@506a000 { > - compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu"; > + compatible = "qcom,adreno-gmu-630.2", "qcom,adreno-gmu"; > > reg = <0x506a000 0x30000>, > <0xb280000 0x10000>, > diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml > index 1cdc91b3439f..200fbf1c74a0 100644 > --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml > +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml > @@ -74,7 +74,7 @@ examples: > vdd3-supply = <&vcclcd_reg>; > vci-supply = <&vlcd_reg>; > reset-gpios = <&gpy4 5 0>; > - power-on-delay= <50>; > + power-on-delay = <50>; > reset-delay = <100>; > init-delay = <100>; > panel-width-mm = <58>; > diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml > index 6f43d885c9b3..df61cb5f5c54 100644 > --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml > +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml > @@ -121,11 +121,11 @@ examples: > #size-cells = <0>; > vopb_out_edp: endpoint@0 { > reg = <0>; > - remote-endpoint=<&edp_in_vopb>; > + remote-endpoint = <&edp_in_vopb>; > }; > vopb_out_hdmi: endpoint@1 { > reg = <1>; > - remote-endpoint=<&hdmi_in_vopb>; > + remote-endpoint = <&hdmi_in_vopb>; > }; > }; > }; > diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml > index 9b072b057f16..a60b1e100ee4 100644 > --- a/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml > @@ -35,7 +35,7 @@ unevaluatedProperties: false > examples: > - | > spi { > - #address-cells= <1>; > + #address-cells = <1>; > #size-cells = <0>; > > adc@0 { > diff --git a/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml b/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml > index 7dde7967c886..1e72b8808d24 100644 > --- a/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml > +++ b/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml > @@ -137,7 +137,7 @@ examples: > > cru_parallel_in: endpoint@0 { > reg = <0>; > - remote-endpoint= <&ov5642>; > + remote-endpoint = <&ov5642>; > hsync-active = <1>; > vsync-active = <1>; > }; > @@ -150,7 +150,7 @@ examples: > > cru_csi_in: endpoint@0 { > reg = <0>; > - remote-endpoint= <&csi_cru_in>; > + remote-endpoint = <&csi_cru_in>; > }; > }; > }; > diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml > index 91e8f368fb52..324703bfb1bd 100644 > --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml > +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml > @@ -303,11 +303,11 @@ examples: > > vin0csi20: endpoint@0 { > reg = <0>; > - remote-endpoint= <&csi20vin0>; > + remote-endpoint = <&csi20vin0>; > }; > vin0csi40: endpoint@2 { > reg = <2>; > - remote-endpoint= <&csi40vin0>; > + remote-endpoint = <&csi40vin0>; > }; > }; > }; > diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml > index f8c976898a95..18f6733408b4 100644 > --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml > +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml > @@ -164,7 +164,7 @@ examples: > reg = <0 0xf80000>; > }; > firmware@f80000 { > - label ="firmware"; > + label = "firmware"; > reg = <0xf80000 0x80000>; > read-only; > }; > diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml > index 0fa2132fa4f4..400aedb58205 100644 > --- a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml > +++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml > @@ -156,7 +156,7 @@ examples: > reg = <0x1101c000 0x1300>; > interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_LOW>; > interrupt-names = "macirq"; > - phy-mode ="rgmii-rxid"; > + phy-mode = "rgmii-rxid"; > mac-address = [00 55 7b b5 7d f7]; > clock-names = "axi", > "apb", > diff --git a/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml b/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml > index 50f46a6898b1..4adab0149108 100644 > --- a/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml > +++ b/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml > @@ -42,8 +42,8 @@ examples: > - | > #include <dt-bindings/interrupt-controller/arm-gic.h> > pmu { > - #address-cells=<2>; > - #size-cells=<2>; > + #address-cells = <2>; > + #size-cells = <2>; > > pmu@ff638000 { > compatible = "amlogic,g12a-ddr-pmu"; > diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml > index 26f2b887cfc1..b8d77165c4a1 100644 > --- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml > +++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml > @@ -83,7 +83,7 @@ examples: > clocks = <&clk26m>; > clock-output-names = "mipi_tx0_pll"; > drive-strength-microamp = <4000>; > - nvmem-cells= <&mipi_tx_calibration>; > + nvmem-cells = <&mipi_tx_calibration>; > nvmem-cell-names = "calibration-data"; > #clock-cells = <0>; > #phy-cells = <0>; > diff --git a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml > index 3100cb870170..76e8ca44906a 100644 > --- a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml > +++ b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml > @@ -75,7 +75,7 @@ additionalProperties: false > examples: > - | > remoteproc@1c { > - compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc"; > + compatible = "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc"; > reg = <0x1c 0x8>, <0x38 0x8>; > reg-names = "remap", "cpu"; > resets = <&media_cpu_reset>; > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml > index 478214ab045e..a59d91243ac8 100644 > --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml > @@ -304,7 +304,7 @@ examples: > # Dual role switch with type-c > - | > usb@11201000 { > - compatible ="mediatek,mt8183-mtu3", "mediatek,mtu3"; > + compatible = "mediatek,mt8183-mtu3", "mediatek,mtu3"; > reg = <0x11201000 0x2e00>, <0x11203e00 0x0100>; > reg-names = "mac", "ippc"; > interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_LOW>; > diff --git a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml > index d25fc708e32c..fec5651f5602 100644 > --- a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml > +++ b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml > @@ -92,7 +92,7 @@ examples: > > usb@31100000 { > compatible = "snps,dwc3"; > - reg =<0x00 0x31100000 0x00 0x50000>; > + reg = <0x00 0x31100000 0x00 0x50000>; > interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>, /* irq.0 */ > <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>; /* irq.0 */ > interrupt-names = "host", "peripheral"; > -- > 2.34.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

10 months, 1 week

Re: [PATCH 2/2] perf report: Don't add to histogram when there is no thread found

by James Clark

On 30/06/2023 22:02, Namhyung Kim wrote: > On Wed, Jun 28, 2023 at 1:06 PM Namhyung Kim <namhyung(a)kernel.org> wrote: >> >> On Wed, Jun 28, 2023 at 3:34 AM James Clark <james.clark(a)arm.com> wrote: >>> >>> >>> >>> On 27/06/2023 18:19, Ian Rogers wrote: >>>> On Tue, Jun 27, 2023 at 9:58 AM Namhyung Kim <namhyung(a)kernel.org> wrote: >>>>> >>>>> On Tue, Jun 27, 2023 at 9:43 AM Ian Rogers <irogers(a)google.com> wrote: >>>>>> >>>>>> On Mon, Jun 26, 2023 at 5:02 PM Namhyung Kim <namhyung(a)kernel.org> wrote: >>>>>>> >>>>>>> On Mon, Jun 26, 2023 at 05:10:58PM +0100, James Clark wrote: >>>>>>>> thread__find_map() chooses to exit without assigning a thread to the >>>>>>>> addr_location in some scenarios, for example when there are samples from >>>>>>>> a guest and perf_guest == false. This results in a segfault when adding >>>>>>>> to the histogram because it uses unguarded accesses to the thread member >>>>>>>> of the addr_location. >>>>>>> >>>>>>> Looking at the commit 0dd5041c9a0ea ("perf addr_location: Add >>>>>>> init/exit/copy functions") that introduced the change, I'm not sure if >>>>>>> it's the intend behavior. >>>>>>> >>>>>>> It might change maps and map, but not thread. Then I think no reason >>>>>>> to not set the al->thread at the beginning. >>>>>>> >>>>>>> How about this? Ian? >>>>>>> (I guess we can get rid of the duplicate 'al->map = NULL' part) >>>>>> >>>>>> It seemed strange that we were failing to find a map (the function's >>>>>> purpose) but then populating the address_location. The change below >>>>>> brings back that somewhat odd behavior. I'm okay with reverting to the >>>>>> old behavior, clearly there were users relying on it. We should >>>>>> probably also copy maps and not just thread, as that was the previous >>>>>> behavior. >>>>> >>>>> Probably. But it used to support samples without maps and I think >>>>> that's why it ignores the return value of thread__find_map(). So >>>>> we can expect al.map is NULL and maybe fine to leave it for now. >>>>> >>>>> As machine__resolve() returns -1 if it gets no thread, we should set >>>>> al.thread when it returns 0. >>>>> >>>>> Can I get your Acked-by? >>>> >>>> Yep: >>>> Acked-by: Ian Rogers <irogers(a)google.com> >>> >>> Looks good to me too. Should I resend the set with this change instead >>> of my one? >> >> No, I can take care of that. I'll take this as your Acked-by. :) > > This part is applied to perf-tools-next, thanks! Thanks Namhyung

10 months, 1 week

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight July 2023