Re: [RFC PATCH v2 00/14] hw/arm: add TI AM64x SoC and am64-virt machine

["Alex Bennée" <alex.bennee@linaro.org>]

Wadim Mueller <wafgo01@gmail.com> writes:

> Add support for the TI AM64x (Sitara AM6442) SoC and a board around it,
> ``am64-virt``. The model is complete enough to run the stock TI boot chain
> end to end:
>
>   ROM boot (tiboot3.bin) -> R5 SPL -> TF-A/OP-TEE -> U-Boot -> Linux SMP
>
> This is a resend: I posted a first RFC back in May [1] but got no feedback
> on it. Since then was the series rebased onto actual master, reworked for
> style and split into reviewable pieces, so I send it out again in the hope
> of getting some review.
>
> RFC because I would like feedback on the overall approach before polishing
> further; see the open questions at the end.
>
> [1] https://lore.kernel.org/qemu-devel/20260528211210.74266-1-wafgo01@gmail.com/
>
> What is modelled
> ================
<snip>
> Open questions
> ==============
>
>   * pc-bios/dtb/am64-virt.dtb: patch 13 checks in a generated DTB (with
>     its source) for convenience. I am not sure a machine-specific blob
>     belongs in pc-bios; happy to drop it and have the functional test
>     generate it with dtc instead, or drop the Linux-boot part of the test.
>
>   * Splitting the DMSC: hw/misc/ti-dmsc.c is large because TI-SCI is
>     large. It could be split per message class (clocks / devices /
>     processor boot / security) if reviewers prefer, at the cost of a
>     non-functional intermediate state.
>
>   * Only one of the four R5F cores is modelled. mc->max_cpus reserves
>     room for the rest. Because the SoC realizes M4F/R5F vCPUs in addition
>     to the A53s and every vCPU needs a TCG context slot inside
>     smp.max_cpus, the machine defaults to the full vCPU budget. I would
>     appreciate a better idea than the actual "fail early with an
>     explanatory message" handling when the user passes a too-small -smp.
>
>   * The register-level stubs (DDRSS in particular) fake success rather
>     than modelling the hardware. That is deliberate, but tell me if you
>     would rather see them as plain unimplemented-device windows plus
>     firmware quirks elsewhere.

I would add one more which is who is committing to maintain this model
if it is merged?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro