Combining "initcode" within SSL (Secure Boot Stream)

Hi Tim,

Yes, you are correct. The initcode routines are not supported in the secure boot scenario.

The secure boot authentication process is performed at the end of the boot process. Execution of any user software prior to the authentication process violates the secure boot requirements. So that Init Block is not supported in a secure boot image.

The following techniques can be used to boot an application that is mapped to external memory:

1. A second-stage loader can be implemented, where the primary application configures the external memory controller and then issues a call using the boot routine to boot an application into external memory.
2. DMC initialization can be pre-programmed into the OTP dmcEn field using the OTP Program API. By setting the dmcEn field of the ADI_ROM_BOOT_CONFIG structure, the ADI_ROM_OTP_DMC_CONFIG structure is read from OTP and used to configure the DMC peripheral.

As you are following the method1, can you please confirm that primary application is fully mapped in L2 Like no error has occurred while build the project and code & data are mapped in L2.

You can also follow the below instruction to change the primary application to map L2 memory.
Project > system.svc → Linker_Files Tab → In the “Select default target memory for code and data:” from ‘L3’ to ‘L2’. This will map the application to L2 memory.

Please note that ARM has 64KB uncached L2 and 384KB cached L2 memory.

In the method2, DDR Frequency is limited to 300 MHz on power on reset. After booting, DCLK can be changed to the desired frequency. This is documented as anomaly. Please refer anomaly “20000073” in the below link for more details.
https://www.analog.com/media/en/dsp-documentation/integrated-circuit-anomalies/ADSP-SC570_571_572_573_ADSP-21571_573-Silicon-Anomaly-List.pdf

Regards,
Nandini C

Thanks for the info on dmcEn.

I resolved this with a three-stage bootloader approach, all of which are wrapped (BLw): The first (runs in L2) performs the initcode routines. This pivots to the regular Second Stage Loader, which can run in L3. This then does all my proprietary bootloader stuff, and then finally boots the primary application.

It was hard work getting the memory maps laid out so all of the apps behave themselves.

Something that I still haven't found documented anywhere, and I don't fully understand, is that the L2 memory regions used by the SSL cannot be reused by subsequent applications. What happens is that the adi_rom_boot call for that next application fails. I'm not sure why that is.

Hi,

Thanks for the update. 

L2 memory regions used by SSL can be reused. But please ensure that the new application loaded does not clobber the load function and the part of the software responsible for making the core jump to the start of the newly loaded application.

i.e, The Primary application and secondary application could not clobber. So, place the bootloader code in a different place in the memory such that they don’t overlap.

You can use #pragma section("section_name") directive to force code into different memory location.

For example, if adi_rom_boot is calls from Start_Application, then place the Start_Application in L2 memory section.

#pragma section("section_name")
void Application (void)

{
..
..

adi_rom_boot();

..
..
}

Also, we recommend referring the below FAQ which will useful to troubleshoot the failures when the adi_rom_boot() fails.

https://ez.analog.com/dsp/sharc-processors/adsp-sc59x/w/documents/32804/how-to-troubleshoot-failures-of-the-adi_5f00_rom_5f00_boot-function