Boot firmware architecture for asymmetric cores

Power-on reset vector location
Power-on reset vector location is the address that is loaded into the program counter of the core from where the first instruction is fetched after the cores have come out of reset. This provides a major design challenge for a boot architecture with asymmetric core SoCs. SoCs with multiple cores inside can be designed to boot from any one of the available cores. Which core to boot from is mostly available as a configuration option, but since the boot software resides in the ROM area of the microprocessor, it should be capable of running on the selected boot core.

So what are the challenges posed by reset vector location for boot software? There is absolutely no problem with symmetric cores. This is because the interpretation of the boot vector location is same for symmetric core. But with asymmetric core there is a problem due to the following reasons:

• Reset vector is different for all the bootable cores.
• Common reset vector location for two or more bootable asymmetric cores.

Reset vector is different for all the bootable asymmetric cores
If the reset vector for all bootable cores is different, then the solution to the problem can be achieved in the boot software as shown in the figure below. The boot software will be located at a different area in ROM memory area where the cores will jump after power on reset.

Figure 5. The boot architecture is simplified if different cores in an asymmetric multicore SoC use different reset vectors.

Common reset vector location for two or more bootable asymmetric cores
The problem gets compounded when the reset vector location is shared across various asymmetric bootable cores.

• Reset vector location interpretation
  Even though the reset vector location is same for two or more asymmetric cores, the interpretation of the data available at the reset vector location can vary from core to core. For example if there is an SoC with two asymmetric cores - for example, Cortex-Ax and Cortex-Mx cores - then the reset vector location for both the cores is 0x0000_0000. The data available at this address is interpreted differently by the two cores. Cortex-Ax interprets this data as an instruction, which will cause a jump to a location where the boot firmware code will reside. But the same data is interpreted as a stack pointer by the Cortex-Mx core.
• Incompatible ISA
  The code present at the reset vector location is comprehensible to one core but not to the other. This can generate an exception or may take the failing core to an unpredictable state.

In such cases, one would like to change the reset vector location of the failing core to a different address location mapped to Flash or any non-volatile memory location. A solution to this type of problem cannot be achieved only in software design. It requires hardware support as well. The solution needs address translator logic inside SoC hardware where the reset vector address on the bus for all the bootable asymmetric core(s) is translated to a different location in the ROM memory area where the reset vector table resides. This is also explained in the figure below.

Figure 6. If different cores in an asymmetric multicore SoC use the same reset vector, a hardware assist in the form of address translator logic is needed to ensure each core boots from its specific boot area.

Summary
The article presents different design approaches or methodology when designing a boot architecture for asymmetric core system. The design methodology for such systems is not limited to what has been described in the article but mainly governed by the SoC design. It can even be a combination of different approaches presented based on hardware architecture.

About the authors

Pradip Singh is Technical Lead engineer at Freescale.

Rishabh Goel is Technical Lead engineer at Freescale.