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.

[FAQ] TDA4VM: Application in the PSDKRA runs standalone from SBL but doesn't run alongside Linux

Part Number: TDA4VM

I took an PSDKRA example ran it using SBL and it ran fine.

But now when I copy the same application executable and put it in /lib/firmware of the SD card, it doesn't load. What could be the problem?

  • Some applications in the SDK are for standalone driver testing and will run standalone using CCS or SBL boot flow. When we put these applications in /lib/firmware in the Linux filesystem the applications might NOT run, this could be due to the one or multiple of the following reasons:


    Memory map

    • The reset vectors need to be properly places and also the application's MPU and Cache setup related code should not be in DDR. Please find more information on this at
    • The application should be using the memory which Linux should not touch. This can be done my marking that memory as reserved memory in the Kernel Device tree or using an already reserved memory of that core. Not using the reserved memory might corrupt the memory space of Kernel and/or the application.


    Resource conflict

    The standalone applications are designed for driver tests and they assume that all the SoCs resources are their to be exercised. But when running along side Linux or any other SW on any other core there needs to be management of these resources.

    If the application and Linux are trying to use the same resource in the same time window then the SW running later will find the particular resource to be busy and this will cause issues.

    The applications need to abide by the RM board config passed to the SYSFW (in the sysfw.itb) to be able to avoid this resource conflict. Documentation on RM (


    Modules not enabled

    Sometimes standalone examples do not do the PRCM in the application but rely on the bootloader for the same. In such a case it could be possible the CCS (via GELs) or SBL enables clocks and power for the module but SPL / u-boot doesn't.

    In that case a quick check would be to halt at u-boot (after loading the application) and try to access the register space of that module (use the md command). If this results in an abort then the module needs to be explicitly turned on in the application init. Please use the SCIClient PM APIs for the same.

    The reference code for the same is available at