U-Boot Debug using CCSv5
1 / 34

U-Boot Debug using CCSv5 - PowerPoint PPT Presentation

  • Uploaded on

U-Boot Debug using CCSv5. In this session we will cover fundamentals necessary to use CCSv5 and a JTAG to debug a TI SDK-based U-Boot on an EVM platform. . July 2012. Pre-work Check List. Installed and configured VMWare Player v4 or later Installed Ubuntu 10.04

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' U-Boot Debug using CCSv5' - ghalib

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

U-Boot Debug using CCSv5

In this session we will cover fundamentals necessary to use CCSv5 and a JTAG to debug a TI SDK-based U-Boot on an EVM platform.

July 2012

Pre work check list
Pre-work Check List

  • Installed and configured VMWare Player v4 or later

  • Installed Ubuntu 10.04

  • Installed the latest Sitara Linux SDK and CCSv5

  • Within the Sitara Linux SDK, ran the setup.sh (to install required host packages)

  • Using a Sitara EVM, followed the QSG to connect ethernet, serial cables, SD card and 5V power

  • Booted the EVM and noticed the Matrix GUI application launcher on the LCD

  • Pulled the ipaddr of your EVM and ran remote Matrix using a web browser

  • Brought the USB to Serial cable you confirmed on your setup (preferable)


  • Sitara Linux SDK Development Components

  • Example Development Environment

  • U-Boot Debug Overview

  • U-Boot Debug Lab

Background for this workshop
Background for this Workshop

  • Understand the SPL/U-Boot/Kernel boot process

  • Knowledge of the Sitara Linux SDK and that it contains a cross compiler for the target device, CCSv5.1 and the source code for SPL/U-Boot/Kernel

  • Have run the setup scripts in the Sitara Linux SDK to configure the target to boot the Linux kernel from tftp.

  • Some knowledge of CCSv5

  • Techniques presented here are not the only way to do things.

Where to get the sitara sdk w ccs
Where to get the Sitara SDK w/ CCS

  • SDK Installer

  • CCSv5Installer

  • The list of available Sitara Linux SDKs can be found at: http://www.ti.com/tool/linuxezsdk-sitara

Ccs installation key things to know
CCS Installation – Key things to know..

  • JTAG use requires a License

    • The XDS100v2 can be used without a license

    • You can use a free 90 day evaluation license for all other emulators

  • To get JTAG support the CCS installer needs to be run in root mode using “sudo”

Example am335x evm debug environment
Example AM335x EVM Debug Environment

  • Ubuntu 10.04 LTS

  • Sitara Linux SDK

  • CCSv5.1

  • XDS560v2 USB JTAG

  • Serial Console

  • Ethernet

  • SD Card

    • MLO/U-Boot Pre-builts

    • Root File System installed

Am335x image load addresses
AM335x Image Load Addresses

  • These addresses are related to the AM335x, other processors will have different addresses, please refer to respective TRMs. The Addresses here are pulled from the AM335x TRM.

U boot debug overview1
U-Boot Debug Overview

  • Familiarize yourself with the u-boot load address. This can be found in the configuration file (i.e. include/configs/am335x_evm.h) and look for the following variables:

    • For SPL - CONFIG_SPL_TEXT_BASE 0x402F0400

    • For U-boot - CONFIG_SYS_TEXT_BASE 0x80100000

  • Define a CCS project and point to the source tree within the SDK

    • This will take a couple minutes since CCS will index the u-boot source tree

  • Create a target configuration (can specify a gel file)

  • Power on the EVM with no SD card installed

  • Launch the target configuration

  • From CCS connect to the Target, this suspends the target

U boot debug overview cont
U-Boot Debug Overview - Cont.

  • Switch from THUMB2 to ARM mode

  • Load the SPL image

    • Load the binary (bin) image if you are not debugging the SPL on the persistent storage

    • If using persistent storage you do not need to load anything

  • Load the U-Boot information

    • Load the ELF image if you are not debugging the u-boot on the persistent storage (i.e. SD card or NAND)

    • Load the symbols only if you are using the u-boot from the persistent storage

  • Navigate Source Code and set desired HW Break Point

U boot debug overview cont1
U-Boot Debug Overview - Cont.

  • Depending on how code was loaded:

    • Start target execution from the U-boot load address if your loaded the ELF image

    • Perform system reset from CCS if you loaded the symbold for u-boot in the persistent storage

  • These steps will be performed in the Debug Lab and will emphasize that how U-Boot is loaded matters (i.e. whether in SPL context or not)

