• State
  • Locked Locked
  • Replies 0 replies
  • Subscribers 100 subscribers
  • Views 413 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[FAQ] Board bring up tips for Sitara devices (AM64x,AM243x, AM62x, AM62Ax, AM62Px)

JJD
Guru 71520 points
Other Parts Discussed in Thread: AM625SIP

The page provides tips on debugging initialization and boot up issues with the following devices:

  • AM64x
  • AM243x
  • AM62x/AM625SIP
  • AM62Ax
  • AM62Px

If this page doesn't address your issue, please submit a ticket at http://e2e.ti.com .  This page will continually be updated with new information

Section 1: No Console Output

If you do have console output, skip to Section 2

Check MCU_RESETSTAT and RESETSTAT signals.  These are status signals that identify if the device is still in reset.  Signals should go high and stay high when the device out of reset.  If either of them stay low after power ramp, the device is still in reset.  If device remains in reset, check power sequencing a voltage rails according to the device datasheet (section Power Supply Sequencing and Recommended Operating Conditions in the datasheet)

After MCU_RESETSTAT and RESETSTAT goes high, the ROM executes and attempts to boot from the primary boot source. 

  • Check to ensure the BOOTMODE signals are set correctly for your boot source.  Check voltage levels on all BOOTMODE signals  
  • Check to see if there is activity on the interface of the primary boot source.  For example:
    • if you are booting from SD Card, see if MMC1_CLK toggles.
    • if you are booting from OSPI, check for OSPI0_CLK toggle or OSPI0_CSN0 goes low.

If there is no activity on the primary boot source, check all power supplies on the board for proper voltage levels, especially with the devices that are your boot sources.  Check to make sure your power up sequencing is correct, and all power supplies are valid and stable after RESETSTATz goes high. 

If there is activity on the primary boot source, then that indicates the ROM is attempting to boot, but is failing.  You may also see that the ROM eventually attempts to boot from the secondary boot source (ie, you see 'CCCCC' if secondary boot source is UART, or USB enumerates if secondary boot source is USB DFU).  Check to make sure your power up sequencing is correct, and all power supplies are valid and stable after RESETSTATz goes high.  Also ensure the boot media is not in reset (maybe a separate signal is holding it in reset) while the ROM is attempting to access it.

Try performing a warm reset on your board if possible.  If the board boots as expected after a warm reset, but does not after a power up, then that may indicate a power sequencing issue, or possibly the boot media peripheral is not 'ready' immediately after power up.  Check interface signals and supplies after RESETSTATz.

If you can boot from the secondary boot source, try to read register MAIN_DEVSTAT_BOOTMODE (address 0x43000030) either using a debugger or from console prompt.  This register indicates the bootmode that was latched by the device.  The device may be inadvertently latching a different bootmode than what is expected from the bootmode pins.  Confirm this bootmode register is latching the correct value (Refer to the Initialization Chapter in the TRM, Section Boot Mode Pins)

Section 2: Hang during DDR initialization

The console output may hang in u-boot like below.  If your console output has more lines or does not hang at this point, skip to Section 3

U-Boot SPL 2023.04-dirty (Apr 03 2024 - 16:03:41 -0500)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
SPL initial stack usage: 13384 bytes

This typically means the DDR configuration is incorrect.  If your design uses a different DDR device from the EVMs (or even if it is the same), you need to use the DDR Register Configuration Tool to generate a header file for your board using one of the following links (depending on the device you are using):

Check the README in the tool for further instructions on how to use the tool.  This also has guidance on where to place the header file output to rebuild it into your code. 

Also check the links in Section 3 for further assistance in customizing the DDR configuration for your board

Adding debug statements to u-boot

To help debug the DDR configuration, add the following to include debug statements in the UART console output:

#define DEBUG

