CoreSight

coresight@lists.linaro.org

7 participants
2689 discussions

Fwd: My learning summary - STM policy management

by Chunyan Zhang

Good day Mathieu and All, I revised this documentation a little, and re-sending this to you (cc'ed maillist and Mark this time) simply because I want to explain how generic STM deals with master IDs you mentioned in another mail yesterday. To find the answer, you can directly go to 4. - "Allocate one master and a range of channels for stm_source class device:" There are a few concepts / glossaries I need to explain here: i) 'stm_source class device' - is used to write trace data to an stm device once linked, like 'stm_ftrace' you wrote for testing integration of Ftrace with STM before. ii) STM device - means the real hardware device of STM which can be found under /dev/ directory on the target. * STM policy management of master/channel: 1. Policy management source code: driver/hwtrace/stm/policy.c 2. Policy management introduce: (excerpts from Documentation/trace/stm.txt) 1) On the receiving end of this STP stream (the decoder side), trace sources can only be identified by master/channel combination, so in order for the decoder to be able to make sense of the trace that involves multiple trace sources, it needs to be able to map those master/channel pairs to the trace sources that it understands. 2) To solve this mapping problem, stm class provides a policy management mechanism via configfs, that allows defining rules that map string identifiers to ranges of masters and channels. If these rules (policy) are consistent with what decoder expects, it will be able to properly process the trace data. 3. Create policy rules on target: 1) mount -t configfs none /config (the directory 'stp-policy/' will appear under 'config/') 2) Create policy rule for given STM device： mkdir /config/stp-policy/10006000.stm.xxx (‘10006000.stm’ is a STM device name to which this policy applies, this is just an example. ‘xxx’ is an arbitrary string which is separated with device by a dot; but "10006000.stm" must be same with the one which can be found under /dev directory) 3) Create policy rules for a given stm_source class device: mkdir /config/stp-policy/10006000.stm.my_policy/stm_ftrace (‘stm_ftrace’ is a registered device of stm_source class which can be linked with an STM device, and then use this 'stm_ftrace' to write trace data into STM and finally output to the sink buffer. Note that the rule's name must be same with the name of stm_source class device) 4) After created policy rule, there will be two files 'master' and 'channel' under rule's directory, for example: # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/masters 0 127 # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/channels 0 65535 These values mean the range of master/channels which can be used on the stm_source device whose name is the same with the rule's name (stm_ftrace in this case), the default values come from the configuration [1] of STM device (i.e. 10006000.stm in this case) These master/channel files are configurable and this rule would be applied on the stm_source class device (stm_ftrace) when linking this stm_source class device with any STM device (10006000.stm in this case), for example, if you want to link 'stm_ftrace' with '10006000.stm', you can create the directories '10006000.stm.xxx/stm_ftrace/', and when linking happens, the rule under this directory will be applied on 'stm_ftrace'. 4. Allocate one master and a range of channels for stm_source class device: 1 ) Like mentioned in 3. above, the policy rule which has the same name with the stm_source class device will be applied on this stm_source class device, and then this device can choose its one master and required number of channels from the range which this policy rule defined in "masters" and "channels" files (if there isn't policy rule with the same name, the default configuration of STM device will be applied.) for outputting traces. The number of required channels is configured in the stm_source class device driver. 2) When linking stm_source with STM device happens, the program will poll all masters from either the start master configured in the "masters" file under the policy rule directory if one policy rule was built for this stm_source class device or otherwise struct stm_data::sw_start which is configured in this STM device driver, to see if there are free channels on the current master, and the number of freed continuous channels must be larger than or equal to the quantity of required channels. The first eligible master and channel range will be configured as the output path of this stm_source class device. 5. Allocate master/channels for applictions: 1) Set policy rule which should include 'assigned master', 'first assigned channel', 'the number of required channels' by means of stm_file ioctl interface. 2) If an application program doesn't set policy rule for itself, when this application writing data into STM device, a rule whose name is 'default' will be applied, if the 'default' policy cannot be discovered either, like what I wrote above, the default configuration of STM device will be applied. Regards, Chunyan [1] https://git.linaro.org/people/zhang.chunyan/linux.git/blob/5234c83d13a4eb12…

10 years, 9 months

The result of verifying if STM master need to be managed by software

by Chunyan Zhang

Hi Mathieu, I've finished the verification of STM master stuff on Juno. We indeed don't need to care about which master the trace data should go from software side. The attachments are the result, one is the trace output from Ftrace another is the decoding result with Mike's CS-STM decoding library. FYI: The CPUs and associated STM Mater id on Juno are: CPU Master ID 0 A53 core0 0x44 1 A57 core0 0x40 2 A57 core1 0x41 3 A53 core1 0x45 4 A53 core2 0x46 5 A53 core3 0x47 Regard, Chunyan

10 years, 9 months

Where can I get STM base address

by Chunyan Zhang

Hi All, I'd like to add STM entry for Juno based on Mathieu's patch [1]. But where can I find the STM base address and STM stimulus base address and their ranges. Thanks, Chunyan [1] https://git.linaro.org/people/mathieu.poirier/coresight.git/commit/202357a3…

10 years, 9 months

Re: Linux panic + CSAL crash dump

by Mathieu Poirier

Hey Tony, nice to hear back from you. I'm taking the liberty of moving our conversation to the coresight mailing list. The team is getting a little bigger now and it allows people to know what is going on and chime in with ideas of their own. What you are referring to is called the kernel crash dump utility. Ubuntu has a good introduction page on the mechanism [1] and we even have a card for it [2] (I hope you can see it) after a conversation with Will Deacon in San Francisco back in Septemeber. Intel has a patchset out that tries to do that as well [3] but don't know where the venture is at. We are currently not working on this feature for lack of resources. Regards, Mathieu [1]. https://help.ubuntu.com/lts/serverguide/kernel-crash-dump.html [2]. https://projects.linaro.org/browse/KWG-157 [3]. http://thread.gmane.org/gmane.linux.kernel/2007199 On 11 December 2015 at 09:11, Tony Armitstead <Tony.Armitstead(a)arm.com> wrote: > Hi Mathieu, > > > > Hope you are well – we have not spoken in a while. > > > > I am being asked about integration of CoreSight Access Library with Linux > kernel panic situations. Now I know this is not a sensible question, but the > idea that the kernel can write out the data set (register, memory, ETB > content etc) somewhere on a kernel panic and then get this picked up somehow > and converted into a data file set for DS-5’s crash dump files, does make > sense. The ‘problem’ is that how does the kernel write the data somewhere > when it has just panicked? > > > > So the question that occurs to me is whether this is already a solved > problem in ‘Linux land’ and there is some frame work our users could use to > provide this feature. Are you aware of anything? > > > > Regards Tony > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you.

10 years, 10 months

Library names.

by Mike Leach

Hi, While I'm doing some meddlation with the makefiles to build .so libs, it occurs to me that this might be a good time to consider the library names. Rctdl_c_api and ref_trace_decoder reflect the origins of the code as an ARM project to produce an open source reference trace decode library - prior to this effort being contributed and folded in to OpenCSD. My thoughts were either libarm_opencsd.so / libarm_opencsd_c_api.so or libarm_cstraced.so / libarm_cstraced_c_api.so Both of which specify the architecture and function a little better than the old names. Opinions?? Regards Mike (RCTDL appears across much of the source code too, but changing that is a massive job, so I'm not considering that at present). ---------------------------------------------------------------- Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE ---------------------------------------------------------------- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

