TDA4VM: Flash Uboot at ospi and run on ospi

Hi，
Any Suggestions for this?

Thanks,
Eason

Hi,

Are there any Ti experts who can help with this issue?

Thanks,
Eason

HI,

Any suggestions here? 

Thanks,
Eason

Hello Eason

    so do you want to run SBL in SRAM and u-boot in OSPI flash， right?

Regards

   Semon

Hi, Semon

That's it!

Thanks,
Eason

Hi,Semon

Any suggestions here? 

Thanks,
Eason

eason zhou said:

Any suggestions here?

hI Eason

     I am checking this, and is asking BU to give suggestion

Regards

   Semon

Hi, Semon

I truly appreciate you.

Best Regards,
Eason

Hi，Semon

On the basis of the above question, I would like to add another question:
Uboot runs in ospi (xip) and needs to load the kernel and file system stored in emmc.
Is there any documentation on this?

Best Regards,
Eason

Hi Semon

Thank you very much for your reply.
I have to ask again, do I still need atf_optee? How do I compile it if necessary?

Because I use this startup method：

1. How should I compile combined dev.appimage? (atf+optee+a72 spl) and flash it to where on ospi?

2. After enabling CONFIG_SPL_XIP_SUPPORT, do I still need to modify the uboot link file? What address of ospi should the compiled uboot.img be written to?

3. What code does sbl need to modify to start combined_dev.appiamge? I did not see the relevant code in sbl_main.c

Best regards,
Eason

Hi，Semon
When I enabled "CONFIG_SPL_XIP_SUPPORT=y" in "j721e_evm_a72_defconfig", a compilation error occurred:


Best regards,
Eason

eason zhou said:

When I enabled "CONFIG_SPL_XIP_SUPPORT=y" in "j721e_evm_a72_defconfig", a compilation error occurred:

Hello Eason

     you can define this MACRO in j721e_spi.h, like:

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

/* With BootMode B = 0 */
#include <linux/bitops.h>
#define BOOT_DEVICE_HYPERFLASH        0x00
#define BOOT_DEVICE_OSPI        0x01
#define BOOT_DEVICE_QSPI        0x02
#define BOOT_DEVICE_SPI            0x03
#define BOOT_DEVICE_ETHERNET        0x04
#define BOOT_DEVICE_I2C            0x06
#define BOOT_DEVICE_UART        0x07
#define BOOT_DEVICE_NOR            BOOT_DEVICE_HYPERFLASH
#define BOOT_DEVICE_XIP            BOOT_DEVICE_OSPI

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

Hi,Semon
Thank you for your answer. Now I have successfully compiled the following firmware, but it seems that the firmware is no different:

Q1：
  I still need atf_optee? How do I compile it if necessary? This is  my startup:


Q2:
   How should I compile combined dev.appimage? (atf+optee+a72 spl) and flash it to where on ospi?

Q3：
  What modifications do I need to make in sbl_main? Is there a demo?

Best Regards,
Eason

Hi， Semon

"please try to enable CONFIG_SPL_XIP_SUPPORT and re-compile u-boot"

My understanding is that in this way qspi runs XIP, and then spl initializes the ddr, and then copies uboot.img to the ddr and runs it, right?

Best Regards,
Eason

eason zhou said:

Q2:
   How should I compile combined dev.appimage? (atf+optee+a72 spl) and flash it to where on ospi?

Q3：
  What modifications do I need to make in sbl_main? Is there a demo?

Hello Eason

     ok, I will involve R&D to investigate this issue

Regards

   Semon

Hi，Semon

I have a case where SBL starts mcu1_0. Mcu1_0 is also running on ospi (xip) and has been started successfully. The following is the startup diagram:

Boot flow:

1, Tibooot3.bin running in ocmc.
2, SBL copy "Dummy app 1"  in ocmc,and run "Dummy app 1"
3, "Dummy app 1" jump to 0x501c0000m where  store mcu1_0 app.

So I think for the A72 core, if I want uboot to run in ospi (xip), can also do this：

(ATF+OPTEE+SPL) = combined_dev.appimage which  SBL can boot image format.

1, SBL copy combined_dev.appimage in A72 sram(or ram)
2, combined_dev.appimage running and Init DDR（for linux_kernel no for uboot） and  A72 system initialization.
3, combined_dev.appimage jump to  the starting address of uboot.bin stored in ospi.
4, uboot running and boot linux_kernel from emmc.

Best Regards,
Eason

eason zhou said:

SBL copy combined_dev.appimage in A72 sram(or ram)
2, combined_dev.appimage running and Init DDR（for linux_kernel no for uboot） and  A72 system initialization.
3, combined_dev.appimage jump to  the starting address of uboot.bin stored in ospi.
4, uboot running and boot linux_kernel from emmc.

Hello Eason

     BU confirm that TI has never verified u-boot in XIP mode, if needed, there should be a new feature, 

     could you explain why you need u-boot to run in XIP, in fact SPL already run in SRAM, and load u-boot to DDR to run

     is there any special requriement?

  Regards

      Semon

Hi,Semon

Thank you for Reply.

The reason why I want uboot xip to run is a long story.

We want mcu1_0 to send out the first frame of can message within less than 100ms （[50, 100)ms） from power on, but the code of our mcu1_0 exceeds 1M, so the can_early_responce demo is not suitable for our project.（Because can_early_responce demo is all run in ocmc, but ocmc is only 1M, and ocmc needs to be shared with mcu1_0 app, sbl, and rom code.）

In SBL, the time to initialize DDR exceeds 30ms, this TI expert has confirmed.

So in order to avoid the need to initialize DDR and reduce the code running address of SBL copy mcu1_0, I designed the xip running of mcu1_0 based on the demo in the sdk, and it has been successful.

In the default SDK, uboot and linux_kernel runs in ddr, so before uboot and linux_kernel starts, ddr must be initialized. This conflicts with not initializing ddr in sbl.

Later, I found the second way to start HLOS in the document, as shown in the red box in the figure below：


This is similar to can_boot_app demo, but we don’t want to add code to start other cores in mcu1_0, but put all the startup processes in sbl, so we don’t choose this option either. 

In the end, there is only one way. I want uboot to run directly in ospi (xip) and delay the initialization of DDR (in SPL or uboot), but the ddr needs to be initialized before linux_kernel is run.

So if I can not initialize DDR in sbl, and let uboot run on ospi (xip), and initialize ddr in uboot before starting linux_kernel to run, all the above problems can be solved.

Or uboot may not run in ospi (no xip required), but combined_dev.appimage can initialize ddr before starting uboot, and then copy uboot from the startup address (ospi) to the running address (ddr). In this way all the above problems will also be solved.

Or are there any other solutions that TI experts can provide?


Best Regards

Eason