From: Wadim Mueller <wafgo01@gmail.com>
To: Bin Meng <bmeng.cn@gmail.com>
Cc: qemu-devel@nongnu.org, qemu-arm@nongnu.org,
"Peter Maydell" <peter.maydell@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@mailo.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Fabiano Rosas" <farosas@suse.de>
Subject: Re: [RFC PATCH v2 00/14] hw/arm: add TI AM64x SoC and am64-virt machine
Date: Sat, 22 Aug 2026 23:13:17 +0200 [thread overview]
Message-ID: <87ld9xj1ua.fsf@gmail.com> (raw)
In-Reply-To: <CAEUhbmXSy7LfbkJeQcjEyOPQ_6WAYsqOdHR4ZHzkSJ7H6kOLJQ@mail.gmail.com>
On 2026-08-22 13:22, Bin Meng wrote:
> Hi Wadim,
>
> On Thu, Aug 20, 2026 at 8:48 PM Wadim Mueller <wafgo01@gmail.com> wrote:
>>
>> 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:
>
> Should the machine be named as something that matches an existing
> board from TI, instead of `am64-virt`, which makes me think it's just
> something we created just for emulation purpose?
>
Yeah, the name is misleading, and it also undersells what is
there.
The SoC side is not really virt-like: it is the real AM64x memory map,
GICv3 at the silicon addresses, the real UART / I2C / timer /
secure-proxy offsets, and it boots stock unmodified vendor firmware
through the complete chain ROM -> R5 SPL -> TF-A/OP-TEE -> U-Boot ->
Linux.
What I did not mention in the cover letter is that my development tree
already models the board identity as well: an M24C32 at i3c address 0x50,
preloaded with a valid PHYTEC api-v2 identity blob
with the correct size and CRC so that
mainline u-boot's accepts it. This is what the vendor
U-Boot reads to detect the SoM. I left it out of v2 because I was not
sure if board specific identity data is wanted upstream, but I think
now this was the wrong decision, because it is exactly the proof that
this is a board model and not something synthetic.
So IMHO the options are:
a) am64-phycore, which matches the phyCORE-AM64x SoM that I boot and
test every day, and the identity EEPROM moves from the SoC model
into the board file, where it belongs anyway
b) am64-evm or am64-sk, after TMDS64GPEVM or SK-AM64B, which means
doing the board identity again against TI's EEPROM format and
getting that firmware
I would prefer a), because this is the configuration I have hardware
for and which I can keep testing for regressions, so the maintenance
story is realistic.
One caveat: not every peripheral is modelled. CPSW
is only an unimplemented-device stub and there is no ethernet node in
the DT. For booting this does not matter, because the whole chain runs
from SD/eMMC, but a machine with a board name should probably document
what is there and what is not. docs/system/arm/am64.rst does this
already, and in v3 I will make the name and the documented scope match.
So my question back: does a non-TI board around the SoC (a SoM from
PHYTEC) fulfill your "matches an existing board", or would you rather
see a TI branded one?
Best regards,
Wadim
>>
>> 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
>> ================
>>
>> The SoC is heterogeneous, and the model reflects that: a Cortex-A53
>> cluster behind a GICv3 (GIC-500) at the real addresses, the Cortex-R5F
>> MCU boot core, and the Cortex-M4F, each with their own RAT (region
>> address translation) view of the memory map.
>>
>> The interesting part is the DMSC. On real silicon it is a hidden core
>> running TI's system firmware (SYSFW) which answers TI-SCI requests for
>> clocks, power, firewalls and processor boot control from every other core.
>> Rather than trying to execute the vendor blob, patch 10 models the DMSC
>> as a TI-SCI endpoint sitting on top of the secure proxy model (patch 9).
>> That is what actually starts the A53 and M4F cores when the R5 SPL asks
>> for it, and what TF-A, OP-TEE, U-Boot and Linux talk to for clock/power
>> management.
>>
>> The remaining devices (patches 4-8) are the supporting cast: the UART,
>> the K3 DMTimer, mailboxes, and register-level stubs for CTRL_MMR
>> (including the DEVSTAT boot pins), GTC, DDRSS, the SDHCI PHY wrapper and
>> the TRNG. The
>> stubs implement the handshakes, which firmware polls for, not the
>> underlying hardware.
>>
>> Patches 1-3 are prerequisites that touch existing code:
>>
>> 1-2 give the OMAP I2C model its own Kconfig symbol so it can be reused
>> outside the OMAP1 SoC, and implement soft reset and NACK reporting
>> 3 fixes SDHCI ADMA chain processing; without it, transfer rate
>> depends from the virtual clock instead of on the guest's
>> programming. Patch 14 contains a qtest that fails without it.
>>
>> To patch 3: it is only needed as long as Bin Meng's SDHCI series [2] (on
>> top of the SDMA boundary fix [3]) is not merged. I posted the same fix
>> standalone in August, Bin showed then, that his series already covers
>> the AM64x case, and I have withdrawn it there [4]. It is kept here only
>> so that this series works on actual master - please drop patch 3
>> together with the pacing qtest in patch 14 as soon as [2] lands. A
>> version of that qtest for the Icicle Kit was posted separately [5].
>>
>> [2] https://patchwork.ozlabs.org/project/qemu-devel/list/?series=515264
>> [3] https://patchwork.ozlabs.org/project/qemu-devel/list/?series=513930
>> [4] https://lore.kernel.org/qemu-devel/20260810124519.34501-1-wafgo01@gmail.com/
>> [5] https://lore.kernel.org/qemu-devel/20260813123210.28987-1-wafgo01@gmail.com/
>>
>> Testing
>> =======
>>
>> Patch 14 adds:
>>
>> * a unit test for the combined-boot-image parser
>> * qtests for the machine topology, GICv3 layout, SMP handling and the
>> DMSC TI-SCI request/response path
>> * an I2C qtest (soft reset, NACK, and a read from an at24c EEPROM which
>> the test attaches with -device)
>> * the SDHCI ADMA pacing reproducer
>> * a functional test that builds a synthetic tiboot3.bin containing a
>> bare-metal R5 payload and checks it runs from the certified entry
>> point. Setting QEMU_TEST_TIBOOT3 boots a real image instead.
>>
>> Migration is not supported yet: none of the new devices has a VMState.
>> I left it out for the RFC, but can add it if you want it before merge.
>>
>> The series was built and tested on top of ae4f344320. Every patch builds
>> on its own, and checkpatch reports no errors.
>>
>> 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.
>>
>> Wadim Mueller (14):
>> hw/i2c/omap_i2c: add a dedicated CONFIG_OMAP_I2C symbol
>> hw/i2c/omap_i2c: implement soft reset and NACK reporting
>> hw/sd/sdhci: complete non-interrupt ADMA descriptor chains in one pass
>> hw/char: add TI AM64x UART model
>> hw/timer: add TI K3 DMTimer model
>> hw/misc: add TI K3 CTRL_MMR, GTC, DDRSS, SDHCI PHY and TRNG models
>> hw/misc: add TI RAT (region address translation) model
>> hw/misc: add TI mailbox (IPC) model
>> hw/misc: add TI K3 secure proxy model
>> hw/misc: add TI DMSC (TI-SCI system controller) model
>> hw/arm: add TI K3 combined boot image parser
>> hw/arm: add TI AM64x SoC model
>> hw/arm: add the am64-virt machine
>> tests: add AM64x unit, qtest and functional tests
>>
>> MAINTAINERS | 22 +
>> docs/system/arm/am64.rst | 74 +
>> docs/system/target-arm.rst | 1 +
>> hw/arm/Kconfig | 26 +
>> hw/arm/am64-virt.c | 347 ++++
>> hw/arm/k3-bootrom-parse.c | 250 +++
>> hw/arm/k3-bootrom.c | 125 ++
>> hw/arm/meson.build | 4 +
>> hw/arm/ti-am64x.c | 1223 ++++++++++++
>> hw/arm/trace-events | 4 +
>> hw/char/Kconfig | 4 +
>> hw/char/meson.build | 1 +
>> hw/char/ti-am64-uart.c | 109 ++
>> hw/i2c/Kconfig | 4 +
>> hw/i2c/meson.build | 2 +-
>> hw/i2c/omap_i2c.c | 234 ++-
>> hw/misc/Kconfig | 27 +
>> hw/misc/meson.build | 10 +
>> hw/misc/ti-dmsc.c | 1725 +++++++++++++++++
>> hw/misc/ti-k3-ctrlmmr.c | 103 +
>> hw/misc/ti-k3-ddrss.c | 98 +
>> hw/misc/ti-k3-gtc.c | 100 +
>> hw/misc/ti-k3-sdhci-phy.c | 91 +
>> hw/misc/ti-k3-trng.c | 139 ++
>> hw/misc/ti-mailbox.c | 566 ++++++
>> hw/misc/ti-rat.c | 290 +++
>> hw/misc/ti-sec-proxy.c | 446 +++++
>> hw/misc/trace-events | 62 +
>> hw/sd/sdhci-internal.h | 9 +
>> hw/sd/sdhci.c | 23 +-
>> hw/timer/Kconfig | 3 +
>> hw/timer/meson.build | 1 +
>> hw/timer/ti-k3-dmtimer.c | 177 ++
>> include/hw/arm/k3-bootrom.h | 43 +
>> include/hw/arm/ti-am64x.h | 86 +
>> include/hw/char/ti-am64-uart.h | 28 +
>> include/hw/misc/ti-dmsc.h | 661 +++++++
>> include/hw/misc/ti-k3-ctrlmmr.h | 26 +
>> include/hw/misc/ti-k3-ddrss.h | 26 +
>> include/hw/misc/ti-k3-gtc.h | 23 +
>> include/hw/misc/ti-k3-sdhci-phy.h | 26 +
>> include/hw/misc/ti-k3-trng.h | 35 +
>> include/hw/misc/ti-mailbox.h | 44 +
>> include/hw/misc/ti-rat.h | 51 +
>> include/hw/misc/ti-sec-proxy.h | 108 ++
>> include/hw/timer/ti-k3-dmtimer.h | 30 +
>> pc-bios/dtb/am64-virt.dtb | Bin 0 -> 6116 bytes
>> pc-bios/dtb/am64-virt.dts | 292 +++
>> tests/functional/aarch64/meson.build | 2 +
>> tests/functional/aarch64/test_am64_bootrom.py | 137 ++
>> tests/qtest/am64-adma-pacing-test.c | 243 +++
>> tests/qtest/am64-virt-test.c | 502 +++++
>> tests/qtest/meson.build | 1 +
>> tests/qtest/ti-am64-i2c-test.c | 137 ++
>> tests/unit/meson.build | 1 +
>> tests/unit/test-k3-bootrom.c | 263 +++
>> 56 files changed, 9060 insertions(+), 5 deletions(-)
>> create mode 100644 docs/system/arm/am64.rst
>> create mode 100644 hw/arm/am64-virt.c
>> create mode 100644 hw/arm/k3-bootrom-parse.c
>> create mode 100644 hw/arm/k3-bootrom.c
>> create mode 100644 hw/arm/ti-am64x.c
>> create mode 100644 hw/char/ti-am64-uart.c
>> create mode 100644 hw/misc/ti-dmsc.c
>> create mode 100644 hw/misc/ti-k3-ctrlmmr.c
>> create mode 100644 hw/misc/ti-k3-ddrss.c
>> create mode 100644 hw/misc/ti-k3-gtc.c
>> create mode 100644 hw/misc/ti-k3-sdhci-phy.c
>> create mode 100644 hw/misc/ti-k3-trng.c
>> create mode 100644 hw/misc/ti-mailbox.c
>> create mode 100644 hw/misc/ti-rat.c
>> create mode 100644 hw/misc/ti-sec-proxy.c
>> create mode 100644 hw/timer/ti-k3-dmtimer.c
>> create mode 100644 include/hw/arm/k3-bootrom.h
>> create mode 100644 include/hw/arm/ti-am64x.h
>> create mode 100644 include/hw/char/ti-am64-uart.h
>> create mode 100644 include/hw/misc/ti-dmsc.h
>> create mode 100644 include/hw/misc/ti-k3-ctrlmmr.h
>> create mode 100644 include/hw/misc/ti-k3-ddrss.h
>> create mode 100644 include/hw/misc/ti-k3-gtc.h
>> create mode 100644 include/hw/misc/ti-k3-sdhci-phy.h
>> create mode 100644 include/hw/misc/ti-k3-trng.h
>> create mode 100644 include/hw/misc/ti-mailbox.h
>> create mode 100644 include/hw/misc/ti-rat.h
>> create mode 100644 include/hw/misc/ti-sec-proxy.h
>> create mode 100644 include/hw/timer/ti-k3-dmtimer.h
>> create mode 100644 pc-bios/dtb/am64-virt.dtb
>> create mode 100644 pc-bios/dtb/am64-virt.dts
>> create mode 100644 tests/functional/aarch64/test_am64_bootrom.py
>> create mode 100644 tests/qtest/am64-adma-pacing-test.c
>> create mode 100644 tests/qtest/am64-virt-test.c
>> create mode 100644 tests/qtest/ti-am64-i2c-test.c
>> create mode 100644 tests/unit/test-k3-bootrom.c
>>
>>
>> base-commit: ae4f3443209ab154b48b706a146e5f557ab147cb
>
> Regards,
> Bin
next prev parent reply other threads:[~2026-08-22 21:14 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 12:48 [RFC PATCH v2 00/14] hw/arm: add TI AM64x SoC and am64-virt machine Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 01/14] hw/i2c/omap_i2c: add a dedicated CONFIG_OMAP_I2C symbol Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 02/14] hw/i2c/omap_i2c: implement soft reset and NACK reporting Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 03/14] hw/sd/sdhci: complete non-interrupt ADMA descriptor chains in one pass Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 04/14] hw/char: add TI AM64x UART model Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 05/14] hw/timer: add TI K3 DMTimer model Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 06/14] hw/misc: add TI K3 CTRL_MMR, GTC, DDRSS, SDHCI PHY and TRNG models Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 07/14] hw/misc: add TI RAT (region address translation) model Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 08/14] hw/misc: add TI mailbox (IPC) model Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 09/14] hw/misc: add TI K3 secure proxy model Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 10/14] hw/misc: add TI DMSC (TI-SCI system controller) model Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 11/14] hw/arm: add TI K3 combined boot image parser Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 12/14] hw/arm: add TI AM64x SoC model Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 13/14] hw/arm: add the am64-virt machine Wadim Mueller
2026-08-20 12:48 ` [RFC PATCH v2 14/14] tests: add AM64x unit, qtest and functional tests Wadim Mueller
2026-08-20 16:25 ` Alex Bennée
2026-08-22 21:04 ` Wadim Mueller
2026-08-21 10:26 ` [RFC PATCH v2 00/14] hw/arm: add TI AM64x SoC and am64-virt machine Alex Bennée
2026-08-22 21:06 ` Wadim Mueller
2026-08-21 16:35 ` Nick Huang
2026-08-22 21:07 ` Wadim Mueller
2026-08-22 5:22 ` Bin Meng
2026-08-22 21:13 ` Wadim Mueller [this message]
2026-08-24 11:51 ` Nick Huang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ld9xj1ua.fsf@gmail.com \
--to=wafgo01@gmail.com \
--cc=bmeng.cn@gmail.com \
--cc=farosas@suse.de \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@mailo.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox