Boot firmware architecture for asymmetric cores

ISA compatibility
The first and foremost design challenge is the ISA compatibility between different cores. ISA is defined as the boundary between hardware and software and is used to convert mnemonics to machine language understood by the processor.

Figure 2. In an asymmetric multicore SoC, incompatible ISA cores require separate boot areas but compatible ISA cores can share some or all boot code.

Based on ISA, boot architecture gets divided into two sections:

1. Incompatible ISA
   This means that software written for one core is incomprehensible to the other core. In such systems, Boot code will be completely different for different cores.
2. Partially compatible ISA
   This means that different cores support a common version of ISA - for example, a system containing cores like ARM Cortex-A and Cortex-M. For this type of system, boot code is divided into two parts.
   • Part I is the core-specific boot code. This section implements software functionality specific to an individual core.
   • Part II is the common boot code implemented using common ISA. This section implements the bulk of the boot functionality. This software invokes core-specific software implemented in Part I.

Many processor architectures implement a register like Processor ID or CPU ID. SoC designers give different values to this register for different cores. Core type is identified by reading this processor identification register. On the basis of this register, boot code can then take a decision to implement core-specific features. The main idea is that the common boot code will execute the same instruction on different cores, yielding different results based on the executing core.

• Common register:
  In the case where the register is memory mapped, then the address to access this register has to be same for all the cores. For example, when interfacing ARM Cortex-Ax and Cortex-Mx, the Processor ID register is accessed by a different mnemonic. Hence in such SOC designs it becomes necessary to implement memory-mapped registers. The mechanism to identify the executing core becomes hardware specific.

  
  Figure 3. When cores use a common register, the boot architecture needs to support memory-mapped registers to support hardware-specific access to boot code.

• Same instruction to read Processor ID/CPU ID:
  In some cases the register is implemented as some kind of special-purpose register (as in case of PowerPC). Care should be taken such that the same instruction can be used to access this register from different cores. For example, cases where Z2 and Z4 PowerPC cores are integrated within SoC, a SPR 286 register is used for accessing Processor ID.

  
  Figure 4. When cores use the same instruction to read the processor ID, designers need to ensure that the different cores can use the same instruction to access this processor ID register.