• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 456 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-J721E: SDK: 7.03

Andrey Dolnikov
Prodigy 10 points
Part Number: PROCESSOR-SDK-J721E


Hi,

I'm trying to enable OSPI boot with SBL on our custom board but instead of
standard MCU-SW (can-boot-app) we are using custom MCU1_0 firmware
(which will boot other cores from OSPI flash just like MCU-SW does).

So basically this is quite similar to the SBL -> MCU-SW setup with the only
difference that MCU-SW is loaded to SRAM while our custom firmware running on MCU1_0 uses DDR.
However this does not work for us out of the box as BSS section is not zeroed during
loading of the binary. Unfortunatelly there is a piece of code related to SCI server/client
logic which assume static variables (which are located in BSS) are actually equal to zero on startup.
For example please see pdk_jacinto_07_03_00_29/packages/ti/drv/sciclient/src/rm_pm_hal/pm/drivers/psc/psc.c
and specifically psc_lookup function which assume 'static struct device *psc_devs' is initialized as zero.
BTW this seems to be not the only place where this assumption is applied as fixing it does not fix the issue completely.

If I got it right RPRC format, used to program OSPI flash, completely miss BSS section information when generated from ELF
so it looks like SBL does not even know for sure which memory region should be zeroed during firmware loading.
As a workaround I've updated SBL with the code to zero whole DDR used for MCUs firmware and now everything works just fine
but as we have quite some MCUs actually utilized we have to zero pretty much a lot of memory which is time consuming
(our MCU firmwatre similary to MCU-SW uses same firmware loading logic and RPRC format so while SBL only loads MCU1_0
it looks like we stil need to zero DDR for other cores like MCU2_0 and MCU3_0 to make sure it will work fine).

I'm wondering if I missed something and there is a way to properly handle BSS to
enable OSPI boot with SBL properly or this behaviour is expected and SBL should start code from SRAM only
(which I assume is zeroed at init due to HW specifics - isn't it?).

Thanks,
Andrey.

  • 0
    TI__Guru**** 485975 points

    Hi Andrey,

    Ideally SBL should memset this section of the memory to 0x0, if it knows about it. Not sure if it already takes care of it. Will check and get back. 

    Another solution is to properly initialize sciclient/sciserver's data structure without depending on bss section to be memset. I will check with the team and see how/if this can be done. 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    TI__Guru**** 485975 points

    Hi Andrey,

    One more option, can you check if your compiler supports zero_init flag? You could then set this flag to be on, like "--zero_init=on", in the linker flag and this should help in initializing these variables..

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 10 points

    Hello Brijesh,

    Thank you for the tip. We are using Ti Arm compiler for R5F cores and this option

    seems to be enabled by default, but there is another option related to --zero_init,

    namely --rom_model/--ram_model.

    --zero-init option affects bss initialization only in case of ROM model while in RAM model

    BSS initialization should be done by loader (SBL in our case).

    So it looks like by default firmware was built in RAM model and it looks like SBL BSS initialization (non-initialization actually) is not an issue when firmware is linked in ROM model and --zero-init enabled. Also this sounds to me like a better solution from the performance point of view - we have not to zero huge amount of memory in SBL.

    My only concern is non-ARM cores. I'm actually not sure if this issue affect them or not and if appropriate compiler provide similar options/link model.

    Thanks,

    Andrey.

  • 0 in reply to Andrey Dolnikov
    TI__Guru**** 485975 points

    Hello Andrey,

    I think there are similar compiler flags available even for DSP cores, so that SBL does not require to zero-init this section.

    Regards,

    Brijesh