• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Subscribers 99 subscribers
  • Views 9769 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.

Linux/AM5728: U-Boot Fails to Debug, SPL works

Tom W
Expert 1280 points
Part Number: AM5728

Tool/software: Linux

Hello, I'm wondering if anyone can enlighten me as to why my U-Boot fails to debug.  I've been following the U-Boot guide: 

and while my SPL works as intended, U-Boot will get stuck immediately upon running.  U-Boot loads to the correct RAM address, 0x80800000, has viewable memory in the CCS debugger, and scoping the power rails for our RAM chips shows action during the end stages of the SPL, which to the best of our knowledge indicates the relocation that happens at the end of the SPL occurs.  

However, when U-Boot is loaded via JTAG and run, even with DEBUG defined, no messages appear on the serial console, and since there are no programming symbols, it is impossible to tell where the program crashes.  Any ideas?  This is a rather large blocker for us, and it's got me stumped.

ADDENUM: I know that I have a similar post here:

but I've reached a wall with this, and I just need a nudge in the proper direction.

  • 0
    TI__Guru**** 170625 points
    Hi Tom,

    What version of AM572x PSDK you are using?

    There is more recent wiki than the one you are using, see below:

    processors.wiki.ti.com/.../Sitara_Linux_Training:_uboot_linux_debug_with_ccsv5_sdk7

    See also if you are hitting LCPD-8265 issue:

    processors.wiki.ti.com/.../Processor_SDK_Linux_Release_Notes

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Expert 1280 points
    I am using PSDK v3.03, and CCSv7. I can apply my changes to a PSDK v4 and retry.
  • 0 in reply to Pavel Botev
    Expert 1280 points

    I have applied my RAM config and device tree changes to a PSDK 4 u-boot build and followed the debug training link you shared earlier, and found no success.  The same problem is occurring where I receive no debug information while running u-boot.

  • 0 in reply to Tom W
    TI__Guru**** 170625 points
    Hi Tom,

    You fail to debug u-boot, but are you able to load/boot u-boot successfully? The problem might be in DDR not function properly. Have you verified DDR is correct? If yes, how?

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Expert 1280 points

    That could be it.  But I've been up and down my DDR configs and they seem okay.  My current hypothesis is that u-boot gets stuck in some loop before the debug banner is sent out over UART. 

    I am not able to load/boot u-boot to the linux kernel.  I've been following the training guide above, where u-boot is loaded into SDRAM via JTAG.  The fact that u-boot-spl manages to relocate the PC register to 0x80800000 and that U-Boot, which is larger than the SRAM cache on the AM5728, actually loads onto the board via JTAG, makes me think that my SDRAM config is working. 

  • 0 in reply to Tom W
    TI__Guru**** 170625 points
    Hi Tom,

    Please check if you are aligned with the below DDR config requirements:

    www.ti.com/.../sprac36a.pdf

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Expert 1280 points
    I've been through that workbook before, but reading through it and the AM5728 Technical Reference Manual again, I have a couple questions about a discrepancy that I've found.

    In the SPRAC36 workbook, my resulting array of EMIF_EXT_PHY_CTRL registers are all commented out. This makes some sense, as we are using hardware levelling and these registers are for software levelling, for the most part. However, in the AM572x TRM, section 15.3.5.1.1.1, it notes that even if I'm using hardware levelling, my EMIF_EXT_PHY_CTRL_1 register should have some populated values. Which should I follow?

    Another thing, after following the 'Quick and Easy' section in this wiki page: processors.wiki.ti.com/.../Common_DDR_Issues I have noticed that when I load U-Boot after running through the SPL, I can view memory in both CPU Memory View and Physical Memory View. Adjusting a value in Physical Memory View does not change the value at the same address in CPU Memory View, and vice versa. Is this normal?
  • 0 in reply to Tom W
    TI__Guru**** 170625 points

    Tom Wallis said:
    In the SPRAC36 workbook, my resulting array of EMIF_EXT_PHY_CTRL registers are all commented out. This makes some sense, as we are using hardware levelling and these registers are for software levelling, for the most part. However, in the AM572x TRM, section 15.3.5.1.1.1, it notes that even if I'm using hardware levelling, my EMIF_EXT_PHY_CTRL_1 register should have some populated values. Which should I follow?

    I think EMIF_EXT_PHY_CONTROL_1 register should be used for HW leveling. I see it is use for AM57x TI board DDR3 configuration in u-boot and in GEL file.

    u-boot/arch/arm/include/asm/emif.h
    u-boot/arch/arm/mach-omap2/emif-common.c
    u-boot/arch/arm/mach-omap2/omap5/sdram.c
    u-boot/board/ti/am57xx/board.c

    ccsv6/ccs_base/emulation/boards/am572x/gel/AM572x_ddr_config.gel

    You can also test your DDR3 memory as shown in below wiki:

    http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_Tuning_the_DDR3_Timings_on_BeagleBoneBlack#Test_the_DDR3_Configuration

    I would also suggest to try u-boot debug on AM57x TI boards (EVM or IDK) where DDR3 is working fine, thus you will isolate DDR3 malfunction.

  • 0 in reply to Pavel Botev
    Expert 1280 points

    Ah, excellent point.  I'll keep that register in then.

    Regarding the DDR3 test in the wiki page you linked, we've gone through that process and the values 'stick' but when we try to use the Fill Memory option, those values do NOT stick.  Any ideas as to why that is?

  • 0 in reply to Pavel Botev
    Expert 1280 points
    Is there a possibility that the inability to step through U-Boot is caused by not having the U-Boot symbols, and U-Boot getting stuck before it can print anything? I've noticed that whenever I pause the debugger, it's stuck in:

    fdt_find_regions(void *, unsigned char * *, int, unsigned char * *, int, struct fdt_region *, int, unsigned char *, int, int)

    Which looks it could be caused by some error in my device tree.

    I'm still fairly convinced that it's the RAM configuration being ornery, but if it were the device tree that could also be plausible.
  • 0 in reply to Pavel Botev
    Expert 1280 points
    One more thing: I used a fresh PSDK image for the AM5728 EVM (GP) and the same behaviour in U-Boot can be observed.
  • 0 in reply to Pavel Botev
    Expert 1280 points

    Hello, just wondering if there are any updates on this?  I've continued working on this also noted that when u-boot and the MLO are loaded onto an SD card (via the create-sdcard.sh script, then clearing out the contents of the rootfs partition) no U-Boot console appears when we use our custom board, but using the EVM with a stock PSDK4 release with just U-Boot and MLO in the method described above results in the U-Boot console loading, as expected.  However, attemtping to use the bdinfo results from the EVM on our product have so far been unsuccessful due to differing RAM sizes resulting in the math to find the offset.

  • 0 in reply to Tom W
    TI__Genius 15510 points

    The labs need some updating. SPL/;u-boot now use device trees that are appended in the built process. For SPL you probably want to use u-boot-spl-dtb.bin. For u-boot you probably want to use u-boot-dtb.bin for debugging. For symbols you can still use the ELF binaries.

    Steve K.

  • 0 in reply to Steve Kipisz
    Expert 1280 points
    For u-boot-dtb.bin should I use the tools->load memory option again, loaded to 0x80800000?
  • 0 in reply to Tom W
    Intellectual 470 points

    Tom any resolution to this issue?  Was it a DDR issue or the device tree, or symbol problem and what did you do to resolve the problem?

  • 0 in reply to Tracy Smith6
    Expert 1280 points

    Tracy Smith6 said:

    Tom any resolution to this issue?  Was it a DDR issue or the device tree, or symbol problem and what did you do to resolve the problem?

    Hi Tracy,

    It was a problem with the methodology of the wiki.  Essentially the u-boot.bin that the wiki article at the original post mentions needs to be u-boot-dtb.bin.  This may be because that wiki article was written before the device tree was added to U-Boot and Linux.  For SPL I also used u-boot-spl-dtb.bin and had some success there too.  I never did manage to get the Linux debug working, sadly.

    I also noticed while getting U-Boot and SPL running that I had an EMIF configuration issue, and once I modified that I was able to get to the U-Boot command line.

  • 0 in reply to Tom W
    Intellectual 470 points

    thanks Tom. Looking at similar concerns now.