U boot spl building
U-Boot/SPL building

  • Have to build U-Boot to get an binary SPL and ELF U-Boot image to work with.

    • Add the debug information in the binary SPL and ELF U-Boot

      • Modify the ti-sdk-am335x-evm-

        • 278 ALL_AFLAGS = $(AFLAGS) $(AFLAGS_$(BCURDIR)/$(@F)) $(AFLAGS_$(BCURDIR)) -g

        • 279 ALL_CFLAGS = $(CFLAGS) $(CFLAGS_$(BCURDIR)/$(@F)) $(CFLAGS_$(BCURDIR)) -g

  • Build the image

    • Follow the guide in http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide#Building_U-Boot.

U boot spl building cont
U-Boot/SPL building Cont.

  • Produced images

    • Locations: ti-sdk-am335x-evm-

    • Images

      • MLO, u-boot.img are the SPL/U-Boot used for boot.

      • u-boot, U-Boot ELF image, also includes the symbol information.

      • u-boot.map, contains the memory map for each symbol

      • u-boot-spl.bin, the binary of SPL

      • u-boot-spl, SPL U-Boot ELF image, also includes the symbol information

      • u-boot-spl.map, contains the information for each symbol

Ccs import the u boot project
CCS – Import the U-Boot project

Menu File -> Import …

Ccs configure the target
CCS – Configure the target

View -> Target Configurations 

Ccs connect to the cortex a8 core
CCS – Connect to the Cortex-A8 core

Right click on the target, click Launch Selected Configuration.

When it successes, it shows the following UI.

Now, the CCS successfully connect to the emulator.

Ccs connect to the cortex a8 core cont
CCS – Connect to the Cortex-A8 core, cont

Right click on the CortxA8 in last page, click Connect Target. Get the following picture

When it is ready.

Now the CCS connect to the Coretex-A8 Core correctly.

Spl debug load the image
SPL Debug – Load the image

Select the CortxA8 core of the target.

Menu Tools -> Load memory, select the u-boot-spl.bin, the binary of the SPL

Spl debug load the image cont
SPL Debug – Load the image cont.

Start Address refers to 0x402f0400 mentioned as before.

Type-Size is 32 bit. This is because it is ARM code, not Thumb code.

The memory loading may fail for the first time, then trying it again will be OK.

Spl debug load symbols
SPL Debug – Load symbols

Menu Run -> Load -> Load Symbols

Choose the image with symbols’ information, u-boot-spl

Spl debug change arm core mode
SPL Debug – Change ARM core mode

The initial status for the Cortex-A8 core here is Thumb, while, the system running

On the SOC is in ARM mode.

Menu View -> Registers. Change T bit to 0.

Spl debug start to debug
SPL Debug – Start to debug

  • The SPL binary was loaded to 0x402F0400, and this is the start point for SPL.

  • So the PCof the ARM core should be reset to this address.

  • This operation is the same as to set the ARM mode in last slide.

  • Click the Assembly Step Into button as in Red, and you can find the PC jumps to

  • the code as below.

Uboot debug
Uboot Debug

  • In general, the CCS debugging for SPL and Uboot has the same procedures in most steps, but there are still some differences. So only list the difference here

    • For U-boot, it can only run when the SPL finishes the DDR and other related low level initialization. So when debugging U-Boot, the SPL needs to be executed firstly.

    • U-Boot ELF image can be used directly for debugging.

    • There is the code relocation in the U-Boot, that is, part of the code will be relocated to higher memory. So the code memory map will be switched to an offset.

Uboot debug load image
Uboot Debug – Load image

  • Here, the U-Boot ELF image can be loaded directly.

  • Menu Run -> Load -> Load Program, choose u-boot.

  • You can see that load address is the one mentioned previous, which is extract from ELF header.

U boot code relocation
U-boot – Code relocation

  • The code relocation is done in the function relocate_code(), which is called by board_init_f(). And the code offset here is 0x9FF88000. So if need to debug the code after relocate_code(), the symbol relocation is necessary before relocate_code().

  • Menu Run -> Load -> Add Symbols, the image is still u-boot, and data/code offset is 0x9FF88000.

Spl u boot debug tips
SPL/U-Boot Debug -- Tips

  • Although the debug information, the breakpoint can’t be placed in the assembly code. So if want to place the breakpoint in the assembly code, it is necessary to find the entry address for the assembly function, which can be found in the memory map file, and read the code in disassembly window to find the correct place.

  • Not every line of C code can place the breakpoint, so it can use the above approach as well.