Stefan Roese wrote:
On Thursday 23 April 2009, Josh Boyer wrote:
On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
There is an error in the way ibm4xx_denali_fixup_memsize calculates
memory size. When testing the DDR_REDUC bit, the polarity is
backwards. A "1" implies 32-bit wide memory while a "0" implies
64-bit wide memory.
For a 32-bit wide system, this bug causes twice the memory to be
reported, leading to boot failure.
Signed-off-by: Steven A. Falco <sfa...@harris.com>
So we had a previous patch for this, and a very long discussion on what the
right solution was. Either we never came to a resolution, or I have just
forgotten what it was.
Stefan, Valentine, do either of you remember?
The patch will break sequia/rainier since u-boot doesn't set the number
of chipselects correctly for them. IIRC, the last conversation didn't
come to any conclusion. We sort of wanted to fix that regardless of
whether we had corrected u-boot or not.
Could we use a "model" property to distinguish between the "real"
sequoia/rainier and other custom boards?
If yes, we could add a workaround the ibm4xx_denali_fixup_memsize to
hardcode the chipselect number to 1 for sequoia/rainier.
Thanks,
Val.
Not really, sorry. Must be longer than 2 weeks ago, so it's already flushed
from my cache. :)
IIRC, it wasn't something
that effected Sequoia or Rainier, but it could (and obviously does) effect
custom boards. I don't remember what we agreed on for the proper fix.
It would effect all 32-bit wide 440EPx/GRx boards using the boot wrapper. I
never used the wrapper on those platforms though. Sorry, I don't remember the
outcome of the discussion either.
Thanks,
Stefan
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
