* patch for PPC Old World Macintosh
@ 2004-08-29 23:52 Hollis Blanchard
2004-08-30 10:25 ` Yoshinori K. Okuji
2004-08-30 16:17 ` Marco Gerards
0 siblings, 2 replies; 9+ messages in thread
From: Hollis Blanchard @ 2004-08-29 23:52 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]
Seeing that Marco did the hard work of porting grub2 to New World Power
Mac, I though I'd try to support Old World (i.e. Macs with sucky Open
Firmware).
'quik' is the OF-based Old World bootloader for Linux. Unfortunately a
stage1 is needed due to firmware limitations, so I am using a slightly
modified quik stage1 (it now "claims" the memory it uses). I have also
slightly modified quik installer (which installs the stage1 to disk) so
that it sets the stage2 base to be 2M, grubof's link address. Long-term
it may be worthwhile to copy quik's stage1 into grub2's source tree,
but the quik *installer* is appalling code and probably warrants a
from-scratch rewrite (maybe NetBSD's installboot(8) meets our needs).
This patch adds basic support for Old World, enough to get to the
rescue or normal prompt. Most of the problems were related to the
memory layout. I have not yet fixed loading from disk; it shouldn't be
hard but I thought I should submit what I have working now.
This patch uses the "/memory/available" property to find memory. Works
for me, but it is not very conservative. I have it on good authority
that Old World firmware defaults to 4M-5M, so I think this is ok
until/unless we find a machine that doesn't work...
ALIGN_UP doesn't need to be in mm.h, but it seemed as good as any place
to put it.
-Hollis
2004-08-29 Hollis Blanchard <hollis@penguinppc.org>
* boot/powerpc/ieee1275/cmain.c: check for quik stage1. If present,
use r3 rather
than r5 as the Open Firmware entry point; claim grub's BSS range since
quik
stage1 doesn't; claim OF's memory range for it (since it doesn't);
* boot/powerpc/ieee1275/crt0.S: zero BSS here since it is required on
Old World pmac.
If it isn't required, it can't hurt anyways.
Pass r3-r5 through unchanged to let cmain() detect quik.
* include/grub/mm.h: add ALIGN_UP macro.
* kern/powerpc/ieee1275/init.c: add a "trap" to abort() so we drop
back to Open
Firmware.
Claim and use all memory that's listed as available in the
/memory/available property.
[-- Attachment #2: grub-oldworld-mem.diff --]
[-- Type: application/octet-stream, Size: 4696 bytes --]
Index: boot/powerpc/ieee1275/cmain.c
===================================================================
RCS file: /cvsroot/grub/grub2/boot/powerpc/ieee1275/cmain.c,v
retrieving revision 1.2
diff -u -r1.2 cmain.c
--- boot/powerpc/ieee1275/cmain.c 4 Apr 2004 13:45:59 -0000 1.2
+++ boot/powerpc/ieee1275/cmain.c 29 Aug 2004 23:02:07 -0000
@@ -23,6 +23,7 @@
#include "grub/machine/ieee1275.h"
#include "grub/kernel.h"
+#include "grub/mm.h"
struct module_info
{
@@ -48,14 +49,34 @@
/* Setup the argument vector and pass control over to the main
function. */
void
-cmain (uint32_t firmware_entry)
+cmain (uint32_t r3, uint32_t r4 __attribute__((unused)), uint32_t r5)
{
char **argv, args[256];
grub_ieee1275_phandle_t chosen;
int argc = 0, actual;
long batl, batu;
- grub_ieee1275_entry_fn = (intptr_t (*)(void *)) firmware_entry;
+ if (r5 == 0xdeadbeef) {
+ /* entered from quik stage1 */
+ uint32_t result;
+ uint32_t aligned_bss;
+ extern char __bss_start;
+ extern char _end;
+
+ grub_ieee1275_entry_fn = (intptr_t (*)(void *)) r3;
+
+ /* Old World Open Firmware may use 4M-5M without claiming it */
+ grub_ieee1275_claim((void *) 0x00400000, 0x00100000, 0, (void *) &result);
+
+ /* we need to claim our own BSS. stage1 claimed the first partial BSS
+ * KB, so round up. */
+ aligned_bss = ALIGN_UP(&__bss_start, LOG_KB);
+ grub_ieee1275_claim((void *) aligned_bss, (grub_size_t) &_end - aligned_bss,
+ 0, (void *) &result);
+ } else {
+ /* assume we were entered from Open Firmware */
+ grub_ieee1275_entry_fn = (intptr_t (*)(void *)) r5;
+ }
/* Initialize BAT registers to unmapped to not generate overlapping
mappings below. */
Index: boot/powerpc/ieee1275/crt0.S
===================================================================
RCS file: /cvsroot/grub/grub2/boot/powerpc/ieee1275/crt0.S,v
retrieving revision 1.2
diff -u -r1.2 crt0.S
--- boot/powerpc/ieee1275/crt0.S 4 Apr 2004 13:45:59 -0000 1.2
+++ boot/powerpc/ieee1275/crt0.S 29 Aug 2004 23:02:07 -0000
@@ -32,7 +32,10 @@
.long 0xffffffff /* virt-base */
.long 0xffffffff /* virt-size */
.long 0x00030000 /* load-base */
-
+
+.extern __bss_start
+.extern _end
+
.text
.align 2
.globl _start
@@ -43,9 +46,18 @@
li 2, 0
li 13, 0
-
- mr 3, 5
+ /* We *must* zero BSS coming from quik stage1. In other cases, why
+ * not? */
+ lis 6, __bss_start@h
+ ori 6, 6, __bss_start@l - 4
+ lis 7, _end@h
+ ori 7, 7, _end@l
+ subf 7, 6, 7
+ mtctr 7
+2: stwu 2, 4(6) /* we know r2 is already 0 from above */
+ bdnz 2b
+
bl cmain
1: b 1b
Index: include/grub/mm.h
===================================================================
RCS file: /cvsroot/grub/grub2/include/grub/mm.h,v
retrieving revision 1.3
diff -u -r1.3 mm.h
--- include/grub/mm.h 4 Apr 2004 13:46:00 -0000 1.3
+++ include/grub/mm.h 29 Aug 2004 23:02:08 -0000
@@ -36,4 +36,7 @@
void grub_mm_dump (unsigned lineno);
#endif
+#define LOG_KB 10
+#define ALIGN_UP(addr, align) ((((unsigned long)(addr - 1) >> align) + 1) << align)
+
#endif /* ! GRUB_MM_H */
Index: kern/powerpc/ieee1275/init.c
===================================================================
RCS file: /cvsroot/grub/grub2/kern/powerpc/ieee1275/init.c,v
retrieving revision 1.4
diff -u -r1.4 init.c
--- kern/powerpc/ieee1275/init.c 27 Jul 2004 17:47:37 -0000 1.4
+++ kern/powerpc/ieee1275/init.c 29 Aug 2004 23:02:09 -0000
@@ -40,19 +40,41 @@
void
abort (void)
{
+ asm ("trap"); /* trap to Open Firmware */
for (;;);
}
void
-grub_machine_init (void)
+grub_arch_mem_init (void)
{
+ char data[64];
+ grub_ieee1275_phandle_t memory;
+ grub_size_t actual;
+ struct grub_ieee1275_mem_region *range;
void *mem;
- if (grub_ieee1275_claim ((void *) 0x300000, 0x150000, 0, &mem) == -1)
- abort (); /* Damn, we are in trouble! */
-
- /* The memory allocations were copied from yaboot. */
- grub_mm_init_region ((void *) 0x300000, 0x150000);
+ if (grub_ieee1275_finddevice ("/memory", &memory))
+ abort();
+
+ if (grub_ieee1275_get_property (memory, "available", data, sizeof data,
+ &actual))
+ abort();
+
+ /* claim and use all regions listed in /memory/available */
+
+ for (range = (struct grub_ieee1275_mem_region *)data;
+ range < (struct grub_ieee1275_mem_region *)(data + actual);
+ range++) {
+ if (grub_ieee1275_claim ((void *) range->start, range->size, 0, &mem) == -1)
+ abort();
+ grub_mm_init_region ((void *) range->start, range->size);
+ }
+}
+
+void
+grub_machine_init (void)
+{
+ grub_arch_mem_init ();
/* XXX: Loadable modules are not supported. */
grub_env_set ("prefix", "");
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: patch for PPC Old World Macintosh
2004-08-29 23:52 patch for PPC Old World Macintosh Hollis Blanchard
@ 2004-08-30 10:25 ` Yoshinori K. Okuji
2004-08-30 16:17 ` Marco Gerards
1 sibling, 0 replies; 9+ messages in thread
From: Yoshinori K. Okuji @ 2004-08-30 10:25 UTC (permalink / raw)
To: The development of GRUB 2
On Monday 30 August 2004 01:52, Hollis Blanchard wrote:
> This patch adds basic support for Old World, enough to get to the
> rescue or normal prompt. Most of the problems were related to the
> memory layout. I have not yet fixed loading from disk; it shouldn't
> be hard but I thought I should submit what I have working now.
Great! I'd like you to integrate your patch into GRUB, but this requires
legal procedures again... I will write to you later.
Okuji
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: patch for PPC Old World Macintosh
2004-08-29 23:52 patch for PPC Old World Macintosh Hollis Blanchard
2004-08-30 10:25 ` Yoshinori K. Okuji
@ 2004-08-30 16:17 ` Marco Gerards
2004-08-31 2:12 ` Hollis Blanchard
1 sibling, 1 reply; 9+ messages in thread
From: Marco Gerards @ 2004-08-30 16:17 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: grub-devel
Hollis Blanchard <hollis@penguinppc.org> writes:
> Seeing that Marco did the hard work of porting grub2 to New World
> Power Mac, I though I'd try to support Old World (i.e. Macs with sucky
> Open Firmware).
This is really great!
Did you had the chance to test your code on a new world mac? If not,
I will do so.
I see that you are claiming all memory available. This is really nice
but we need to consider two things when doing this.
1) It all needs to be freed. Currently I did not free the claimed
memory (shame on me).
2) The linux loader claims some memory and want it to be mapped on the
address on which the kernel was linked. If all memory is claimed
already this will not work.
Do you have any ideas how this can be resolved?
Thanks,
Marco
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: patch for PPC Old World Macintosh
2004-08-30 16:17 ` Marco Gerards
@ 2004-08-31 2:12 ` Hollis Blanchard
2004-09-01 8:27 ` Yoshinori K. Okuji
0 siblings, 1 reply; 9+ messages in thread
From: Hollis Blanchard @ 2004-08-31 2:12 UTC (permalink / raw)
To: Marco Gerards; +Cc: grub-devel
On Aug 30, 2004, at 11:17 AM, Marco Gerards wrote:
> Hollis Blanchard <hollis@penguinppc.org> writes:
>
> Did you had the chance to test your code on a new world mac? If not,
> I will do so.
I haven't, no.
> I see that you are claiming all memory available. This is really nice
> but we need to consider two things when doing this.
>
> 1) It all needs to be freed. Currently I did not free the claimed
> memory (shame on me).
Could this can be done by walking the grub_mm_regions allocated via
grub_mm_init_region() and freeing them one by one? I guess we only want
to release the memory just before launching a kernel, so even if the
memory is still "in use" by GRUB code it should be safe to give it up.
> 2) The linux loader claims some memory and want it to be mapped on the
> address on which the kernel was linked. If all memory is claimed
> already this will not work.
Hmm. I think the i386 loader doesn't worry about such things, but
rather loads the kernel in a fixed region?
One easy possibility is this: don't reserve all memory at all. Instead
reserve a fixed amount that we know we need, and if a kernel wants to
be loaded there then fail. Since the kernel load address doesn't change
often we can probably find a spot that's both big enough for GRUB and
doesn't conflict.
What is the advantage of giving more memory to grub_mm_init_region()
anyways? If it's not very important (e.g. a small performance
improvement when loading a file from a filesystem) then I think we can
agree that avoiding conflict with the kernel is more important...
-Hollis
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: patch for PPC Old World Macintosh
2004-08-31 2:12 ` Hollis Blanchard
@ 2004-09-01 8:27 ` Yoshinori K. Okuji
2004-09-01 16:04 ` Hollis Blanchard
0 siblings, 1 reply; 9+ messages in thread
From: Yoshinori K. Okuji @ 2004-09-01 8:27 UTC (permalink / raw)
To: The development of GRUB 2
On Tuesday 31 August 2004 04:12, Hollis Blanchard wrote:
> Hmm. I think the i386 loader doesn't worry about such things, but
> rather loads the kernel in a fixed region?
Here is a short description about how GRUB/i386-pc works:
1. At the initialization stage, GRUB reserves about 2/3 of the whole
memory for OS images. This starts from 1MB. GRUB never use this region
for its own use.
2. When GRUB boots an OS image actually, GRUB releases all memory
regions which have been allocated for its own use.
3. GRUB copies OS images to appropriate locations, according to
Multiboot Header or other information. This stage is performed by the
kernel (more precisely, the assembly code located at the region
starting from 0x8000).
I think you can use the same way on Mac as well.
Okuji
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: patch for PPC Old World Macintosh
2004-09-01 8:27 ` Yoshinori K. Okuji
@ 2004-09-01 16:04 ` Hollis Blanchard
2004-09-02 4:47 ` Hollis Blanchard
2004-09-02 10:48 ` Yoshinori K. Okuji
0 siblings, 2 replies; 9+ messages in thread
From: Hollis Blanchard @ 2004-09-01 16:04 UTC (permalink / raw)
To: The development of GRUB 2
On Sep 1, 2004, at 3:27 AM, Yoshinori K. Okuji wrote:
> On Tuesday 31 August 2004 04:12, Hollis Blanchard wrote:
>> Hmm. I think the i386 loader doesn't worry about such things, but
>> rather loads the kernel in a fixed region?
>
> Here is a short description about how GRUB/i386-pc works:
>
> 1. At the initialization stage, GRUB reserves about 2/3 of the whole
> memory for OS images. This starts from 1MB. GRUB never use this region
> for its own use.
Ah thanks for the explanation! I think I'm getting it. You just avoid
calling grub_mm_init_region() on the memory from 1MB up to 3/4 of the
total memory.
So in a system with 64M of RAM, from 1MB to ~49M is avoided and never
used for the grub heap (or anything else for that matter). 49M to 64M
would be allocated to the grub heap.
> 2. When GRUB boots an OS image actually, GRUB releases all memory
> regions which have been allocated for its own use.
>
> 3. GRUB copies OS images to appropriate locations, according to
> Multiboot Header or other information. This stage is performed by the
> kernel (more precisely, the assembly code located at the region
> starting from 0x8000).
Ok, the bulk of Linux is loaded at GRUB_LINUX_BZIMAGE_ADDR (1MB) so
that's fine...
I see when you load multiboot ELF segments you require that they live
in the 1M+ unreserved region described above. What OSs use multiboot,
and are they all linked at 1MB or above?
I think this could indeed work on PPC. Right now the entry point and
thus load base is hardcoded to 20M. I think we can claim all free
memory below 20M for the grub heap and leave the rest for OSs.
Of course that would mean that all OSs on PPC must also be linked above
20M, but I think that is safest. Open Firmware can live at various
spots across different machines, including 4-5M and 12-20M. Right now
grub links and loads at 2M (but could load as low as 16K if we wanted
to). That leaves the most viable hole between 5M and 12M, or above 20M.
Linux kernels with attached ramdisks can be quite large...
-Hollis
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: patch for PPC Old World Macintosh
2004-09-01 16:04 ` Hollis Blanchard
@ 2004-09-02 4:47 ` Hollis Blanchard
2004-09-02 10:48 ` Yoshinori K. Okuji
1 sibling, 0 replies; 9+ messages in thread
From: Hollis Blanchard @ 2004-09-02 4:47 UTC (permalink / raw)
To: The development of GRUB 2
On Sep 1, 2004, at 11:04 AM, Hollis Blanchard wrote:
>
> I think this could indeed work on PPC. Right now the entry point and
> thus load base is hardcoded to 20M. I think we can claim all free
> memory below 20M for the grub heap and leave the rest for OSs.
This was very easy to implement. Any comments on the questions and
implications in my earlier mail though?
-Hollis
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: patch for PPC Old World Macintosh
2004-09-01 16:04 ` Hollis Blanchard
2004-09-02 4:47 ` Hollis Blanchard
@ 2004-09-02 10:48 ` Yoshinori K. Okuji
2004-09-02 14:09 ` Jeroen Dekkers
1 sibling, 1 reply; 9+ messages in thread
From: Yoshinori K. Okuji @ 2004-09-02 10:48 UTC (permalink / raw)
To: The development of GRUB 2
On Wednesday 01 September 2004 18:04, Hollis Blanchard wrote:
> I see when you load multiboot ELF segments you require that they live
> in the 1M+ unreserved region described above. What OSs use multiboot,
> and are they all linked at 1MB or above?
I don't remember the implementation for GRUB 2, since it was written by
Jeroen instead of me. So I cannot say anything about that.
There many operating systems based on Multiboot. Just search on the web.
You can find GNU/Hurd, L4, AtheOS, and so on.
Normally OS images are linked to 1MB or above, although Multiboot
Specification does not mention this.
But note that you can relocate the OS image. For example, the Linux
loader on i386 must move a kernel image to <1MB before booting it, if
the format is zimage instead of bzimage. This stage overwrites a part
of GRUB, but there is no problem, because the relocation code resides
at a much lower place.
Okuji
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: patch for PPC Old World Macintosh
2004-09-02 10:48 ` Yoshinori K. Okuji
@ 2004-09-02 14:09 ` Jeroen Dekkers
0 siblings, 0 replies; 9+ messages in thread
From: Jeroen Dekkers @ 2004-09-02 14:09 UTC (permalink / raw)
To: The development of GRUB 2
At Thu, 2 Sep 2004 12:48:05 +0200,
Yoshinori K. Okuji wrote:
>
> On Wednesday 01 September 2004 18:04, Hollis Blanchard wrote:
> > I see when you load multiboot ELF segments you require that they live
> > in the 1M+ unreserved region described above. What OSs use multiboot,
> > and are they all linked at 1MB or above?
>
> I don't remember the implementation for GRUB 2, since it was written by
> Jeroen instead of me. So I cannot say anything about that.
>
> There many operating systems based on Multiboot. Just search on the web.
> You can find GNU/Hurd, L4, AtheOS, and so on.
>
> Normally OS images are linked to 1MB or above, although Multiboot
> Specification does not mention this.
The Multiboot loader just checks whether the ELF segments fit in the
space between grub_os_area_addr and
grub_os_area_addr+grub_os_area_size. It will give an error if it
doesn't fit.
Jeroen Dekkers
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-09-02 14:14 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-29 23:52 patch for PPC Old World Macintosh Hollis Blanchard
2004-08-30 10:25 ` Yoshinori K. Okuji
2004-08-30 16:17 ` Marco Gerards
2004-08-31 2:12 ` Hollis Blanchard
2004-09-01 8:27 ` Yoshinori K. Okuji
2004-09-01 16:04 ` Hollis Blanchard
2004-09-02 4:47 ` Hollis Blanchard
2004-09-02 10:48 ` Yoshinori K. Okuji
2004-09-02 14:09 ` Jeroen Dekkers
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.