to the very top (above all #include) of drivers/ram/k3-ddrss/k3_ddrss.c

A successful boot with DEBUG messages and LPDDR4 memory will look something like this:

U-Boot SPL 2023.04-dirty (Apr 03 2024 - 16:48:03 -0500)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
k3_ddrss_probe(dev=43c34cdc)
k3_ddrss_ofdata_to_priv(dev=43c34cdc)
k3_ddrss memorycontroller@f300000: ddr freq0 not populated, using bypass frequency.
k3_ddrss_power_on(ddrss=43c3a640)
k3_ddrss memorycontroller@f300000: vtt-supply not found.
k3_lpddr4_probe: PASS
k3_lpddr4_init: PASS
--->>> LPDDR4 Initialization is in progress ... <<<---
k3_lpddr4_freq_update: received freq change req: req type = 1, req no. = 0, instance = 0
k3_lpddr4_freq_update: received freq change req: req type = 0, req no. = 1, instance = 0
k3_lpddr4_freq_update: received freq change req: req type = 1, req no. = 2, instance = 0
k3_lpddr4_freq_update: received freq change req: req type = 2, req no. = 3, instance = 0
k3_lpddr4_freq_update: received freq change req: req type = 1, req no. = 4, instance = 0
k3_lpddr4_freq_update: received freq change req: req type = 2, req no. = 5, instance = 0
k3_lpddr4_start: Post start PASS
SPL initial stack usage: 13384 bytes
Trying to boot from MMC2

<boot log continues...>

Getting DDR register dump after initialization

Sometimes it can be helpful to get a DDR register dump after initialization and training have completed.  The following patch can be applied to u-boot.  This patch will output all of the DDR registers to the console immediately after the initialization is complete.  You can start a new e2e thread and attach the register dump log to help assist with the debug.

/cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_regdump_2D00_patch_2D00_files.patch

Apply the patch with the following command at the u-boot root directory:
git apply -v 0001-regdump-patch-files.patch

A boot with DEBUG messages and register dump patch implemented will look like this:

k3_lpddr4_start: Post start PASS
Begin DDR Register Dump
0x0f308000 0x10460b01  //DDRSS_CTL_0_DATA
0x0f308004 0x5d1af3c3  //DDRSS_CTL_1_DATA
0x0f308008 0x0171a610  //DDRSS_CTL_2_DATA
<many more registers>
0x0f30d5ec 0x00018011  //DDRSS_PHY_1403_DATA_F2
0x0f30d5f0 0x0089ff00  //DDRSS_PHY_1404_DATA_F2
0x0f30d5f4 0x20040004  //DDRSS_PHY_1405_DATA_F2
End of DDR Register Dump

SPL initial stack usage: 13384 bytes
Trying to boot from MMC2

Hardware checks:

Power
Ensure the power up sequencing and voltage level of all voltage rails related to DDR are correct on the board.
For DDR4 designs, check the following
  
Processor Voltage Rails:
  • VDDS_DDR = VDDS_DDR_C = 1.2V
  • VDDA_PLL1 = 1.8V (AM64x/AM243)
  • VDDA_PLL0 = 1.8V (AM62x)
  • VDDA_DDR_PLL0 = VDD_CORE = 0.75 or 0.85V (AM62 AMC package only)

Memory voltage rails:

  • VTT = 0.6V
  • DDR_VREFCA = 0.6V
  • DDR_VPP = 2.5V

For LPDDR4 designs:

Processor voltage rails:

  • VDDS_DDR = VDDS_DDR_C = 1.1V
  • VDDA_PLL1 = 1.8V (AM64x/AM243)
  • VDDA_PLL0 = 1.8V (AM62x)
  • VDDA_PLL4 = 1.8V (AM62Ax)
  • VDDA_PLL3 = 1.8V (AM62Px)
  • VDDA_DDR_PLL0 = VDD_CORE = 0.75 or 0.85V (AM62 AMC package, AM62Ax, AM62Px)

Memory voltage rails:

  • VDDQ = VDD2 = 1.1V
  • VDD1 = 1.8V

Clocks

  • probe DDR_CK to see if it is the expected frequency

Resets

DDR4:

  • ensure DDR_RESETn signal is low throughout power ramp and transitions high (1.2V) only once, at least 200us after power ramp completes 
  • ensure DDR_CKE transitions high- (1.2V) at least 500us after DDR_RESETn transitions high

LPDDR4:

  • ensure DDR_RESETn signal is low throughout power ramp and transitions high (1.1V) only once, at least 200us after power ramp completes
  • ensure DDR_CKE transitions high (1.1V) at least 2ms after DDR_RESET transitions high

Section 3: Debugging Software failures during boot

Consult some of the software documentation for Linux board port

  • Go to https://dev.ti.com/tirex/explore/
  • Expand 'Arm-based processors'
  • Expand 'Training'
  • Choose 'AM6*** Academy' for the device and SDK version you are using
  • Expand 'Linux'
  • Select 'Porting Linux to Custom Hardware' and follow the guidance on the subsequent pages

If you are using MCU+ SDK, consult the online documentation for MCU+:

  • go to the Documentation link in your device's MCU+ SDK page.  

  • In the left hand tabs, choose SOC Peripheral Drivers->DDR->Creating your own DDR config file for DDR4 designs (or Creating your own LPDDR config file for LPDDR4 designs)

Some other links that can possibly help:

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1226815/faq-buildroot-support-for-sitara-am62x-am62ax-am62px-am64x-devices

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1294675/faq-am62x-am64x-faq-debugging-sbl-boot-in-rtos-sdk?tisearch=e2e-sitesearch&keymatch=faq%252525252525252520am64x#