From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.33) id 1Cjc7S-00007t-54 for mharc-grub-devel@gnu.org; Wed, 29 Dec 2004 06:35:58 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cjc74-0008UL-FV for grub-devel@gnu.org; Wed, 29 Dec 2004 06:35:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cjc6w-0008T6-EH for grub-devel@gnu.org; Wed, 29 Dec 2004 06:35:29 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cjc6v-0008Qh-Le for grub-devel@gnu.org; Wed, 29 Dec 2004 06:35:25 -0500 Received: from [145.74.66.11] (helo=mail-cn.han.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CjbvB-0004OM-Kc for grub-devel@gnu.org; Wed, 29 Dec 2004 06:23:18 -0500 Received: from vscan-ca.han.nl (mars.han.nl [145.74.129.116]) by mail-cn.han.nl (Postfix) with ESMTP id 37792995E for ; Wed, 29 Dec 2004 12:21:03 +0100 (CET) Received: from mail-cn.han.nl ([145.74.66.51]) by vscan-ca.han.nl (mars.han.nl [145.74.129.116]) (amavisd-new, port 10024) with LMTP id 05379-08-33 for ; Wed, 29 Dec 2004 12:21:00 +0100 (CET) Received: from mail1.han.nl (mail1.han.nl [145.74.103.11]) by mail-cn.han.nl (Postfix) with ESMTP id 208A49925 for ; Wed, 29 Dec 2004 12:21:00 +0100 (CET) Received: from marco.marco-g.com (mgerards.xs4all.nl [82.92.27.129]) by mail1.han.nl (Postfix) with ESMTP id D4CCDC061 for ; Wed, 29 Dec 2004 12:20:59 +0100 (CET) Mail-Copies-To: metgerards@student.han.nl To: The development of GRUB 2 References: <87brceni14.fsf@marco.marco-g.com> <19294A70-595C-11D9-842B-000A95A0560C@penguinppc.org> From: Marco Gerards Date: Wed, 29 Dec 2004 11:20:21 +0000 In-Reply-To: <19294A70-595C-11D9-842B-000A95A0560C@penguinppc.org> (Hollis Blanchard's message of "Tue, 28 Dec 2004 23:40:07 -0600") Message-ID: <87acrxjqq2.fsf@marco.marco-g.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new (2.2.0) at vscan-ca.han.nl Subject: Re: Claim on IEEE1275 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 11:35:37 -0000 Hollis Blanchard 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