Re: PPC update

[Marco Gerards]

Hollis Blanchard <address@hidden> writes:

>> 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.

s/Eight/Right/ :-)

> 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...

Yeah, but it is quite hard to look where I am now... :-/

>> 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...

Perhaps you can adjust some variable in OF that points to the device
you loaded it from or so...  Anyways, that is just a random thought
while I have no clue how your code works.

>> 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

Heh, that's code and not a description. ;)

I was wondering why it was required, some background, etc.

--
Marco