imx8ulp peripheral data sharing between domains

[Spal_13]

Hello,

I’m trying to understand peripheral and data sharing across domains on the i.MX 8ULP, especially when one domain is in a low-power state.

From Figure 6 (i.MX 8ULP architecture diagram) in the reference manual, I understand which peripherals are associated with the Real-Time Domain (RTD) versus the Application Domain (APD). However, I’d like to confirm what is and is not possible in the following scenarios:

1) RTD access to APD peripherals during APD low-power states

Is there a supported way for the RTD to access data from APD owned peripherals if the APD is in a very low-power mode (for example, suspend-to-RAM or another low-power state)?

If this is possible, what is the recommended method (shared memory, DMA, etc)?

Are there power-mode limitations where APD peripherals become inaccessible because clocks/power are gated?

And similarly, is the reverse possible:

2) APD access to RTD peripherals while RTD is in low power

Can the APD access data from RTD owned peripherals while the RTD is in its lowest/low power states? If yes, what is the recommended approach?

3) Peripheral/data sharing between RTD and the DSP domain (within RTD)

We’re also curious how this works for the DSP domain inside the RTD:

Is peripheral/data sharing between RTD and DSP handled similarly to RTD↔APD sharing, or is it different since the DSP is within the RTD?

In Figure 6, we noticed what appears to be a missing Sx label on the connection from the DSP domain crossbar to the RTD crossbar (there is a line indicating connectivity). Is this a documentation error?

As drawn, the diagram seems to imply data can only flow RTD → DSP, not DSP → RTD, which doesn’t seem intentional. Can you confirm the correct access directionality?

4) APD access to DSP-domain data

Lastly, how does the APD access data produced by the DSP domain?

Does the APD access DSP resources through the chain of crossbars (APD → RTD → DSP), or is there a more direct/standard mechanism ?

Thank you.

[dimsu]

Hello All,

this is, indeed, an interesting topic.
1) Is it possible to use rpmsg driver? What limitations does it have (i.e. bandwidth, delays)?
2) What exact M33 firmware is needed to be run at M33 for supporting this?

At least i.MX 8ULP EVK uses I2C0 and I2C1 (RTD domain related buses) for communicating with sensors and other periphery. 

[Manuel_Salas]

Hello @Spal_13 

I hope you are doing very well.

Actually, the domains have their own peripherals and those are not shared.

Please take a look to the Figure 6. i.MX 8ULP architecture diagram of the Reference Manual:

You can see the peripherals ca not be accessed from domains that are not owners.

Taking as reference the APD:

You can see the GPIOs that the APD can access are GPIOE, GPIOF and GPIOD (GPIOD through LPAVD).

And you can confirm it in  the imx8ulp.dtsi:

Best regards,

Salas.

[meketok]

@Manuel_Salas  

Could you please explain the code here?

The u-boot is running in AP domain and accessing the RTD domain i2c0.

Both port(iomux) and the module i2c0. Why?

uboot-imx/board/freescale/imx8ulp_evk/imx8ulp_evk.c at lf-6.12.3-1.0.0 · nxp-imx/uboot-imx · GitHub

#define I2C_PAD_CTRL	(PAD_CTL_ODE)
static const iomux_cfg_t lpi2c0_pads[] = {
	IMX8ULP_PAD_PTA8__LPI2C0_SCL | MUX_PAD_CTRL(I2C_PAD_CTRL),
	IMX8ULP_PAD_PTA9__LPI2C0_SDA | MUX_PAD_CTRL(I2C_PAD_CTRL),
};

#define TPM_PAD_CTRL	(PAD_CTL_DSE)
static const iomux_cfg_t tpm0_pads[] = {
	IMX8ULP_PAD_PTA3__TPM0_CH2 | MUX_PAD_CTRL(TPM_PAD_CTRL),
};

