• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 1034 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.

Problem with SPL DEBUG for AM335x

long qin
Intellectual 915 points

According to http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_uboot_linux_debug_with_ccsv5,

during SPL debug,

In function board_init_r() (the filename is \board-support\u-boot-2013.01.01-psp06.00.00.00\common\spl\spl.c),

the sub function called is boot_device = spl_boot_device();

the value of boot_device is 0,

after the step,program jumps to

inline void hang(void)
{
    puts("### ERROR ### Please RESET the board ###\n");
    for (;;)
        ;
}

in fact ,i boot mode is set as UART0.

I think boot_params is not correctly set,where is set for params ?

and where does source code of  save_boot_params function  locate ?

  • 0
    TI__Guru**** 393215 points
    Hi Qin,
     
    Please take a look at this thread:
     
    I think your problem is related to the solution found in the last post there.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 915 points

    Hi Biser

    I read through it,and it's useful to me.

    But how can i fixed the problem with save_boot_params function.

    Best Regards

    Qin Long

  • 0 in reply to long qin
    TI__Mastermind 25235 points

    Hi Qin Long,

    Please check this U-Boot cross reference:

    http://code.metager.de/source/xref/denx/u-boot/arch/arm/cpu/armv7/am33xx/board.c#214

    Here you will find the usage of the save_omap_boot_params() function Benjamin mentions in the other thread. This function isn't present in the U-Boot from the TI SDK. It also seems like the s_init() function (early system initialization) has been moved from u-boot/board/ti/am335x/board.c to u-boot/arch/arm/cpu/armv7/am33xx/board.c. What  they did to fix their issue is to import the save_omap_boot_params() function and use it in the s_init() as shown in the cross reference link I posted above.

    Best regards,
    Miroslav

  • 0 in reply to Miroslav Kiradzhiyski XID
    TI__Genius 15510 points

    save_omap_boot_params() does exist in the TI SDK. Look in arch/arm/cpu/armv7/omap-common/lowlevel_init.S. You will find

     33 ENTRY(save_boot_params)
     34         /*
     35          * See if the rom code passed pointer is valid:
     36          * It is not valid if it is not in non-secure SRAM
     37          * This may happen if you are booting with the help of
     38          * debugger
     39          */
     40         ldr     r2, =NON_SECURE_SRAM_START
     41         cmp     r2, r0
     42         bgt     1f
     43         ldr     r2, =NON_SECURE_SRAM_END
     44         cmp     r2, r0
     45         blt     1f
     46
     47         /*
     48          * store the boot params passed from rom code or saved
     49          * and passed by SPL
     50          */
     51         cmp     r0, #0
     52         beq     1f
     53         ldr     r1, =boot_params
     54         str     r0, [r1]
     55 #ifdef CONFIG_SPL_BUILD
     56         /* Store the boot device in spl_boot_device */
     57         ldrb    r2, [r0, #BOOT_DEVICE_OFFSET]   @ r1 <- value of boot device
     58         and     r2, #BOOT_DEVICE_MASK
     59         ldr     r3, =boot_params
     60         strb    r2, [r3, #BOOT_DEVICE_OFFSET]   @ spl_boot_device <- r1

    Section 26.1.10.2 explains the Booting Parameters Structure. There is a byte the describes which device you booted from. The only time I've seen this as 0 was when I loaded SPL through JTAG and bypassed the boot ROM.

    Steve K.

  • 0 in reply to Steve Kipisz
    Intellectual 915 points

    Hi Steve K

    Thanks a lot for reply.

    above funtion will be executed at the start of reset,

    but underdebug mode,the follow code just run,

    ldr r2, =NON_SECURE_SRAM_START

    cmp r2, r0

    bgt 1f

    thenbgt 1f will be true,so jump to

    1: bx lr

    so the boot_device will not be set. in other words,under debug mode,r0 is not expired value,

    it can not run correctly.

    if not in debug mode,it can run correctly, Why?

    Best Regards

    Qin Long

  • 0 in reply to long qin
    Intellectual 915 points

    According to section 26.1.10.2 Execution in "AM335x ARM® Cortex™-A8 Microprocessors (MPUs) Technical Reference Manual", Booting Parameters Structure is described,how i can know the address os the structure?

    Best Regards

    Qin Long