Am 27. Mai 2026 17:34:33 UTC schrieb Gaurav Sharma <[email protected]>:
>
>
>> -----Original Message-----
>> From: Bernhard Beschow <[email protected]>
>> Sent: 27 May 2026 02:56
>> To: Gaurav Sharma <[email protected]>; [email protected]
>> Cc: [email protected]; [email protected]
>> Subject: [EXT] Re: [PATCHv1 0/7] hw/arm: Adding Cortex-M7 Asymmetric
>> Multiprocessing boot support for i.MX8MP
>>
>> Caution: This is an external email. Please take care when clicking links or
>> opening attachments. When in doubt, report the message using the 'Report
>> this email' button
>>
>>
>> Am 19. Mai 2026 17:56:28 UTC schrieb Gaurav Sharma
>> <[email protected]>:
>> >Changes in v1:
>> >
>> >This series adds Asymmetric Multiprocessing (AMP) boot support for the
>> >Cortex-M7 core on the i.MX8MP SoC. The M7 firmware can be loaded and
>> >started from Linux running on the Cortex-A53 cores via the remoteproc
>> >framework.
>> >
>> >The series introduces the following peripheral models needed for AMP:
>> > - GPC (General Power Controller)
>> > - GPR (General Purpose Registers)
>> > - SRC (System Reset Controller) authored by Bernhard Beschow
>> ><[email protected]>
>> > - MU (Messaging Unit)
>> > - Extends the CCM with M7 clock outputs and wires into the i.MX8MP
>> >SoC
>> > - Enable Cortex-M7 boot in i.MX8MP EVK functional test
>>
>> Awesome work!
>>
>> I'd like to experiment with this series myself. Could there be some "cooking
>> recipe" in the board documentation for easy reproduction/failsafe tutorial?
>> Is
>> there perhaps some Buildroot defconfig with the appropriate support
>> enabled? Or even better: Are there any binary images that could be used in a
>> functional test in addition?
>>
>
>Hey Bernhard,
>Thanks for your feedback!
>
>There's an application note that covers this use-case (AN5317, referenced in
>the rst doc). However, the complete setup requires combining information from
>multiple sources.
>
>Requirements to exercise M7 image loading via Linux:
>
>1. RPMSG-specific device tree with M7 DDR alias - covered in AN5317
>2. Bare-metal ELF executable linked to run from DDR - requires building from
>MCUXpresso SDK
>
>Building the M7 firmware:
>
>1. Download the MCUXpresso SDK for i.MX8MP
>2. Build a DDR-linked example using the ARM GCC toolchain (e.g.,
>boards/evkmimx8mp/driver_examples/uart/polling)
>3. Copy the resulting ELF to the guest Linux filesystem
>4. Load via remoteproc as documented in the rst
>
>Currently there isn't a single official document covering the complete
>end-to-end flow. Users might need to refer two different sources at best. I
>can add concise build instructions to the rst doc itself, providing a
>self-contained reference. How does that sound?
Yes, sounds good! One way to think about it is to provide detailed instructions
for conducting a manual test for somebody who has never done this before.
>
>Regarding binary images: We can provide a pre-built test ELF for functional
>testing, though users would still need the appropriate device tree
>configuration.
I think binary images would only be needed for fully automated functional
tests. AFAIU this requires kernel support for e.g. remoteproc -- do normal
Linux distributions enable this? Then the device tree blob would need to be
patched and the M7 ELF be injected into the guest. I wonder if the functional
testing framework can do this?
Anyhow, this is juat an idea for fully automated tests which QEMU encurages. If
it is infeasible it shall not block this series.
>
>> Last but not least: Wouldn't it be useful if you became co-maintainer of the
>> imx8mp-evk? Perhaps the two sections in the MAINTAINERS file could be
>> merged.
>>
>
>Sure. I can add myself to the MAINTAINERS of imx8mp-evk, but what do you mean
>by merging the two sections in the MAINTAINERS file ?
I was thinking about merging the imx8mm and imx8mp sections in the MAINTAINERS
file, similar to the MPS2 and MPS3 family of boards. It seems that more shared
device models might evolve in the future where choosing between imx8mm and
imx8mp sections becomes awkward. Moreover, when modifying one SoC, the other
one should probably be kept in sync. Hence it might make sense to merge the
sections. What do you think?
>
>> Best regards,
>> Bernhard
>>
>> >
>> >Signed-off-by: Gaurav Sharma <[email protected]>
>> >
>> >Bernhard Beschow (1):
>> > hw/misc: Add SRC (System Reset Controller) to i.MX8MP
>> >
>> >Gaurav Sharma (6):
>> > hw/misc: Add i.MX8MP GPC (General Power Controller) IP
>> > hw/misc: Add GPR (General Purpose Register) IP to iMX8MP
>> > hw/misc: Add MU (Messaging Unit) IP to i.MX8MP device model
>> > hw/misc: Extend i.MX8MP CCM with Cortex-M7 clock outputs
>> > hw/arm: Enable Cortex-M7 AMP boot on i.MX8MP
>> > tests/functional: Enable Cortex-M7 boot in i.MX8MP EVK functional
>> >test
>> >
>> > docs/system/arm/imx8m.rst | 90 +++-
>> > hw/arm/Kconfig | 4 +
>> > hw/arm/fsl-imx8mp.c | 212 ++++++++++
>> > hw/misc/Kconfig | 12 +
>> > hw/misc/imx8mp_ccm.c | 9 +
>> > hw/misc/imx8mp_gpc.c | 124 ++++++
>> > hw/misc/imx8mp_gpr.c | 129 ++++++
>> > hw/misc/imx8mp_mu.c | 308 ++++++++++++++
>> > hw/misc/imx8mp_src.c | 431 ++++++++++++++++++++
>> > hw/misc/meson.build | 4 +
>> > hw/misc/trace-events | 5 +
>> > include/hw/arm/fsl-imx8mp.h | 29 +-
>> > include/hw/misc/imx8mp_ccm.h | 3 +
>> > include/hw/misc/imx8mp_gpc.h | 34 ++
>> > include/hw/misc/imx8mp_gpr.h | 56 +++
>> > include/hw/misc/imx8mp_mu.h | 53 +++
>> > include/hw/misc/imx8mp_src.h | 32 ++
>> > tests/functional/aarch64/test_imx8mp_evk.py | 3 +-
>> > 18 files changed, 1535 insertions(+), 3 deletions(-) create mode
>> > 100644 hw/misc/imx8mp_gpc.c create mode 100644 hw/misc/imx8mp_gpr.c
>> > create mode 100644 hw/misc/imx8mp_mu.c create mode 100644
>> > hw/misc/imx8mp_src.c create mode 100644
>> include/hw/misc/imx8mp_gpc.h
>> > create mode 100644 include/hw/misc/imx8mp_gpr.h create mode 100644
>> > include/hw/misc/imx8mp_mu.h create mode 100644
>> > include/hw/misc/imx8mp_src.h
>> >
