Re: [PATCH v2 04/18] hw/arm: Add i.MX 8M Plus EVK board

[Peter Maydell <peter.maydell@linaro.org>]

On Mon, 10 Feb 2025 at 22:44, Bernhard Beschow <shentey@gmail.com> wrote:
>
>
>
> Am 10. Februar 2025 17:30:01 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
> >On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow <shentey@gmail.com> wrote:
> >>
> >> As a first step, implement the bare minimum: CPUs, RAM, interrupt controller,
> >> serial. All other devices of the A53 memory map are represented as
> >> TYPE_UNIMPLEMENTED_DEVICE, i.e. the whole memory map is provided. This allows
> >> for running Linux without it crashing due to invalid memory accesses.
> >>
> >> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
> >> ---
> >
> >
> >
> >> --- /dev/null
> >> +++ b/docs/system/arm/imx8mp-evk.rst
> >> @@ -0,0 +1,56 @@
> >> +NXP i.MX 8M Plus Evaluation Kit (``imx8mp-evk``)
> >> +================================================
> >> +
> >> +The QEMU i.MX 8M Plus EVK board emulation is intended to emulate a plain i.MX 8M
> >> +Plus system on chip (SoC). All peripherals the real board has such as flash and
> >> +I2C devices are intended to be added via configuration, e.g. command line.
> >
> >Why do this? If they're on the real hardware board, we should
> >be creating them by default in the machine model in QEMU.
> >Command line options are for devices that are optional and
> >pluggable by the user on the hardware.
>
> My goal is to be able to model a custom, proprietary machine which runs in a CI. In order to avoid peripherals getting in the way, the idea is to have a machine which essentially exposes the plain SoC, and allow users to "decorate" it themselves. Is an EVK machine the wrong approach for this? Are there any other ways to achieve this, e.g. with -nodefaults?

That's not really a usage model QEMU currently supports. We generally
speaking model what the actual hardware does. In the same way,
if you were running CI on the real EVK board your CI would have
to deal with those devices being present.

> >> +        /*
> >> +         * Magic value from Linux output: "arch_timer: cp15 timer(s) running at
> >> +         * 8.00MHz (phys)".
> >> +         */
> >> +        object_property_set_int(OBJECT(&s->cpu[i]), "cntfrq", 8000000,
> >> +                                &error_abort);
> >
> >This is the CNTFRQ value in Hz. The datasheet actually tells you
> >this, so we don't need to call it a magic number (section 4.11.4.1.6.4
> >of the i.MX 8M Plus Applications Processor Reference Manual says the
> >base frequency of the system counter is 8MHz).
>
> Ah, so then it's the "nxp,sysctr-timer"-compatible counter in
> the device tree? I've stared my own implementation but didn't
> see the relation to the cp15 timer. Thanks for clarifying this.

Yeah; I haven't actually checked carefully whether there
are NXP specifics here, as that device-tree compat string
suggests. But it's almost certainly the same general principle:
there's a memory-mapped system counter which is the global
source of the system count, and each CPU consumes that count
and uses it to feed its generic timers and counters. So if
you mess with the enable on the memory mapped system counter
then this causes the CPU's timers/counters to stop ticking.

I modelled this similarly to the in-tree M-profile
sse-counter and sse-timer, where you link the timer to
the counter and there's an API that lets the timer know
when the counter is enabled/disabled, changes frequency, etc.
This needs changes to the timer and counter code in the CPU
itself. (You can get away without doing this if you assume
that the guest code never tries to actually disable the system
counter or pick a non-default frequency, which is typically true:
it will just want to set it up to a single standard config and
then leave it alone.)

> >(Incidentally the memory mapped system counter is a stock Arm
> >IP block and I have about 60% of a model of it, I just haven't
> >needed to upstream it yet because in practice no guest software
> >really tries to mess with it. If we turn out to need it for
> >this SoC that would be a reason for me to clean it up and
> >send it out. But I suspect we don't need it in practice.)
>
> The ugly workaround for the cpu-idle-states above is actually related to this counter, IIUC. I suppose that QEMU doesn't support these idle states, it only seems to support WFI. But if it did, then this counter would wake up the CPUs (if I'm not mistaken, I'm no expert here). It would be nice to be able to boot the machine via U-Boot, and I wonder if that could fix the idle states when there are PSCI handlers in the secure world. Again, this probably also requires the counter implementation. Looking into U-Boot, TF-A, and OP-TEE is on my plan, but right now I'm focusing on direct kernel boot.

Hmm, if the system counter can generate interrupts then
it might be different from the Arm IP block in that
respect. I'd have to check the datasheet. Anyway, as
you suggest this is all something we can postpone until
we need to care about running EL3 firmware in the guest.

thanks
-- PMM