Hello.
At present, we are developing I.MX9596 chip, and have built the development environment of MCUXPresson for VSCode, which can compile M7 core normally. But how to load M7 core in uboot phase?
We get a method, but we don't know how to implement it: To load M7 images in the Uboot phase, you need to compile System manager(M33) with imx95evkrpmsg. Copy your generated M7 image to the Boot (FAT32) partition of SD/eMMC. You can use this command in the Uboot phase.
Hi @Zhiming_Liu
We don't have the source code of FRDM to compile, can you provide the compiled image from your side, I will test it on the board.
Thank you!
Tried both EVK and my own boards, same phenomenon, and since we don't have the source code for the EVK boards, we are using the mirrors you provided. Is it related to this
EVK:
Can you send me the M33 image from your side for testing?
Hi @HL_G
I'm using the imx-boot-variant-rpmsg-imx95-19x19-lpddr5-evk-sd.bin-flash_lpboot_sm_a55 inside the L6.12.49 demo image, and it's loadable. Are you currently using an EVK or a board you made yourself? If EVK, what is the exact model number?
Best Regards,
Zhiming
Hi @Zhiming_Liu
That's what's being used.
mkimg compile command make SOC=iMX95 flash_a55 LPDDR_TYPE=lpddr4x OEI=YES
In addition to imx-sm using mx95evkrpmsg, flash_lpboot_sm_a55 is required for imx-mkimage .
We didn't build the yocto environment, we compiled it manually using imx-sm, imx-mkimage.
IMXBOOT_VARIANT= "rpmsg "What changes are made in the source code behind the options corresponding to these two.
Thanks!
Just compile imx-boot separately, with bitbake imx-boot, it's fast.
Hi @HL_G
You add IMXBOOT_VARIANT= "rpmsg " to yocto's local.conf and try it with the following imx-boot.
Best Regards,
Zhiming
Best Regards,
HL_G
Hi @HL_G
Is it the same error loading the .bin
Best Regards,
Zhiming
In imx-sm there is the imx95evkrpmsg related configuration.
Currently compiled the M33 core program according to this, and do not let the M33 start M7, the M7 bin file and elf file to the SD/eMMC Boot (FAT32) partition, the back is loaded in the uboot stage, the execution of the second step of the reboot error.
Hi @Zhiming_Liu
An error occurs when loading the M7 core, as shown below:
After the error, core A restarted, and M7 did not print information.
Hi @HL_G
Specific steps in uboot:
To compile the M7 image into imx-boot for power-on booting, refer to the imx-mkimage section of the documentation
https://www.nxp.com/docs/en/user-guide/UG10163.pdf
There is no imx95evkrpmsg related configuration in imx-sm though .
https://github.com/nxp-imx/imx-sm/tree/master
Best Regards,
Zhiming
Hi @HL_G
This board and the corresponding yocto are still in beta, no official release, I can't test it at the moment. This rpmsg variant corresponds to mx95evkrpmsg for imx-sm, and lpboot_sm_a55 for imx-mkimage. check again to see if these two .bin's are actually updated in.
https://github.com/nxp-imx/meta-imx/blob/walnascar-6.12.49-2.2.0/meta-imx-bsp/conf/machine/include/i...
Best Regards,
Zhiming
Hello @Zhiming_Liu
Testing on our own board, imx-mkimg compiled make SOC=iMX95 LPDDR_TYPE=lpddr4x OEI=YES flash_lpboot_sm_a55 results in the following image:
imx-mkimg compile make SOC=iMX95 LPDDR_TYPE=lpddr4x OEI=YES The result of flash_lpboot_sm_all is shown below:
All other firmware is the same and it fails to load and reboot is just uboot rebooting itself, M33 is normal, suspect that uboot is accessing points that it is not allowed to access, is there any method or suggestion about this?
Thank you!
Hi @HL_G
fatload actually loads the firmware to the address 0x90000000, try another address like 0x90100000. also you look at the real value of the variable $loadaddr.
Best Regards,
Zhiming