• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 501 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

CCS/AM5728: SBL project build issues

RTOS/AM5718: Best practise for double booting

Stefan Thorlacius
Intellectual 570 points
Part Number: AM5718

Tool/software: TI-RTOS

We have a custom board that is equipped with a

SD card 

eMMC (NAND flash)  16GB

NOR Flash 512 Mb (64Mx8)

USB

 

The normal boot order will most likely be USB->SD->eMMC

 

Our ambition is to have it this way

First an RTOS based program (hereafter “RTOS program”) is executed (on the A15) to perform various tests of peripherals, such as RTC, EEPROM, DDR3 (this mean it must be executed in OCMC ram internal in the SoC) this program will then start a Linux kernel.

This RTOS program also do Board_Init to set up the custom board we have.

Is there a way to concatenate an RTOS program with the linux core and in the RTOS program to call some magic function call, to start the Linux core?

Like RTOS_Start_Bundled_LinuxCore().

 

http://processors.wiki.ti.com/images/b/b7/TDA_SBL_UserGuide.pdf

 

Only deals with how to create a bootable image, we assume, either for only a RTOS or a Linux image.

(on page 11 the path given, packages/ti/boot/sbl_auto dont exist, we assume it should be packages/ti/boot/sbl)

 

Or should the RTOS program be placed in the NOR flash?

If SYSBOOT instruct the RBL to boot from QSPI to start the RTOS program and when it is finished the RTOS program calls a function in RBL and tell it to boot from eMMC ?

 

In this way we can build an image for NOR flash for the RTOS and a eMMC image for the linux kernal ?

 

The beauty with this is that the RTOS and Linux is in no ways depending on each other and via SYSBOOT we can skip the execution of the RTOS program.

 

 

Regards

 

 

  • 0
    TI__Guru** 116170 points

    Stephan,

    The boot design that you are considering is kind of custom and not a commonly observed use case. Generally most of our customers design their boot mechanism corresponding to OS used by the application. What you are looking for needs some software customization.

    Keeping the RTOS image on NOR flash (only serial NOR flash boot is currently supported in RTOS) and Linux image on eMMC is an option if you plan to use switches for SYSBOOT pin or an external micro that can drive GPIOs into SYSBOOT input to pick between the two boot media.  This will work if you want to run only one image during one power cycle. The boot media selection sequence on these devices are designed to use alternate boot media as a back up boot media if an image is not found on a given boot media for which the chip is configured to boot from. This allows user to put back up boot images on other boot media in the boot sequence and guarantee that the product boots even if one boot media image gets corrupted in the field.

    Just to clarify. If your board has SYSBOOT hardwired to one boot sequence. For example USB-> SD->eMMC ->QSPI and you put an boot image on eMMC then the bootloader will not run the image on QSPI NOR until eMMC is erased or the image in EMMC is corrupted.

    The boot mechanism that you are looking for requires you understand the SBL in RTOS and UBoot-SPL in Linux to enable this customization. The SBL in RTOS is designed to initialize the SOC  (clock, pinmux, UART, DDR) and load the application not only for A15 but for all the other slave cores on the device. Uboot -SPL on the other hand only initializes the SOC clocks and interfaces needed to get uboot and linux kernel loaded on A15 cores. 

    In your setup you need to be able to run the SBL from OCRAM amd load the diagnostic app and SPL code (also runs from OCRAM) and then run the disgnostic code and then pass control into the entry point of SPL so the Linux boot process can eb launched. In the process you would also need to clean up the MMU setup, cache, reeet vectors on the ARM so that SPL can run from a clean state on the A15. This is is a non trivial effort.

    I have a few questions on this software design: 

    • Why do you need diagnostics to everytime you boot? 
    • Can`t you simplify this boot flow by implementing diagnostics in uboot using built in uboot drivers? there are some tests like mem_test built into uboot code.
    • Is running the diagnostic on one of the slave cores while Linux boots on A15 an option ? Even this requires customization but the effort would be lesser compared to the approach you are considering.

    Regards,

    Rahul

     

  • 0 in reply to Rahul Prabhu
    Intellectual 570 points

    The reason for this idea is that, as soon as the Linux is loaded it start to use the DD3, one of the task for the RTOS program is to test the DDR3 ram to see if it is ok, before the Linux kernal is loaded.

    Yes, it is possible for a RAM test program to test the RAM it is stored on (that is, part of the u-boot or a pure Linux program if it is loaded to the DD3) but it might be to late if the RAM is broken where the test program is stored. 

    But I guess we have to skip the RAM test and place the rest of the test code in u-boot as you mentioned.

    (and yes, the orignal idea must  assume that the internal RAM, OCMC, is Always working correct)

    Perhaps it could be an idea for next SoC. an internal flash area which is programable by the customer and is essential called like a subroutine (like the OS is calling the main function) before the RBL is doing the booting sequence as it do today.