On Fri, 14 Feb 2020 at 02:00, Era Tiwari era.tiwari@nxp.com wrote:
Thank you Mathieu and Zeid We have been trying many things in last week, but probe for etm4x does not get called.
Regards Era
-----Original Message----- From: Mathieu Poirier mathieu.poirier@linaro.org Sent: Thursday, February 6, 2020 10:30 PM To: Poonam Aggrwal poonam.aggrwal@nxp.com Cc: Coresight ML coresight@lists.linaro.org; Era Tiwari era.tiwari@nxp.com Subject: [EXT] Re: Coresight enablement on NXP ARMv8 device
Caution: EXT Email
On Wed, 5 Feb 2020 at 22:16, Poonam Aggrwal poonam.aggrwal@nxp.com wrote:
Thank you Mathieu.
Apologies for delayed response. I have been struggling a bit to get the
coresight compiled in and making device tree changes referring to Juno platform.
Right now the driver's are not getting probed.
-----Original Message----- From: Mathieu Poirier mathieu.poirier@linaro.org Sent: Friday, January 24, 2020 10:32 PM To: Poonam Aggrwal poonam.aggrwal@nxp.com Cc: Coresight ML coresight@lists.linaro.org Subject: Re: Coresight enablement on NXP ARMv8 device
Hi Poonam,
Please CC the coresight mailing list (as I did) when asking questions
- there is a lot of well informed people on there that can also help you.
On Thu, 23 Jan 2020 at 22:33, Poonam Aggrwal poonam.aggrwal@nxp.com wrote:
Hello Mathieu
Greetings!
I have started to take a look at the Linux coresight framework, and get this
enabled on a NXP ARMv8 device.
Can you share some documentation on the configs required to be enabled and
the device tree nodes?
For V8 we have to reference implementation - ARM Juno and the dragonboard 410c. I highly recommend purchasing the latter (because it is very cheap) in order to get an understanding of what a working coresight system look like. It is much easier to start from a working
example than nothing at all.
Sure Mathieu, let me get the dragonboard 410c So for this board the stuff
would work pretty much out of box, this is very good.
That is correct.
Thank you
that the coresight bindings [1] are full of good examples. I would also have a look at the DT for Juno [2] and the dragonboard[3]. The HOWTO.md [4] on github is a really good starting point when you'll get to
test things out.
[1]. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fel ixir.boo
tlin.com%2Flinux%2Flatest%2Fsource%2FDocumentation%2Fdevicetree%2F bi
nd
ings%2Farm%2Fcoresight.txt&data=02%7C01%7Cpoonam.aggrwal%40n xp
.com%7C85f0d8e123d44ebb68a708d7a0ef23fc%7C686ea1d3bc2b4c6fa92c
d99c
5c301635%7C0%7C0%7C637154821265667926&sdata=hwovHzXiyLp2szqL
PYiBnFPdJRGRKnoMT8Z9MgduTzs%3D&reserved=0 [2]. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fel ixir.boo
tlin.com%2Flinux%2Flatest%2Fsource%2Farch%2Farm64%2Fboot%2Fdts%2F ar
m%2Fjuno-
base.dtsi&data=02%7C01%7Cpoonam.aggrwal%40nxp.com%7C85f0d8e 12
3d44ebb68a708d7a0ef23fc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
0%7C637154821265667926&sdata=s%2BwfDTntgyrPnhmUCJTn0CZWsi4 HI
hC3QqX7jGa3SUo%3D&reserved=0 [3]. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fel ixir.boo
tlin.com%2Flinux%2Flatest%2Fsource%2Farch%2Farm64%2Fboot%2Fdts%2F qco
m%2Fmsm8916.dtsi&data=02%7C01%7Cpoonam.aggrwal%40nxp.com% 7C
85f0d8e123d44ebb68a708d7a0ef23fc%7C686ea1d3bc2b4c6fa92cd99c5c30163
5%7C0%7C0%7C637154821265667926&sdata=LCtENREzhwSeswwekjUFI uj
iNnq7Z%2BDpUWqNGJmC3qg%3D&reserved=0 [4]. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi thub.co
m%2FLinaro%2FOpenCSD%2Fblob%2Fmaster%2FHOWTO.md&data=02 %7
C01%7Cpoonam.aggrwal%40nxp.com%7C85f0d8e123d44ebb68a708d7a0ef23 f
c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63715482126566792
6&sdata=XxKbwvEBcV3sH5jQKpIMrtbxNnVLcDeCj%2BykNKh4NT4%3D &am
p;reserved=0
To start I am looking to enable the ARMv8 ETM tracing.
Before going further I advise you to look at the source and sink configuration on your platform. Up to now we've been working with configurations where sources share a single sink (N:1 topology).
In the SoC we are using, The sources are ETM0/1/2/3 and sinks could be either TPIU, or ETR
(memory).
So not it is not like one source one sink topology. Does this answer your Q?
Yes, this is the kind of topology supported by the upstream drivers.
To complement Zied's question, the goal at this point is to understand why the drivers are not getting probed. This is usually a DT problem or that coresight blocks are not powered. Regarding the former, there is plenty of examples to follow. To know if coresight devices are powered up at boot time, instrument your kernel to output the amba CID/PID of the devices that are being probed[1].
I printed the CIDs in the kernel , and they look fine. For example [ 0.391831] The value of CID read is b105900d
That is a good start.
If you can't find the coresight PID than your devices aren't powered. If you do find it, it may be that your device IDs aren't part of the recognised devices yet[2].
The devices should be powered on, otherwise register accesses will not work.
That depends on the SoC...
I also checked the APB clock which is reaching fine. I could not co-relate the IDs in id_table in etm4x.c 0x000bb95d What does this mean? Do we need some corresponding entry in device tree. amba_driver_register, get called, but seems like that amba is not able to probe the etm4x driver. Do we need to register the device to amba explicitly somewhere? Seems there us a missing link..
You may need to add an entry for your device in etm4_ids[] [1]. To know why the device aren't being probe instrument amba_lookup() and amba_cs_uci_id_match()[2].
[1]. https://elixir.bootlin.com/linux/v5.6-rc1/source/drivers/hwtracing/coresight... [2]. https://elixir.bootlin.com/linux/v5.6-rc1/source/drivers/amba/bus.c#L29
Regards Era