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.

Linux/TDA2PXEVM: About the address of remotecores

Part Number: TDA2PXEVM

Tool/software: Linux

Hello,

1. For early boot, I don't understand why it need  a comp_addr,  why not decompress binaries from SD card to load address directly?  Also I don't understand the relationship between cma_base and load_addr in the struct rproc, that is to say, cma_base is used for what?  According to wiki from TI, the cma_base must the same with kernel DTS's cma_pool.

2. For normal boot, the remotecore's START_ADDR defined in .xs file, it is the same with remotecore's cma pool address defined in kernel DTS. That is to say, the cma pool address is load address for normal boot?

Thanks a lot

Terence

  • Hi Terence,

    1. When you early-boot, the boot partition of your boot media (the partition that contains the MLO) has binaries present in the lzop compressed format (for example dra7-ipu1-fw.xem4 is compressed to dra7-ipu1-fw.lzop). So the bootloader reads this compressed binary from the boot media and loads it to DDR. The address to which this compressed binary is loaded is comp_addr. After the compressed binary is loaded to DDR, its then decompressed to the load_addr, from where the firmware executes.

    2. Yes, your understanding is correct. In early boot case the load_addr in u-boot is the same as cma pool address in kernel DTS which is also the same address as the START_ADDR in the xs file.

    Regards
    Shravan

    Edit: The load_addr is where the decompressed binary is loaded. The address DRA7_RPROC_CMA_BASE should match the Vision-SDK resource file entry and the kernel DTB entry.

  • Hi Shravan,
    Understood. Thanks a lot for your answer.
    In early boot case, you said, 'the load_addr in u-boot is the same as cma pool address in kernel DTS which is also the same address as the START_ADDR in the xs file'.
    If so, there have a new issue. How to set the memory size for each core? Because, I find the size of the remotecores' load_addr are the same, it is defined as MAX_REMOTECORE_BIN_SIZE in ti_omap5_common.h file. In fact, we usually need different memory sizes for each core.

    On the other hand, for early boot, I don't find the EVE load address in ti_omap5_common.h file.

    Thanks
    Terence
  • Hi Shravan,
    If I can set the load address for each core myself in the ti_omap5_common.h file? Due to the default address is set to the gap of MAX_REMOTECORE_BIN_SIZE, the MAX_REMOTECORE_BIN_SIZE is 12M.

    Thanks
  • Hi Terence,

    The MAX_REMOTECORE_BIN_SIZE is the size of the lzop compressed firmware. If the lzop compressed firmware is more than 12MB, binary will not be loaded.
    This is typically not the case, since stripped, compressed firmwares are rarely greater than 6MB (Vision-SDK firmwares containing all links and use-cases are only ~3-4MB after lzop compression).
    The size of each remote-core binary after decompression is defined in board/ti/dra7xx/lateattach.c (e.g DRA7_RPROC_CMA_SIZE_IPU1 etc.)

    The EVE firmware is bootstrapped from the primary IPU core (the EVE firmware is embedded as part of the IPU firmware image), so u-boot loads primary IPU, which inturn loads EVE. So there is no entry needed in u-boot. You only need a reserved entry in kernel to prevent overwrite by kernel (and late-attach of EVE timers).

    Regards
    Shravan

  • Hi Shravan,
    Understood. Thanks a lot for your reply.
    It may be a different version of your SDK. We used the visionSDK 03 05. There is no board/ti/dra7xx/lateattach.h file. The DRA7_RPROC_CMA_SIZE_IPU1 is defined in lateattach.c directly.

    Thanks
    Terence