ARMv7 SMC Call Misconfiguration Leading to Core0 Execution Instead of Target Core
The issue at hand involves the failure to correctly start a secondary core in an ARMv7 baremetal environment using the SMC (Secure Monitor Call) instruction. The primary goal is to initiate a secondary core (Core2 or Core3) to execute a specific function (blink), but instead, Core0 ends up executing the function. This misbehavior suggests a fundamental misunderstanding or misconfiguration of the SMC call parameters, the ARMv7 power state coordination interface (PSCI), or the underlying hardware-specific implementation of the Allwinner H3 SoC.
The SMC call is being used to invoke the CPU_ON function, which is part of the PSCI specification. The function ID 0x84000003 corresponds to CPU_ON, and the parameters include the target CPU ID, the entry point address (blink), and a context ID. Despite the correct function ID and seemingly appropriate parameters, the target core does not start as expected. Instead, Core0 executes the blink function, indicating that the SMC call is either not reaching the intended core or is being misinterpreted by the hardware or firmware.
This issue is compounded by the fact that the program is running in a baremetal environment, meaning there is no operating system to handle core initialization or provide abstractions for inter-core communication. The absence of an OS increases the complexity of debugging, as the developer must directly interact with the hardware and ensure that all low-level details are correctly configured.
Incorrect CPU ID Specification and PSCI Implementation Assumptions
One of the primary causes of this issue is the incorrect specification of the target CPU ID in the SMC call. The ARM architecture typically uses zero-based indexing for core IDs, meaning Core0 is ID 0, Core1 is ID 1, and so on. In the provided code, the target CPU ID is specified as 0x02, which would correspond to Core2. However, the behavior suggests that the SMC call is not being correctly interpreted by the hardware or firmware, leading to Core0 executing the blink function instead.
Another potential cause is the assumption that the PSCI implementation on the Allwinner H3 SoC adheres strictly to the ARM PSCI specification. While ARM provides a standardized interface for power management and core control, SoC vendors often implement their own variations or extensions to the specification. These vendor-specific implementations may require additional steps or parameters that are not documented in the ARM PSCI specification. For example, the Allwinner H3 SoC may require specific register configurations or additional SMC calls to initialize the secondary cores correctly.
Additionally, the context ID parameter in the SMC call is set to 0, which may not be appropriate for the specific use case. The context ID is typically used to pass additional information to the target core, such as a pointer to a data structure or a configuration value. If the context ID is not correctly set, the target core may fail to initialize or execute the intended function.
The use of the smc_call assembly routine is also a potential source of error. The routine is minimal, consisting of only the SMC instruction and a branch return (bx lr). While this is sufficient for invoking the SMC call, it does not include any error handling or status checking. The ARM architecture specifies that the SMC call should return a status value indicating the success or failure of the operation. Without checking this status, it is impossible to determine whether the SMC call was executed successfully or if an error occurred.
Verifying CPU ID Mapping and Implementing Robust SMC Call Handling
To resolve this issue, the first step is to verify the CPU ID mapping for the Allwinner H3 SoC. The ARM architecture uses zero-based indexing for core IDs, but the SoC vendor may use a different numbering scheme. Consult the Allwinner H3 datasheet or technical reference manual to confirm the correct CPU ID for the target core. If the datasheet does not provide this information, experiment with different CPU IDs to determine the correct mapping.
Once the correct CPU ID is confirmed, update the SMC call to use the appropriate value. For example, if Core2 is ID 2, ensure that the target CPU ID parameter is set to 0x02. If Core3 is ID 3, use 0x03. This step ensures that the SMC call is targeting the correct core.
Next, investigate the PSCI implementation on the Allwinner H3 SoC. The ARM PSCI specification provides a standardized interface, but the actual implementation may vary between SoCs. Review the Allwinner H3 documentation to identify any vendor-specific requirements or extensions to the PSCI interface. This may include additional SMC calls, register configurations, or initialization sequences that are necessary to start the secondary cores.
If the documentation is unavailable or incomplete, analyze the boot process of the Allwinner H3 SoC to identify any initialization steps that are performed by the bootloader or firmware. This may involve disassembling the bootloader or using a debugger to trace the execution flow. Look for any SMC calls or register writes that are related to core initialization and replicate these steps in the baremetal program.
The smc_call assembly routine should also be updated to include error handling and status checking. The ARM architecture specifies that the SMC call should return a status value in a specific register (typically r0). Modify the smc_call routine to capture this value and check it for errors. If the SMC call fails, the program should log the error and take appropriate action, such as retrying the call or halting execution.
Here is an example of an updated smc_call routine with error handling:
.globl smc_call
.arch_extension sec
smc_call:
SMC #0
cmp r0, #0 // Check the status value
bne smc_error // Branch to error handling if the status is non-zero
bx lr // Return if the SMC call was successful
smc_error:
// Log the error or take appropriate action
b smc_error // Infinite loop to halt execution
Finally, ensure that the context ID parameter is correctly set in the SMC call. The context ID is used to pass additional information to the target core, such as a pointer to a data structure or a configuration value. If the context ID is not relevant to the use case, it can be set to 0. However, if the target core requires additional information, ensure that the context ID is correctly configured.
By following these steps, the issue of Core0 executing the blink function instead of the target core can be resolved. The key is to verify the CPU ID mapping, investigate the PSCI implementation, and implement robust SMC call handling. With these changes, the secondary core should start correctly and execute the intended function.
Additional Considerations for Baremetal Core Initialization
In addition to the specific steps outlined above, there are several general considerations for baremetal core initialization on ARMv7 architectures. These considerations apply to any baremetal environment and can help ensure reliable and efficient core startup.
First, ensure that the memory system is correctly configured for multi-core operation. This includes setting up the MMU (Memory Management Unit) and cache coherency mechanisms. The MMU should be configured to provide the same memory mappings for all cores, ensuring that each core can access the necessary code and data. Cache coherency is particularly important for multi-core systems, as it ensures that each core has a consistent view of memory. Use the appropriate cache maintenance operations to invalidate or clean the cache as needed.
Second, consider the synchronization between cores. In a baremetal environment, there is no operating system to provide synchronization primitives such as mutexes or semaphores. Instead, use hardware-specific mechanisms such as spinlocks or atomic operations to coordinate access to shared resources. The ARM architecture provides several instructions for atomic operations, including LDREX and STREX, which can be used to implement spinlocks.
Third, be aware of the power state of the secondary cores. The PSCI interface provides functions for controlling the power state of cores, including CPU_ON, CPU_OFF, and CPU_SUSPEND. Ensure that the secondary cores are in the correct power state before attempting to start them. If a core is in a low-power state, it may require additional steps to wake it up and initialize it.
Finally, consider the debugging and monitoring of the secondary cores. In a baremetal environment, traditional debugging tools such as GDB may not be available. Instead, use hardware-specific debugging features such as JTAG or SWD (Serial Wire Debug) to monitor the execution of the secondary cores. Additionally, use logging or tracing mechanisms to capture the execution flow and identify any issues.
By addressing these considerations, the baremetal core initialization process can be made more reliable and efficient. The key is to understand the hardware-specific requirements and implement the necessary configurations and mechanisms to ensure correct operation. With these steps, the secondary cores should start correctly and execute the intended functions, providing the desired multi-core performance and functionality.
