Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for different base address of the shared mem in the memory map of each core in openamp_rsc_table sample #84168

Open
iuliana-prodan opened this issue Jan 17, 2025 · 1 comment · May be fixed by #84170
Assignees
Labels
Enhancement Changes/Updates/Additions to existing features

Comments

@iuliana-prodan
Copy link
Collaborator

Is your enhancement proposal related to a problem? Please describe.

Now, in open_amp_rsc_table sample we support only the device that have the same value for physical and virtual address.
See:

  • here we get the shared memory address from dts overlay;
  • next, we use the same value for physical address here;
  • later, in the sample, we use these addresses to open an I/O region here;
    (see metal_io_init() implementation, in libmetal).

Describe the solution you'd like

We need to give both the physical and virtual address of the device, in case they are different.

So, if the 2 addresses have different values, use in dts overlay the following reg property:

		/*
		 * second value for pa register is not used,
		 * is just required by devicetree 'reg' property
		 */
		reg = <0x1bef0000 0x110000>, <0x8fef0000 0x110000>;

In openamp_rsc_table sample, will get the physical address from the second register block, in case it exists, otherwise will be the first register block, as it is now.

Here are the changes need it:

diff --git a/samples/subsys/ipc/openamp_rsc_table/src/main_remote.c b/samples/subsys/ipc/openamp_rsc_table/src/main_remote.c
index a33089e7623..132ccb3c42b 100644
--- a/samples/subsys/ipc/openamp_rsc_table/src/main_remote.c
+++ b/samples/subsys/ipc/openamp_rsc_table/src/main_remote.c
@@ -36,6 +36,10 @@ LOG_MODULE_REGISTER(openamp_rsc_table, LOG_LEVEL_DBG);
 #define SHM_START_ADDR DT_REG_ADDR(SHM_NODE)
 #define SHM_SIZE               DT_REG_SIZE(SHM_NODE)
 
+#define SHM_PHYS_START_ADDR    COND_CODE_1(DT_NUM_REGS(SHM_NODE),   \
+                               (DT_REG_ADDR(SHM_NODE)),             \
+                               (DT_REG_ADDR_BY_NAME(SHM_NODE, pa))) \
+
 #define APP_TASK_STACK_SIZE (1024)
 
 /* Add 1024 extra bytes for the TTY task stack for the "tx_buff" buffer. */
@@ -52,8 +56,7 @@ static struct k_thread thread_tty_data;
 static const struct device *const ipm_handle =
        DEVICE_DT_GET(DT_CHOSEN(zephyr_ipc));
 
-static metal_phys_addr_t shm_physmap = SHM_START_ADDR;
+static metal_phys_addr_t shm_physmap = SHM_PHYS_START_ADDR;
 static metal_phys_addr_t rsc_tab_physmap;
 
 static struct metal_io_region shm_io_data; /* shared memory */

Additional context

For all the boards that have support now for openamp_rsc_table sample there will be no changes needed.
When adding new board if the device address is different than the physical address we need to add 2 register blocks:

  • The first one is the address of the device and the size of shared memory, as before.

  • Second element is the physical address of the device. The second value for pa register is not used,
    is just required by devicetree 'reg' property.

The problem was found while trying to add support for i.MX8ULP where the physical and virtual address for DSP are different.
The endpoints for sample_client or tty were not created, because for the payload buffer the address conversion failed.

@iuliana-prodan iuliana-prodan added the Enhancement Changes/Updates/Additions to existing features label Jan 17, 2025
@iuliana-prodan iuliana-prodan self-assigned this Jan 17, 2025
@iuliana-prodan
Copy link
Collaborator Author

Here is my proposal to fix this: #84170

A use case is 8ULP support here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Changes/Updates/Additions to existing features
Projects
None yet
1 participant