Remoteproc with SDK v2

Duo
1

Hi everyone,

I am relatively new to Linux kernel development and am struggling to understand the underlying memory management flow between U-Boot and the Kernel. I hope someone can shed some light on this.

I am trying to enable remoteproc/rpmsg on the current SDK v2 by essentially porting the Arduino remoteproc implementation directly.

Resources Referenced:

SDK Commit: duo-buildroot-sdk(arduino)

The Issue: After applying the changes, the driver fails to probe with the following error:

cvitek-rproc c906l_rproc@0: unable to acquire memory-region
remoteproc remoteproc0: Boot failed: -22

My Analysis:
I noticed that the cvitek_remoteproc driver uses of_reserved_mem_lookup(), which generally requires the memory region to be within valid System RAM. However, the default memmap.py sets KERNEL_MEMORY_SIZE to 254MB, effectively “hiding” the FreeRTOS region (at the end of DRAM) from the Linux kernel.

I attempted to modify memmap.py to move the FreeRTOS region to the middle of the RAM (e.g., 128MB) and declared the full 256MB to the kernel (KERNEL_MEMORY_SIZE = DRAM_SIZE). However, I still encountered issues getting it to work properly.

As a kernel beginner, I am fundamentally confused about how the official implementation works:

  • Why does the original “tail-end” configuration work in the official Arduino images? If the memory is “hidden” (254MB declared vs 256MB physical), how does of_reserved_mem_lookup succeed in the official build?
  • Is there a hidden mechanism? Does the official U-Boot perform a runtime memory fixup (forcing the DTB memory node back to 256MB before booting Linux), or is there something specific I missed during the porting process that allows the driver to access this “hidden” memory?

Any insights or explanations on how this flow is supposed to work would be greatly appreciated. Thanks!

1 Like
2

I know it’s been a long time but I’ve gotten remoteproc working withe mainline Linux 7.0 kernel, and there, the set up is:

  • Linux DTS defines the full 256MB for the SoC
  • Linux DTS defines a “carve-out” reserved memory region at the last 2MB of RAM
  • Programs on the Linux side can read/write that 2MB portion, but Linux will never allocate it as general memory

The V2 SDK DTS files do set up the 2MB carve-out at the end of RAM, so I would try just giving the kernel the full 256MB in memmap.py, make no other changes, and see what happens. Moving the RTOS RAM location only in memmap.py but not also in the DTS file would be guaranteed not to work. The board DTS and memmap.py need to be in sync.