On Wed, Aug 7, 2024 at 4:24 AM Philippe Mathieu-Daudé <phi...@linaro.org> wrote: > > On 6/8/24 22:31, Octavian Purdila wrote: > > On Tue, Aug 6, 2024 at 7:06 AM Alex Bennée <alex.ben...@linaro.org> wrote: > >> > >> Octavian Purdila <ta...@google.com> writes: > >> > >>> Picked from: > >>> > >>> https://github.com/nxp-mcuxpresso/mcux-soc-svd/blob/main/MIMXRT595S/MIMXRT595S_cm33.xml > >>> > >>> NOTE: the file is truncated to keep the email size reasonable. Please > >>> use the link above and download the full file if you want to try out > >>> the patch. > >>> > >>> Signed-off-by: Octavian Purdila <ta...@google.com> > >>> --- > >>> hw/arm/svd/MIMXRT595S_cm33.xml | 224052 > >>> ++++++++++++++++++++++++++++++ > >> > >> I guess one thing we need to decide is if the source XML should live in > >> the repository as the preferred method of making changes or just the > >> translations generated by the tool. > >> > > > > I think we might want to store the XML in the qemu repo, even if we > > don't use it to generate the header files at compile time. This avoids > > issues with the original XML moving, going away, changed in > > incompatible ways, etc. > > Until now we tracked external sources with git submodules or meson > wrap files (see commit 2019cabfee) forked into our GitLab namespace > (https://gitlab.com/qemu-project/) at a particular commit, so if > the external project is modified, we aren't disturbed, or have to > adapt our source to update the submodule. Isn't it good enough? >
Yes, this should definitely work. Thanks for pointing out the wrap files, I'll give it a try. > > > > As for generating the headers at compile time, I don't have a strong > > preference. I like it because there is slightly less work to do and it > > avoids dealing with resolving changes on both the SVD and the > > generated headers. For example, the initial headers are committed, > > then some changes are done directly to the headers and then we want to > > pick up a new SVD from the vendor to support a new hardware revision. > > > > There are disadvantages as well: pysvd dependency for building qemu, > > hard to review if the vendor dumps a new version with lots of changes > > and we want to update to it for a new hardware revision, slight > > increase in build time. > > > >>> 1 file changed, 224052 insertions(+) > >>> create mode 100644 hw/arm/svd/MIMXRT595S_cm33.xml > >>> > >>> diff --git a/hw/arm/svd/MIMXRT595S_cm33.xml > >>> b/hw/arm/svd/MIMXRT595S_cm33.xml > >>> new file mode 100644 > >>> index 0000000000..8943aa3555 > >>> --- /dev/null > >>> +++ b/hw/arm/svd/MIMXRT595S_cm33.xml > >>> @@ -0,0 +1,1725 @@ > >>> +<?xml version="1.0" encoding="UTF-8"?> > >>> +<device schemaVersion="1.3" > >>> xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"; > >>> xs:noNamespaceSchemaLocation="CMSIS-SVD.xsd"> > >>> + <vendor>nxp.com</vendor> > >>> + <name>MIMXRT595S_cm33</name> > >>> + <version>1.0</version> > >>> + <description>MIMXRT595SFAWC,MIMXRT595SFFOC</description> > >>> + <licenseText> > >>> +Copyright 2016-2023 NXP > >>> +SPDX-License-Identifier: BSD-3-Clause > >>> + </licenseText> > >> > >> This certainly seems compatible. XML is not the medium I personally > >> would have chosen as a register specification language but I guess there > >> are no other alternatives? > >> > > > > I agree that the choice of XML is unfortunate but I am not aware of > > alternatives, this is what vendors will provide. >
