OMAP35xx x-loader runs but u-boot does not

Matt said:

Do I need to alter either for the different memory and processor?

The processor portion probably will not matter, I doubt U-Boot has any dependencies on the DSP, though there is a good chance you will have to make modifications for the memory, typically this would be the big change to port between boards. Does U-Boot ever print anything out? It seems strange to me that a U-Boot dependency on memory would cause total failure to print anything unless the DDR itself was not functional (or specifically configured to be functional).

Thanks for replying.

U-boot does not print anything out.

I have since modified X-Loader to do a memory test.  I found out the DDR is not working at all.  I am writing 0xFFFFFFFF to a memory addresses and reading out 0x80008802.  So something is seriously wrong with the interface to the pop chip.  X-rays of the chip show no bridging and everything appears to be assembled correctly.  The memory clock is at 6ns interval (or 166MHz) which should be correct. 

Is it still possible that there is a SDRC or other setting that can be messing things up?

Under-clocking the memory from 166MHz to 133MHz has significantly reduced the bit errors, but has not eliminated them.  This memory part is supposed to support 166 MHz.  None of the SDRC pads are connected on my board with the exception of the SDRC_CLK and SDRC_NCS0 lines.  They just go to very close-by test points.

I am trying to lower the memory frequency to 100MHz to get a working board.  However, I am not clear yet on how exactly to do that.  The 133MHz change was a simple #define switch in the x-loader code.   From reading the TRM, I understand the SDRC clock is linked to the L3_ICLK which is linked the DPLL3 and CORE_CLK... I think.  I'm not clear on what knobs to turn yet

Bernie, Can you or someone else point me in the right direction?

I am not sure that there is a good example setting for the x-loader to operate at this speed, however in the GEL file for the OMAP3 there is a 100MHz L3 configuration where it looks like they just change a few registers based on the input clock frequency.

omap3430_prcm_clock_configs.gel said:

#define CORE_CFG2C               3  /*L3=100MHz*/

...

      if (in_nConf == CORE_CFG2C)
      {
         if (in_nSysClk == 0)
         {  /*12MHz*/
          DPLL_MULT_VALUE = 200;
          DPLL_DIV_VALUE = 11;
          DPLL_FREQ_SEL_VALUE = 0x3;
         }
         else if (in_nSysClk == 1)
         {  /*13MHz*/
          DPLL_MULT_VALUE = 200;
          DPLL_DIV_VALUE = 12;
          DPLL_FREQ_SEL_VALUE = 0x3;
         }
         else if (in_nSysClk == 2)
         {  /*19.2MHz*/
          DPLL_MULT_VALUE = 177;
          DPLL_DIV_VALUE = 16;
          DPLL_FREQ_SEL_VALUE = 0x4;
         }
         else if (in_nSysClk == 3)
         {  /*26MHz*/
          DPLL_MULT_VALUE = 200;
          DPLL_DIV_VALUE = 25;
          DPLL_FREQ_SEL_VALUE = 0x3;
         }
         else if (in_nSysClk == 4)
         {  /*38.4MHz*/
          DPLL_MULT_VALUE = 151;
          DPLL_DIV_VALUE = 28;
          DPLL_FREQ_SEL_VALUE = 0x5;
         }
      }

These values appear to go into the CM_CLKSEL1_PLL register shown in section 1.14.1.8.7 of chapter 4 of the TRM.

Thanks Bernie.  That was what I needed. 

Unfortunately, It turns out that the speed does not affect it.  That the improved behavior that I thought was caused by lowering the memory clock from 166MHz to 133MHz, was actually do to the fact that I power cycled the board to load the modified x-loader.  Whereas before, I was just reseting.

The improved memory behavior occurs for about 20 seconds after the power is cycled.  Then something happens, and the bit errors increase dramatically.   So I am no closer to solving my problem.

I am about ready to give up.  It turns out that for my application, I might be able to use some off-the-shelf OMAP boards that were not an option when I first started.

That is a bit strange, if that PoP memory was to work at all it would most likely be some DDR interface configuration, since there is no real layout to deal with. Maybe a close comparison between the Beagle's PoP module and your own as well as a DDR configuration comparison would give some ideas. Another thought, if it starts out ok and than gets worse perhaps there is some problem with the refresh cycle or its timing.

Have you run the issue past Micron?

I have been changing the AC timing characteristics and set a conservative refresh interval.  None of those have had an effect.  We strongly suspect the board assembly house, because we found that the OMAP on another board had intermittened contact with it's pads.  I haven't contacted Micron, but we are chaning coarse on the project any way.  We found a vendor that make a OMAP3 board that will do what we need.  Thanks for your help.