DM8148 u-boot debug by CCS

Hi Kazu,

Kazu Kon said:

I think U-Boot-MIN and SPL are same meaning.

Yes, correct.

Kazu Kon said:

But I was not able to do symbol debug because there is not like u-boot-spl file which is the ELF executable. What should I do? Please give me advices.

When I execute the below three steps, I have 5 result files:

:~/board-support/u-boot-2010.06-psp04.04.00.01$ make distclean
:~/board-support/u-boot-2010.06-psp04.04.00.01$ make ti8148_evm_min_sd
Setting up TI8148 minimal build for 1st stage...
Configuring for ti8148_evm board...
:~/board-support/u-boot-2010.06-psp04.04.00.01$ make u-boot.ti
........
arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin
tools/mkimage -T tiimage \
        -e 0x40300000 -n ti81xx -d u-boot.bin u-boot.min.sd
Image Type:   Texas Instruments ti81xx Boot Image
Image Size:   68860 Bytes = 67.25 kB = 0.07 MB
Load Address: 40300000
Entry Point:  40300000


The result files are: u-boot, u-boot.bin, u-boot.lds, u-boot.map, u-boot.min.sd

Two of these 5 files are executable: u-boot and u-boot.bin.

So, could you try with these two files? I think one of these 2 should be the correct one.

Also, can you try to change the OCMC RAM start address from 0x402F0400 to 0x40300000.

Best Regards,
Pavel

Hello Pavel,

Thank you for your advice. I was able to run u-boot.min.sd at 0x40300000. Then I loaded symbol with u-boot. Because u-boot is ELF executable file but u-boot.bin is data. But I can't load symbols correctly.

When I put the mouse cursor on board_init function in /board/ti/ti8148/evm.c, the value was displayed 0x80708c34 by CCS. I realized that this address is mapped by u-boot.map. Then I also loaded symbols to have 0x40300000 for code and data offset. After that board_init function had 0x40308c34. But I was not able to put hardware breakpoint on board_init function. Please give me advice.

Regards,
Kazu

Kazu,

In the wiki guide, we have two files to load from the CCS: u-boot-spl.bin and u-boot-spl

And I think these correspond to:

AM335x u-boot-spl  <--> DM814x u-boot

AM335x u-boot-spl.bin  <--> DM814x u-boot.bin

So, can you try with u-boot and u-boot.bin files, u-boot.bin instead of u-boot.min.sd! Does it make any difference?

Regards,
Pavel

Hi Pavel,

It's same. I loaded data for u-boot.bin, and I loaded sysmbol for u-boot with offset(0x40300000). I was able to run SPL, but I was not able to do symbol debug. I mean I can't put hardware breakpoint.

I'm a little confused. It seems that correlation is below, I think.

AM335x u-boot-spl  <--> DM814x NOTHING (2nd stage loader/ELF)
AM335x u-boot-spl.bin  <--> DM814x  u-boot.min.sd (2nd stage loader/DATA)
AM335x u-boot  <--> DM814x  u-boot (3rd stage loader/ELF)
AM335x u-boot.bin  <--> DM814x u-boot.bin (3rd stage loader/DATA)

Regards,
Kazu

Kazu,

Kazu Kon said:

I'm a little confused. It seems that correlation is below, I think.

AM335x u-boot-spl  <--> DM814x NOTHING (2nd stage loader/ELF)
AM335x u-boot-spl.bin  <--> DM814x  u-boot.min.sd (2nd stage loader/DATA)
AM335x u-boot  <--> DM814x  u-boot (3rd stage loader/ELF)
AM335x u-boot.bin  <--> DM814x u-boot.bin (3rd stage loader/DATA)

No, I do not think this is the correlation. We should not mess up the 1st stage bootloader and its related files to the 2nd stage bootloader with its related files.

In AM335x device we have as below :

While in DM814x/AM387x device we have as below:

Thus I think the correlation for the 1st stage bootloaders is:

AM335x u-boot-spl  <--> DM814x u-boot
AM335x u-boot-spl.bin  <--> DM814x  u-boot.min.uart/sd or u-boot.bin
AM335x u-boot  <--> we do not have u-boot in AM335x 1st stage bootloaders!
AM335x u-boot.bin  <-->  we do not have u-boot.bin in AM335x 1st stage bootloaders!

Kazu Kon said:

I mean I can't put hardware breakpoint.

"But I was not able to put hardware breakpoint on board_init function."

Can you try (as the wiki page instruct) to put HW breakpoint at the beginning of the s_init function (not board_init).

Best Regards,
Pavel

Kazu,

For the 1st stage u-boot binary, only u-boot.min.uart/sd (at addr 0x40300000) is working fine. When I load u-boot.bin, there is error reported in the CCS console:

Cortex-A8: Trouble writing memory block at 0x4....

Thus we should use u-boot.min.uart/sd and u-boot.

But I also can not set HW breakpoint in the evm.c file, I have "No code is associated with ..../evm.c, line 1101 in any loaded symbols"

Let me check with our CCS team for a clue why this breakpoint error occur.

BR
Pavel

Kazu,

Can you try the things described in the below wiki page and also the video inside it:

http://processors.wiki.ti.com/index.php/U-boot_Debug_in_CCSv5 -> http://software-dl.ti.com/sdo/sdo_apps_public_sw/CCSv5/Demos/u-boot_debug_autonomous/u-boot_debug_autonomous.html

This video is for DM816x device, but I think DM816x u-boot is more close to DM814x u-boot than AM335x u-boot.

Regards,
Pavel

Hi Pavel,

Thanks a lot. I was able to have h/w breakpoint, start_armboot and s_init, on the disassembly window. But I can't look at source file by doing assembly step . And I can't also have h/w breakpoint on the source file. I think maybe this problem is caused by c-compiler option. What do you think?

Regards,
Kazu

Hi Pavel,

It's working now. Thank you very much!

Regards,

Kazu