Sitara Linux Training: uboot linux debug with ccsv5 sdk7

Return to the Sitara Linux Training List

Introduction

---

This lab is going to walk you through the process of using CCSv5 to debug U-Boot and the Linux kernel on the AM335x EVM. For more information on the overall debug flow please refer to the accompanying debug presentation.

Before you Begin ......

Just a reminder of directory notation, when seeing the ~/ti-sdk.... the ~ represents that user's home directory.

In effort to make this article future proof in terms of SDK version numbers future proof please note the following method to be used to substitute the current SDK version numbers. There is a version number for the Sitara Linux SDK.

For example in this article Sitara Linux SDK

• ti-sdk-am335x-evm-xx.xx.xx.xx/

At the time this article was written, the version numbers translated to this

• ti-sdk-am335x-evm-07.00.00.00/

Please note that the "tab" key can be used to auto-complete a version number

NOTE: In this guide commands to be executed for each step will be marked in BOLD

Lab Configuration

The following are the hardware and software configurations for this lab. The steps in this lab are written against this configuration. The concepts of the lab will apply to other configurations but will need to be adapted accordingly.

Hardware

1. Beaglebone Black (www.beagleboard.org/Products/BeagleBone+Black)
2. USB to serial cable (elinux.org/Beagleboard:BeagleBone_Black_Accessories#Serial_Debug_Cables)
   
3. USB cable to connect the board to you Linux Host
4. JTAG emulator ( XDS100 v2, XDS520 and XDS560)
   

   NOTE
   
   Through trial and error it was found that XDS100 based emulators do not perform well under a VM environment. This is due to the base VMWare driver for these devices and the low throughput they provide. Faster JTAG emulators such as the XDS560 V2 were found to have the best performance under VMWare

Software

1. A Linux host system configured as per the Linux Host Configuration page
   • Make sure you have installed the version of CCSv5 provided with the Sitara SDK installed under sudo mode so the JTAG drivers are installed (with either temporary license or permanent license)
   • Sitara Linux SDK installed. This lab assumes the SDK is installed in /home/sitara. If you use a different location please modify the below steps accordingly.
     
     • For help configuring the NFS and TFTP setup see Sitara Linux Training: Hands on with the SDK
2. SD card with Sitara Linux SDK installed.
   • For help creating a 2 partition SD card with the SDK conent see the create_sdcard.sh script page

   IMPORTANT
   
   For this lab you should either remove the zImage file in the boot directory of the rootfs of the SD card, or rename the file zImage-pre-built. This is to prevent the board from booting automatically from the SD card when the card is installed

Configure your Development Environment

Description

This section is going to walk you through the steps to make sure your development environment is properly configured.

Key Points

• Setting up the system for Debug
• Verifying your console connection

Lab Steps

1. Remove the SD card from board
2. Setup USB cable connection between the board and your Linux Host

1. The following steps will help you validate that you have a valid serial connection with your target board

   IMPORTANT
   
   These steps are written for boards like the EVM-SK and Beaglebone which use an FTDI USB-to-Serial adapter. For boards with a straight UART connection you can ignore the steps for /dev/ttyUSBx and instead just use the serial port on your Linux host that is connected to the board

2. Connect the USB cable between your Linux host and your target board

   IMPORTANT
   
   On the AM335x EVM-SK, the USB cable enables a USB-to-serial interface to the Linux host PC. If using a virtual machine, please insure the AM335x EVM-SK is a selected USB device.

   NOTE
   
   If you are running your VMWare image with Windows 7 some USB-to-Serial adapters do not properly work with Windows 7. Make sure that your adapter specifically says that it supports Windows 7. You may also need to install an additional driver for your adapter.

3. Open a terminal and run the following command to find the USB serial adapters available on the system. The FTDI chip used on the board presents two serial interfaces to the Linux host. The first interface is the JTAG interface and the second one is the serial console interface.

   ls /dev/ttyUSB*

   You should see output like:

   /dev/ttyUSB0

   /dev/ttyUSB1

   NOTE
   
   If using VMWare you may need to pass the "Future Technology Devices" device into the VMWare image

4. As mentioned above since the board's serial interface is the second interface you will want to open a serial console to the second device node. In this case that is /dev/ttyUSB1. This can be done by doing:
   • minicom -w -s
   • Select Serial port setup and press ENTER
   • Press A to modify the Serial Device and change the device to /dev/ttyUSB1. Press ENTER
   • Press ENTER to exit the serial setup
   • Select Exit and press ENTER
5. You should now see a minicom window.
6. Power on the board, you should see "ccccc" being printed in the window, if so the serial connection is working as expected. Go ahead and leave this console RUNNING in the background.

   NOTE
   
   For the EVM-SK board the power button is under the board in the upper-right hand corner. You must press and hold this button to power on the board.

   NOTE
   
   For the Beaglebone the board will power on as soon as the USB cable is connected. you can reset the board by pressing the reset button which should provide you with the expected output

   

Setup a U-Boot Debug Project

Description

This lab will step you through the steps necessary to create a CCS project. Here a project for U-Boot will be created.

Key Points

• A CCS project is set up and assigned a source tree that is indexed, this speeds up source level debug.

Lab Steps

1. Start CCS by double clicking the Code Composer Studio v5 icon on the desktop

   

2. You will see the CCSv5 splash screen appear while CCS loads

   

3. The next window will be the Workspace Launcher window which will ask you where you want to locate your CCSv5 workspace. Take the default value.

   

4. CCS will load the workspace and then launch to the default TI Resource Explorer screen

   

5. Close the TI Resource Explorer screen. This screen is useful when making TI CCS projects which use TI tools. The Sitara Linux SDK uses open source tools with the standard Eclipse features and therefore does not use the TI Resource Explorer. You will be left in the Project Explorer default view.

   

6. Create New User Project
   • Select File -> New -> Project
   • Expand the C/C++ category
   • Select Makefile Project with Existing Code

   

   • Click Next to enter the Import Existing Code dialog
7. Import the U-Boot code using the following steps
   • Click the Browse button.
   • Navigate the the U-Boot source directory. This is by default located at /home/sitara/ti-sdk-am335x-evm-xx.xx.xx.xx/board-support/u-boot-xxxx.xx
   • Click OK to select this as the root of the existing code

     IMPORTANT
     
     You should see the the Project Name has been filled in for you. You should take this default value because it allows easy association between the binaries being loaded later and the sources for the project. Changing this value can break that association.

   • Your project configuration should look something like

     

   • Click Finish
8. You should now be back at the main CCS screen. You should see your project listed in the Project Explorer tab and the code indexer running at the bottom right

   

Setup Linux Kernel Debug Project

Description

This lab will step you through the steps necessary to create a CCS project. Here a project for the Linux kernel is created.

Key Points

• A CCS project is set up and assigned a source tree that is indexed, this speeds up source level debug.

Lab Steps

1. With CCS still running from Sitara Linux Training: uboot linux debug with ccsv5_sdk7#Setup_a_U-Boot_Debug_Project_Setup_a_U-Boot_Debug_Project re-run the steps with the following change
   • Instead of browsing to the u-boot sources browse to the /home/sitara/ti-sdk-am335x-evm-xx.xx.xx.xx/board-support/linux-x.xx directory.
2. Once you have finished importing this project you should now see both the u-boot and Linux kernel projects in your Project Explorer tab.

   

Setup Target Configuration

Description

This section is going to walk you through the steps to set up a CCS target configuration. This is necessary to connect to a target for debugging both U-Boot and Linux.

Key Points

• How to create a new target connection
• Selecting the JTAG emulator and board type

Lab Steps

1. Select File -> New -> Target Configuration File
2. In the New Target Configuration dialog box give the configuration a name. For this lab we will use AM335x-TC

   

3. Click Use shared location, then Click Finish
4. The AM335x-TC configuration you created will now be opened for editing. Perform the following steps to finish the target configuration.
   • In the Connection drop-down box select Texas Instruments Blackhawk USB560-M Emulator

     NOTE
     
     If you are using a different emulator please select that one instead. You will only see emulators for which you have installed the drivers

   • In the Board or Device selection list check the AM335x device
   • You screen should look like

     

   • Click the Save button at the right of the screen
5. You can now test your target connection by pressing the Test Connection button at the right of the screen.
   • You should see a dialog box open. Scroll to the bottom of the output and look for the The JTAG DR Integrity scan-test has succeeded

     

     NOTE
     
     There are other tests run during the connection test and the status of these tests is also displayed in the dialog box

     NOTE
     
     The JTAG scan test may take a few seconds to complete on slower laptops.

6. Close the Test Connection dialog box
7. The target connection is now created

Build U-Boot for Debug

Description

This section is going to walk you through the steps to build SPL and U-Boot for debugging.

Key Points

• The ELF images from a build of U-Boot contains the debug information necessary.
• Which images are used for debugging

Lab Steps

1. Open a console terminal
2. Change Directories to the Sitara SDK Board Support U-Boot Source tree
   • ti-sdk-am335x-evm-xx.xx.xx.xx/board-support/u-boot-2013.10
3. Add the build tools from the SDK into your PATH

   NOTE
   
   You can also call the build tools with the absolute path, but this step will make it easier to type the following commands

   Make sure the build tools from the SDK are in the Path

   • echo $PATH
   • If you see something like this for the PATH, which contains the linux-devkit/sysroot/i686-arago-linux/usr/bin/ directory then the tools are already in your PATH.

     /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/sitara/ti-sdk-am335x-evm-xx.xx.xx.xx/linux-devkit/sysroot/i686-arago-linux/usr/bin/

   • If the tools are not in the PATH then add them with this command (hint:use the Tab key to complete directory paths)

     export PATH=$PATH:/home/sitara/ti-sdk-am335x-evm-xx.xx.xx.xx/linux-devkit/sysroot/i686-arago-linux/usr/bin/

4. Clean the U-Boot sources to start with a known good setup

   NOTE
   
   In the following commands there should always be a space after the arm-linux-gnueabihf- entry

   • make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- distclean
5. Perform configuration to default for the AM335x device

   NOTE
   
   The same configuration is used for the EVM, EVM-SK, and Beaglebone

   • make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_config
6. Compile SPL and U-Boot
   • make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
7. When the build finishes you should have the following files created
   • u-boot - ELF image that contains debug symbols
   • spl/u-boot-spl.bin - stripped binary SPL image that can fit into the internal memory
   • spl/u-boot-spl - Full SPL image containing all debug symbols. Too big for internal memory but can be used to load the symbols
8. Go ahead to the next lab step to build the kernel while U-Boot finishes building

Build The Linux Kernel for Debug

Description

This section is going to walk you through the steps to build a Kernel Image with debug information.

Key Points

• Debug information needs to be stored in the vmlinux image.
• Using the kernel configuration utility kernel debug information can be enabled.

Lab Steps

1. Open another console terminal
2. Change Directories to the Sitara SDK Board Support Linux Source tree
   • ti-sdk-am335x-evm-xx.xx.xx.xx/board-support/linux-x.xx
   • This directory is where all commands below are referenced from
3. Add the build tools from the SDK into your PATH

   NOTE
   
   You can also call the build tools with the absolute path, but this step will make it easier to type the following commands

   Make sure the build tools from the SDK are in the Path

   • echo $PATH
   • If you see something like this for the PATH, which contains the linux-devkit/sysroots/i686-arago-linux/usr/bin directory then the tools are already in your PATH.

     /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/sitara/ti-sdk-am335x-evm-xx.xx.xx.xx/linux-devkit/sysroots/i686-arago-linux/usr/bin

   • If the tools are not in the PATH then add them with this command (hint:use the Tab key to complete directory paths)

     export PATH=$PATH:/home/sitara/ti-sdk-am335x-evm-xx.xx.xx.xx/linux-devkit/sysroots/i686-arago-linux/usr/bin

4. Clean the kernel sources

   NOTE
   
   In the following commands there should always be a space after the arm-linux-gnueabihf- entry

   • make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- mrproper

   NOTE
   
   The make target of mrproper is used to reset the build configuration to a default state. This is done prior to configuring the kernel for a processor configuration.

5. Start with the default Sitara Linux SDK configuration

   NOTE
   
   There are two config files for the AM335x in the kernel tree. This lab uses the tisdk_am335x-evm_config file which matches the configuration used for the Sitara Linux SDK build

   • make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- tisdk_am335x-evm_defconfig
6. Modify the Kernel configuration for debug
   • make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig

     NOTE
     
     All the debug configuration information is enabled in the kernel hacking choice of kernel configuration. A quick note about navigating within menuconfig. The up/down move the cursor vertically on the menu choices. Use the left/right arrows to move the cursor between select and exit. Use the the space bar to select a kernel configuration choice. To navigate up from a submenu, use the right arrow to select exit and press enter.

   • Navigate into the Kernel Hacking submenu. Use the down arrow to select the Kernel Hacking submenu and press enter. This will navigate into the submenu.

     

   • Enable Kernel debug info under Kernel Hacking submenu by using the SPACE bar

     

   • Highlight Compile-time checks and compiler options and select it by using the spacebar.
   • Enable Compile Kernel with Debug info and use the space bar to select.
     

   • 

   • Have to go back up a submenus, use the right arrow to select exit and press enter.
     
   • Enable Stack Unwinding support under the Kernel Hacking submenu

     

   • Have to change submenus, use the right arrow to select exit and press enter.
     
   • Navigate up to top menu by selecting exit
   • Select exit again to leave the configuration utility
   • Save the kernel configuration

     IMPORTANT
     
     Be sure to save the kernel configuration. (Note this is where to put cursor on exit using the right arrow and pressing enter to navigate up the kernel configuration tree.

7. Open linux-x.xx.x/drivers/leds/Makefile in gedit
   
   • gedit /home/sitara/ti-sdk-am335x-evm-07.00.00.00/board-support/linux-3.12.1/drivers/leds/Makefile
     
8. At the bottom of the Makefile add the below line
   
   • CFLAGS_leds-gpio.o += -O0
     
   • 
     
9. Save and close gedit
   

Build the kernel

1. • make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage
2. When the build is finished, copy the kernel into the boot directory of the rootfs.
   
3. Plug in microSD card into the SD card reader and plug it in to the PC and then run the following commands.
   
   • cp arch/arm/boot/zImage /media/rootfs/boot
     
   • sync sync
     
   • umount /media/boot /media/rootfs
     
4. Remove the microSD card from the SD card reader but don't put it into the Beaglebone Black just yet.
   
5. Go ahead and continue with the next lab step while the kernel finishes building.
   

Change ARM mode

Description

This section will walk you through how to change the ARM core mode from THUMB-2 to ARM which is required to run the SPL and U-Boot binaries. This is normally done by the ROM code but since we are bypassing the ROM code load of the SPL we will need to do it ourselves.

Key Points

• Changing the ARM core mode from THUMB-2 to ARM

Lab Steps

1. Switch back to your CCS window
2. Launch your target configuration
   • Click View -> Target Configurations

     This should open a tab on the right side of your screen called Target Configurations

   • Expand the User Defined list
   • Right-Click the AM335x-TC configuration and select Launch Selected Configuration
3. You view should have changed to now show a Debug tab and the scan chain for the AM335x

   

   NOTE
   
   You can close the AM335x-TC file. You may also want to re-arrange the windows to make viewing easier

4. Right-Click the CortxA8 line item and select Connect Target

   

   • This will connect to the target and halt the processor.

     NOTE
     
     You will likely see a message about no source available for some memory address. This is not important

5. Now that you have connected you can set the processor in ARM Mode with CCS

   IMPORTANT
   
   The ROM code runs in Thumb2 Mode and before the SPL code can be run the processor must be set to ARM mode. This would normally be done by the ROM code, but since we are bypassing the ROM load of the SPL we must do it ourselves

   • Select the Registers tab

     

   • Expand the Core Registers
   • Inside of Core Registers expand the CPSR list

     

   • Scroll down in the CPSR register list and change the T register from 1 to 0. This is done by
     • Clicking the the Value box for the T register where the 1 located
     • Pressing delete to remove the value
     • Entering 0
     • Pressing Enter
   • You should see the CPSR value change to reflect the new value

     

   IMPORTANT
   
   You need to do this each time the board is powered completely off or reset. If you use the JTAG to do a SW reset this value will be preserved as well. Likewise, if you attach to a board that was already running a booted system this value will be configured properly but you should always go ahead and check it just to be safe

Perform SPL Debug

Description

This section will walk you through how to do source level debugging of the SPL code. This section is required before debugging U-Boot to make sure that the processor is set into the right mode and that the SPL has initialized device.

Key Points

• Loading the SPL binary
• Loading the SPL symbols
• Setting break points
• Stepping through code

Lab Steps

1. Assuming that the processor is now in ARM mode from the previous lab you can now load the SPL binary into the internal chip memory. This is done using the following steps
   • Click Tools -> Load Memory

     IMPORTANT
     
     The Load Memory tool is used here because we are loading the SPL binary and not and ELF image. The reason for this is that the binary is sized to be able to fit into the internal RAM of the SoC

   • Click the Browse button and browse to the following directory

     /home/sitara/ti-sdk-am335x-evm-xx.xx.xx.xx/board-support/u-boot-xxxx.xx/spl

   • Change the filter in the lower-right corner to All (*)

     

   • Select the u-boot-spl.bin file and click OK
   • You should now be back at the Load Memory dialog. Select Next
   • In the next screen change the following settings
     • Start Address: 0x402F0400

       IMPORTANT
       
       This is the start address of the SPL binary as defined in the u-boot sources

     • Type-size: 32 bits

     

   • Click Finish
   • You should see a box pop up showing the memory load operation

     

     NOTE
     
     This may take a bit of time since the XDS100v2 is a slower JTAG emulator than some other devices. Just be patient and allow the process to finish

2. Now that the SPL binary is loaded you can use the following commands to load the symbols for that binary to allow source level debugging
   • Click Run -> Load -> Load Symbols...
   • In the dialog box click the Browse button
   • Like before browse to the spl directory and change the filter to All
   • Select the u-boot-spl file which is the ELF executable that also contains the symbols and click OK
   • Click OK
3. Now that the binary and symbols are loaded we need to set the program counter to the beginning of the SPL code. To do this go back to your Registers Tab and in the Core Registers list change the PC value to the start address you entered before (0x402F0400)

   

4. Click View -> Disassembly to open the Disassembly view and see that the program counter is now at 0x402F0400 and that there appears to be valid content in the memory.

   

5. Now open the source file so we can set a breakpoint in the s_init function
   • Click File -> Open File
   • Browse to /home/sitara/ti-sdk-am335x-evm-xx.xx.xx.xx/board-support/u-boot-xxxx.xx/arch/arm/cpu/armv7a/am33xx
   • select the board.c file and click OK
   • Use CTRL+F to search for s_init
6. Set a hardware breakpoint by doing the following
   • Right-Click the line number on the left side that you want to set a breakpoint at
   • Select Breakpoint (Code Composer Studio) -> Hardware Breakpoint. For this lab select line 202
   • You should now see a Breakpoints tab opened listing your new breakpoint
     

     

7. You can now click the green run arrow to start execution of the SPL code. You should notice the execution stop at your breakpoint.

   

8. Go ahead and click the Step Into operation to step into the save_omap_boot_params() function
   
9. 
   
10. You can now hover over variable names to see their values.
    • For example click the rom_params variable on line 26 and you can see the value of that structure.
      

      

    • 
      

      NOTE
      
      The yellow arrows are for source step operations, the green arrows are for assembly step operations

      IMPORTANT
      
      Because of compiler optimizations the source level step operations may not be 100% accurate, but they are generally close enough to give you an idea of what is going on

11. Go ahead and click the green run button to let SPL finish running to completion
12. After a second or two press the yellow pause symbol to suspend execution#
13. You should either see output on the console window of ### ERROR ### Please RESET the board ### or the equivalent line in C code
    

    

    IMPORTANT
    
    You will only see the console output on your minicom window.

14. This means that SPL has run and tried to read the U-Boot image from the SD card, the default boot setting for the EVM. The processor now has the SPL context which means means the board is ready for U-Boot.

    IMPORTANT
    
    DO NOT RESET YOUR BOARD. If you reset your board at this point you will need to re-run these steps and re-load SPL to go on to the debugging U-Boot lab

Perform U-Boot Debug

Description

This section is going to walk you through the steps to debug a U-Boot Image. In the previous step SPL was run to enable the SoC to be ready for the U-Boot image. A HW break point will be set in an intialization function. After the break point is triggered, CCS will be used to step in and over functions and a memory location will be accessed.

Key Points

• Loading an ELF image into the processor memory instead of a raw binary
• Setting break points

Lab Steps

1. Assuming that you have executed SPL you can now perform the following steps to load the U-Boot ELF image.
   • Click Run -> Load -> Load Program...
   • Click the Browse button and this time select the u-boot file in the /ti-sdk-am335x-evm-xx.xx.xx.xx/board-support/u-boot-xxxx.xx-pspxx.xx.xx.xx directory

     

     NOTE
     
     As always you will need to change the filter to All

   • Click OK to load the program

     IMPORTANT
     
     As with the SPL load this may take some time and you may see your screen gray out periodically. This is OK. Be patient and allow the operation to finish. This is again due to the slower speed of the XDS100v2 emulator

2. Notice that this time because an ELF image was loaded the PC was automatically set for you because CCS had enough information in the image to do so.

   

3. Determine the U-Boot relocation offset.
   • Now that U-Boot is loaded go ahead and run the executable by clicking the green run arrow

     NOTE
     
     In the minicom window you should see U-Boot start running and timeout after three seconds. It will end with an error about being unable to get the kernel image. This is OK

   • In your minicom terminal use the command bdinfo to find the relocaddr.

     You should see output like the following which shows the relocation address to be 0x9F751000 - this value changes with different SDKs

     

     IMPORTANT
     
     You want to get the relocaddr value, NOT the 'reloc off value.

     IMPORTANT
     
     The values shown here are for a beaglebone. The relocaddr value can change depending on how much memory your target board has

4. Re-load U-Boot now that we have the relocation information so we can be ready to debug
   • Click Run -> Load -> Reload Program and allow the load to finish
5. Now the U-Boot is loaded again we need to reload the symbols based on the relocation offset we determined before. This way the hardware breakpoints we set next will actually work.
   • Click Run -> Load -> Load Symbols...
     • Make sure that the Program file entry is still set to your u-boot file. If not then browse to the proper file.
     • In the Code offset field enter the offset value you found before. i.e. 0x9F751000
     • In the Data offset

     

     IMPORTANT
     
     As was discussed in the presentation that accompanies this lab u-boot initially loads into low memory. U-Boot then relocates itself into high memory later to make room for the Linux kernel.
     
     This relocation is done by the relocate_code function which is called very early in the U-Boot process, generally in areas that should not need modification.
     
     In this lab we will be setting a breakpoint AFTER the code has been relocated, so you will have to reload the symbols as instructed below. However, if you truly did want to debug that early code you would not want to reload these symbols

6. The following steps will look familiar from the SPL debug lab and will cover setting breakpoints in U-Boot.
   • If you do not already have the board.c file open then do File -> Open File and navigate to the ti-sdk-am335x-evm-xx.xx.xx.xx/board-support/u-boot-xxxx.xx/board/ti/am335x dirctory and select board.c
   • Search for the definition of the board_init function (around line 488)
   • Set A HW Break Point at the start of function int board_init(void) (around line 488)

     NOTE
     
     This is done the same way as with SPL, by right-clicking the line number and selecting the HW breakpoint

7. Click the green run arrow to resume execution. You should see you hardware breakpoint be hit.
8. You can now do single step and step over operations in the same way you did for SPL.
9. CCS also has be ability to show you the contents of memory, which can be useful when debugging register values. To view a memory location do:
   • Click View -> Memory Browser
   • In the text box enter the following address and press ENTER
     • 0x44E10600
   • You should see output like the following

     

10. The value read above matches the Device ID value defined in the TRM

    NOTE
    
    You can find the Device ID value in the TRM in section 9.3.2 as well as its offset. Adding that offset to the base address for the CONTROL_MODULE registers found in table 2-2 of section 2.1 gives the address used of 0x44E10600

Perform Linux Kernel Debug

Description

This lab will show how to set debug the kernel. Here MLO and U-Boot are being loaded from the SD card. Next the vmlinux image is loaded that contains the debug information. A HW break point will be set and then using the boot command from a U-Boot prompt the kernel will be tftp'd from the host machine and the bootm command issued. As the kernel boots this particular break point should be hit as it is set in an initialization in the target board file which is executed on kernel boot.

Key Points

• Using vmlinux image to source level debug of the linux kernel
• Virtual to Physical location access

Lab Steps

1. If CCS is still connected click the red square icon to Terminate the connection
2. Make sure your SD card is not in the board
3. Re-launch the target configuration by
   • Right-clicking on the AM335x-TC file and selecting Launch Selected Configuration
   • Right-clicking on the CortxA8 line and selecting Connect Target

   IMPORTANT
   
   When using the XDS100v2 on a Beaglebone connecting to the target causes the system to reset and the boot sequence to start over. In this case you should perform the following steps
   # In CCS click the green run arrow
   # In minicom press any key to stop the autoboot

4. Put the SD card with the MLO and U-Boot image into the board
5. Go to your minicom window
6. Press the reset button on the EVM-SK and stop the autoboot
7. After stopping the auto boot sequence this is the output that should be seen on the serial console.

   

8. Click the yellow pause icon to Suspend the processor
9. From CCS load symbols from the vmlinux image from the debug configured kernel build
   • Click Run -> Load -> Load Symbols...
   • Click the Browse button and navigate to the linux source directory

     /home/sitara/ti-sdk-am335x-evm-xx.xx.xx.xx/board-support/linux-x.xx/

   • Change the filter to All as usual and select the vmlinux file

     
     
     

   • If you still have offsets configured from the U-Boot lab delete them
     
     

     

   • Click OK
10. Set a hardware breakpoint
    • Click File -> Open File
    • Navigate to the /home/sitara/ti-sdk-am335x-evm-xx.xx.xx.xx/board-support/linux-x.xx/drivers/leds/ directory
    • Select the leds-gpio.c file
    • Set the hardware breakpoint at the entry to the gpio_led_probe function.
      

    
    
    

    • The break point will now be displayed in the break point window
11. Resume the target by clicking the green run arrow
12. After resuming from the serial console press the enter key a few times, the u-boot prompt should be printed on each key press. This shows that the processor is executing U-Boot.
13. Boot theboard
    • On a HOST console run
    • boot
      
14. The kernel should now start to boot and stop at the HW break point
    • In the minicom window the processor is halted at the daughter card detection output
    • In the CCS window the processor is halted at the break point

      NOTE
      
      Always pause the execution before setting a breakpoint.

      NOTE
      
      A general note on pause and stop. Pause stops the execution so breakpoints, memory location etc. can be examined. The stop command terminates the debug session.

15. Like in the U-Boot portion of the lab the processor can be single stepped and step over functions.

    IMPORTANT
    
    Because the kernel is compiled with optimizations enabled the step functions do not always correspond directly to the lines of code. i.e. it may take multiple clicks to move one line.

16. Open a Memory Browser and see how to look at a physical location through a virtual address
    • The CCS memory browser is only able to use the virtual addresses that the Kernel has setup. To view a physical location an offset has to be added to the physical address that is in the TRM. For the AM335x that offset is 0xb5000000. This value is found here in the linux kernel source:
      • linux-x.xx/arch/arm/mach-omap2/iomap.h
      • AM33XX_L4_WK_IO_OFFSET 0xb5000000
    • Enter the address 0xF9E10600, this is the Device ID, the actual physical location 0x44E10600

    

    • Enter the address 0xF9E10630, this is the MAC IDs for the AM335x, the actual physical location 0x44E10630

    

17. Once done examining memory resume the target and let the kernel finish booting.

    IMPORTANT
    
    Leave the board in this state for the next Lab. You should be booted up into Linux now.

Additional Debug Path using Debug Access Port (DAP)

1. This Lab continues where the previous one left off with Linux fully booted and running and CCS connected to the Cortex-A8.

   • NOTE
     
     Debugging so far has been through the ARM Cortex-A8, but what if something is wrong and you can't read memory mapped locatons. One example may be the MMU table is not correct. Then there is a another path to the L4 bus that bypasses the ARM/MMU and you can access physical memory addresses.

2. If CCS is still connected click the yellow square icon to Pause execution.
3. Now we are going to connect to DAP and view memory.
   • Start by Right-clicking on the AM335x-TC in the debug window on CCS and select Show all cores

   

   • Then you should see another entry appear called "Non Debuggable Devices".
   • If you click on Non Debuggable Devices, you should see some more entries including: "CS_DAP_DebugSS" which maybe already connected.
   • If Disconnected then right click on CS_DAP_DebugSS and connect.

   

   • Once connected, go back to the Memory Debug window and type in the physical address: 0x44E10600. Notice that even though we are booted up to Linux with the MMU enabled, we can view this register bypassing the ARM.

   

   • NOTE
     
     The Memory Browser is updated depending on which debug path you have highlighted. If you have highlighted the CS_DAP_DebugSS then you can bypass the ARM and read physical addresses. If you selected the Cortex-A8 and it is highlighted, then you will be reading through the ARM/MMU.