Am 11. Februar 2025 10:06:19 UTC schrieb Peter Maydell
<peter.mayd...@linaro.org>:
>On Mon, 10 Feb 2025 at 22:44, Bernhard Beschow <shen...@gmail.com> wrote:
>>
>>
>>
>> Am 10. Februar 2025 17:30:01 UTC schrieb Peter Maydell
>> <peter.mayd...@linaro.org>:
>> >On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow <shen...@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 <shen...@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.
Why not support such usage model? The machine in this series works amazingly
well for our purposes. If modeling a concrete board implies hardcoding
peripherals, would modeling an artificial "board" which just contains the SoC
work instead? IOW should I drop the "-evk" suffix from the machine and claim it
only models the SoC?
>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.
Yeah, this also is how I understand the documentation of the system counter in
the reference manual.
>
>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.)
I have this implementation which puts the focus more on waking up the CPUs via
the IRQ:
<https://github.com/shentok/qemu/commit/1aa0887a5ff926572ab40b39fe5a087acb3ff249>
The IRQ fires but doesn't wake any CPU in case of direct kernel boot since the
IRQ is masked in EL1 (rich OS mode) and EL3 isn't set up.
>
>> >(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.
Yeah, this would probably work with U-Boot then. But for direct kernel boot
we'd need support beyond WFI directly in QEMU -- which is currently missing,
right?
Best regards,
Bernhard
>
>thanks
>-- PMM
