Paul Mackerras wrote:
Mark Bellon writes:
Simply put the existing code has a fixed reservation (claim) address and
once the kernel plus initrd image are large enough to pass this address
all sorts of bad things occur. The fix is the dynamically establish the
first claim address above the loaded kernel plus initrd (plus some
"padding" and rounding). If PROG_START is defined this will be used as
the minimum safe address - currently known to be 0x01400000 for the
firmwares tested so far.
The idea is fine, but I have some questions about the actual patch:
-void *claim(unsigned int, unsigned int, unsigned int);
+void *claim(unsigned long, unsigned long, unsigned long);
What was the motivation for this change? Since the zImage wrapper is
a 32-bit executable, int and long are both 32 bits. I would prefer to
leave the parameters as unsigned int to force people to realize that
the parameters are 32 bits (even if said people have been working on
64-bit programs recently).
The function, claim, is found in prom.c uses longs. The long is the
usual idiom for hiding a pointer, not an int, so I fixed accordingly.
I'm open to further discussion of course.
On a 64 bit machine long and int are different sizes. This would make
things "proper" if things changed in the future.
+ claim_base = _ALIGN_UP((unsigned long)_end, ONE_MB);
+
+#if defined(PROG_START)
+ /*
+ * Maintain a "magic" minimum address. This keeps some older
+ * firmware platforms running.
+ */
+
+ if (claim_base < PROG_START)
+ claim_base = PROG_START;
+#endif
This appears to be the meat of the patch, the rest is "cleanup", right?
Correct. The preceding comment explains what is going on. Removing the
magic numbers seemed like a good idea.
mark
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
