Messages in this thread | | | Date | Tue, 06 Sep 2005 16:49:55 -0700 | From | Mark Bellon <> | Subject | Re: [PATCH] PPC64: large INITRD causes kernel not to boot [UPDATE] |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |