CoreSight

coresight@lists.linaro.org

7 participants
2442 discussions

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 >

2 years, 1 month

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

2 years, 1 month

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

2 years, 1 month

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

2 years, 1 month

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

2 years, 1 month

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

2 years, 1 month

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

2 years, 1 month

Re: [PATCH 1/1] perf: cs-etm: Fixes in instruction sample synthesis

by James Clark

On 23/06/2023 19:22, Tanmay Jagdale wrote: > The existing method of synthesizing instruction samples has the > following issues: > 1. Non-branch instructions have mnemonics of branch instructions. > 2. Branch target address is missing. > > Set the sample flags only when we reach the last instruction in > the tidq (which would be a branch instruction) to solve issue 1). > > To fix issue 2), start synthesizing the instructions from the > previous packet (tidq->prev_packet) instead of current packet > (tidq->packet). This way, it is easy to figure out the target > address of the branch instruction in tidq->prev_packet which > is the current packet's (tidq->packet) first executed instruction. > > After the switch to processing the previous packet first, we no > longer need to swap the packets during cs_etm__flush(). Hi Tanmay, I think the fix for setting the right flags and instruction type makes sense, but is it possible to do it without the change to swapping in cs_etm__flush() or some of the other changes to cs_etm__synth_instruction_sample()? I'm seeing some differences in the output related to the PID that's assigned to a sample and some of the addresses that aren't explained by the commit message. Also there is no corresponding change to cs_etm__synth_branch_sample(), which is also using prev_packet etc so I'm wondering if that's correct now without the swap? That function gets used with the default itrace options or itrace=b For example if I run 'perf script --itrace=i100ns' and diff the output before and after your change I see a difference even though branch and instruction info isn't printed, so I wouldn't expect to see any changes. This is on a systemwide recording of a system under load. Thanks James > > Signed-off-by: Tanmay Jagdale <tanmay(a)marvell.com> > --- > tools/perf/util/cs-etm.c | 32 +++++++++++++++++++++++++------- > 1 file changed, 25 insertions(+), 7 deletions(-) > > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c > index 91299cc56bf7..446e00d98fd5 100644 > --- a/tools/perf/util/cs-etm.c > +++ b/tools/perf/util/cs-etm.c > @@ -1418,10 +1418,26 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq, > sample.stream_id = etmq->etm->instructions_id; > sample.period = period; > sample.cpu = tidq->packet->cpu; > - sample.flags = tidq->prev_packet->flags; > sample.cpumode = event->sample.header.misc; > > - cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->packet, &sample); > + cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->prev_packet, &sample); > + > + /* Populate branch target information only when we encounter > + * branch instruction, which is at the end of tidq->prev_packet. > + */ > + if (addr == (tidq->prev_packet->end_addr - 4)) { > + /* Update the perf_sample flags using the prev_packet > + * since that is the queue we are synthesizing. > + */ > + sample.flags = tidq->prev_packet->flags; > + > + /* The last instruction of the previous queue would be a > + * branch operation. Get the target of that branch by looking > + * into the first executed instruction of the current packet > + * queue. > + */ > + sample.addr = cs_etm__first_executed_instr(tidq->packet); > + } > > if (etm->synth_opts.last_branch) > sample.branch_stack = tidq->last_branch; > @@ -1641,7 +1657,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq, > /* Get instructions remainder from previous packet */ > instrs_prev = tidq->period_instructions; > > - tidq->period_instructions += tidq->packet->instr_count; > + tidq->period_instructions += tidq->prev_packet->instr_count; > > /* > * Record a branch when the last instruction in > @@ -1721,8 +1737,11 @@ static int cs_etm__sample(struct cs_etm_queue *etmq, > * been executed, but PC has not advanced to next > * instruction) > */ > + /* Get address from prev_packet since we are synthesizing > + * that in cs_etm__synth_instruction_sample() > + */ > addr = cs_etm__instr_addr(etmq, trace_chan_id, > - tidq->packet, offset - 1); > + tidq->prev_packet, offset - 1); > ret = cs_etm__synth_instruction_sample( > etmq, tidq, addr, > etm->instructions_sample_period); > @@ -1786,7 +1805,7 @@ static int cs_etm__flush(struct cs_etm_queue *etmq, > > /* Handle start tracing packet */ > if (tidq->prev_packet->sample_type == CS_ETM_EMPTY) > - goto swap_packet; > + goto reset_last_br; > > if (etmq->etm->synth_opts.last_branch && > etmq->etm->synth_opts.instructions && > @@ -1822,8 +1841,7 @@ static int cs_etm__flush(struct cs_etm_queue *etmq, > return err; > } > > -swap_packet: > - cs_etm__packet_swap(etm, tidq); > +reset_last_br: > > /* Reset last branches after flush the trace */ > if (etm->synth_opts.last_branch)

2 years, 1 month

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

by James Clark

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? > > Thanks, > Ian > >> Thanks, >> Namhyung

2 years, 1 month

Re: [PATCH v6 09/13] Add nodes for dsb edge control

by Tao Zhang

On 6/20/2023 4:49 PM, Greg Kroah-Hartman wrote: > On Tue, Jun 20, 2023 at 04:31:59PM +0800, Tao Zhang wrote: >> On 6/20/2023 3:37 PM, Greg Kroah-Hartman wrote: >>> On Tue, Jun 20, 2023 at 03:32:37PM +0800, Tao Zhang wrote: >>>> Add the nodes to set value for DSB edge control and DSB edge >>>> control mask. Each DSB subunit TPDM has maximum of n(n<16) EDCR >>>> resgisters to configure edge control. DSB edge detection control >>>> 00: Rising edge detection >>>> 01: Falling edge detection >>>> 10: Rising and falling edge detection (toggle detection) >>>> And each DSB subunit TPDM has maximum of m(m<8) ECDMR registers to >>>> configure mask. Eight 32 bit registers providing DSB interface >>>> edge detection mask control. >>>> >>>> Signed-off-by: Tao Zhang<quic_taozha(a)quicinc.com> >>>> --- >>>> .../ABI/testing/sysfs-bus-coresight-devices-tpdm | 32 +++++ >>>> drivers/hwtracing/coresight/coresight-tpdm.c | 143 ++++++++++++++++++++- >>>> drivers/hwtracing/coresight/coresight-tpdm.h | 22 ++++ >>>> 3 files changed, 196 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm >>>> index 2a82cd0..34189e4a 100644 >>>> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm >>>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm >>>> @@ -60,3 +60,35 @@ Description: >>>> Bit[3] : Set to 0 for low performance mode. >>>> Set to 1 for high performance mode. >>>> Bit[4:8] : Select byte lane for high performance mode. >>>> + >>>> +What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge_ctrl >>>> +Date: March 2023 >>>> +KernelVersion 6.5 >>>> +Contact: Jinlong Mao (QUIC)<quic_jinlmao(a)quicinc.com>, Tao Zhang (QUIC)<quic_taozha(a)quicinc.com> >>>> +Description: >>>> + Read/Write a set of the edge control registers of the DSB >>>> + in TPDM. >>>> + >>>> + Expected format is the following: >>>> + <integer1> <integer2> <integer3> >>> sysfs is "one value", not 3. Please never have to parse a sysfs file. >> Do you mean sysfs file can only accept "one value"? > Yes. Hi Greg, I‘d like to clarify the usage of this sysfs file again. In the current design, three integers will be written to "dsb_edge_ctrl" to configure DSB edge detection. Integer #1: The start number of edge detection which needs to be configured. Integer #2: The end number of edge detection which needs to be configured. Integer #3: The type of the edge detection needs to be configured. Below is an example. echo 0x3 0x25 0x1 > dsb_edge_ctrl It will configure edge detection #3 to #37 as "falling edge detection". Since these three integers are interrelated and written to achieve the same function, can we use these three integers as "one tuple" here? Best, Tao > >> I see that more than one value are written to the sysfs file >> "trigout_attach". > Then someone missed that and it needs to be fixed. > >>>> +static ssize_t dsb_edge_ctrl_show(struct device *dev, >>>> + struct device_attribute *attr, >>>> + char *buf) >>>> +{ >>>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent); >>>> + ssize_t size = 0; >>>> + unsigned long bytes; >>>> + int i; >>>> + >>>> + spin_lock(&drvdata->spinlock); >>>> + for (i = 0; i < TPDM_DSB_MAX_EDCR; i++) { >>>> + bytes = sysfs_emit_at(buf, size, >>>> + "Index:0x%x Val:0x%x\n", i, >>> Again, no, one value, no "string" needed to parse anything. >> I also see other sysfs files can be read more than one value in other >> drivers. > Again, they are broken, please send patches to fix them. > >> Is this "one value" limitation the usage rule of Linux sysfs system? > Yes. > > thanks, > > greg k-h

2 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight