[U-Boot-Users] [PATCH] ppc4xx: Don't use last 256 bytes of SDRAM, workaround for 440EPx CHIP 11 errata
Larry Johnson
lrj at acm.org
Thu Mar 20 17:06:27 CET 2008
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
More information about the U-Boot
mailing list