[SOLVED] Problems debugging u-boot on iMX6Q sabresd board

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] Problems debugging u-boot on iMX6Q sabresd board

    Hello,


    I am trying to debug u-boot running on an iMX6Q sabresd board from RAM with a JLink plus. I followed the instructions from this tutorial:

    boundarydevices.com/debugging-using-segger-j-link-jtag/

    I can debug only the code that is written in assembler, when the code gets to C code, and I try step, gdb gets stuck forever.

    Find attached the output from gdb and JLinkGDBServer.

    This is my gdb init file:



    Source Code

    1. # Sabre SD
    3. # Initializing target
    4. target remote localhost:2331
    5. monitor reset
    6. monitor halt
    7. monitor sleep 200
    9. monitor memU32 0x020e0798=0x000C0000
    10. monitor memU32 0x020e0798
    11. monitor memU32 0x020e0758=0x00000000
    12. monitor memU32 0x020e0588=0x00000030
    13. monitor memU32 0x020e0594=0x00000030
    14. monitor memU32 0x020e056c=0x00000030
    15. monitor memU32 0x020e0578=0x00000030
    16. monitor memU32 0x020e074c=0x00000030
    17. monitor memU32 0x020e057c=0x00000030
    18. monitor memU32 0x020e058c=0x00000000
    19. monitor memU32 0x020e059c=0x00000030
    20. monitor memU32 0x020e05a0=0x00000030
    21. monitor memU32 0x020e078c=0x00000030
    22. monitor memU32 0x020e0750=0x00020000
    23. monitor memU32 0x020e05a8=0x00000030
    24. monitor memU32 0x020e05b0=0x00000030
    25. monitor memU32 0x020e0524=0x00000030
    26. monitor memU32 0x020e051c=0x00000030
    27. monitor memU32 0x020e0518=0x00000030
    28. monitor memU32 0x020e050c=0x00000030
    29. monitor memU32 0x020e05b8=0x00000030
    30. monitor memU32 0x020e05c0=0x00000030
    31. monitor memU32 0x020e0774=0x00020000
    32. monitor memU32 0x020e0784=0x00000030
    33. monitor memU32 0x020e0788=0x00000030
    34. monitor memU32 0x020e0794=0x00000030
    35. monitor memU32 0x020e079c=0x00000030
    36. monitor memU32 0x020e07a0=0x00000030
    37. monitor memU32 0x020e07a4=0x00000030
    38. monitor memU32 0x020e07a8=0x00000030
    39. monitor memU32 0x020e0748=0x00000030
    40. monitor memU32 0x020e05ac=0x00000030
    41. monitor memU32 0x020e05b4=0x00000030
    42. monitor memU32 0x020e0528=0x00000030
    43. monitor memU32 0x020e0520=0x00000030
    44. monitor memU32 0x020e0514=0x00000030
    45. monitor memU32 0x020e0510=0x00000030
    46. monitor memU32 0x020e05bc=0x00000030
    47. monitor memU32 0x020e05c4=0x00000030
    48. monitor memU32 0x021b0800=0xa1390003
    49. monitor memU32 0x021b080c=0x001F001F
    50. monitor memU32 0x021b0810=0x001F001F
    51. monitor memU32 0x021b480c=0x001F001F
    52. monitor memU32 0x021b4810=0x001F001F
    53. monitor memU32 0x021b083c=0x43270338
    54. monitor memU32 0x021b0840=0x03200314
    55. monitor memU32 0x021b483c=0x431A032F
    56. monitor memU32 0x021b4840=0x03200263
    57. monitor memU32 0x021b0848=0x4B434748
    58. monitor memU32 0x021b4848=0x4445404C
    59. monitor memU32 0x021b0850=0x38444542
    60. monitor memU32 0x021b4850=0x4935493A
    61. monitor memU32 0x021b081c=0x33333333
    62. monitor memU32 0x021b0820=0x33333333
    63. monitor memU32 0x021b0824=0x33333333
    64. monitor memU32 0x021b0828=0x33333333
    65. monitor memU32 0x021b481c=0x33333333
    66. monitor memU32 0x021b4820=0x33333333
    67. monitor memU32 0x021b4824=0x33333333
    68. monitor memU32 0x021b4828=0x33333333
    69. monitor memU32 0x021b08b8=0x00000800
    70. monitor memU32 0x021b48b8=0x00000800
    71. monitor memU32 0x021b0004=0x00020036
    72. monitor memU32 0x021b0008=0x09444040
    73. monitor memU32 0x021b000c=0x555A7975
    74. monitor memU32 0x021b0010=0xFF538F64
    75. monitor memU32 0x021b0014=0x01FF00DB
    76. monitor memU32 0x021b0018=0x00001740
    77. monitor memU32 0x021b001c=0x00008000
    78. monitor memU32 0x021b002c=0x000026d2
    79. monitor memU32 0x021b0030=0x005A1023
    80. monitor memU32 0x021b0040=0x00000027
    81. monitor memU32 0x021b0000=0x831A0000
    82. monitor memU32 0x021b001c=0x04088032
    83. monitor memU32 0x021b001c=0x00008033
    84. monitor memU32 0x021b001c=0x00048031
    85. monitor memU32 0x021b001c=0x09408030
    86. monitor memU32 0x021b001c=0x04008040
    87. monitor memU32 0x021b0020=0x00005800
    88. monitor memU32 0x021b0818=0x00011117
    89. monitor memU32 0x021b4818=0x00011117
    90. monitor memU32 0x021b0004=0x00025576
    91. monitor memU32 0x021b0404=0x00011006
    92. monitor memU32 0x021b001c=0x00000000
    94. # set the default clock gate to save power
    95. monitor memU32 0x020c4068=0x00C03F3F
    96. monitor memU32 0x020c406c=0x0030FC03
    97. monitor memU32 0x020c4070=0x0FFFF000
    98. monitor memU32 0x020c4074=0x3FF00000
    99. monitor memU32 0x020c4078=0x00FFF300
    100. monitor memU32 0x020c407c=0x0F0000F3
    101. monitor memU32 0x020c4080=0x000003FF
    103. # enable AXI cache for VDOA/VPU/IPU
    104. monitor memU32 0x020e0010=0xF00000CF
    106. # set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7
    107. monitor memU32 0x020e0018=0x007F007F
    108. monitor memU32 0x020e001c=0x007F007F
    110. #
    111. # Setup CCM_CCOSR register as follows:
    112. #
    113. # cko1_en = 1 --> CKO1 enabled
    114. # cko1_div = 111 --> divide by 8
    115. # cko1_sel = 1011 --> ahb_clk_root
    116. #
    117. # This sets CKO1 at ahb_clk_root/8 = 132/8 = 16.5 MHz
    118. #
    119. monitor memU32 0x020c4060=0x000000fb
    Display All
    What Am I doing wrong?

    Best regards,

    Oscar.
    Files

    • gdb.txt

      (9.89 kB, downloaded 436 times, last: )

    • JLinkGDBServer.txt

      (260.94 kB, downloaded 359 times, last: )

  • From the logs, I do not see anything being „stuck“. Looks normal from what I can say.
    But if source level stepping is a problem, while instruction stepping works, it most probably is an issue with GDB not being able to read the debug information of the ELF file properly and then calculating wrong addresses for source BPs to be set etc.

    A few hints:
    Did you use the same GCC + GDB version as recommended by the tutorial?
    Did you make sure that the GDB used for debugging, comes from the same toolchain installation as the GCC that built the ELF file?

    We have seen problems in the past, where one GDB could not read ELF files properly that have been created with a different GCC version.
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Hello Alex,

    Many thanks for your answer. I can't use the Linaro toolchain used in the tutorial because I am debugging a newer version of u-boot and this version needs at least GCC 6.0 (the toolchain used in the tutorial is gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf.tar.xz).

    I always used the gdb that comes with the toolchain I built u-boot.

    I tried the following toolchains:

    - The external SDK from the NXP's yocto project for IMX processors (version imx-yocto-L5.10.35_2.0.0).
    - gcc-arm-linux-gnueabihf from Ubuntu's 20.04 repositories.

    All these toolchains are behaving the same way.

    The procedure is the following:

    Start JLinkGDBServer:

    JLinkGDBServer -device MCIMX6Q6

    Start gdb:

    1) gdb --nx -ix /media/oscar/b1877f95-cdff-4928-9aa1-3dfe90603ba8/imx/debugging/gdbinit_sabrsd u-boot
    2) Inside gdb I load symbols and set a brekpoint in s_init symbol.
    3) start the program (continue).
    4) At this point gdb stops at s_init. Next assembly instruction is "x17803d70 <s_init> push {r3, lr}"

    At this point executing single stepping (si) always returns to the instruction "x17803d70 <s_init> push {r3, lr}"

    Find attached JLinkGDBServer output for this session and a picture from gdb's assembly view.

    I also tried to add an extra breakpoint at _start in order to check if the board is reseting and it is not.

    Many thanks.

    Best regards,
    Oscar
    Files

    The post was edited 1 time, last by OscarNext ().

  • Again, I do not see any misbehavior on the J-Link side.
    The PUSH is a breakpointed instruction, so the core is halted on a BP.
    Now you tell GDB to do an single instruction step.
    What you should see is:
    Remove BP
    Step
    Set BP

    What GDB actually does is:
    Remove BP
    Set BP
    Go

    So it looks like GDB does not do what you told it to do and the core is halted immediately again because it hits the BP.

    J-Link is not allowed to overstep the BP on its own because. GDB expects to do stuff like this by itself, not by the GDB Server it is connected to.

    You should get in touch with the GDB vendor, as this looks like a bug in the build of it.

    J-Link is working fine with tons of GDB builds, so a generic single stepping issue on the J-Link side is very unlikely.
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.