On Wed, Jul 25, 2007 at 12:51:27PM -0500, Hollis Blanchard wrote: > > I was indeed trying to make it absolute. GRUB is linked at 0x10000, or > 64KB. Add in all the modules and you still are only using a couple > hundred KB.
But if GRUB is linked at 0x10000, how come the firmware loads it since that's below the 0x19111e4 limit? (or am I missing some physical vs logical issue here?) > I don't remember *why* I was trying to make it absolute; I'm sure it > was to fix a problem (rather than I was bored). If we could get away > from this anachronistic Changelog crap, the commit message would have > told us exactly what we need to know. I pasted the ChangeLog entries in an earlier mail. Do you mean the CVS commit message might have more information? > I *think* it was because we have a relocation problem with OSes that > are linked at 4MB, which is the case with Xen (and I believe yaboot). > If GRUB is using that memory, we simply can't load anything there. > > I think we can add some somewhat-special-case logic that says if there > is nothing available below HEAP_LIMIT, claim something beginning as > low as we can. That reduces functionality on such platforms (as > described above), but there's little we can do about that unless > firmware is fixed. So the purpose of HEAP_LIMIT is to support code that is linked at fixed addresses? > My big question is this: why is Efika firmware saying that 0x19111e4 > (around 25MB) is the first available address? What is wrong with that? Is it general practice that all firmwares load at low addresses so that non-relocatable code can be linked at 4MB or such? > BTW, does Jordi have any details on this Mac problem? He said that after appliing the patch that makes heaplimit a relative address it still won't work. /memory/available: 00003000 0000d000 0002d000 007d3000 00848000 1f3b8000 I'm CCing him. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
