Analog Devices ADSP-SC58 Series Hardware Reference Manual page 3478

Secure Boot
NOTE: The ROM_BFLAG_RETURN flag is set when calling the boot routine for the other cores than the core
executing the second stage loader then cleared when loading the cores own image. Failure to do so would
result in unintentional behavior.
When a core is used to boot a separately generated boot stream for another core, the ROM_BFLAG_RETURN flag
should be used when calling
which in this case is back to the core that was running the second stage loader. Failure to set this flag would result in
the core vectoring to the location in its own RCU_SVECT[n] register which would not be the intention. In order
to allow the core that was just booted to start running the newly loaded application.
By default when implementing a scheme such as previously described where one processor is responsible for booting
images for another core, the other cores in the system will remain in their existing idle state that they should be
placed in prior to the boot commencing. In order to allows the cores to execute their new application the corew that
was responsible for booting the other cores must reset the cores via the
reset. If there is a requirement to release the core from the reset state, then this must be done within the application
code of the running core.
Releasing other cores from reset to run application software while other processors are running a boot process re-
quires careful system design. The drivers used by the boot kernel for the boot process assume the various peripheral
and infrastructure resources such as MDMA channels and peripherals are available for use, and are not being used
by another core. If the boot routine is being executed while other cores are running applications, then those applica-
tions must ensure that all the required boot resources are freed up and remain free in order for the boot process to
complete on the remaining cores.
Multi-core Boot Images
Multi-core boot images are generated as a result or processing the multiple linker output files for multiple cores to-
gether to create a single compliant boot stream. The resulting boot stream has a first header block at the beginning
of each core boot stream and a single final block at the end of the boot stream. The boot stream must only have a
single final block to allow the boot kernel to continue processing the entire boot stream. A final block results in the
boot kernel terminating triggering the final public key authentication sequence.
The block headers BLOCK_CODE.HDRSIGN field of the resulting boot stream is used to identify which core the
image is intended for. This identification is required such that the boot code can set the correct RCU_SVECT[n]
when the first block is read to set the application start address for that core. When the boot image is loaded and
authentication was successful, the core executing the boot sequence jumps to the location stored in the cores corre-
sponding RCU_SVECT[n] register. However, as the boot stream has multiple first blocks present for each of the
cores, all other cores RCU_SVECT[n] register is set for their applications. Upon the booting core running its appli-
cation, it must release the other cores from reset in order for them to then start running their loaded applications.
If a product supports three or more cores, it is acceptable to create a dual core boot image and then load the other
cores later using single core boot images stored elsewhere in the boot source. There are no restrictions on a multi-
core boot stream requiring to contain an application for all the cores in a product.
The resulting multi-core boot stream must then be signed and optionally encrypted resulting in a complaint secure
boot stream that can be used to boot a secure device.
53–58
instructing the boot kernel to return to the calling application,
adi_rom_Boot()
ADSP-SC58x/ADSP-2158x SHARC+ Processor Hardware Reference
RCU_CRCTL then release them again from