SVD files : missing the core peripherals

[Jegeva]

Hello,

multiple vendors (keil, ST, etc...) refuse to include the core peripherals in theirs SVDs, claiming that it is arm's job (see https://github.com/posborne/cmsis-svd/issues/28) even arm relying on keil's (https://github.com/ARM-software/CMSIS_5/issues/48).

The old cmsis's svd had the core peripheral and on CMSIS_5 the commit removing them claims it was "cleaning" (commit 9d12a19aaaccd07e943f5a5cf30cdca5bf8200d5), i can understand it for the header files but not really for the SVDs (well being SVDs they should describe the core peripherals for the cores because that's what SVDs are for).

Not having machine parse-able sources for this very (pun intended) core data is extremely annoying.

[JonatanAntoni]

Hi @Jegeva,

the root cause for this forth and back is basically that SVD isn't designed with a modular approach. Today every device has exactly one single SVD file associated that describes all the peripherals. The core peripherals are ignored. Most tools cope with the core stuff in a hard coded way.

It should be possible to come up with SVD files covering the default core peripherals. We need to keep these definitions separate from the SVD templates in Device/ARM/SVD.

Cheers, Jonatan

[Jegeva]

@JonatanAntoni

Hi Jonatan,

Yes, i understand the non modular nature of the SVDs but :

• the current state of 'things' is that the core peripherals should be in the vendors svds but are not.
• the nature of the SVDs and logic should actually point towards the core periphs. being in the SVDs for the core ( if you look at the content of the core SVDs, without the periphs., they seem to only indicate that 0->0xffffffff is RW... so their usefullness is limited to say the least...)

from my point of view, i see multiple cases where that can be beneficial

• softcores (not my use case really but i can see this helping some people)
• header generation for chips where the svd is incomplete (yes, maybe not the core target of SVDs but at least it is one use for them besides 'yes, the 32bits address space exists')
• code analysis tools
• etc.

If there could be something somewhere where they could be available to soften the 'hard coding' of these in tools that would be great :) (on a side note, 'tools usually hardcode that' looks more for an argument in favor for inclusion than against it to be honest) It is possible to apply some git to get the old ones with the peripherals but for 35P and 55 which is sad.

sincerely

jg

[JonatanAntoni]

Hi @Jegeva,

the situation is a bit more complicated than that.

Silicon vendors use the SVD files (together with SVDConv utility) to generate device header files. The core peripherals must not be (re)defined in device specific header files because these are already part of the generic CMSIS-Core headers.

The SVD files contained in this repo (Device/ARM/SVD) are "empty" templates. As its supposed to be used as a starting point by Silicon vendors we should not add the core peripherals into these files. Otherwise it might happen that we get a redefinition for core peripherals.

The actual register set of core peripherals in Cortex-M controllers is not too big. Hence is should not be a big deal to put together separate SVD files for those (35P and 55 share major parts).

Cheers, Jonatan

[Jegeva]

@JonatanAntoni

Jonatan, would it be possible to add something like Device/ARM/SVD_full with the complete SVDs in there ?

• That shouldn't mess with vendors toolset while allowing people with less resources at hand to parse them easily (for ex. w/ https://github.com/posborne/cmsis-svd).
• Everything should be available at ARM already no ?

[JonatanAntoni]

Hi @Jegeva,

As discussed earlier, e.g. in #48, we don't maintain SVD files for core peripherals (as part of CMSIS or in Arm). And even the template SVD's in earlier version didn't contain all the core peripherals. One would need to spent the time to put this together, e.g. from the TRM's or the core headers.

I agree, we could put the SVDs somewhere in this repo. But perhaps its more reasonable to keep them next to cmsis-svd. I confirm that keeping this separately would not create a mess. But it might be confusing because most tools cannot cope with multiple SVD files at the same time (for a single device). So in order to actually make use of separate core SVDs you need proper support in the tools as well.

Cheers, Jonatan

[Jegeva]

@JonatanAntoni

Well it's a shame, maybe you have some machine parseable data that describe them in another format that SVD that i could use to publish these svds ? It seems really backwards in 2020, especially in the light of SVD existing as a format, not to have this for a platform as pervasive as as ARM.

[Jegeva]

@JonatanAntoni

hummm... apparently ARM does maintain full fledged SVDs in the CMSDK (they are integrated in keil's BSP packs pointed by reinhard keil in #46 that is available publicly on their repo on Azure and the licence headers in the files are ARM's). Would it be possible to integrate in a SVD_full (or such) directory in the CMSIS ? That'd be great :)

