SPL on Custom AM335x Board

Jason,

Can you disable CONFIG_DRIVER_TI_CPSW and see what is the behavior? Also can you share what is the exact time taken to boot?

Renjith,

CONFIG_DRIVER_TI_CPSW is disabled.  The board I have never boots properly from either MMC/SD or from the UART boot mechanism.  It does show "C" on the Uart console and I am able to connect to it.

Jason,

I'm not able to understand your test scenario properly? Can you explain me in detail, which all boot modes works for you? What is the time taken to boot in each of the mode? If possible, please share the complete logs.

Hello Renjith,

I've been working with Jason on this board, and here is the scenario...

1. We have disabled Ethernet, and at this point we are just trying to boot the board to run the SPL and U-boot.

2. Please see the forum post - http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/791/p/223017/786287.aspx#786287

3. The system powers up fine, we've checked all the rails, and the sequence. The board prints out the default lines on the console when preloader_console_init function is executed in the s_init function. It is after this that there seems to be a long delay and this delay is inconsistent, it sometimes prints out OMAP SD/MMC : 0 but then it just hangs. There was just one time that U-boot was able to run, but we have not been able to replicate it.

4. Also in rp_connect2.h file I've declared CONFIG_NO_ETH and hence the CONFIG_DRIVER_TI_CPSW and all Ethernet support is not defined.

Hope this helps to clarify the situation, thanks a lot for taking the time out to reply.

Regards

Santhosh

Santhosh,

Can you share the complete serial logs with time stamps. You can do this by saving the logs using teraterm with timestamp enabled or using grabserial utility.

Hello Renjith,

This is what I see with the grabserial utility...

Attempt 1

0.00       0    
0.00       0    U-Boot SPL 2011.09 (Oct 30 2012 - 09:14:10)
0.00       0    Texas Instruments Revision detection unimplemented
11.54    1154    8F��c� F��� !F��}�p� F��-�A    �I    h���!� "���: 1751187456, '��A@L|: -1622142942,

Attempt 2

0.00       0    
0.00       0    U-Boot SPL 2011.09 (Oct 30 2012 - 09:14:10)
0.00       0    Texas Instruments Revision detection unimplemented
37.20    3719    O: 0,

Hope these help a little...

Thank you so much for your patience and replies.

Regards

Santhosh

Santhosh,

I think there is something seriously wrong with the clock settings.

I believe that you are junk in UART because of the change in baud-rate that's happening. So there are two simple ways to confirm this. First try different baud rates from your teraterm/minicom window and see whether you can get any meaningful prints from uart. Or else, connect an oscilloscope to UART output and measure the baudrate at which it sends delayed prints. 

What are the major changes that you've done w.r.t the original SPL code?

Attached is the diff between the base UBOOT code and the code that was modified.  Thanks for your time to review.  4846.diff2.txt

-Jason

Hello Renjith,

Thank you again for your replies, but I do not think there is something seriously wrong with the clock settings. Here is why...

1. If you look at the function s_init declared in evm.c, you will notice that pll_init is called before initializing the UART, memory etc.

2. In the function preloader_console_init which is defined in spl.c, the printf statements for the first 2 lines are called after setting up the baudrate. So again the baudrate change is not cause of the weird characters printed out from the terminal.

3. I have placed multiple debug printfs till the point where the spl_load_image function is executed and every single one of them gets printed correctly.

So I agree that something is wrong with the pll settings but I don't believe it's for the processor, my suspicion is that DDR settings are wrong. The reason I say that is because although SPL runs in internal RAM it does use external memory for it's bss section. I think that it's being corrupted..because the access to DDR RAM is not consistent.

Again this is my theory, but I will go through the tests you have recommended and post the results. Thank you once again for taking the time out and also for your patience.

Regards

Santhosh

Hello Renjith,

I tried changing the baudrate on my serial console once the messages start printing but I have not seen any change so far, are there any other hints or suggestions for me?

Thank you

Regards

Santhosh

Hello Renjith, Jason,

I added a few printf statements to my DDR initialization and then used grabserial utility to print them out with timestamps...here is what I have..

Please note that I'm running the code from CCS so it says that there are no boot devices found. The format is simple...

SR - my initial

func1 - current function

message - whatever is the message

The two places where I can see significant delay is with CONFIG registers...I don't know why it takes 8ms to write to those registers.

0.00       0    
0.00       0    U-Boot SPL 2011.09 (Nov 01 2012 - 12:26:15)
0.00       0    Texas Instruments Revision detection unimplemented
0.01       0    SR: s_init - i2c enabled
0.01       0    SR: s_init - entering ddr_pll_config
0.02       0    SR: s_init - entering config_am335x_ddr2
0.02       0    SR: config_am335x_ddr2 - mddr clocks enabled
0.03       0    SR: config_am335x_ddr2 - config_vtp done
0.03       0    SR: config_am335x_ddr2 - Cmd_Macro_Config_ddr2 done
0.03       0    SR: config_am335x_ddr2 - Data_Macro_Config_ddr2 done
0.04       0    SR: config_am335x_ddr2 - DATAx_RANK0_DELAYS_0 written
0.04       0    SR: config_am335x_ddr2 - DDR_CMDx_IOCTRL and DDR_DATAx_IOCTRL written
0.05       0    SR: config_am335x_ddr2 - DDR_IO_CTRL and DDR_CKE_CTRL written
0.05       0    SR: config_am335x_ddr2 - Entering function config_emif_ddr2
0.06       0    SR: config_emif_ddr2 - EMIF4_0_DDR_PHY_CTRL_x values written
0.06       0    SR: config_emif_ddr2 - EMIF4_0_SDRAM_TIM_x values written
8.92     885    SR: config_emif_ddr2 - EMIF4_0_SDRAM_CONFIG values written
8.92       0    SR: config_emif_ddr2 - EMIF4_0_SDRAM_REF_CTRL values written
8.93       0    Starting delay...
8.93       0    SR: config_emif_ddr2 - End delay
8.93       0    SR: config_emif_ddr2 - EMIF4_0_SDRAM_REF_CTRL values written
16.06     712    SR: config_emif_ddr2 - EMIF4_0_SDRAM_CONFIG values re-written
16.06       0    DDR Config done
16.34      28    SPL: Un-supported Boot Device - 0!!!
16.34       0    ### ERROR ### Please RESET the board ###

Hello,

Another update.. I was able to put a scope to the DDR clock and yes it is clocking at 200Mhz, exactly the same as what I had set it up to be.

Now at this point I'm completely toast...I don't have any other clue, any pointers will be helpful.

Thank you

Regards

Santhosh

Santhosh,

Its good progress. But I'm wondering where the delay is coming from.  Also did you check which is the device its trying to boot from?

16.34      28    SPL: Un-supported Boot Device - 0!!!
16.34       0    ### ERROR ### Please RESET the board ###

Jason,

I checked the code and the diff. I'm getting confused what the actual code is. For eg. the If I search for EMIF4_0_SDRAM_TIM in the patch, I can see that all code related to that is removed. Whereas in the code that you've sent me, EMIF4_0_SDRAM_TIM is present in the evm.c file. So, I'm getting really confused. 

If you guys can share one board, I can fix it.