void mipi_dsi_mux_panel(void)
{
	int ret;
	struct gpio_desc desc;

	/* It is temp solution to directly access i2c, need change to rpmsg later */

	/* enable lpi2c0 clock and iomux */
	imx8ulp_iomux_setup_multiple_pads(lpi2c0_pads, ARRAY_SIZE(lpi2c0_pads));
	writel(0xD2000000, 0x28091060);

[Manuel_Salas]

Hello @meketok 

I hope you are doing very well.

That is a great question.

You can take a look to the imx8ulp.dtsi from U-boot and see that the access to that peripheral is possible through the Per_Bridge1. 

But this is not recommended in a Linux environment because accessing an M33 peripheral from the APD (Cortex A) through a bridge creates a "side-channel." If the Cortex A crashes, it can hang the bus of the M33, defeating the purpose of hardware isolation.

Best regards,

Salas.

[dimsu]

Hi @Manuel_Salas,

Your notes may be critically important for all companies who design product with o.mx 8ulp SoC.
Basic 8ULP architecture assumes that both cores can be used collaboratively for achieving best results in terms of power efficiency.  For example, APD may go to sleep / power down mode, while RTD stays active, acquiring data from sensors, and independently saving it to a buffer. APD then may become active only when user intervention (touch, button, motion) detected.
But when you saying that the M33 bus may get hang, the serious limitation appear. Why do we need this M33 core then?  
If the such hang situations may exist, then we all together (NXP and Community) shall work on the workarounds and the "dangerous" scenarios must be described clearly.

Moreover, the imx8ulp EVK - let's say golden sample - demonstrates interactive working with RTD-connected periphery from APD:


1) We can get access to the I2C0 (RTD) bus devices:

root@imx8ulpevk:~# i2cget -f -y 0 0x60
0x00
root@imx8ulpevk:~# i2cget -f -y 0 0x6c
0xc1
root@imx8ulpevk:~# i2cget -f -y 0 0x6c 2
0x61

2) Which corresponds to the DTS:

&i2c_rpbus_0 {

    #address-cells = <1>;

    #size-cells = <0>;

    status = "okay";

    mpl3115@60 {                   // altimeter

        compatible = "fsl,mpl3115";

        reg = <0x60>;

    };

    ite_bridge: it6161@6c {       // MIPI-to-HDMI 

        compatible = "ite,it6161";

        reg = <0x6c>;

    };

};

3) Also we can see the events from pressing RTD-connected buttons SW7/8 (PTB13/12):

root@imx8ulpevk:~# evtest /dev/input/event0

Input driver version is 1.0.1

Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0

Input device name: "rpmsg-keys"

Supported events:

  Event type 0 (EV_SYN)

  Event type 1 (EV_KEY)

    Event code 114 (KEY_VOLUMEDOWN)

    Event code 115 (KEY_VOLUMEUP)

Properties:

Testing ... (interrupt to exit)

Event: time 1748573575.153335, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1

Event: time 1748573575.153335, -------------- SYN_REPORT ------------

Event: time 1748573575.332514, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0

Event: time 1748573575.332514, -------------- SYN_REPORT ------------

Event: time 1748573579.152752, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1

Event: time 1748573579.152752, -------------- SYN_REPORT ------------

Event: time 1748573579.309757, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0

Event: time 1748573579.309757, -------------- SYN_REPORT ------------

[vatevo]

Do you have the answer yet?

[seti]

I am also very interested in this issue.

1. @Spal_13 's questions are all chip-related, including questions about different possible scenarios.

2. NXP's BSP Linux is only one of many scenarios that can run on the iMX8ULP chip. It's just that NXP's software design is like that. It's just that NXP's BSP Linux doesn't do that. It's just that the application scenario for NXP BSP Linux doesn't involve that. You can't explain the chip's capabilities based on the current BSP scenarios.

3. Your interpretation of Figure 6 (i.MX 8ULP architecture diagram) is completely opposite to @meketok 's. meketok's question directly points to the opposite answer. Frankly, I currently think meketok is right, and you are wrong.

4. Please answer @meketok 's questions one by one.

[meketok]

@Manuel_Salas 

Could you explain the purple AXI buses connecting the various domains in the diagram, which you showed to @Spal_13 ?

Could you explain why RTD Peripheral Bridge 0 and Peripheral Bridge 1 appear in the A35 memory map?

Could you explain why APD Peripheral Bridge 3 and Peripheral Bridge 4 appear in the M33  memory map?

Table 2.
A35 system memory map

Table 5.
CM33 memory map