ppc: Add CFG_MEM_TOP_HIDE option to hide memory area that doesn't get "touched"

It is strongly recommendet to not use the last 256 bytes on those

README +9 -0

@@ -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

README Configuration Settings: · line 1875

Quoted 4 lines

README +4 -0

+		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?

README Configuration Settings: · line 1866

Quoted 12 lines · Stefan Roese

[...]
+- CFG_MEM_TOP_HIDE (PPC only):

README +9 -0

+        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.
[...]

Hi Stefan,

I also have a nit to pick :-) . It's not clear to me whether the clause in the last sentence is meant to be restrictive or non-restrictive. If restrictive, I recommend removing the comma before the word "that". If non-restrictive, I recommend replacing the word "that" with the word "which".

README Configuration Settings: · line 1866

Quoted 11 lines

+- CFG_MEM_TOP_HIDE (PPC only):

README +9 -0

+		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.
[...]

Hi Stefan,

I also have a nit to pick :-) . It's not clear to me whether the clause in the last sentence is meant to be restrictive or non-restrictive. If restrictive, I recommend removing the comma before the word "that". If non-restrictive, I recommend replacing the word "that" with the word "which".

Quoted 13 lines · Larry Johnson

README Configuration Settings: · line 1866

Quoted 11 lines

+- CFG_MEM_TOP_HIDE (PPC only):

README +9 -0

+		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.
[...]

Hi Stefan,

Quoted 5 lines

I also have a nit to pick :-) . It's not clear to me whether the clause in the last sentence is meant to be restrictive or non-restrictive. If restrictive, I recommend removing the comma before the word "that". If non-restrictive, I recommend replacing the word "that" with the word "which".

Thanks. Its sometimes helpful if native English speakers helps out here. I have to admit that I don't really get the difference of both versions you mention above. In this sentense I refer to Linux board ports which need *additional* fixes in Linux. I'll send the changed patch in a few minutes with this sentence:

"
Only Linux board
ports in arch/powerpc with bootwrapper support, which recalculate the memory size from the SDRAM controller setup, will have to get fixed in Linux additionally.
"

I hope its clear now.

BTW, there is no general agreement on whether the word "that" in the preceding sentence is correct. While I prefer it, some believe the word "which" should be used instead. English is such a complicated language, even for native speakers, that I am always amazed at the quality of the postings from contributors who did not learn it as their first language.

Best regards,
Larry

Yeah, Wolfgang has corrected my English more than once. :-D

It's clear now, but unfortunately I don't know enough to tell whether it is also correct :-( . The statement as now written implies that the statement without the clause, i.e., "Only Linux board ports in arch/powerpc with bootwrapper support will have to get fixed in Linux additionally", is also true. If this is not correct (because boards that do not recalculate their memory size do not need to be fixed in Linux), then you would write: "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 in Linux additionally."

Quoted 9 lines · Larry Johnson

It's clear now, but unfortunately I don't know enough to tell whether it is also correct :-( . The statement as now written implies that the statement without the clause, i.e., "Only Linux board ports in arch/powerpc with bootwrapper support will have to get fixed in Linux additionally", is also true. If this is not correct (because boards that do not recalculate their memory size do not need to be fixed in Linux), then you would write: "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 in Linux additionally."

Now I'm confused. :)

Here is the current version I now have in my "master" branch (with your last sentense):

- 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 in Linux additionally.

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 major problems.

Please send a patch to change this description if necessary.

Thanks.

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 patch enables this config option on some PPC440EPx boards as a workaround
for the CHIP 11 errata. Here the description from the AMCC documentation:

ram_size, i'd add a memreserve in the device tree that the kernel

Quoted 4 lines

This patch enables this config option on some PPC440EPx boards as a workaround
for the CHIP 11 errata. Here the description from the AMCC documentation:

If you reduce the memory size this way does the 44x kernel have issues with the TLBs that are used to mapped pin kernel lowmem?

I know on 85xx this would be a bad thing and rather than changing gd-> ram_size, i'd add a memreserve in the device tree that the kernel got passed.