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.

AM3352: Issue Booting Custom Board – Stuck at "DRAM: 512"

Part Number: AM3352

Tool/software:

Hi,

I’m currently working on getting our custom board to boot. We're using the AM3352, and our design is based on the BeagleBone Black (BBB).

We’ve already addressed the issue of the missing EEPROM with board information by patching the U-Boot SPL, which is now working correctly.

However, we’re now facing another issue: U-Boot hangs at the "DRAM: 512" message and does not proceed further. We're using USB0 to boot the bootloader in order to flash the eMMC on the board. For reference, this process works fine on the BBB.

While we plan to use JTAG for deeper debugging, in the meantime I’ve added some debug logs to the source code. Based on my investigation, the problem appears to occur around this point in the code:


common/board_r.c, in the "init_sequence_r" function array.

#ifdef CONFIG_WINBOND_83C553
	initr_w83c553f,
#endif
	initr_barrier,
	initr_malloc,
	bootstage_relocate,
#ifdef CONFIG_DM
	initr_dm,


Interestingly, the output seems non-deterministic — in some cases, simply placing a printf changes the behavior. This leads me to suspect the issue may be timing-related.

Here it is the UART0 output:

U-Boot SPL 2014.07-00002-gc3d638d-dirty (May 20 2025 - 10:59:54)
Using default environment

usb_ether
using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC 98:89:24:73:2a:84
HOST MAC de:ad:be:af:00:00
RNDIS ready
musb-hdrc: peripheral reset irq lost!
high speed config #2: 2 mA, Ethernet Gadget, using RNDIS
USB RNDIS network up!
BOOTP broadcast 1
BOOTP broadcast 2
Using usb_ether device
TFTP from server 192.168.1.9; our IP address is 192.168.1.3
Filename 'uboot'.
Load address: 0x807fffc0
Loading: #################################################################
	 ######################
	 449.2 KiB/s
done
Bytes transferred = 440424 (6b868 hex)


U-Boot 2014.07-00002-gc3d638d-dirty (May 20 2025 - 10:59:54)

I2C:   ready
DRAM:  512 MiB

Please let me know if you need more details.

Best regards,
Luís

  • While we plan to use JTAG for deeper debugging, in the meantime I’ve added some debug logs to the source code. Based on my investigation, the problem appears to occur around this point in the code:


    common/board_r.c, in the "init_sequence_r" function array.

    Looks like your issues are happening just as DDR is getting exercised more.. Are you using the same DDR chip that is on the BeagleBone black, and the same associated DDR configuration? Also since you are using a custom board perhaps the logic (usually located in the "board file") that picks whatever DDR configuration needed for a given AM335x reference board is missing or broken?

    While we plan to use JTAG for deeper debugging,

    When you do that you can use the memory map view in CCS to spot-check if all DDR is there as expected, and read/write is working. Of course running a memory test will be even better,

    Regards, Andreas

  • Hi again,

    I was able to boot the board until the u-boot shell. I am now able to interact with u-boot.

    But even now, it does not always boot until this point. It seems it still has undeterminist behavior.
    Here is what I did.

    In the file: common/board_r.c

    static int initr_caches(void)
    {
    	/* Enable caches */
    	//enable_caches();      //Try with no cache
    	return 0;
    }

    Next I am try to load the kernel with this setup.

  • Good to hear about the progress. You should run a memory read/write stress test (like `memtester` in Linux). I'm on PTO this week but I will need be picking up E2E support again next week. Thanks.