[U-Boot] [PATCH 0/3] DMA ECC update

[Jerry Van Baren]

Ira W. Snyder wrote:
> On Wed, Jul 08, 2009 at 05:59:33PM -0500, Peter Tyser wrote:
>> On Wed, 2009-07-08 at 15:31 -0700, Ira W. Snyder wrote:
>>> On Wed, Jul 08, 2009 at 02:28:39PM -0500, Peter Tyser wrote:
>>>> These changes bring the 83xx SDRAM ECC initialization in line
>>>> with the 85xx/86xx boards and also fixes a minor bug in fsl_dma.c.
>>>>
>>>> I don't have any 83xx boards to test on, so it would be appreciated
>>>> if someone with 83xx hardware that uses ECC could give the patches
>>>> a shot.
>>>>
>>>> It'd be nice if SDRAM could be initialized via the DDR controller
>>>> with CONFIG_ECC_INIT_VIA_DDRCONTROLLER on the 83xx platform too,
>>>> but I'm not going to tackle it:)
>>>>
>>>> The patches also resolve the compile error Stefan brought up with
>>>> non-freescale boards with CONFIG_ECC.
>>>>
>>>> Peter Tyser (3):
>>>>   83xx: Default to using DMA to initialize SDRAM
>>>>   83xx: Added CONFIG_MEM_INIT_VALUE for boards with ECC
>>>>   fsl_dma: Fix SDRAM initial value
>>>>
>>> Something in this patch makes the ECC DDR initialization VERY slow. It
>>> used to take <5 seconds, now it takes ~20 seconds for the memory to
>>> initialize.
>>>
>>> I wonder why the CPU method would be so much faster?
>>>
>>> Other than the speed, I can confirm that it works as expected on my
>>> 8349emds-based board. I see no reason why there would be a problem on
>>> the mpc8349emds, though I cannot test on the eval board itself. I do not
>>> have an ECC SDRAM module.
>> Thanks for testing Ira.  The original code had the instruction cache
>> enabled during SDRAM init, but it'd be pretty amazing if it gave that
>> much performance boost.  I would have guessed that the DMA init would
>> have been faster even without the icache enabled.
>>
>> If you have a second, could you try adding this patch on top of the
>> previous ones?  It'd be interesting to see where the bottleneck is with
>> and without the icache...
> 
> It didn't apply cleanly (I'm not sure why), but I applied it (fixed the
> missing semicolon).
> 
> It makes the DMA initialization normal speed again. The DMA in the for
> loop takes the longest (as expected).
> 
> So yes, strangely it makes a HUGE difference. The total time is <3
> seconds now. It is now faster than the previous CPU method.

Not that strangely.  In fsl_dma.c, the dma_check() routine does a 
busy-poll to wait for the DMA to complete:

   80 static uint dma_check(void) {
   81         volatile fsl_dma_t *dma = &dma_base->dma[0];
   82         uint status;
   83
   84         /* While the channel is busy, spin */
   85         do {
   86                 status = in_dma32(&dma->sr);
   87         } while (status & FSL_DMA_SR_CB);

With icache enabled, this is going to run out of instruction cache and 
not compete with the DMA engine on the SDRAM bus.  With icache disabled, 
the processor is going to be fetching instructions from SDRAM *one* *by* 
*one* (no bursting - quadruple whammy), competing with the DMA engine 
and thus destroying the DMA engine's performance.

Aside: SDRAM performance *sucks* when address/data pipelining and 
bursting is turned off or gets defeated.  I ran the numbers a while back 
and came to the realization that dynamic RAM access times have *not* 
changed substantially in 20 years.  The difference is that the memory 
subsystem is now a WHOLE lot better at hiding the access delay by 
pipelining additional requests to fill the time waiting for the first 
access to produce its data.

IOW, cache on the CPU and the SDRAM bursting/pipelining is what is 
faster, not the memory within the SDRAM itself.

[snip]

> Ira
> 
>> Thanks,
>> Peter

Thanks,
gvb