AM5749: Early boot problem (SPL/ MLO)

Hi,

Are there any logs on the console or just a blank sceen?
Can you share the call stack from the debugger?

- Keerthy

Hi Keerthy,

Thank you for your reply!
We have console ,but did not any output(Just a blank sceen).

Update curent status:
[Situation 1]. When bootup we wait about 60 seconds.then start to run "step over" to trace.
The code will into _main() --> memset and stop at here.

The CCS will looks the following photos:

And no cell stack infomation output.

Then I push "supend" butten, the  code will  jump to 0x0000000c PRUSS1_CFG_PRUSS_GPCFG1.

[Situation 2]. When bootup immediately start to run "step over" to trace.
The code will success to over _main().
And the system will alive just jumping bwtween 0x4030fffe and 0x40310004 in function dm_spi_release_bus().
Cell stack atdm_spi_release_bus() at spi-uclass.c:82.

Hi,

What is the boot media? Where are you loading the boot binaries from?

Regards,

Keerthy

Hi,

I download SPL(MLO) to SD card by create-sdcard.sh.

U-boot version is "u-boot-2019.01+gitAUTOINC+333c3e72d3-g333c3e72d3".

The binaries build from  u-boot-2019.01.

The configure command is make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- DEVICE_TREE=am574x-idk am57xx_evm_defconfig

The build command is make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- DEVICE_TREE=am574x-idk

And I added test code in spl_relocate_stack_gd() like following:

asm("test: nop");
asm(" nop");
asm(" b test ");
asm(" nop");
asm(" nop");

When bootup PC will stop at test code position,then I modified PC to PC+4 for jumping leave test code.

Hi,

Have you tried using the MLO that's in the board-support/prebuilt-images folder of the SDK?

Can you try to check if that behaves differently on the custom board?

Regards,

Keerthy

Hi,

I use MLO that is in the board-support/prebuilt-images to boot,The PC will be  jump to 0x0000000c PRUSS1_CFG_PRUSS_GPCFG1.

But we didnot have any test code to lock PC,so we can not debug step by step. 

I have two question:

1. Why the PC jump to PRUSS1_CFG_PRUSS_GPCFG1?

2. What kinds hardware modified let the code keep in dm_spi_release_bus()?

I upload schematic in the following:

https://drive.google.com/file/d/18dAa_4N50VTIAZShWKz7TJ-HIMD5DxA-/view?usp=sharing

Hi 

In Situation 2:

I trace the asm from memset() jump to dm_spi_release_bus() in memset like following:

_main() --> memset() --> 0x40303102 bx r14 

Then in to this line will be jump to r14(0x4030ffff) that is dm_spi_release_bus() -->0x4030ffe ldr r3,[r3,#4]

Hi,

Since we cannot reproduce this issue It will be helpful if you can provide a detailed call stack.
Also jumping to 0xC is definitely sign of an issue. The execution space should be in the internal RAM space.

- Keerthy

Adding to Keerthy's response...

0xC is the vector for CPU abort. It has nothing to do with PRUSS1_CFG_PRUSS_GPCFG1.

You may have loaded some binary with those symbols at the address.

What most likely happened was something wrong in your code, for example, an invalid pointer causing CPU to access invalid address which generated DATA ABORT. It will end up at 0xC address.