
26 Mar
2008
26 Mar
'08
11:33 p.m.
Dear Stefan,
in message 1206523009-18011-1-git-send-email-sr@denx.de you wrote:
It is strongly recommendet to not use the last 256 bytes on those
<nitpick> recommended </nitpick>
--- a/README +++ b/README @@ -1854,6 +1854,27 @@ Configuration Settings: Scratch address used by the alternate memory test You only need to set this if address zero isn't writeable
+- CFG_MEM_TOP_HIDE (PPC only):
If CFG_MEM_TOP_HIDE is defined in the board config header,
this specified memory area will get subtracted from the top
(end) of ram and won't get "touched" at all by U-Boot. By
fixing up gd->ram_size the Linux kernel should gets passed
the now "corrected" memory size and won't touch it either.
This should work for arch/ppc and arch/powerpc. Only Linux
board ports in arch/powerpc with bootwrapper support, that
recalculate the memory size from the SDRAM controller setup
will have to get fixed.
This option can be used as a workaround for the 440EPx/GRx
CHIP 11 errata where the last 256 bytes in SDRAM shouldn't
be touched.
WARNING: Please make sure that this value is a multiple of
the Linux page size (normally 4k). If this is not the case,
then the end address of the Linux memory will be located at a
non page size aligned address and this could cause mayor
<nitpick> major </nitpick>
Will you send a pull request for the ppc4xx repo, or should I apply this directly?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The human mind treats a new idea the way the body treats a strange
protein - it rejects it. - P. Medawar