On Thu, 9 Jan 2025 21:53:48 +0000, Ilkka Koskinen wrote:
> Trying to record a trace on kernel with 64k pages resulted in -ENOMEM.
> This happens due to a bug in calculating the number of table pages, which
> returns zero. Fix the issue by rounding up.
>
> $ perf record --kcore -e cs_etm/@tmc_etr55,cycacc,branch_broadcast/k --per-thread taskset --cpu-list 1 dd if=/dev/zero of=/dev/null
> failed to mmap with 12 (Cannot allocate memory)
>
> [...]
Applied, thanks!
[1/1] coresight: catu: Fix number of pages while using 64k pages
https://git.kernel.org/coresight/c/0e14e062f5ff
Best regards,
--
Suzuki K Poulose <suzuki.poulose(a)arm.com>
Hi Suzuki,
thanks for the reply! The CPUs of the boards I am using are all based on Arm-v8(.2), but I found the components' addresses in the manuals of the SoCs.
I managed to modify the Devicetree by writing my own .dtsi file (see attachment) and finally got the CoreSight devices in /sys/devices/.
However, dmesg shows the following:
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.9.253-coresight (user@user-desktop) (gcc version 7.5.0 (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) ) #1 SMP PREEMPT Wed Jan 1 18:45:04 CET 2025
[ 0.000000] Boot CPU: AArch64 Processor [411fd071]
(omitted 87 lines)
[ 0.212039] DTS File Name: /home/user/Downloads/Linux_for_Tegra/source/public/kernel/kernel-4.9/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-a02.dts
[ 0.212045] DTB Build time: Jan 1 2025 16:04:45
(omitted 35 lines)
[ 0.420616] DTS File Name: /home/user/Downloads/Linux_for_Tegra/source/public/kernel/kernel-4.9/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-a02.dts
[ 0.420622] DTB Build time: Jan 1 2025 16:04:45
(omitted 75 lines)
[ 0.524166] OF: amba_device_add() failed (-19) for /funnel_bccplex@73001000
(omitted 367 lines)
[ 1.330484] OF: graph: no port node found in /etf@72030000
[ 1.330757] OF: graph: no port node found in /etr@72050000
[ 1.330987] OF: graph: no port node found in /funnel_major@72010000
[ 1.331238] OF: graph: no port node found in /ptm0@73440000
[ 1.331451] coresight-etm4x 73440000.ptm0: CPU0: Cortex-A57 ETM v4.0 initialized
[ 1.331482] OF: graph: no port node found in /ptm1@73540000
[ 1.331689] coresight-etm4x 73540000.ptm1: CPU1: Cortex-A57 ETM v4.0 initialized
[ 1.331719] OF: graph: no port node found in /ptm2@73640000
[ 1.331938] coresight-etm4x 73640000.ptm2: CPU2: Cortex-A57 ETM v4.0 initialized
[ 1.331944] extcon-disp-state extcon:disp-state: cable 47 state 0
[ 1.331946] Extcon AUX1(HDMI) disable
[ 1.331976] OF: graph: no port node found in /ptm3@73740000
[ 1.332192] coresight-etm4x 73740000.ptm3: CPU3: Cortex-A57 ETM v4.0 initialized
[ 1.332250] OF: graph: no port node found in /replicator@72040000
[ 1.332305] coresight-replicator-qcom 72040000.replicator: REPLICATOR 1.0 initialized
[ 1.332350] OF: graph: no port node found in /stm@72070000
[ 1.332386] coresight-stm 72070000.stm: stm_register_device failed, probing deffered
(omitted 64 lines)
[ 1.411751] OF: graph: no port node found in /stm@72070000
[ 1.412025] coresight-stm 72070000.stm: STM32 initialized
(omitted 212 lines)
Do you have an idea what I did wrong? In the end, I want to be able to follow the steps described here:
https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3275/index.html#pa…
Best regards,
Vincent
(P.S. There was a problem sending this email a first time, but it should work now)
On 17/02/2025 9:30 am, Jie Gan wrote:
> From: Jie Gan <jie.gan(a)oss.qualcomm.com>
>
> The Coresight TMC Control Unit(CTCU) device hosts miscellaneous configuration
> registers to control various features related to TMC ETR device.
>
> The CTCU device works as a helper device physically connected to the TMC ETR device.
> ---------------------------------------------------------
> |ETR0| |ETR1|
> . \ / .
> . \ / .
> . \ / .
> . \ / .
> ---------------------------------------------------
> ETR0ATID0-ETR0ATID3 CTCU ETR1ATID0-ETR1ATID3
> ---------------------------------------------------
> Each ETR has four ATID registers with 128 bits long in total.
> e.g. ETR0ATID0-ETR0ATID3 registers are used by ETR0 device.
>
> Based on the trace id which is programed in CTCU ATID register of
> specific ETR, trace data with that trace id can get into ETR's buffer
> while other trace data gets ignored. The number of CTCU ATID registers
> depends on the number of defined TMC ETR devices. For example, two TMC
> ETR devices need eight ATID registers. ETR0 with ETR0ATID0-ETR0ATID3
> and ETR1 with ETR1ATID0-ETRATID3.
>
> The significant challenge in enabling the data filter function is how
> to collect the trace ID of the source device. The introduction of
> trace_id callback function addresses this challenge. The callback function
> collects trace ID of the device and return it back. The trace ID will be
> stored in the structure called coresight_path and transmitted to helper
> and sink devices.
>
> The coresight_path structure is created to address how to transmit
> parameters needs by coresight_enable_path/coresight_disbale_path
> functions.
>
> Here is the definition of the struct coresight_path:
> /**
> * struct coresight_path - data needed by enable/disable path
> * @path: path from source to sink.
> * @trace_id: trace_id of the whole path.
> */
> struct coresight_path {
> struct list_head *path;
> u8 trace_id;
> };
>
> The atid_offset mentioned before is the offset to ATID register in CTCU
> device.
>
> Enabling the source device will configure one bit in the ATID register based
> on its trace ID.
> Disabling the source devices will reset the bit in the AITD register
> based on its trace ID.
>
> Useage:
> Enable:
> STM device with trace ID 5 and ETR0 is activated.
> Bitmap before the enablement:
> ETR0ATID0:
> 31..................543210
> ==========================
> 0000000000000000000000...0
> ==========================
>
> Bitmap after the enablement:
> 31..................543210
> ==========================
> 0000000000000...0000100000
> ==========================
>
> The bit 5 of the ETR0ATID0 register is configured to 1 when enabling the
> STM device.
>
> Disable:
> STM device with trace ID 5 and ETR0 is activated.
> Bitmap before the disablement:
> ETR0ATID0:
> 31................6543210
> =========================
> 000000000010111...0100000
> =========================
>
> Bitmap after the disablement
> ETR0ATID0:
> 31................6543210
> =========================
> 000000000010111...0000000
> =========================
>
> The bit 5 of the ETR0ATID0 register is reset to 0 when disabling the STM
> device.
>
> Sincere thanks to James Clark for providing an excellent idea to handle
> the trace_id of the path.
>
> Changes in V12:
> 1. Update the method for allocating trace_id for perf mode.
> Link to V11 - https://lore.kernel.org/linux-arm-msm/20250214024021.249655-1-quic_jiegan@q…
>
I tested the latest change, looks good to me.
On 17/02/2025 1:14 am, Jie Gan wrote:
>
>
> On 2/14/2025 7:09 PM, James Clark wrote:
>>
>>
>> On 14/02/2025 1:34 am, Jie Gan wrote:
>>>
>>>
>>> On 2/14/2025 12:00 AM, James Clark wrote:
>>>>
>>>>
>>>> On 07/02/2025 6:42 am, Jie Gan wrote:
>>>>> Add 'struct coresight_path' to store the data that is needed by
>>>>> coresight_enable_path/coresight_disable_path. The structure will be
>>>>> transmitted to any required devices to enable related
>>>>> funcationalities.
>>>>>
>>>>> The trace_id will be allocated after the path is built. Consequently,
>>>>> The ETM3x and ETM4x devices will directly read the trace_id from path
>>>>> which result in etm_read_alloc_trace_id and etm4_read_alloc_trace_id
>>>>> being deleted.
>>>>>
>>>>> Co-developed-by: James Clark <james.clark(a)linaro.org>
>>>>> Signed-off-by: James Clark <james.clark(a)linaro.org>
>>>>> Signed-off-by: Jie Gan <quic_jiegan(a)quicinc.com>
>>>>> ---
>>>>> drivers/hwtracing/coresight/coresight-core.c | 106 ++++++++++++
>>>>> +-----
>>>>> drivers/hwtracing/coresight/coresight-dummy.c | 5 +-
>>>>> .../hwtracing/coresight/coresight-etm-perf.c | 30 +++--
>>>>> .../hwtracing/coresight/coresight-etm-perf.h | 2 +-
>>>>> drivers/hwtracing/coresight/coresight-etm.h | 1 -
>>>>> .../coresight/coresight-etm3x-core.c | 54 ++-------
>>>>> .../coresight/coresight-etm4x-core.c | 54 ++-------
>>>>> drivers/hwtracing/coresight/coresight-etm4x.h | 1 -
>>>>> drivers/hwtracing/coresight/coresight-priv.h | 12 +-
>>>>> drivers/hwtracing/coresight/coresight-stm.c | 3 +-
>>>>> drivers/hwtracing/coresight/coresight-sysfs.c | 17 ++-
>>>>> drivers/hwtracing/coresight/coresight-tpdm.c | 3 +-
>>>>> include/linux/coresight.h | 12 +-
>>>>> 13 files changed, 143 insertions(+), 157 deletions(-)
>>>>>
>>>> [...]
>>>>> @@ -352,7 +352,7 @@ static void *etm_setup_aux(struct perf_event
>>>>> *event, void **pages,
>>>>> * CPUs, we can handle it and fail the session.
>>>>> */
>>>>> for_each_cpu(cpu, mask) {
>>>>> - struct list_head *path;
>>>>> + struct coresight_path *path;
>>>>> struct coresight_device *csdev;
>>>>> csdev = per_cpu(csdev_src, cpu);
>>>>> @@ -405,15 +405,15 @@ static void *etm_setup_aux(struct perf_event
>>>>> *event, void **pages,
>>>>> cpumask_clear_cpu(cpu, mask);
>>>>> continue;
>>>>> }
>>>>> -
>>>>> /* ensure we can allocate a trace ID for this CPU */
>>>>> - trace_id = coresight_trace_id_get_cpu_id_map(cpu, &sink-
>>>>> >perf_sink_id_map);
>>>>> - if (!IS_VALID_CS_TRACE_ID(trace_id)) {
>>>>> + trace_id = coresight_path_assign_trace_id(path,
>>>>> CS_MODE_PERF);
>>>>> +
>>>>> + /* Can be 0 and valid, ETE doesn't need an ID */
>>>>> + if (trace_id < 0) {
>>>>
>>>> Not sure why I wrote it like this, but I think we should leave it as
>>>> it was with !IS_VALID_CS_TRACE_ID(). Even with ETE it calls the
>>>> trace ID allocator, so nothing has changed here.
>>>>
>>> Sure, Will restore. For ETE or ETM, we dont need traverse the path,
>>> just directly allocate the trace id based on cpu id.
>>>
>>> Jie
>>>
>>>
>>
>> Sorry I meant to only keep the !IS_VALID_CS_TRACE_ID() bit. We still
>> need to call the new coresight_path_assign_trace_id() otherwise it
>> doesn't get assigned to the path. I saw that got removed in v11.
>>
>>
> Sorry for the misunderstanding, I was focused on "nothing has changed
> here", lol.
>
> I got your point here.
> So the updated codes should be:
> ...
> /* ensure we can allocate a trace ID for this CPU */
> trace_id = coresight_path_assign_trace_id(path,
> CS_MODE_PERF);
> if (!IS_VALID_CS_TRACE_ID(trace_id)) {
> cpumask_clear_cpu(cpu, mask);
> coresight_release_path(path);
> continue;
> }
> ...
>
>
> Thanks,
> Jie
Yes that looks good.