OSD3358-512M-BAS Boot Question

[Dong David]

We made a demo based on the Beaglebone Black wireless development board. The PCB diagram is exactly the same as the development board, but there is an issue: 1. U-boot cannot start. Attached is the information printed during startup, and above the red line is the log printed by our circuit board. Below the red line is the normal startup information printed by the Beaglebone Black Wireless development board. 2. Our circuit board cannot run after SDRAM initialization. Is there a need to make other configurations for the new chip during SDRAM initialization? Now I want to pinpoint where the problem lies and find a solution. thank you.

Attachments:

1. 

   log.png
   

[Dong David]

Chip Name  OSD3358-512M-BAS-XB

Attachments:

1. 

   OSD3358-CHIP-1.jpg
   

[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

[Neeraj Dantu]

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

[Dong David]

Thank you for your reply.

There are three sample boards with the same issue. When this problem occurs, testing the 24MHz crystal oscillator frequency and 3.3V/1.8V power output is normal. We speculate that the program stopped at this point due to some internal initialization issues within the chip, and more log information can accurately locate the problem point.

There are two questions that need to be confirmed:

1. The data manual mentions that we need to perform software leveling for DDR3. Is this necessary?

2. There is a procurement question: How can we purchase the latest chip version? How long is the manufacturer’s chip warranty period?

[Neeraj Dantu]

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

[Author]

Posts