A core SDK version :6.1.55
M core SDK version:2.14
The first test:using flash.bin(make by make SOC=iMX9 flash_singleboot_m33) to start both A and M cores,then M core cannot control the GPIO(Test using M-core GPIO routine),However, other peripherals such as the SPI IIC work properly
The secord:using flash.bin(make by make SOC=iMX9 flash_singleboot) to start A cores,start M kernel using elf link file,then The M core can control GPIO normally
The third:In the uboot phase, load the firmware for gpio control (.bin format) to m33 and run m33 to control gpio normally
The above test methods are based on IMX93-EVK test,Do you have the general idea and solution of the positioning problem? Thank you
#IMX9352
已解决! 转到解答。
Hi @ChumingYang
You are correct.
If yes, what can be judged by ATF module initialization success
-->You can try to read GPIO_BASE + 0x10/0x14/0x18/0x1c status.
The first test:using flash.bin(make by make SOC=iMX9 flash_singleboot_m33) to start both A and M cores,then M core cannot control the GPIO(Test using M-core GPIO routine),However, other peripherals such as the SPI IIC work properly
--> The difference between test1 and test2&3 is that, test1 will load M33 firmware before loading A55 firmware. Please check your M-core GPIO routine rules, the current M-core GPIO routine you use may need load A55 firmware before M33 core.
I've confirmed your point by adding a 5 second delay to the M-core GPIO routine(before RGPIO_PININIT)
By reading the RM, I suspect that GPIO control in the M core is required after the initialization of the ATF security module in the A core is complete,Is this correct? If yes, what can be judged by ATF module initialization success
Hi @ChumingYang
You are correct.
If yes, what can be judged by ATF module initialization success
-->You can try to read GPIO_BASE + 0x10/0x14/0x18/0x1c status.
Thank you very much. I will continue to test in this direction. In addition, I am also very interested in the following questions