[JonatanAntoni]

Hi @Jegeva,

the files you are talking about are device specific for MPS2. The described peripherals are MPS2 ones, not the core ones. I doubt these files aren't actually what you are looking for. I am sorry, we do not maintain something suitable and there are no plans to do so.

Cheers, Jonatan

[flit]

@JonatanAntoni

Fwiw and afaik, the cmsis-svd project is no longer being maintained. (I've copied the SVD parsing code into pyocd so there is no dependency on cmsis-svd, which will pull in gigabytes of SVD files. At some point I'd like to improve the parser. It's quite slow, and the resulting objects could be easier to use.)

Storing core peripheral SVDs in the CMSIS_5 repo makes more sense to me. And yes, most tools cannot handle multiple SVD files right now. But to a large extent that is because there is no need to. If standard core peripheral SVD files were made available in CMSIS, then tools would have a reason to support multiple SVD files. We have to start somewhere to make progress.

Also, the problem with not wanting core peripherals in device SVDs because of header generation can be solved relatively easily. We can add an attribute to the top level XML elements for core peripherals that identify them as such. Then SVDConv can avoid generating output for peripherals with that attribute.

[ilg-ul]

Many years ago, when I visited Keil/Arm in Germany, we discussed the issue of system peripherals and the conclusion was that Arm should define separate SVD files with their definitions. As far as I can tell, it never happened.

I'd still prefer the solution with two separate files, one defined by the vendor and one defined by Arm.

I am aware that this solution requires some help from the tools developers, and I'm ready to update the GNU MCU Eclipse debugger to input the names of the two files.

The other solution, to ask all vendors to include the common definitions, is unrealistic, I guess all of them generate the xmls with some automated tools and changing something in the process is kind of mission impossible.

[flit]

@ilg-ul You're right, many silicon partners have their own in-house tools for generating header files from data. Often the same tool generates the SVD as well.

Glad to hear you're ready to update GME to address this. That's highly motivating to really address this, at least for me. 😄

[Jegeva]

i think it is relatively easy keep all sides happy either : Sol1: by having the cpu elements in the svd definition accepting a "derivedfrom style" pointing to an arm provided set of core peripherals (but the possibility of breaking vendors toolsets)

or

Sol2: by having a separate 'SVD_full' directory in the CMSIS where parsers can find the definition of the core peripherals, delegating the responsability of integrating the peripherals to the tool implementors (based on the series attribute of the cpu element ,winkwinknudgenudge to solution 1), leaving the vendor tooling alone.

To be honest, even tho a lot of the tools are getting around the issue by hardcoding the core peripherals (and we all know how good hardcoding things is), there if a plethora of tool developers (gcc, kvasir, any rtos, etc.) whose life would be really eased by this.

[JonatanAntoni]

@Jegeva, Basically we should already have something like a "derived-from style" in place. Each SVD file has a <cpu> section. The given name is used to include the correct core_<name>.h header file from CMSIS-Core.

@all, We could discuss about adding core_<name>.svd files to ./CMSIS/Core/SVD next to the include folder. Ultimately, someone needs to spent the effort putting together those core SVD files. Volunteers welcome.

Unfortunately, there are currently no means to add those to the pack description. Thus tools would need to look up those files either manually or by naming convention (i.e. relative to core_<name>.h). Does this make sense to you?

Cheers, Jonatan

[ilg-ul]

adding core_<name>.svd files to ./CMSIS/Core/SVD next to the include folder

That would be a first step forward.

there are currently no means to add those to the pack description ... naming convention

There aren't many such files, so a naming convention might be enough for start.

@JonatanAntoni, Can you make a more detailed proposal on how the file name can be derived from the existing definitions, and what would be the actual files in the CMSIS/Core/SVD folder?

[JonatanAntoni]

Hi @ilg-ul,

As an example for the new Cortex-M55, we could add ./CMSIS/Core/SVD/core_cm55.svd. This SVD file can describe all the "core peripherals" encoded in ./CMSIS/Core/Include/core_cm55.h. A tool that is aware of the location of the actually used core header file (core_cm55.h) can deduce the location of the according SVD file (core_cm55.svd).

Same applies to all other core headers we have today.

Cheers, Jonatan

[ilg-ul]

Sorry if my questions are stupid (I did not use CMSIS recently), but is there any variable in the definition of a Cortex-M55 device that explicitly says 'cm55'?

If so, then I extrapolate that it should be easy to derive the SVD file name for any device.

[ilg-ul]

./CMSIS/Core/SVD/core_cm55.svd. This SVD file can describe all the "core peripherals" encoded in ./CMSIS/Core/Include/core_cm55.h

I did not check that header file, but just to be sure there is no misunderstanding, the use case I see for the new core SVD files is mainly to help debuggers that implement a peripheral registers viewer to show the system peripherals, missing in vendor SVDs.

[Jegeva]

@ilg-ul normally ? yes, cf. https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/Utilities/CMSIS-SVD.xsd => /device/cpu/name is an enumerated value

in practice? vendors not always adhere to the spec. looking at the svd corpus in cmsis svd, roughly 50% have the attribute.

[Jegeva]

@JonatanAntoni hello jonatan,

is there some data at arm that could be easily transformed ? what are the dgugs generated from ?

[JonatanAntoni]

@Jegeva, no, unfortunately we would need to assemble these SVDs manually.

[ilg-ul]

roughly 50% have the attribute.

Does your SVD validator spot this condition?

[JonatanAntoni]

@ilg-ul, SVDConv creates a warning if cpu section is missing. The cpu section has been added with SVD 1.1. For backward compatibility reasons we made it optional. Hence older SVD files might miss this section. And newer files as well if not properly checked with SVDConv because they were never used for generating the device header file.

[Jegeva]

@ilg-ul

my "highly evolved svd validator" is just a bash loop with xmllint -xpath

j=0;k=0;for i in cmsis-svd/data/*/*;do echo -n $i' ';core=`xmllint -xpath 'string(/device/cpu/name)' $i`;rev=`xmllint -xpath 'string(/device/cpu/revision)' $i`; echo $core $rev $j $k;((j=j+1));[ -z "$core$rev" ] && ((k=k+1)) || echo; done;echo "$k / $j"

-> 268/667

[ilg-ul]

You mean 268 out of 667 include the information that we could use to automatically select the Arm provided SVD with the core peripherals? Not very encouraging...

In practical terms this means that the user must manually enter the path to the core_<name>.svd file.

[Jegeva]

@ilg-ul

no, the reverse , 268 have no device/cpu/name [ -z $val ] evaluate as true if val is empty (replace with -n to see the reverse)

additionally, 23 of the 268 have the CPUID peripheral in there already, meaning you can replace the cpu/name with a derived value of the reset state of CPUID.

for your use-case (debugging, i presume over JTAG) you only need to read SCB->CPUID (AFAIK, *0xE000ED00 on all M cores) of the actual chip to get the partno. Easily deriving the core version and revision (eg. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646c/CIHCAGHH.html for the M7 core) and then voila, you know the correct SVD to fuse.

i don't think your need more than knowing that you are talking with a coresight core to do that.

[ilg-ul]

read SCB->CPUID

yes, thank you, just that this is not practical, the debugger must be configured before starting the debug session.

[Jegeva]

making some progress :

https://gist.github.com/Jegeva/cdbca5763a2a424f0fd4d8f37f6ebb8b

m0,m0p,m3,m7,m23,m33 : -core pripherals -registers w/ adresses -bit fields definitions

still missing

• the interrupts
• the coresight/TAP related registers (should that be in there anyways ?)
• M4 (since there is no online dgug, just a pdf :-1: ).
• FPU definitions for M33 (because i can't find a map with the register addresses anywhere)
• CMO definitions for the M7 (they are on the way, they documentation is articulated weirdly for them)

Scraping infocenter.arm.com makes me better understand why @JonatanAntoni was saying "we don't have plans for that", I think the documents are all actually redacted by a human and not generated uniformly, with attributes and ways to describe things varying for no reasons, sometimes between 2 registers of the same peripheral...🤷

[flit]

@ilg-ul I disagree, the debugger should actively perform discovery on the target rather than rely on a fixed configuration. That's kind of the point of CoreSight.

@JonatanAntoni Remember, we do have the data from DS; it only needs to be transformed to SVD format.

[Jegeva]

@flit

what data from DS ? is it shareable (in the end if it is in the svd it should be no ?) cause scraping infocenter is kind of annoying and very brittle...

[ilg-ul]

the debugger should actively perform discovery on the target rather than rely on a fixed configuration. That's kind of the point of CoreSight.

I generally agree, just that implementing this in the Eclipse Debug framework is not trivial.