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

On 2026-08-21 11:26, Alex Bennée wrote:

> Wadim Mueller <[email protected]> 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/[email protected]/
>>
>> 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?
>

That would be me. The series already adds a MAINTAINERS entry with
S: Maintained. In v3 I will make the F: patterns narrower, because
hw/misc/ti-*.c currently claims every future TI misc device and not
only the K3 ones.

I develop and test firmware on
real AM64x silicon (a phyCORE-AM64x SoM), and I use this model every
day for this work, so I have both the hardware and the vendor boot
chain here to reproduce regressions. I also intend to review patches
which touch these files.

The testing side of the same question I have answered in the thread of
patch 14, where you raised it.

Best regards,
Wadim

> -- 
> Alex Bennée
> Virtualisation Tech Lead @ Linaro