• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 99 subscribers
  • Views 458 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-AM64X: Questions about AM64 boot process

Hirotaka Matsumoto
Guru 27585 points
Part Number: PROCESSOR-SDK-AM64X
Other Parts Discussed in Thread: UNIFLASH

Hi all

I have some questions about AM64x boot process.
I am developing using MCU+SDK 8.6.0.


<Question 1>
Using uart_uniflash.py and boot/sbl_prebuilt/am64x-evm/default_sbl_null.cfg, I think my PC transports sbl_prebuilt/am64x-evm/sbl_uart_uniflash.release.hs_fs.tiimage in first step.
Also I think this image operates in AM64 as write next image to flash.
Does this image(sbl_uart_uniflash.release.hs_fs.tiimage) deploy and operate in AM64's internal RAM? Or external DDR4 memory?

<Question 2>
In case of this K3 archtecture boot flow, does SBL correspond to tiboot3.bin, SYSFW, and tispl.bin?
https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_06_00_42/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html#boot-flow


<Question 3>
Does the SBL include DMSC software not only R5F software?


<Question 4>
In case of .appimage code (not XiP image), when does memcopy process(copy Flash to RAM) operate in boot flow?


Kind regards,

Hirotaka Matsumoto

  • +1
    TI__Guru 69061 points

    Hello Hirotaka-san,

    1/ 

    Hirotaka Matsumoto said:
    Does this image(sbl_uart_uniflash.release.hs_fs.tiimage) deploy and operate in AM64's internal RAM? Or external DDR4 memory?

    We can look at the sbl_uart_uniflash example's Linker Command (linker.cmd) file to know the memory regions used by the example. The example's linker.cmd file is located at the path <MCU+ SDK PATH>/examples/boot/sbl_uart_uniflash/am64x-evm/r5fss0-0_nortos/ti-arm-clang. In this file, the memory regions are defined in the section called MEMORY and they are as follows:

    MEMORY
{
    R5F_VECS : ORIGIN = 0x00000000 , LENGTH = 0x00000040
    R5F_TCMA : ORIGIN = 0x00000040 , LENGTH = 0x00007FC0
    R5F_TCMB0: ORIGIN = 0x41010000 , LENGTH = 0x00008000
    MSRAM_VECS: ORIGIN = 0x70000000 , LENGTH = 0x100
    MSRAM_0  : ORIGIN = 0x70000100 , LENGTH = 0x80000 - 0x100
    MSRAM_1  : ORIGIN = 0x70080000 , LENGTH = 0x18000
    DDR      : ORIGIN = 0x80000000 , LENGTH = 0x800000
}

    Out of these defined memory regions, only the MSRAM_VECS, MSRAM_0, MSRAM_1 & DDR are used. The first three of these are the first two banks of MSRAM and contains all the code and data of the application except the buffer used to hold the image data received over the UART. This buffer is stored in the DDR.

    2/ 

    Hirotaka Matsumoto said:
    In case of this K3 archtecture boot flow, does SBL correspond to tiboot3.bin, SYSFW, and tispl.bin?

    No, the SBL only corresponds upto the R5F ROM boot step. The tispl.bin is a PSDK specific boot binary. More specifically, all the steps after R5F ROM are PSDK specific boot steps.

    3/ 

    Hirotaka Matsumoto said:
    Does the SBL include DMSC software not only R5F software?

    Yes, the SBL (.tiimage) is a ROM combined bootable image which packages R5F software, DMSC software & Board Configuration data.

    4/ 

    Hirotaka Matsumoto said:
    In case of .appimage code (not XiP image), when does memcopy process(copy Flash to RAM) operate in boot flow?

    This step comes after the ROM boots the SBL. Once the SBL boots, the SBL parses the .appimage and loads the exectuables for different cores. At the end, it resets all the required cores and the applications starts running.

    Regards,

    Prashant