[Alexio Velazquez]

The system seems to stop right before calling board_init_f. Early_board_init succeeds

[Alexio Velazquez]

Hey this is Alexio, David’s teammate. Adding in additional information:

Debugging attempts summarized (from our documentation):

 

• Began with a verified working Linux image for a BeagleBone Black Wireless, the board design our circuit is directly identical to outside of our external interfaces (back-up power, microcontroller com lines, etc.)
• Verified power profile and power rail responses as expected and within range
• Verified successful start of boot on OSD-3358 by observing ROM bootloader initialization, and system debug output of search for next SPL record – “CCCCCC” characters on UART0
• Verified successful read of SD card and SDIO interface by loading an older version of Linux and u-boot that has messaging at that stage. U-boot messaging indicates inability to read EEPROM for board ID, which is expected as EEPROM has not been programmed. – Older version of u-boot that outputs this message on UART0. Found from other forum posts.
• Patched u-boot to bypass EEPROM read for board ID, which is required from the system to set up the right device tree configuration for our circuit. Patch hardcodes the correct board ID at the check rather than reading the local EEPROM. This should allow us to move forward in the boot process.
• Verified ability to modify and re-compile u-boot from source code, application of patch and it’s contents, successful board ID skip. System still not booting.
• Moved to a newer version of u-boot. Slimmed down code and overall boot process to eliminate variables.
• Added additional debug messages in graduating order to indicate each step of the boot process. This entailed iterative compiling and recompiling of u-boot for additional debugging.
• Re-verified hardware design. Removed components to isolate our additional circuits from the OSD/BeagleBone design to isolate the system from potential errant race conditions (signals at the wrong time messing up the boot process)
• Narrowed down and eliminated factors to DRAM initialization to exactly where the lowest level assembly code is pushed to the stack.
• Attempted various configurations for DRAM initialization, including clock setup and timing.
• Attempting pinmux configuration edits and calibration using TI’s Software Development Kit (SDK), including the AM335x DDR3 Software Leveling program

[Author]

Posts