On Thu, Aug 8, 2024 at 6:30 PM Octavian Purdila <ta...@google.com> wrote:
> On Thu, Aug 8, 2024 at 2:56 PM John Snow <js...@redhat.com> wrote:
> >
> >
> >
> > On Mon, Aug 5, 2024 at 4:17 PM Octavian Purdila <ta...@google.com>
> wrote:
> >>
> >> From: Stefan Stanacar <stefa...@google.com>
> >>
> >> From: Stefan Stanacar <stefa...@google.com>
> >>
> >> The CMSIS System View Description format(CMSIS-SVD) is an XML based
> >> description of Arm Cortex-M microcontrollers provided and maintained
> >> by sillicon vendors. It includes details such as peripherals registers
> >> (down to bitfields), peripheral register block addresses, reset
> >> values, etc.
> >>
> >> This script uses this information to create header files that makes it
> >> easier to emulate peripherals.
> >>
> >> The script can be used to create either peripheral specific headers or
> >> board / system specific information. The script generated headers are
> >> similar to the SVDConv utility.
> >>
> >> Peripheral specific headers contains information such as register
> >> layout, register names and reset values for registers:
> >>
> >> typedef struct {
> >> ...
> >> union {
> >> uint32_t PSELID; /* 0x00000FF8 Peripheral Select and
> >> * Flexcomm module ID */
> >> struct {
> >> uint32_t PERSEL : 3; /* [2..0] Peripheral Select */
> >> uint32_t LOCK : 1; /* [3..3] Lock the peripheral
> select */
> >> uint32_t USARTPRESENT : 1; /* [4..4] USART present indicator */
> >> uint32_t SPIPRESENT : 1; /* [5..5] SPI present indicator */
> >> uint32_t I2CPRESENT : 1; /* [6..6] I2C present indicator */
> >> uint32_t I2SPRESENT : 1; /* [7..7] I2S Present */
> >> uint32_t : 4;
> >> uint32_t ID : 20; /* [31..12] Flexcomm ID */
> >> } PSELID_b;
> >> };
> >> ...
> >> } FLEXCOMM_Type; /* Size = 4096 (0x1000) */
> >>
> >> #define FLEXCOMM_PSELID_PERSEL_Pos (0UL)
> >> #define FLEXCOMM_PSELID_PERSEL_Msk (0x7UL)
> >> #define FLEXCOMM_PSELID_LOCK_Pos (3UL)
> >> #define FLEXCOMM_PSELID_LOCK_Msk (0x8UL)
> >> ...
> >>
> >> typedef enum { /* FLEXCOMM_PSELID_LOCK */
> >> /* Peripheral select can be changed by software. */
> >> FLEXCOMM_PSELID_LOCK_UNLOCKED = 0,
> >> /* Peripheral select is locked and cannot be changed until this
> >> * Flexcomm module or the entire device is reset. */
> >> FLEXCOMM_PSELID_LOCK_LOCKED = 1,
> >> } FLEXCOMM_PSELID_LOCK_Enum;
> >> ...
> >>
> >> #define FLEXCOMM_REGISTER_NAMES_ARRAY(_name) \
> >> const char *_name[sizeof(FLEXCOMM_Type)] = { \
> >> [4088 ... 4091] = "PSELID", \
> >> [4092 ... 4095] = "PID", \
> >> }
> >>
> >> Board specific headers contains information about peripheral base
> >> register addresses.
> >>
> >> Signed-off-by: Stefan Stanacar <stefa...@google.com>
> >> Signed-off-by: Octavian Purdila <ta...@google.com>
> >> ---
> >> configure | 2 +-
> >> meson.build | 4 +
> >> python/setup.cfg | 1 +
> >> python/tests/minreqs.txt | 3 +
> >> pythondeps.toml | 3 +
> >> scripts/svd-gen-header.py | 342 ++++++++++++++++++++++++++++++++++++++
> >> 6 files changed, 354 insertions(+), 1 deletion(-)
> >> create mode 100755 scripts/svd-gen-header.py
> >>
> >> diff --git a/configure b/configure
> >> index 5ad1674ca5..811bfa5d54 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -956,7 +956,7 @@ mkvenv="$python
> ${source_path}/python/scripts/mkvenv.py"
> >> # Finish preparing the virtual environment using vendored .whl files
> >>
> >> $mkvenv ensuregroup --dir "${source_path}/python/wheels" \
> >> - ${source_path}/pythondeps.toml meson || exit 1
> >> + ${source_path}/pythondeps.toml meson svd-gen-header || exit 1
> >
>
> Hi John,
>
> Thanks for reviewing!
>
:)
>
> >
> > I haven't read the rest of this series; I'm chiming in solely from the
> build/python maintainer angle. Do we *always* need pysvd, no matter how
> QEMU was configured? Adding it to the meson line here is a very big hammer.
> >
>
> I think the minimum we can do is to install it only if CONFIG_ARM is
> enabled. That might change in the future if the models we create with
> pysvd are enabled for other architectures.
>
OK, Understood. I will see if Paolo has any thoughts on this; I am
admittedly a little hesitant to add only our 2nd unconditional python
dependency. For context, meson is our first and only such dependency and
Paolo has been very active in development of that project as well; this
would be the first that none of us have any connection with. If the project
were to ever update in such a way that it became not pure-python or
required additional dependencies, the challenges in vendoring it might
cause unscheduled future headaches.
We can always pin to/vendor versions that suit our needs, but it may be
worth sending the developer an email to ask what his policies on
dependencies are, if only to let him know he might have a user out there
that's hedging on it remaining pure python and dep-free, as a courtesy.
(For my money, personally: it's probably fine; but very possibly any
boards/devices/models you add that require it *might* wind up needing a
configure flag that add this dependency, like --enable-svd-devices or
something of the sort. I'll let Paolo comment on that, don't take my word
as gospel - I handle the Python more than I do the build system; you
managed to find the precise intersection of the two.)
>
> > If not, consider looking at how sphinx (the "docs" group) is only
> conditionally installed into the configure venv and mimic that using the
> appropriate configure flags that necessitate the availability of pyvsd for
> the QEMU build.
>
> Thanks for the pointer, I'll take a look.
>
> >
> > We also need to provide a way for pysvd to be available offline; some
> packages are available via distro libs and if this package is available for
> every distro we officially support, that's sufficient (but requires updates
> to our various docker and VM test configuration files to add the new
> dependency). Otherwise, like we do for meson, we need to vendor the wheel
> in the tree so offline tarball builds will continue to work.
> >
> > It looks like pysvd is a pure python package with no dependencies, so it
> should be OK to vendor it in qemu.git/python/wheels/ - look at
> qemu.git/python/scripts/vendor.py and consider updating and running this
> script.
>
> Thanks, I'll look at it and add it in v2.
>
Thanks! Sorry this area of the build system is so persnickety. If you run
into troubles please reach out. I've also pinged Paolo to take a look as
the build system "SME" in case there's something I overlooked, too.
Good luck! :)
~js
>
> >
> > (The real blocker here is that RPM builds are performed offline and
> dependencies that cannot be satisfied via rpm can't be added through pip.
> We need any one of these to be true: (A) pyvsd is available (of a
> sufficient version) in all distro repositories we target; (B) This build
> feature is conditional and nobody minds if it never gets enabled for RPM
> builds; (C) The package can be vendored.)
> >
> > ~~js
> >
> > That said, you might be the first person I've seen outside of Paolo and
> I to brave mucking around with the python build venv. You deserve a bravery
> sticker :)
> >
> >>
>
[...]
