> -----Original Message-----
> From: Bernhard Beschow <[email protected]>
> Sent: 01 June 2026 04:22
> To: Gaurav Sharma <[email protected]>; [email protected]
> Cc: [email protected]; [email protected]
> Subject: RE: [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 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]>; qemu-
> [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?
> 

On NXP's linux-imx repo, the remoteproc is typically enabled in linux by 
default so all we need is dtb to get it working. Not sure about the buildroot 
defconfigs though.

> 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?
> 

Yes, that makes sense. 

> >
> >> 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
> >> >

Reply via email to