10 years, 10 months

STM masters/channels from hardware view

by Chunyan Zhang

Hi Mike, Mathieu I've been reading STM driver and its device tree configurations along with the specifications recently. Yesterday, Mathieu asked me a question about the true definition of STM masters. This morning, I read code and spec again. There's still a few details need to ask Mike. Mike, please correct me if anything what I'm writing here is wrong. >From what I have understood, I think STM masters/channels are a continuous physical space in STM, a bit like registers on this point. On my Spreadtrum's board, for example, we are configuring 0x180000 byte space for stimulus ports (i.e. channels). The TRM documents that CS-STM has 129 masters, 128 for software, each supporting 65536 channels. And my question is : 1) How much physical space each channel should take? 2) Do the channels dump the trace packets in real time? 3) Is it correct that set total 0x180000 byte space for 128 masters and 128*65536 channels? Thank you, Chunyan

10 years, 10 months

TMC RAM Read Pointer

by Mathieu Poirier

Friends, I'm reading section 3.3.4 (RAM Read Pointer Register) of the "CoreSight Trace Memory Controller Technical Reference Manual", revision r0p1 and I'm puzzled. The second paragraph of the "Purpose" section reads as follow: "The value written to this register must be a byte-address aligned to the width of the trace memory databus and to a frame boundary. For example, for 64-bit wide trace memory and 128-bit wide trace memory, the four LSBs must be 0s. For 256-bit wide trace memory, the five LSBs must be 0s..." So for 64 bit wide memory RRP can be set to values like 0, 8, 16, 24... for 128 bit 0, 16, 32, 48... and for 256 bit 0, 32, 64... What is perplexing is the statement about the LSBs. Things work for 256 bit and 128 bit with 5 and 4 LSBs respectively but for 64 bit, it should be 3 and not 4 as mentioned. Am I missing something here? Can someone double check me? Thanks, Mathieu

10 years, 11 months

New bundles

by Mathieu Poirier

