I just fixed an embarassing bug in kern/powerpc/cache.S, where if
`address' is not cacheline-aligned (which is a common and reasonable
thing), it would fail to flush/invalidate the last cacheline. (It takes
a little thinking, but draw a picture and think about the loop
termination condition and you'll see why.) Vincent, I believe
kern/sparc64/cache.S has the same problem... the fix is only two lines,
so finding a failing testcase is the only hard part. :)
I found the failure by relinking GRUB above 96MB; I guess the lower
addresses were well-trafficked enough, at least as far as cacheline
congruence classes go. Why did I change the link address? Open Firmware
has a "claim" method in which a client program (that's us) reserves
memory for exclusive use. BootX, the Mac OS X bootloader, claims almost
every byte of memory up to 96MB, and it fails if GRUB has claimed
memory in the way.
(BTW, I commented out the "map" part of grub_claimmap(), and everything
works fine without it. If we can get a little more testing with that, I
will remove it entirely.)
Once I fixed the cache flushing bug, I was able to execute BootX
further than before. It displayed an icon indicating it could not find
OS X's kernel, which is expected because I had to copy BootX to a
separate partition with a supported filesystem to load it at all.
So Marco, any time you're ready with that HFS+ driver... ;) In the
meantime I will continue to try to find a way to load BootX without
linking at 96MB. It would be nice not to require 96MB of RAM to run
GRUB...
-Hollis
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
