OSD3358-512M-BAS Boot Question

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

Alexio,

I am not sure about the u-boot version that the log posted above uses, but SPL  in newer versions does a preliminary size check for DDR that would error out if there is an issue with the DDR here: https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-omap2/am33xx/board.c#L501.

Q: Does the PMIC stay ON after the board encounters an error?

Q: Is it possible for you to point to the location where the fault occurs in u-boot?

My suspicion right now is a cold solder joint causing an in-rush based error. Please also let us know the status of how many boards you built/how many are failing this way. All units behaving the same way could indicate something systemic.

Please take a look at “Setup early (debug) UART” section of https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/How_to_Guides/Board_Port/U-Boot.html for more information on enabling UART outputs in early boot.

Best,

Neeraj

David,

1. The parameters that are default for Beagleboards can be used for OSD3358. Because how close the DDR is to the SoC, a range of parameters work well. Please take a look at Section 6.2 of the datasheet(https://octavosystems.com/docs/osd335x-datasheet/) for the parameters that Octavo publishes and recommends.

2. Please contact sales@octavosystems.com for purchase information.

Best,

Neeraj