SVDConv rejects 2GiB buffer in range 0x40000000-0xBFFFFFFF as invalid

[eperie]

Version found: 3.3.4

CMSIS-SVD peripherical definition:

<peripheral> <name>DDR_III_LPDDR_II</name> <description>DDR3/LPDDR2 address space.</description> <baseAddress>0x40000000</baseAddress> <addressBlock> <offset>0</offset> <size>0x80000000</size> <usage>buffer</usage> </addressBlock> </peripheral>

I am getting an error ERROR M380, and the following message: AddressBlock of Peripheral 'DDR_III_LPDDR_II' (@0x40000000) [0x7fffffff ... 0x00000000] does not fit into 32Bit Address Space.

Please note that I wanted to define a 2GiB buffer between 0x40000000 and 0xBFFFFFFF, but may have misused the CMSIS-SVD constructs - thanks.

[jkrech]

I confirm that this sounds like a bug in SVDConv. Regardless of that, could you please help us to understand what it is your intention of describing a buffer of this size ? It looks like an address range for an external memory interface. As we are unable to address this issue quickly, I just want to make sure that you are not blocked by this.

[eperie]

I am currently processing a text version of a datasheet for a Cortex-A7 device from a vendor not providing any software support for its IP in the form of C header files describing the SoC registers.

It happens that the vendor describes the address range for the external memory interfaces in the same section than the memory-mapped registers, and that I found interesting to keep all the information in the CMSIS-SVD-compliant file I am building from the datasheet.

I understand now that a memory element was removed in CMSIS-SVD schema 1.1, and that the \<peripherical> element is therefore not the proper place for describing such an item.

Bottom-line, this is not an issue and I will just remove the external memory interfaces from the file by hand, even though this is not fitting well with the 'automated processing' aspect of my current work. I think the memory section was a very good idea though.

I would have a closely related question for you: is ARM currently providing header files built from either CMSIS-SVD or IP-XACT files describing Cortex-Ax core registers - I was not able to find such files yet. If not, do you think ARM would consider providing them ? this will be of a great help for facilitating the ramp-up process for people learning about the Cortex-A processors, and at a very low cost for ARM since all the required information is already present in some IP-XACT files somewhere at ARM.

Thanks.

[JonatanAntoni]

Just two hints from my side:

• The memory layout of a device is described in the pack description.
• We are currently working on CMSIS for Cortex-A.

Please let us know whether this fits your needs or what we lack of.

[eperie]

Thanks you very much for those hints.

Yes, the pack description does fit the need for describing address ranges for external memory I guess.

What I would really like to see in CMSIS for Cortex-A would be descriptions for core registers similar to those used in ARM DS-5 configdb files - For exemple, definition in configdb for core register MIDR is:

<register access="RO" name="MIDR" size="4"> <gui_name language="en">Main ID</gui_name> <alias_name>CP15_MIDR</alias_name> <device_name type="rvi">CP15_MIDR</device_name> <device_name type="cadi">MIDR</device_name> <description language="en">Provides identification information for the processor, including an implementer code for the device and a device ID number</description> <bitField conditional="false" name="Implementor"> <gui_name language="en">Implementor</gui_name> <description language="en">Indicates the implementor</description> <definition>[31:24]</definition> </bitField> <bitField conditional="false" name="Variant"> <gui_name language="en">Variant</gui_name> <description language="en">Indicates the variant number, or major revision, of the processor</description> <definition>[23:20]</definition> </bitField> <bitField conditional="false" name="Architecture"> <gui_name language="en">Architecture</gui_name> <description language="en">Indicates whether the architecture is given in the feature registers</description> <definition>[19:16]</definition> </bitField> <bitField conditional="false" name="Primary_part_number"> <gui_name language="en">Primary part number</gui_name> <description language="en">Indicates the part number</description> <definition>[15:4]</definition> </bitField> <bitField conditional="false" name="Revision"> <gui_name language="en">Revision</gui_name> <description language="en">Indicates the revision number, or minor revision, of the processor</description> <definition>[3:0]</definition> </bitField> </register>

This would be easily converted by software into a CMSIS-SVD equivalent by ARM.

What is missing in the configdb description (I guess) and would be great to have in a potential CMSIS version would be the information about which coprocessor is the register located in.

In the example of MIDR, this could have be specified in an element like:

<coprocessor number="15" read=" 0, c0, c0, 0"/> - no 'write' attribute here since MIDR is read-only.

Since MIDR can be read using MRC p15, 0, <Rt>, c0, c0, 0. This would allow automatically generating code for accessing coprocessor registers.

Having definitions for ARMv8a core registers would be great as well, since they are already available in configdb files.

You obviously know better, but this is likely that dual Cortex-A53/Cortex-M systems similar to the NXP i.MX 7 solo may appear at one point, and having header files for all available core registers would be tremendously useful for developers - not mentioning they could be used right now for learning/implementation purpose on widely available, inexpensive a53 SBC boards.

The easier the ramp-up for ARM Cortex-A processors is, the better it is I guess for ARM, ARM vendors and software developers, and this is why CMSIS for Cortex-M is so great.

Does this make sense ? - thanks.

[eperie]

In the case you would find the idea interesting, but would lack bandwidth for implementing it, I forgot to mention that I would be glad to contribute a configdb-to-CMSIS-SVD 1.3.x application compliant with the open-source license of your choice for automating the core registers descriptions import process. Your current schema compiles nicely using Java JAXB.