ARM926EJS U-Boot Relocation to DDR Failure: Symptoms and Context
The issue at hand involves the failure of U-Boot to function correctly after relocating its code and stack from SRAM to DDR on an ARM926EJS-based system. The system in question is implemented on a Xilinx FPGA, with the boot process initiated from an SD card. The initial stages of U-Boot execution, where the stack pointer resides in SRAM, proceed without issues. Debug prints and initial console outputs are visible, indicating that the UART and GPIO drivers are functioning as expected. However, after the relocation of U-Boot to DDR and the subsequent change of the stack pointer to a DDR address, the system begins to exhibit erratic behavior. The console outputs become corrupted, displaying non-printable ASCII characters, and the U-Boot prompt, although visible, becomes unresponsive to user inputs.
The memory map for the system is as follows:
- SD Card: 0x00000000 – 0x007FFFFF
- SRAM: 0x90000000 – 0x90007FFF
- DDR: 0x40000000 – 0x43FFFFFF
The console log provided shows that U-Boot successfully initializes and begins executing, but after the relocation to DDR, the stack pointer is set to 0x43eaeec0, and the system starts to malfunction. The key observation here is that the stack corruption occurs post-relocation, leading to the conclusion that the issue is related to the DDR memory access or the relocation process itself.
Stack Corruption and SDRAM Controller Configuration Issues
The root cause of the problem lies in the interaction between the ARM926EJS core, the U-Boot relocation process, and the SDRAM controller configuration. The ARM926EJS core, being a classic ARM9 processor, relies heavily on the correct configuration of the memory subsystem for proper operation. In this case, the SDRAM controller on the FPGA was initially configured to allow only 32-bit accesses, which led to failures when U-Boot attempted to perform 8-bit or 16-bit accesses during its operation. This misconfiguration caused data corruption, particularly in the stack region, which is critical for the proper functioning of U-Boot.
The stack corruption manifests when U-Boot relocates its code and stack to DDR. The relocation process involves copying the U-Boot image from the SD card to the DDR memory and then updating the stack pointer to point to the new location in DDR. However, due to the SDRAM controller’s restriction to 32-bit accesses, any 8-bit or 16-bit memory operations during this process result in incorrect data being written to or read from the DDR. This corruption affects the stack, leading to the observed erratic behavior in the console outputs and the unresponsiveness of the U-Boot prompt.
Additionally, the issue is exacerbated by the fact that the ARM926EJS core does not have a built-in memory management unit (MMU), which means that it relies on the correct configuration of the memory controller to handle different data access widths. The lack of an MMU also means that any memory access issues are more likely to cause severe system instability, as there is no hardware mechanism to handle memory access faults gracefully.
Implementing SDRAM Controller Reconfiguration and Debugging Techniques
To resolve the issue, the SDRAM controller must be reconfigured to support 8-bit, 16-bit, and 32-bit accesses. This reconfiguration ensures that all memory operations performed by U-Boot, regardless of their data width, are handled correctly by the memory subsystem. The steps to achieve this are as follows:
-
Reconfigure the SDRAM Controller: Access the SDRAM controller’s configuration registers and modify them to enable support for 8-bit, 16-bit, and 32-bit accesses. This typically involves setting specific bits in the controller’s control registers to allow for mixed-width accesses. The exact register settings will depend on the specific SDRAM controller implementation on the FPGA.
-
Verify SDRAM Access Widths: After reconfiguring the SDRAM controller, perform a series of memory access tests to verify that 8-bit, 16-bit, and 32-bit accesses are functioning correctly. This can be done by writing known patterns to different memory locations and reading them back to ensure data integrity.
-
Relocate U-Boot to DDR: Once the SDRAM controller is correctly configured, proceed with the U-Boot relocation process. This involves copying the U-Boot image from the SD card to the DDR memory and updating the stack pointer to point to the new location in DDR. Ensure that the relocation offset and the new stack pointer address are correctly calculated and applied.
-
Debugging with a Debugger: If available, use a debugger such as ARM DS-5 to step through the U-Boot relocation process and monitor the stack and memory contents. This allows for real-time observation of the system’s behavior and can help identify any remaining issues with the relocation process or memory access.
-
Fallback to SRAM for Critical Sections: As a temporary workaround, consider keeping the stack and heap in SRAM while limiting the static and dynamic allocations in the code to fit within the SRAM space. This approach can help isolate the issue to the DDR memory subsystem and provide a stable environment for further debugging.
-
Review U-Boot Relocation Code: Ensure that the U-Boot relocation code is correctly implemented and that it handles the transition from SRAM to DDR smoothly. Pay particular attention to the calculation of the relocation offset and the updating of the global data structure (gd) and stack pointer.
By following these steps, the issue of stack corruption and unresponsive U-Boot prompts after relocation to DDR can be resolved. The key takeaway is that the correct configuration of the SDRAM controller is critical for the proper functioning of the ARM926EJS core, especially in systems where U-Boot is relocated to DDR. Proper debugging techniques, including the use of a debugger and careful review of the relocation code, are essential for identifying and resolving such issues.
In conclusion, the ARM926EJS U-Boot relocation failure is a complex issue that requires a thorough understanding of the memory subsystem and the interaction between the processor core and the SDRAM controller. By reconfiguring the SDRAM controller to support mixed-width accesses and carefully debugging the relocation process, the issue can be resolved, ensuring stable and reliable operation of U-Boot on the ARM926EJS-based system.
