• State Accepted Answer
  • Replies 1 reply
  • Subscribers 121 subscribers
  • Views 164 views
  • Users 0 members are here
Options
Related
How was your experience today?

DS-5 Problems debugging u-boot

Jacqueline Maatuq

Dear colleagues,

I am trying to debug U-Boot as bare Metal Core A5 and facing some issues.
After connecting to target DS-5 loads the ELF image and debugger stops in start.S at _start: b reset.
I can see all U-Boot functions in funtions tab, but in tab variables I can not expand the e.g. Globals or File Static Variables.
I can set a breakpoint in crt0.S at b relocate_code, but after the code has been relocated I cannot set breakpoint after this 'function' e.g. at bl c_runtime_cpu_setup.

Selecting a U-boot function within the function tab loads the corresponding C file and I can set a breakpoint (at one of the command handler).
Continuing and entering the command into the hush shell stops sometimes execution, but there is no stack trace or variables visible and the debugger stops every time I click 'continue' 
debugger stops every time at a 'pseudo' breakpoint (visible in the command tab'

I build U-boot 2013.07 with CFLAGS -g -Og -fno-omit-frame-pointer (this is diabled by default).
During build the linker complained with
   u-boot relocation R_ARM_MOVW_ABS_NC against `a local symbol' 
So I added the -fPIC
I checked for symbols with readelf.


- Debug from Entry Point
No OS awareness

My equipment:
DS-5 5 .25.0/Eclipse Luna SR2(4.4.2) with ARM Keil uLlinkPro.
Timesys factory gcc 4.9.3 (imported the project as makefile project)
The board is Phytect PCM052

Upgrading the environment is not an option.
BTW: With this equiment I am able to debug bare metal M4 NXP MQX.

What am I doing wrong ? Configuration U-Boot Compiler/ Linker options ? Configuration DS-5 ? 

Thanks for your support.

Parents
  • +1

    Hi,

    My name is Stephen and I work at Arm.

    Thanks for your clear description of your issues :)

    DS-5 5.25.0 is a _very_ old toolkit.  I know you wrote "Upgrading the environment is not an option.", but please consider updating to Arm DS 2024.0.  You will still be able to plug-in the Timesys factory gcc 4.9.3 compiler.  As time goes by, it becomes increasingly difficult for us to support legacy toolkits.

    To be able to view the Globals and File Static variables in the Variables view, you must first explicitly add them to the Variables view.  In the bottom right of the Variables view, click Browse to display the Add Variable dialog.  Expand the required folders and filenames to see the variables they contain. Then select one or more variables that you are interested in and click OK to add them to the Variables view.  Ctrl+A selects all the variables that are visible in the dialog.  Selecting a filename or folder does not automatically select its variables.  See:

    developer.arm.com/.../variables-view

    Local variables are usually held in processor registers (except for larger items that get spilled onto the Stack), which is fast and efficient.  By contrast, File Static and Global variables are held in RAM, accessed via the memory system.  So this approach of having to add memory-based variables keeps the Debugger's intrusiveness on the target's memory system under the user's control, which is especially important for e.g. board bring-up scenarios, where the memory system might not be fully working correctly.

    From your description, it sounds like code and/or data is being moved (relocated) at run-time.  I guess the debug symbols in your "u-boot" executable file describe the locations of symbols _before_ they are moved.

    To be able to debug at source level _after_ they are moved, an offset must be applied to the addresses in the debug information.  To apply the offset after executing, c_runtime_cpu_setup(), first unload the existing symbols with a command in the Commands view:
    file

    then reload the symbols, with an offset with, e.g.:
    add-symbol-file /path/to/u-boot <offset>
    where <offset> is the numeric difference between their address after moving and their source address before moving.  The address offset might be positive or negative, depending on whether code/data is being moved forwards or backwards in memory.  See:

    developer.arm.com/.../add-symbol-file

    You can use the built-in expression evaluator to do the maths for you, e.g.:
    add-symbol-file /path/to/u-boot (0x8765000-0x1234000)

    Depending on whether your code executes in Secure (S:) or Non-secure (N:) address space, you might need to qualify the offset with the appropriate address prefix, e.g.:
    add-symbol-file /path/to/u-boot S:(0x8765000-0x1234000)

    So I think you just need to reload the symbols with an offset - no -fPIC needed!

    Hope this helps

    Stephen

Reply
  • +1

    Hi,

    My name is Stephen and I work at Arm.

    Thanks for your clear description of your issues :)

    DS-5 5.25.0 is a _very_ old toolkit.  I know you wrote "Upgrading the environment is not an option.", but please consider updating to Arm DS 2024.0.  You will still be able to plug-in the Timesys factory gcc 4.9.3 compiler.  As time goes by, it becomes increasingly difficult for us to support legacy toolkits.

    To be able to view the Globals and File Static variables in the Variables view, you must first explicitly add them to the Variables view.  In the bottom right of the Variables view, click Browse to display the Add Variable dialog.  Expand the required folders and filenames to see the variables they contain. Then select one or more variables that you are interested in and click OK to add them to the Variables view.  Ctrl+A selects all the variables that are visible in the dialog.  Selecting a filename or folder does not automatically select its variables.  See:

    developer.arm.com/.../variables-view

    Local variables are usually held in processor registers (except for larger items that get spilled onto the Stack), which is fast and efficient.  By contrast, File Static and Global variables are held in RAM, accessed via the memory system.  So this approach of having to add memory-based variables keeps the Debugger's intrusiveness on the target's memory system under the user's control, which is especially important for e.g. board bring-up scenarios, where the memory system might not be fully working correctly.

    From your description, it sounds like code and/or data is being moved (relocated) at run-time.  I guess the debug symbols in your "u-boot" executable file describe the locations of symbols _before_ they are moved.

    To be able to debug at source level _after_ they are moved, an offset must be applied to the addresses in the debug information.  To apply the offset after executing, c_runtime_cpu_setup(), first unload the existing symbols with a command in the Commands view:
    file

    then reload the symbols, with an offset with, e.g.:
    add-symbol-file /path/to/u-boot <offset>
    where <offset> is the numeric difference between their address after moving and their source address before moving.  The address offset might be positive or negative, depending on whether code/data is being moved forwards or backwards in memory.  See:

    developer.arm.com/.../add-symbol-file

    You can use the built-in expression evaluator to do the maths for you, e.g.:
    add-symbol-file /path/to/u-boot (0x8765000-0x1234000)

    Depending on whether your code executes in Secure (S:) or Non-secure (N:) address space, you might need to qualify the offset with the appropriate address prefix, e.g.:
    add-symbol-file /path/to/u-boot S:(0x8765000-0x1234000)

    So I think you just need to reload the symbols with an offset - no -fPIC needed!

    Hope this helps

    Stephen

Children
No data