Using SAI3 pins as GPIOs in i.MX95evk

[deepshika_borundiya]

I am trying to use GPIO_IO16 and GPIO_IO26 as GPIO pins and then toggle it in my Zephyr application in M7 core. However, these pins are listed as SAI3 pins and are controlled by A55 (as per system manager's config file). How can I achieve the following:
1. Move SAI3's control/ownership from A core to M Core.
2. Change pin mux configuration from SAI3 pins to GPIO pins
3. Toggle these pins using Zephyr's elf in M Core.

iMX95

[danielchen]

Hi @deepshika_borundiya 

This involves three layers. System Manager (SM) config, pin muxing, and Zephyr GPIO driver.

step1:  Move SAI3 pins from A55 to M7 IN SM.  In the mx95evk.cfg file, those pins are currently listed as the A55 non-secure LM section as owner.

imx-sm/configs/mx95evk.cfg at master · nxp-imx/imx-sm · GitHub

We need to remove them from the A55 LM's pins list. and Add them under LM1 (M7) pins section as owner.

Then rebuild the SM firmware (imx-sm) and flash it. This ensures the TRDC and SM policies allow M7 to configure the pins.

step2 &3 , change pin mux from SAI3 to GPIO,  and toggle pins in Zephyr on M7.

I would suggest you refer to the i.MX95 EVK blinky demo.  It blinks an LED forever using the GPIO API.

https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/basic/blinky

Regards

Daniel

[deepshika_borundiya]

Hi Daniel,
I modified SM's config file and flashed the image on the board. Proceeding to the next step, I changed the pinmux configuration by changing the status of SAI3 to "disabled and I added the following lines in an overlay file:

/ {
aliases {
led0 = &user_led;
};

leds {
compatible = "gpio-leds";

/* USER LED on GPIO2 line 16 (GPIO_IO16) */
user_led: led_gpio_io16 {
gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>;
label = "USER_LED_IO16";
/* NOTE: gpio-leds child nodes do NOT allow pinctrl-* properties */
};
};
};


/* Prevent GPIO1 (0x47400000) from probing on M7 */
&gpio1 {
status = "disabled";
};


/* Apply pin mux directly to the GPIO controller using the IOMUXC pin node */
&gpio2 {
status = "okay";

/* This must point to the IOMUXC pin node (numeric pinmux array),
* NOT to a pinctrl "group".
*/
pinmux = <&iomuxc_gpio_io16_gpio_io_bit_gpio2_io_bit16>;
};

/* Optional: keep SAI3 out of the way */
&sai3 {
status = "disabled";
/delete-property/ pinctrl-0;
/delete-property/ pinctrl-names;
};

However, M7 is unable to execute gpio_pin_configure_dt api.
Can you please help me debug this?

[danielchen]

Hi @deepshika_borundiya 

I would suggest you

1.  check the return value of gpio_pin_configure_dt (&led, GPIO_OUTPUT_ACTIVE), 

int ret = gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE);
if (ret < 0) {
    printk("Failed to configure GPIO: %d\n", ret);
}

 Then you can know which error , please refer to Zephyr API 

Zephyr API Documentation: GPIO

2. check whether GPIO device is ready.

Check device_is_ready before calling gpio_pin_configure_dt()

if (!device_is_ready(led.port)) {
    printk("GPIO device not ready\n");
    return;
}

If it fails, it means the GPIO is not initialized properly.

Next we will check why GPIO initialized fail.

[deepshika_borundiya]

Hi @danielchen, I have already added these statements to my main.c and established that my device is ready. Initially I encountered -ENOTSUP for gpio_pin_configure_dt(). However, I added gpio-reserved-ranges to my overlay file to debug that error. Moving forward, I encountered:

*** Booting Zephyr OS build v4.1.0-3508-g8b1f06af052f ***
Entered Main Function
[00:00:00.006,000] <err> os: ***** BUS FAULT *****
[00:00:00.012,000] <err> os: Precise data bus error
[00:00:00.018,000] <err> os: BFAR Address: 0x443c0254
[00:00:00.024,000] <err> os: r0/a1: 0x00000001 r1/a2: 0x200003a9 r2/a3: 0x00000000
[00:00:00.032,000] <err> os: r3/a4: 0x443c0000 r12/ip: 0x00001eb9 r14/lr: 0x0000071d
[00:00:00.041,000] <err> os: xpsr: 0x01000000
[00:00:00.046,000] <err> os: Faulting instruction address (r15/pc): 0x00000732
[00:00:00.054,000] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:00.062,000] <err> os: Current thread: 0x20000198 (unknown)
[00:00:00.069,000] <err> os: Halting system

