[U-Boot-Users] [PATCH] ppc4xx: Don't use last 256 bytes of SDRAM, workaround for 440EPx CHIP 11 errata

[Larry Johnson <lrj@acm.org>]

Stefan Roese wrote:
> Hi Wolfgang,
> 
> On Thursday 20 March 2008, Wolfgang Denk wrote:
>>> This patch adds this workaround for the following 440EPx boards:
>>> sequoia, lwmon5. Others should probably follow this example.
>> OK, the default configs for Sequoia doesn't use shared log buffer, and
>> the lwmon5 uses CONFIG_ALT_LB_ADDR (i. e. it puts the log buffer in
>> OCM), so these boards will work.
>>
>> But any changes to the configuration may easily break this again.
> 
> Understood.
> 
>> I don't like the idea that  each  affected  board  has  to  fix  this
>> (probably  differently)  in  it's board config file. I would prefer a
>> fix (common to all affected boards) in one central location.
> 
> I don't like this either. But I have not come up with a "generic" solution 
> till now. It's not so easy since the 440EPx SDRAM setup code is sometimes 
> common (cpu/ppc4xx/denali_spd_ddr2.c) and sometimes board specific. And it 
> gets even more complicated when ECC initialization is needed too. So 
> currently I have no "better" solution as to do it in a board specific way.
> 
> As always, patches implementing a "better" more generic solution are welcome.
> 
> Thanks.
> 
> Best regards,
> Stefan

Hi Stefan,

Having multiple implementations of the 440EXp SDRAM setup code is, in
itself, less than ideal.  One alternative is to have a 440EPX board with
on-board SDRAM chips fake an array of SPD bytes describing the chips,
and pass it to the "denali_spd_ddr2.c" code.  The SPD code then becomes
the single location for the technology of how to configure the Denali
SDRAM controller.

The additional benefit (for me, anyway :-) ) is having more eyeballs on
the SPD code, with more opportunities for testing, bug fixing, and
enhancements.

Best regards,
Larry