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

am3352 SPL issue

Bernhard Breinbauer
Prodigy 60 points

Other Parts Discussed in Thread: AM3352

Hi,

I'm currently trying to bring up a custom AM3352 based board. It is quite similar to the BB, but we are using a 25MHz oscillator and a different DDR RAM chip. The boot pins are configured for 25MHz and boot sequence MMC0, SPI0, UART0, USB0 (LCD_DATA[15..0] 1000 0000 0011 0111).

The HW engineer checked the voltage signals and power up and they seem to be valid. The ROM bootloader boots and starts to print out 'C' characters on UART0.

I configured the u-boot SPL for 25MHz, but did not configure for the DDR yet as I first want the SPL to start up.

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 3e0439e..f8f3b59 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -214,7 +214,7 @@
 #endif

 /* Clock Defines */
-#define V_OSCK                         24000000  /* Clock output from T2 */
+#define V_OSCK                         25000000  /* Clock output from T2 */
 #define V_SCLK                         (V_OSCK)

When I provide the resulting SPL (either via UART0/xmodem or via uSD card) no further 'C' characters are printed but also no other output is printed. I guess, the SPL is booted but gets stuck somewhere before getting the chance to print anything (even though u-boot DEBUG is turned on for early debug messages). Also I guess the AM3352 is functional as the ROM bootloader seems to work correctly.

The same SPL binary boots quite fine on a BB (interestingly enough even though 25MHz are configured).

I get a XDS100 in a few days to look further into the issue, but does someone have some pointers where to look at and what to try to get a better understanding of the problem? Or maybe even a solution ;)

Thanks,

Bernhard

  • 0
    Expert 1530 points

    Hi Bernhard,

    From my experience working around SPL boot up I recall that it uses DRAM.

    Static variables go to addresses above 0x8000 0000.

    The SPL code one could easily load and step through using XDS100 (you currently have no but you should: it helps).

    Also greatly helped toggling a LED and study LED diagram using oscilloscope.

     

    rgds,

  • 0 in reply to sviss
    Prodigy 60 points

    Hi sviss,

    thanks for your response. Are you sure the SPL uses the external RAM? My understanding is that the main purpose of the SPL is to run only with internal RAM and initialize the external RAM for the full u-boot binary. Also the config_ddr() is called at the end of s_init(), and according to my debug printfs I never get to this function call.

    I'm looking forward to the arrival of the XDS100, as I need it quite urgently ;) (It got delayed...)

    I modified the SPL to toggle a LED on beaglebone and on my board, I saw the LED toggling on BB but not on my board. But I did not check with the scope yet, will do that now.

    cheers,

    Bernhard

  • 0 in reply to Bernhard Breinbauer
    TI__Mastermind 25235 points

    Bernhard,

    The SPL runs from the internal memory, initializes the external DDR and loads U-Boot there. Using LED toggling throughout the boot code seems to be the only feasible solution at this point, before you get your debugger.

    Put some LED toggling code inside s_init(), perhaps even do something like a binary counter using a few LEDs and check with the oscilloscope where the s_init() function hangs.

    Best regards,
    Miroslav

  • 0 in reply to Bernhard Breinbauer
    Expert 1530 points

    Hi Bernhard,

    this is what I had:

    http://e2e.ti.com/support/arm/sitara_arm/f/791/t/244358.aspx

    As I recall, my board became operable after I enabled the DDR3 power. 

    HTH

    ps: my experience is not that big, and if Miroslav say please trust Miroslav first.

    I just looked into my u-boot.spl.map and see there:

    .bss 0x80000000 0x33088

    0x80000000 . = ALIGN (0x4)
    0x80000000 __bss_start = .
    *(.bss*)
    .bss.gpmc_cfg 0x80000000 0x4 arch/arm/cpu/armv7/am33xx/libam33xx.o
    0x80000000 gpmc_cfg
    .bss.elm_cfg 0x80000004 0x4 arch/arm/cpu/armv7/am33xx/libam33xx.o
    0x80000004 elm_cfg
    .bss.ctrlc_was_pressed
    0x80000008 0x4 common/libcommon.o
    .bss.ctrlc_disabled
    0x8000000c 0x4 common/libcommon.o
    .bss.max_total_mem
    0x80000010 0x4 common/libcommon.o

    Maybe I do not understand something .. :)

  • 0 in reply to Miroslav Kiradzhiyski XID
    Prodigy 60 points

    Hi Miroslav,

    thanks for your response. I'm going to do GPIO debugging for now, but I still think the uart should also work, especially as the ROM bootloader is using it already and as I see eg: the output ">>spl:board_init_r()\n" on the BB, which is at the very beginning of the SPL board_init_r() function.

    What different requirements do the ROM bootloader and the SPL have? Why would one be able to use uart and not the other?

    cheers,

    bernhard

  • 0 in reply to sviss
    Prodigy 60 points

    Hi sviss,

    thanks for the information. You are right SPL seems to put some stuff into DDR (maybe for later use by u-boot?). But In my case I do not get so far with booting. There is some DDR write access happening (eg: in board_init_f())  but no read, so I guess the DDR should be not a problem at the moment? Nevertheless I will also start on DDR3 configuration, btw. what DDR3 are you using? ;)

    cheers,

    bernhard

  • 0 in reply to Bernhard Breinbauer
    Expert 1530 points

    MT41J128M16

    > What different requirements do the ROM bootloader and the SPL have? 

    I do not remember there were any peculiarities. SPL prompt arrived instantly on the UART, after I proved the DDR is required, and powered it. Troubles with DDR? A simple test might help.

  • 0 in reply to sviss
    Prodigy 60 points

    Hello sviss, Miroslav,

    just a follow up: I got my XDS100 today. The problem was in  rtc32k_enable(). Our board does not use the internal RTC and therefore no 32k Osc is populated on the board. My guess is that activating the RTC resulted in an exception because of the missing Osc.

    Thanks for your support,

    bernhard