Which indicates to lack access to IOMUX. I have moved IOMUXC from M33 to M7 in SM config of imx-system manager and reflashed the image but that's not helping.

[danielchen]

Hi @deepshika_borundiya 

Is it possible to send your device tree for Linux and Zephyr and mx95evk.cfg file to me for reproduce this issue?   

[deepshika_borundiya]

Hi @danielchen ,
I have attached Linux dts (imx95-19x19-evk.dts), Zephyr's dts (generated after building the project), and m95evk.cfg (.cfg files are not supported hence uploaded as a .txt document). 

[danielchen]

Hi deepshika:

The IOMUXC and IOMUXC_GPR should be left in M33, they are owned by CM33 and managed by the System Manager.  M7 can call it via SCMI interface.

[deepshika_borundiya]

Hi @danielchen

While exploring, I figured that I'll have to enable access to IOMUX (while IOMUX remains under M55) via SCMI and TRDC. To do so, I'll have to modify config_scmi.h and config_trdc.h. However, config_trdc.h consists of PAC values and I am unable to traceback which hexadecimal value is assigned to which Domain's Resource: To put it otherwise, I am unable to identify GPIO2's PAC value for M7 Domain. If you could help me with that, I'll enable read and write access of GPIO2 to IOMUX for M7 Domain. You can find these files in configs/mx95evk/

[danielchen]

Hi @deepshika_borundiya 

In the system manager side, the following two lines need to be commented out in the current place:

#PIN_GPIO_IO16 OWNER
#PIN_GPIO_IO26 OWNER

And add to M7 section:

PIN_GPIO_IO14 OWNER
PIN_GPIO_IO15 OWNER
#add the following two lines after IO15
PIN_GPIO_IO16 OWNER
PIN_GPIO_IO26 OWNER

This will assign these two pins to M7 and allow M7 to configure the corresponding pin control registers.

In the zephyr source code, these two pins can be used as GPIO.
Since the pins are muxed, the same procedure for the pinctrl must be followed to configure as GPIO.

This is the high level description. If U-boot or Linux is currently using these two pins, they can be disabled from the device tree.

[deepshika_borundiya]

Hi @danielchen ,
I have moved PIN_GPIO_IO16 and GPIO2 itself from A55 NS to M7. I have also enabled SCMI permissions related to these. They can be verified in the modified files attached to this post. However, I am yet to enable hardware access to IOMUX and other permissions via TRDC. Can you please guide me to how can I traceback TRDC PAC values for GPIO2, IOMUX, etc. and enable them for M7. 

[danielchen]

Hi  @deepshika_borundiya 

Thanks for your update.   For TRDC, please make the following changes to mx95evk.cfg.

#=================================================================#
# M7 EENV #
#=================================================================#

LM1 name="M7", rpc=scmi, boot=2, skip=1, did=4, safe=seenv

Under # API

Add:

PERLPI_GPIO2 ALL

Under #Resources

Add

GPIO2 OWNER

This should configure TRDC to allow M7 to access GPIO2. I think we should keep GPIO2 in AP section since GPIO2 are still used there for other pins.

[deepshika_borundiya]

Hi @danielchen,

As reflected in the mx95evk.cfg file and A55's dts file shared before, I have already made these changes, while keeping IOMUX ownership with M33. As far as I know, I will have to modify config_scmi.h and trdc_h. I am attaching the latest modified configuration files. Please let me know how can I retrace trdc pac values to their resources.

[danielchen]

Hi @deepshika_borundiya , could you please share with me how you test it,  do you test it with i.mx EVK or your custom board?

[deepshika_borundiya]

Hi @danielchen ,
I am using imx95evk board (lpddr5 19x19). I am using an Oscilloscope to probe resistor 1075 to check voltage level (as per schematic).

[danielchen]

Hi @deepshika_borundiya 

can you  execute 'err' on the SM console to check for any trdc related errors

[deepshika_borundiya]

Hi @danielchen ,

I ran err command and it pointed out the exact MBC memory block of IOMUX that I had to permit in AON (TRDC_A). However, on adding IOMUX access to AP-S and regenerating headers, 0x10650u is not reflecting changes in 4th bit. I am attaching the image of SM for your reference. Please let me know the next step.