Re: [RFC PATCH 04/23] hw/arm: add SVD file for NXP i.MX RT595

[Octavian Purdila <tavip@google.com>]

On Wed, Aug 7, 2024 at 4:24 AM Philippe Mathieu-Daudé <philmd@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.bennee@linaro.org> wrote:
> >>
> >> Octavian Purdila <tavip@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 <tavip@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.
>