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.

Linux/AM5728: U-Boot Debug fails at GPT/MBR partitioning

Part Number: AM5728

Tool/software: Linux

Hello, we're working on bringing up our AM5728-based custom board, and I've run into an issue following the u-boot debug guide in order to get the relocaddr value for the u-boot debugger symbols: 

I reach the stage where I load u-boot proper after reaching the end of the SPL with the Hang message:  

U-Boot SPL 2016.05-00323-g1ddff7 (Jul 26 2017 - 13:41:10)
DRA752-GP ES2.0
SPL:failed to boot from all boot devices
### ERROR ### Please RESET the board ###

However, after loading U-Boot proper, once I step into the program (even just one step into a breakpoint at the start point of the disassembly for U-Boot) the program fails at 

write_mbr_and_gpt_partitions(struct blk_desc *, void *)

And nothing appears on the UART debug output as specified in the lab.  My guess was that this is caused by trying to run U-Boot without a boot media attached in a MMC controller (our boot order is SD/eMMC, where we have a physical SD card), but I'm more leaning towards an improperly configured MMC or another subsystem.  

Attempting to boot by the SD card with the full SDK linux image, and with just the boot partition populated (with u-boot.img and MLO) predictably fails and only a few gibberish characters are printed to the screen.

Are these clues hinting at some kind of misconfiguration for our board?  The major differences between our board and the EVM are that we're only using 1GB of RAM (on EMIF2) and our SD card boots off of MMC3.  UART3 is still used for console debugging.

  • Hi,

    Can you compile your u-boot with
    #define DEBUG
    added in configs/am57xx_evm.h and share the console output?

    Best Regards,
    Yordan
  • My build already had DEBUG defined. Unfortunately, this has no effect.
  • I should also note that the PC register goes to 0x0C when this happens, so it's a possibility that it jumps through a null pointer, but I can't discount the possibility that without any debugging symbols loaded the debugger just gives up and throws an address (this is my first real effort debugging a chip with CCS)
  • I had the suspicion that this was because the CPU couldn't read the RAM after being configured by the SPL, but after changing some EMIF PHY EXT registers to align more properly with TRM guidelines, no changes were observed either.
  • Hello Yordan, I've been working on this for a week now, and I'm still at a total loss as to what's happening. I've reconfigured my DDR and EMIF registers several times, and barring a highly unlikely hardware failure, I've run short on ideas. My SPL *looks* to be configuring the AM5728 perfectly for the SDRAM bank, when U-Boot is loaded via JTAG I can view in the SDRAM memory and move the CPU PC register in and around the mapped memory, but any attempt to advance or step through the bootloader does nothing. Adding the DEBUG macro accomplishes nothing since the program does not even reach the point where a debug message can be sent.

    This is a rather significant blocker, and I'd appreciate any help you can give me.