• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 451 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/AM3358: U-boot debug

Ulf Samuelsson
Expert 1010 points
Part Number: AM3358
Other Parts Discussed in Thread: SYSCONFIG

Tool/software: Code Composer Studio

I am porting U-Boot to a new AM3358 based board.
This can boot from SPI flash and from the SD/MMC0 connector.
I am familiar with U-Boot, but only as a second level bootloader.
In order to get a better understanding of the U-Boot 1st level bootloader (MLO)
I would like to single step through it to follow the program flow.

The bootprocess is as follows:

We have SYSCONFIG[4:0] = 10110: Boot order: SPI0, MMC0, UART0, EMAC1

At reset, the CPU will first try the SPI boot, which will fail because
at this time we will only have MLO on the SD-Card.
The ROM boot will then find MLO on the SD-Card and load it into internal SRAM.
Alternatively, no SD-Card and download using UART.

Right after the download into SRAM, I would like to break the CPU so I can single step through MLO using CCS.

I have noticed that there is training on how to compile U-Boot which I have not watched yet.
I expect that I will be able to compile U-Boot using CCS to get an ELF file with the symbols,
but normally the debugger would want to download the file.

How can I breakpoint the CPU right after the download completes?

Can you simply set a H/W breakpoint on the beginning of the SRAM?

Are there any application notes covering board bringup using the ROMboot?

  • 0
    TI__Guru 69707 points

    Hi Ulf,

    Ulf Samuelsson said:
    How can I breakpoint the CPU right after the download completes?

    From my experience if you break at the beginning of SPL's (MLO's) arch/arm/mach-omap2/am33xx/board.c:board_init_f() function that is sufficiently early for debugging most if not all boot issues, and it allows it to work with C code right away. For this, I suggest you simply insert a loop to trap the program execution similar like this at the top of that board_init_f() function...

    ...
volatile int halt_pc = 1;
while (halt_pc) {};
...

    Ulf Samuelsson said:
    Can you simply set a H/W breakpoint on the beginning of the SRAM?

    ...continuing on the above thought, you would then try to boot normally, with the code essentially getting trapped, and attach(!) the JTAG debugger and take control of the CPU. You can then load SPL's symbols from the spl/u-boot-spl ELF file. I would NOT recommend using the debugger to load SPL/MLO or U-Boot directly and instead always use the "organic" boot flow to load it to avoid introducing a whole host of potential side effects and pitfalls. You can then change the variable (halt_pc in this case) to break out of the loop and continue program execution. From here on you can also easily set breakpoints within SPL using CCS.

    You can also find what essentially are the same steps in our U-Boot SPL debugging User's Guide located at http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_U-Boot.html#uboot-spl-debugging-tips  The guide covers a different device but the general flow still applies.

    Then, if you can't even get to your debugger trap loop there might be something more fundamentally wrong with your HW and boot setup. In this case I'd recommend using our CCS-based debug scripts that interrogate the device via JTAG and print various useful information regarding the state of the boot. For this, please

    1. Review instructions here: https://git.ti.com/cgit/sitara-dss-files/am335x-dss-files/plain/README
    2. Run the specific script located here: https://git.ti.com/cgit/sitara-dss-files/am335x-dss-files/plain/am335x-boot.dss

    Ulf Samuelsson said:
    Are there any application notes covering board bringup using the ROMboot?

    See above link to the U-Boot user's guide in our Processor SDK Linux documentation. Actually I'm working currently on a more comprehensive and consolidated board port/bringup reference guide that will be part of a future SDK documentation release to make this effort easier. Until then there is also a wealth of information readily available regarding board bringup and debugging various issues that can be found by searching our E2E forum so I'd highly encourage anybody really to take advantage of this resource.

    Regards, Andreas