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!