Good day all, New bundles can be found here [1]. It is the same 'uname' command but generated with the only two options currently supported: timestamp and cycle accurate. We can add more at will but let's start with that. On V3 the options are pushed to the hardware and as such the trace format should change accordingly. On ETMv4 the perf framework does convey the options but they are not configured in the tracers. Even if the options are set the traces won't reflect it - this is obviously only temporary and will be fixed after I release the 3rd version of the patchset. I have verified the validity of the headers (both for V3 and V4) along with the information they conveys. The layouts haven't changed from what I previously had [2] - the only difference is that config registers are artificially generated from options provided on the cmd line. On the topic of configuration registers, at this time TRACEIDR on V3 and TRCCONFIGR on V4 __have the same layout__, i.e bit 12 for cycle accurate and bit 28 for timestamp. I simply did not see the need to select a different bit field layout for V4 since Tor's code will ultimately parse that before feeding it to the decode library. A different layout for V4 would mean more code for Tor - get back to me if you think enacting the V4 TRCCONFIGR layout is important. Keep in mind that nothing of this is set in stone, if you think we can do better please speak up. Mike and Al, this doesn't support ETMv4.1. Let's discuss this further at the meeting on Wednesday. For now (and for a little while) I need to concentrate on getting the 3rd iteration of the patchset out. Regards, Mathieu [1]. http://people.linaro.org/~mathieu.poirier/openCSD/ [2]. https://git.linaro.org/people/mathieu.poirier/coresight.git/blob/refs/heads…

10 years, 11 months

Fwd: Collection of metadata in a multi-session environment

by Mathieu Poirier

---------- Forwarded message ---------- From: Mathieu Poirier <mathieu.poirier(a)linaro.org> Date: 3 November 2015 at 21:27 Subject: Collection of metadata in a multi-session environment To: private-opencsd <private-opencsd(a)linaro.org> As reported in my other email (Trace bundles for ETMv3/v4) moving to a multi-session scheme his forcing me to rethink how metadata is collected as one can no longer assume that what gets read from sysFS actually pertains to the session being reported. When looking at the required registers (once again, please refer to Mike's document, section 4.3.1 to 4.3.3) a lot of them are RO: ETMv3/PTM: ETMIDR ETMv4: TRCIDR[0, ..., 13], TRCAUTHSTATUS Some are RW but can easily be made RO when using the CS framework from Perf: ETMv3/PTM: ETMTRACEID ETMv4: TRCTRACEIDR In fact I remember having this conversation with Mike in San Francisco and nobody would cry if we were to let the framework decide the traceIDs configured on the tracers. Anything that is RO can still be retrieved using the current sysFS driven method since their values don't change. That leaves us with the other RW registers: ETMv3/PTM: ETMCR, ETMCCR ETMv4: TRCCONFIGR The question is, what information is needed from these registers in order to do trace decoding? Is there anything in there that is coming from the HW that can't be deduced otherwise? From what I understand we are talking about user configurable options that could be communicated to the trace decoding library using other means than conveying the whole registers. Using a bitmap is the first option that comes to mind, i.e, if cycle accurate tracing is configured, bit X is set. With the above in mind I need you guys to help me identify the mandatory information in those tracer registers that is needed for trace decoding. Once again we can discuss this further in our meeting tomorrow. Thanks, Mathieu

10 years, 11 months

Fwd: Trace bundles for ETMv3/v4

by Mathieu Poirier

---------- Forwarded message ---------- From: Mathieu Poirier <mathieu.poirier(a)linaro.org> Date: 3 November 2015 at 11:48 Subject: Trace bundles for ETMv3/v4 To: private-opencsd <private-opencsd(a)linaro.org> After a programming marathon I am please to bring you trace bundles for both ETMv3[1] and v4[2]. The code is based on the latest development branch[3], something that seemed like a good idea to avoid maintaining two different tree. It certainly served the purpose but other problems inherent to that approach have also showed up - more on that later. Since the ETMv4 has more metadata (as per Mike's enclosed document[4]) I had to modify the AUX_TRACE header format. The new format can be found here [5], with the assignment of the slots described here [6]. The end result is that ETMv3 headers will have zero'ed out slots, something I can't avoid since the auxiliary area foundation assumes a fix amount of data for all tracers. It's not my ideal solution but we can always try to change the world when things are actually working. The perf.data file found in both bundles have been generated using this command: $ perf record -vvv -e cs_etm// --per-thread uname As such the amount of traces should be relatively small. In the bundles you will also find the .debug directory, the perf.data file and a medata.txt file. The latter is simply a snapshot of the relevant registers as listed in Mike's document[4]. The snapshot was taken *after* the trace run and only there to *somewhat* make sense of how things were configured, which brings us to the problems I've hinted about earlier. Contrary to V1 and V2 the newest code base is configuring tracers as the event is scheduled rather than at initialisation time, making the metadata in the perf.data completely irrelevant. I will likely have a solution for that so hang tight, it's coming. Please have a look and we'll touch base in the meeting tomorrow. Regards, Mathieu [1]. uname.etmv3.tgz [2]. uname.etmv4.tgz [3]. https://git.linaro.org/people/mathieu.poirier/coresight.git/shortlog/refs/h… [4]. RefTrcDecode-API and Components_0v3.pdf [5]. https://git.linaro.org/people/mathieu.poirier/coresight.git/blob/refs/heads… [6]. https://git.linaro.org/people/mathieu.poirier/coresight.git/blob/refs/heads…

10 years, 11 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight