• State
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 3 replies
  • Subscribers 102 subscribers
  • Views 208 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SK-AM62B-P1: [YOCTO] [SDK_9.02.01.09] Main domain I2C0 does not work when M4 binary is loaded by linux

LEE INJAE
Intellectual 370 points
Part Number: SK-AM62B-P1

Tool/software:

Dear TI.

I changed "ipc_rpmsg_echo_linux_am62x-sk_m4fss0-0_freertos_ti-arm-clang" to test below fuction.

- M4 binary is loaded when Linux is boot-up

- Communicate between Linux and M4 via IPC (Make some IPC message routine for test purpose)

- M4 uses main domain I2C0 to verify if M4 can use main domain peripheral.

First, I disabled main_i2c0 in device tree, so /dev/i2c0 is not 20000000.i2c, but 20020000.i2c like below.

root@am62xx-evm:/sys/devices/platform/bus@f0000# ls -al /dev/i2c*
crw------- 1 root root 89, 0 May 31 06:18 /dev/i2c-0

root@am62xx-evm:/sys/devices/platform/bus@f0000# ls -al
total 0
drwxr-xr-x 47 root root 0 Apr 28 2022 .
drwxr-xr-x 31 root root 0 Apr 28 2022 ..
drwxr-xr-x 8 root root 0 Apr 28 2022 100000.syscon
drwxr-xr-x 4 root root 0 Apr 28 2022 20020000.i2c

And I moved I2C from MCU_I2C0 to MAIN_I2C0 in CCS syscfg of "i2c_read_am62x-sk_m4fss0-0_nortos_ti-arm-clang" example. it worked OK.

And I merged this change to "ipc_rpmsg_echo_linux_am62x-sk_m4fss0-0_freertos_ti-arm-clang" for loading M4 binary by Linux and to use IPC.

When I load M4 binary after Linux is boot-up by below command. it worked as I expected.

- Make the  symbolic link the generated binary with /lib/firmware/am62-mcu-m4f0_0-fw

---------------------------------------------------------

echo stop > /sys/class/remoteproc/remoteproc0/state

sleep 2

echo start > /sys/class/remoteproc/remoteproc0/state

---------------------------------------------------------

-  When I send IPC message to M4, it could read EEPROM successfully. (I tested it over 100 times and it worked correctly every time)

The problem was happened when M4 binary was loaded by Linux during boot-up time.

When I send same IPC message to M4, it showed below error messages in M4 console.

ERROR: i2c_read_error_handler:158: 

After this problem happening, If I load M4 binary again manually, it works again.

Could you check if there's anything suspicious ?

BR

Jace

  • 0
    TI__Guru* 93335 points

    Hello Jace,

    Interesting. From the Linux side, I would not expect the remoteproc driver to behave differently when initializing a remote core during Linux boot time as opposed to during Linux runtime. Typically if I see issues, it's because the MCU+ core is not waiting for the Linux driver to initialize the RPMsg VIRTIO infrastructure - but if Linux is the one initializing communication in your design, that would not be an issue.

    I am sending your thread to another team member to comment on the I2C driver error and what it could be telling us.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Mastermind 37818 points

    Hello Jace,

    As Nick mentioned earlier, the issue might be coming because the MCU+ core is not waiting for the Linux driver to initialize the RPMsg VIRTIO infrastructure. 

    Can you please check before sending the IPC messages, Is RPMessage_waitForLinuxReady() API being called by application?

    Please refer below image.

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Intellectual 370 points

    Hello Tushar.

    I added codes based on "ipc_rpmsg_echo_linux_am62x-sk_m4fss0-0_freertos_ti-arm-clang"

    When Linux boot-up, M4 console displays below log.

    [IPC RPMSG ECHO] Version: REL.MCUSDK.09.02.00.38+ (May 31 2024 16:06:36):
    [IPC RPMSG ECHO] Remote Core waiting for messages at end point 13 ... !!!
    [IPC RPMSG ECHO] Remote Core waiting for messages at end point 14 ... !!!

    In the source code, there is "RPMessage_waitForLinuxReady" at ipc_rpmsg_echo_main()

    As far as I checked, logs are displayed like below sequence.

    [IPC RPMSG ECHO] Version: REL.MCUSDK.09.02.00.38+ (May 31 2024 16:06:36):

    --> RPMessage_waitForLinuxReady is called at ipc_rpmsg_echo_main()

    --> Two receive tasks(ipc_recv_task_main) are created.

    --> ipc_recv_task_main starts and displays below log
    [IPC RPMSG ECHO] Remote Core waiting for messages at end point 13 ... !!!
    [IPC RPMSG ECHO] Remote Core waiting for messages at end point 14 ... !!!

    I always send test IPC message after these logs.

    So RPMessage_waitForLinuxReady is called before test IPC message is sent.

    BR

    Jace