0

I've been having some issues debugging U-Boot. I believe it is due to a RAM configuration error, but I would like to get some clarity on it.

My methodology for testing is below, and is based on these instructions for the BeagleBone Black

  1. Load board with no memory/image
  2. load u-boot-spl.bin to the SRAM memory via JTAG at the proper address specified in processor manual (TI AM5728, so address 0x40300000) and load u-boot-spl ELF symbols
  3. Set PC register to the start address of U-Boot-SPL (0x40300000)

  4. Run SPL, and pause after I receive a message such as this one: u-boot-spl no MMC warning

  5. At this point I know that U-Boot has relocated from the SRAM to the DDR3 RAM due to spl_relocate_stack_gd() being already called.

  6. Load U-Boot via JTAG, the PC automatically changes to address 0x80800000 due to having the context of the relocation.

From here I would resume the application to get to the U-Boot console and get the gd->relocaddr from bdinfo, but even single stepping into the program results in U-Boot becoming unresponsive, and the PC moving to address 0x0000000C.

My guess is that this is because the SDRAM was not configured correctly, resulting in an erroneous read, considering that the first instruction is a branch, which could result in the erroneous PC value.

The trouble is that when I try this with a TI AM5728 EVM, with the known-correct RAM configs, the same thing happens. But when I start the EVM with a SD card that only has u-boot.img and MLO, I reach the U-Boot command line.

EVM bdinfo

Am I going crazy with the notion that this could be the RAM? Since I have evidence of a working RAM configuration for the same SoC doing the same behaviour, or is there something else that I am missing? printf()'s don't seem to work, and enabling the DEBUG macro does not print anything to console, either.

Brendan
  • 908
  • 2
  • 15
  • 30
T. Wallis
  • 189
  • 3
  • 14
  • If you think there could be a DRAM controller (EMIF?) issue, then compare the contents of the controller's configuration registers in working versus goofy modes. Boot from SDcard for the "good" configuration, and use the `md` command to dump the entire register block of the memory controller. Then obtain another register dump under the problematic situation (using JTAG?). Compare the two sets, and try to account for every difference. BTW *"1. Load board with no memory/image"* makes no sense to me. Are you trying to zero-out memory? – sawdust Aug 19 '17 at 00:03
  • Please post details about how your board is different from the EVM and what your code changes are, and diffs as well. For a known and stable SoC like this you should not need to be using JTAG to load U-Boot in, you should be able to put in at least basic default values and load from SD card. – Tom Rini Aug 20 '17 at 13:44
  • Compared to the EVM, my board only uses 256MB rather than the 2GB that the EVM uses, and we're using hardware levelling for the RAM in our board. The EVM uses MMC1 and MMC2 for SD and eMMC, mine uses MMC1 and MMC3 both for SD card (MMC1 is boot). Code diff is [here](https://pastebin.com/1McpJQES) – T. Wallis Aug 21 '17 at 13:34
  • I have also managed to get the debug output from my board, but U-Boot hangs at 'Jumping to U-Boot' paste is [here](https://pastebin.com/humyCuvj) – T. Wallis Aug 21 '17 at 17:28

0 Answers0