grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Claim on IEEE1275


From: Marco Gerards
Subject: Re: Claim on IEEE1275
Date: Wed, 29 Dec 2004 11:20:21 +0000
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Hollis Blanchard <address@hidden> writes:

> 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've done that before I removed it.  It did not help.  Perhaps the
problem is caused because stack is in .bss and it is not executable?

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

Ok.  Hopefully Johan can comment on that, he wrote that code.

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

Ok.

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

I assume it is mapped by claim.  Anyway, yaboot does not use map and
neither does linux, as it seems.

> 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?").

On my powerbook it is set to false, while it is set to true on the
pegasos.  So what do you suggest?  Using map when it is set to false?

Thanks,
Marco






reply via email to

[Prev in Thread] Current Thread [Next in Thread]