• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 4 answers
  • Subscribers 98 subscribers
  • Views 332 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.

PROCESSOR-SDK-J784S4: Boot sequence guidance request

Jaime Jimenez
Prodigy 80 points
Part Number: PROCESSOR-SDK-J784S4

Tool/software:

Hello TI experts,

I have few questions where i would like your guidance to continue mi investigation through the correct path:

1-What is the typical boot sequence for SDK QNX? (considering for SDK RTOS is "MCUROM->SBL->App" and for SDK LINUX is MCUROM->R5SPL->A72SPL->UBOOT->LinuxKernel)

2-Could you guide me how to initialize Main Domain (lets say the A72 core) using SDK RTOS? (i already generated the SBL image and was able to bring up MCU domain, now i want to initialize the Main Domain and according to docs seems like i need another image but is not clear to me how to proceed)

3-I already found where i can declare the address for the MCU R5F application entry point, but where is the declaration of this entry point for another secondary image, lets say A72 from Main domain (related to previous question) in the SDK RTOS?

Many thanks in advance for your support!

  • 0
    TI__Guru** 111215 points

    Hi Jaime,

    Jaime Jimenez said:
    1-What is the typical boot sequence for SDK QNX? (considering for SDK RTOS is "MCUROM->SBL->App" and for SDK LINUX is MCUROM->R5SPL->A72SPL->UBOOT->LinuxKernel)

    There are lots of different boot combinations possible, and the default that we use with our QNX SDK is to use the Boot App on MCU1_0 to boot QNX and all othe toerh cores. There is no OPTEE with QNX, so the sequence is indeed MCUROM->SBL->BootApp (MCU1_0 Application)->ATF->A72 QNX.

    Jaime Jimenez said:
    2-Could you guide me how to initialize Main Domain (lets say the A72 core) using SDK RTOS? (i already generated the SBL image and was able to bring up MCU domain, now i want to initialize the Main Domain and according to docs seems like i need another image but is not clear to me how to proceed)

    The SDK comes with various build targets at the SDK top-level. Please follow the Vision Apps Build and Run Steps for QNX to run the SDK-level Vision Apps stack. You can also see the QNX SDK 3. Build Steps for some discrete QNX based steps for running specific components.

    Jaime Jimenez said:
    3-I already found where i can declare the address for the MCU R5F application entry point, but where is the declaration of this entry point for another secondary image, lets say A72 from Main domain (related to previous question) in the SDK RTOS?

    The ATF is positioned at the beginning of the MSMC RAM at 0x70000000, and the A72 boot always starts from the ATF in the Secure World. This is pre-defned in the Boot App using the macro ATF_START_RAM_ADDR at <ti-processor-sdk-rtos-j784s4-evm-09_02_01_01>/pdk_j784s4_09_02_01_22/packages/ti/boot/sbl/example/boot_app/soc/j784s4/boot_core_defs.h file, and is assigned as the entry point in BootApp_mmcsdBootStageImage or BootApp_ospiBootStageImage.

    regards

    Suman

  • 0 in reply to Suman Anna
    Prodigy 80 points

    Many thanks for the answer Suman!

    Regarding question number 2, seems like you gave me guidance but for SDK-QNX package, but i am using SDK-RTOS package, so in this case, what is the process to initialize MCU (R5F core) and MAIN domains (A72 core)? (from my research seems like having an appImage per core is enough so these will be launched by the SBL, but MCU one needs to be initialized first before the A72).

    Lets say i want to initialize/launch the MCU domain with some appImage, and in addition, i also want to initialize the MAIN domain with another appImage, then i would have 2 entry points to be declared in the SBL (one per image/core), so where are these addresses declarations done using this RTOS-SDK?

    Graphical representation of what i pretend to do and understand if its correct:

    MCUROM -> SBL -> MCU R5 AppImage -> MAIN A72 AppImage

    Appreciate the support! Slight smile

  • 0 in reply to Jaime Jimenez
    TI__Guru** 111215 points

    Hi Jaime,

    Jaime Jimenez said:
    Regarding question number 2, seems like you gave me guidance but for SDK-QNX package, but i am using SDK-RTOS package,

    The SBL Bootloader is part of the RTOS SDK package indeed, while the SPL Bootloader is part of the Linux SDK package. The QNX SDK build procedure does involve untarring the QNX PSDK tarball within the corresponding RTOS SDK installation itself.

    Jaime Jimenez said:
    what is the process to initialize MCU (R5F core) and MAIN domains (A72 core)? (from my research seems like having an appImage per core is enough so these will be launched by the SBL, but MCU one needs to be initialized first before the A72).

    The QNX SDK bootflow steps I gave above already cover all of the above steps. The Boot App (named app on the SDCard) is the MCU1_0 application firmware, which has a Boot task responsible for loading all other processors through various images, along with the main firmware tasks of the MCU1_0 application itself.

    Please see the following picture from the QNX installation that showcases the various binaries involved.

       

    The A72 QNX images are the atf_optee.appimage (A72 secure world binary) and the ifs_qnx.appimage (A72 QNX image w/ minimal ramfs).

    The other MAIN domain R5F and C7x images are part of the lateapp1 and lateapp2 files. 

    Jaime Jimenez said:
    (from my research seems like having an appImage per core is enough so these will be launched by the SBL, but MCU one needs to be initialized first before the A72).

    Correct, MCU application needs to be initialiazed, so the boot flow sequence is indeed tiboot3.bin (SBL) -> tifs.bin (TIFS) -> app (MCU1_0 Application), with the app further processing the lateapp1, lateapp2, atf_optee.appimage and ifs_qnx.appimage files.

    appImage per core is not really necessary, but the SBL BootApp can be customized as per your need. It currently deals with the various remote processor images as two multicore appImage files.

    Jaime Jimenez said:
    MCUROM -> SBL -> MCU R5 AppImage -> MAIN A72 AppImage

    This is already the standard boot flow for the QNX within the SDK.

    Please see the Boot App code in <ti-processor-sdk-rtos-j784s4-evm-10_00_00_05>/pdk_j784s4_10_00_00_27/packages/ti/boot/sbl/example/boot_app folder. 

    The corresponding documentation for the same is in 5.3. Boot App section of the PDK SBL documentation.

    regards

    Suman

  • 0 in reply to Suman Anna
    Prodigy 80 points

    Hello Anna!

    I got a little bit lost, in my case, what i want to achieve is to boot up both domains (with the simplest configuration possible): the MCU_R5F and MAIN_A72 (with their corresponding images pulled from OSPI) but only using RTOS-SDK (not LINUX-SDK nor QNX-SDK involved).

    Reading TI documentation i found there are many combinations possibles to achieve it using specifically RTOS-SDK but the 2 main methods suggested are:

    Method 1: SBL booting all MAIN domain cores (and then MCU R5 at the end)

    Method 2: SBL boots MCU R5 and this launches autosar app (and then autosars boot manager can initialize all the remaining cores in MAIN domain)

    Considering above context (please correct me if some of it is wrong) i have the following but more specific questions:

    1-Which from both Methods i mentioned above is simpler/easier to achieve and why? (please illustrate me if there is even a simpler method than those 2 you can suggest me to use)

    2-Is it possible to run a Linux image in A72 (MAIN domain) using only the RTOS-SDK (not LINUX/QNX SDK involved) or we are limited to have only a freeRTOS image in this case?

    3-Which core from MCU_R5F (core 0 or core 1) is the one that launches and executes the app image in SDK-RTOS? (as far as i have investigated is the core 0 but i just want to confirm it and understand what is the purpose of core 1 in this booting scenario)

    4-If i use the "Method 1" from above, should all the different images be in a combined imaged or can also be separated? If so, where are these individual images entry point addresses defined?

    Thanks in advance!!! Slight smile

  • 0 in reply to Jaime Jimenez
    TI__Guru** 111215 points

    Hi Jaime,

    Jaime Jimenez said:
    what i want to achieve is to boot up both domains (with the simplest configuration possible): the MCU_R5F and MAIN_A72 (with their corresponding images pulled from OSPI) but only using RTOS-SDK (not LINUX-SDK nor QNX-SDK involved).

    I am confused. You mention that you want to boot MAIN_A72, but also do not want to use Linux SDK or QNX SDK. What images are you expecting to run on A72 core? This is a HLOS core, and would be running either Linux or QNX. How do you expect to build a A72 image without either of the Linux or QNX SDK? The RTOS SDK alone will not build an image for A72.

    Jaime Jimenez said:
    i found there are many combinations possibles to achieve it using specifically RTOS-SDK but the 2 main methods suggested are:

    Correct, these are indeed the 2 main methods.

    Jaime Jimenez said:
    Method 2: SBL boots MCU R5 and this launches autosar app (and then autosars boot manager can initialize all the remaining cores in MAIN domain)

    The TI SDK does not have a true Method 2 in that we don't have an AutoSAR OS, so it is equivalent using FreeRTOS.

    Both the methods follow the simple sequence of SBL -> TIFS -> AppImage, and the differentiation really comes if the AppImage is just an image for MCU1_0 or a Multi-Core AppImage combining more than one processor firmware image.

    There is support for both in the SDK. Method 2 is the default mode used by QNX, given the requirements for the MCU Safety Core to be up as soon as possible in Automotive usecases.

    Jaime Jimenez said:
    1-Which from both Methods i mentioned above is simpler/easier to achieve and why? (please illustrate me if there is even a simpler method than those 2 you can suggest me to use)

    I am not sure how you are quantifying simpler/easier. I would say Method #1 is simpler owing to the smaller number of image files. You would have to combine the individual image files into a single MultiCore AppImage.

    Jaime Jimenez said:
    2-Is it possible to run a Linux image in A72 (MAIN domain) using only the RTOS-SDK (not LINUX/QNX SDK involved) or we are limited to have only a freeRTOS image in this case?

    Please see above. The Linux Kernel and DTB images cannot be built natively using just the RTOS SDK.

    Jaime Jimenez said:
    3-Which core from MCU_R5F (core 0 or core 1) is the one that launches and executes the app image in SDK-RTOS? (as far as i have investigated is the core 0 but i just want to confirm it and understand what is the purpose of core 1 in this booting scenario)

    MCU R5F supports LockStep (for Safety) or Split-mode (for CPU capacity) modes, and Core1 is only used with its own firmware image only in Split-mode. 

    SBL (or bootloader) always runs on Core0. The Automotive usecases run the MCU R5F in LockStep mode, as the MCU R5F is the Safety Master in the system.

    Jaime Jimenez said:
    4-If i use the "Method 1" from above, should all the different images be in a combined imaged or can also be separated? If so, where are these individual images entry point addresses defined?

    They are combined into a single AppImage. Please see the section 5.2.5. Image Formats in the PDK SBL documentation. The entry point for each core is part of the rprc header.

    regards

    Suman

  • 0 in reply to Suman Anna
    Prodigy 80 points

    Thanks for the answers Anna, seems like i was confused with some concepts among the SDK capabilities.

    I read the SDK LINUX and RTOS documentation and now i have a more clear understanding of the whole sequence.

    In addition, i found the following image from TI which provides some booting options (i drawed some red number to each square for better reference to  each option in the image):

    Where if i understand correctly:

    Question 1: The option 1 is achievable only using SDK-RTOS, option 2 is achievable using SDK-RTOS + SDK-LINUX, option 3 also requires SDK-RTOS + SDK-LINUX, and finally option 4 requires of SDK-RTOS + SDK-QNX, could you please confirm if this is right? (i d appreciate if you correct me if is not)

    My "plan" is to follow this below sequence (the final expected goal is to run LinuxKernel in MAIN_A72 and that is why i think SDK-RTOS+SDK-LINUX is enough avoiding SDK-QNX):

    MCU_ROM -> R5F SBL -> ClassicAutosarAppImg -> A72 SPL -> A72 UBOOT -> LinuxKernel

    Question 2: This sequence seems to match with the number 3 from the image, i also thought about number 2 (which is the same but removing U-BOOT) but seems to require more complexity (additional configurations to be done) to be achieved due to UBOOT removal, am i right?

    Question 3: The only point i have not been able to figure out yet even reading a lot is how i could make ClassicAutosarAppImg to launch A72 SPL, any idea? (seems like the ECUM / BSWM could do the job...)

    Question 4: Could you suggest me which option is the most recommended for my "plan" so i can choose the indicated one (even if is not in the image)?

    I hope these questions are more clear now and sorry for the previous confusion i created with messy concepts/SDKs.

    Slight smile

  • 0 in reply to Jaime Jimenez
    TI__Guru** 111215 points

    Hi Jaime,

    Jaime Jimenez said:
    I read the SDK LINUX and RTOS documentation and now i have a more clear understanding of the whole sequence.

    Yeah, most of your understanding is correct.

    Jaime Jimenez said:
    Question 1: The option 1 is achievable only using SDK-RTOS, option 2 is achievable using SDK-RTOS + SDK-LINUX, option 3 also requires SDK-RTOS + SDK-LINUX, and finally option 4 requires of SDK-RTOS + SDK-QNX, could you please confirm if this is right? (i d appreciate if you correct me if is not)

    This looks to be a slightly older slide. Anyway, A72 RTOS is no longer supported, so Option #1 is just reduced to R5F and C7x cores.

    The RTOS SDK is not required for booting (R5 SPL is part of U-Boot in Linux SDK) Linux in Option #3, but RTOS SDK is needed to build the full-fledged Vision related firmware images.

    Option #4 requires RTOS SDK + either Linux SDK or QNX SDK (and not both), depending on which is your desired HLOS.

    Jaime Jimenez said:
    MCU_ROM -> R5F SBL -> ClassicAutosarAppImg -> A72 SPL -> A72 UBOOT -> LinuxKernel

    Your plan looks ok. Where do you plan to boot the MAIN R5F and C7x cores, since they can be booted from either A72 U-Boot or Linux Kernel or your MCU1_0 Application firmware?

    Jaime Jimenez said:
    Question 2: This sequence seems to match with the number 3 from the image, i also thought about number 2 (which is the same but removing U-BOOT) but seems to require more complexity (additional configurations to be done) to be achieved due to UBOOT removal, am i right?

    This is actually Option #4. Option 3 does not use the RTOS SBL, it uses the Linux U-Boot SPL.

    Jaime Jimenez said:
    (which is the same but removing U-BOOT) but seems to require more complexity (additional configurations to be done) to be achieved due to UBOOT removal, am i right?

    Correct. This is a variation of Option #4. Option #2, Mode-1 is the R5 SBL directly booting Linux (followed by MCU R5F application), and requires you to have the final DTB and either change ATF to jump to the kernel load address, or change the address at which the Linux Image has to be loaded to match the address used by ATF. 

    Jaime Jimenez said:
    Question 3: The only point i have not been able to figure out yet even reading a lot is how i could make ClassicAutosarAppImg to launch A72 SPL, any idea? (seems like the ECUM / BSWM could do the job...)

    You need to load ATF, OPTEE and A72 SPL images from the MCU1_0 application. There should be support for this in the Boot App for Linux.

    Jaime Jimenez said:
    Question 4: Could you suggest me which option is the most recommended for my "plan" so i can choose the indicated one (even if is not in the image)?

    You are really looking at Option #4 or variants of it depending on whether you want to go through U-Boot or not for loading the kernel Image. 

    MCU_ROM -> R5F SBL -> ClassicAutosarAppImg is essentially Option #4 and, the ClassicAutosarAppImg is equivalent of the PDK BootApp from this option.

    In the end, what really matters is your product goals, and whether you need A72 SPL/U-Boot or not, and from where you want to load the other R5F and C7x firmware images. 

    regards

    Suman

  • 0 in reply to Suman Anna
    Prodigy 80 points

    Great! now everything starts to get clear to me, i had decent understanding in RTOS-SDK reading the documentation but now i am learning about LINUX-SDK (mainly HLOS) and how to use them (RTOS-SDK and LINUX -SDK) together for my final plan to develop.

    I will follow the Option #4 from the image shared in previous comment, obtaining the following sequence as the final one (i dont plan to use QNX but only RTOS-SDK + LINUX-SDK to be capable to trigger A72): 

    MCU_ROM -> R5F SBL -> ClassicAutosarAppImg -> ATF -> A72 SPL -> A72 UBOOT -> LinuxKernel

    I have some few last questions to finish this thread:

    Q1: Regarding how to initialize the MAIN_R5F and MAIN_C7x cores, i am not really sure yet since i was just focused in A72 so far, do you have any suggestion in which way is the easiest (and why) to launch them among A72-U-Boot, LinuxKernel or MCU_R5F_Autosar? In addition, when we say U-Boot can launch the other cores images, we refer to ATF, SPL or literally U-BOOT?

    Q2: I know SDK-RTOS can also generate HLOS image (this beside GP and HS), so what would be the difference (or when to use) between this HLOS image from SDK-RTOS and using SDK-LINUX which is dedicated to HLOS, [i simply dont understand why we can generate a HLOS image with SDK-RTOS if we cannot trigger A72 just using this RTOS-SDK? (I suppose this SDK-RTOS HLOS image is to generate a SBL compatible with SDK-LINUX somehow but is just an assumption)

    Q3: I read if i plan to use HLOS (is not clear if SDK-RTOS HLOS image or SDK-LINUX which i understand is for HLOS core) the image should be combined, but which image the documentation really refers to (SBL, App, LinuxImages, etc)?

    Q4: Since is clear that "A72 is a HLOS core" it means A72 cannot run bare metal apps and R5F/C7x cannot run HLOS, am i right (at least in J784S4)? 

    Q5: Is HLOS image in SDK-LINUX also signed as HS image?


    I really appreciate your support and patience, many thanks in advance for your time!!! Slight smile

  • 0 in reply to Jaime Jimenez
    TI__Guru** 111215 points

    Hi Jaime,

    Jaime Jimenez said:
    Q1: Regarding how to initialize the MAIN_R5F and MAIN_C7x cores, i am not really sure yet since i was just focused in A72 so far, do you have any suggestion in which way is the easiest (and why) to launch them among A72-U-Boot, LinuxKernel or MCU_R5F_Autosar?

    This really depends on your product needs, and boot metric requirements. The Linux kernel can also boot the MAIN R5Fs and C7x firmwares as part of the kernel boot if you do not want to do anything (easiest approach). The Linux kernel can do a fallback boot if they were not booted earlier. The only thing that is not allowed is that the MCU R5F trying to load these after it has launched A72 (otherwise it would be a race condition between A72 U-Boot/Linux and the MCU1_0 firmware).

    Jaime Jimenez said:
    In addition, when we say U-Boot can launch the other cores images, we refer to ATF, SPL or literally U-BOOT?

    None of them. I meant the MAIN R5F and C7x processors. The Linux A72 boot sequence has ATF as the first component, followed by A72 SPL and then A72 U-Boot.

    Jaime Jimenez said:
    I know SDK-RTOS can also generate HLOS image (this beside GP and HS), so what would be the difference (or when to use) between this HLOS image from SDK-RTOS and using SDK-LINUX which is dedicated to HLOS

    RTOS can only generate a SBL bootable image (in appimage format) given a pre-built HLOS Image. The current RTOS SDK build steps leverage a pre-built boot and rootfs tarballs as part of generating the corresponding appImages. The bootloader image files and formats are different between RTOS SBL and Linux SPL. The image formats generated by Linux SDK are only natively supported by the full Linux SPL/U-Boot flow.

    The A72 Linux Images are only generated through the Linux SDK.

    Jaime Jimenez said:
    [i simply dont understand why we can generate a HLOS image with SDK-RTOS if we cannot trigger A72 just using this RTOS-SDK?

    The RTOS SDK builds firmware images that are running an RTOS, namely R5F and C7x processors. The SDK itself doesn't contain the HLOS (that's where the Linux and QNX SDKs come into picture).

    Jaime Jimenez said:
    (I suppose this SDK-RTOS HLOS image is to generate a SBL compatible with SDK-LINUX somehow but is just an assumption)

    Yes, correct.

    Jaime Jimenez said:
    Q3: I read if i plan to use HLOS (is not clear if SDK-RTOS HLOS image or SDK-LINUX which i understand is for HLOS core) the image should be combined, but which image the documentation really refers to (SBL, App, LinuxImages, etc)?

    I suggest you follow the Vision Apps Build and Run Steps for Linux to begin on the TI EVM to understand the overall flow.

    Jaime Jimenez said:
    Q4: Since is clear that "A72 is a HLOS core" it means A72 cannot run bare metal apps and R5F/C7x cannot run HLOS, am i right (at least in J784S4)?

    Yes, correct. A72 can technically run bare-metal applications, but TI doesn't support it. Similarly, we don't have Linux or QNX OS on R5F or C7x. This is true for all TDA4/J7 devices.

    Jaime Jimenez said:
    Q5: Is HLOS image in SDK-LINUX also signed as HS image?

    This is not really associated with HLOS, but the device type.

    The image build procedure is the same. The images for a HS device requires that the images be signed, as they will be authenticated during their boot. 

    regards

    Suman