Re: PPC update

[Hollis Blanchard]

On Dec 10, 2005, at 8:18 AM, Marco Gerards wrote:

> Hollis Blanchard <address@hidden> writes:
>
> > 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. :)
>
> Eight.  And when in doubt, better flush too much.

Eight lines?  
http://cvs.savannah.gnu.org/viewcvs/grub/grub2/kern/powerpc/ 
cache.S.diff?tr1=1.1&tr2=1.2&r1=text&r2=text says it's two.

My first approach was just to flush one extra line, but that failed  
(DEFAULT CATCH) when accessing unmapped memory (i.e. past the end of  
memory which had been claimed). The proper fix was simple anyways.

> > 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.
>
> Right, but you haven't made this change in CVS, I assume?

Of course not. You can see for yourself...

> > (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.)
>
> Sure.  I don't even remember why we needed it in the first place.

I had convinced myself that something wasn't getting mapped. Actually,  
I bet I know what it was...
"claim" on Old World firmware didn't work properly, and you did need to  
map it explicitly. BootX has more complete code to handle this case,  
and we should take that same approach when we worry about Old World.

> > 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...
>
> Yeah, I'll let you know.  My guess is that it will take a week.  Can't
> you just copy the file to the wrapped HFS fs in the meanwhile, or is
> it too small?

I have copied BootX there. The mach_kernel is 4MB though, which is too  
large for my HFS partition, and I assume the root filesystem detection  
code would get confused anyways...

> Can you describe your biarch change and how that affects the AMD64
> port?  Can I still crosscompile like I was used to?

http://cvs.savannah.gnu.org/viewcvs/grub/grub2/configure.ac.diff? 
tr1=1.17&tr2=1.18&r1=text&r2=text

In a word: yes.

-Hollis