Re: Claim on IEEE1275

[Hollis Blanchard]

On Dec 28, 2004, at 5:02 PM, Marco Gerards wrote:
> Some minutes ago I have committed a patch that removes the stack
> initialization code.  This seems to work perfectly fine for both the
> PegasosII and the newworld mac.  This was required for loading linux
> on the PegasosII.  Without this change linux crashed when decompressing
> itself.  It's ok for me to restore this code when the problem is
> found.  But at the moment this seems like a fine fix.

I would still like to have some idea of the problem we're avoiding. We 
*were* using an 8KB stack (which seems like a lot). Now we use whatever 
firmware gave us. Firmware is required by spec (8.2.2 of the PowerPC 
IEEE1275 binding) to give us at least a 32KB stack, but of course we 
cannot guarantee that all implementations do this correctly. It is 
possible that Linux's gunzip code requires a stack greater than 8KB, 
and that would be good to know (and comment). Would you mind testing 
the old code with larger stack sizes and see if that matters?

I said earlier that I didn't think the old stack initialization code 
was correct, but now I think it may be ok. I have never seen use of the 
"la" mnemonic, but it might do what we want here.

> Only one problem remains for loading linux on the PegasosII.  The
> grub_claimmap call fails because the map fails.  I think this is
> because the firmware already maps the memory.

You can verify this by consulting the "translations" property of 
/chosen/mmu if I recall correctly.

> Hollis, is the map call really required?  We can better go back to
> using grub_ieee1275_claim if it is not.  If it is required, do you
> have an idea of how to detect this?

It is certainly required: how would you like it if you claimed some 
memory to write to but it was never mapped?

There is a "real-mode?" configuration variable, but I think that just 
specifies OF's translation mode, independent of the client's mode (see 
the IEEE1275 PowerPC and CHRP bindings). Knowing the value of that 
variable might be interesting but I wouldn't recommend changing it, as 
Apple firmware in particular is known to die a horrible death by 
mucking with one of those settings (I'm pretty sure it's "real-mode?").

-Hollis