* another regression on Efika
@ 2007-07-02 18:16 Robert Millan
2007-07-02 21:14 ` Robert Millan
` (2 more replies)
0 siblings, 3 replies; 35+ messages in thread
From: Robert Millan @ 2007-07-02 18:16 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]
Hi,
I spotted another regression, caused by the following commits:
2007-02-21 Hollis Blanchard <hollis@penguinppc.org>
* kern/powerpc/ieee1275/init.c (HEAP_SIZE): Removed.
(HEAP_LIMIT): New macro.
(grub_claim_heap): Claim memory up to `heaplimit'.
2007-02-21 Hollis Blanchard <hollis@penguinppc.org>
* conf/powerpc-ieee1275.rmk (kernel_elf_LDFLAGS): Link at 64KB.
* kern/powerpc/ieee1275/init.c (_end): Add declaration.
(_start): Likewise.
(grub_arch_modules_addr): Return address after `_end'.
* util/powerpc/ieee1275/grub-mkimage.c: Include grub/misc.h.
(load_modules): Use new parameter as `p_paddr' and `p_vaddr'.
(add_segments): Calculate `_end' from phdr size and location.
(ALIGN_UP): Moved to ...
* include/grub/misc.h: here.
* include/grub/powerpc/ieee1275/kernel.h (GRUB_IEEE1275_MOD_ALIGN):
New macro.
(GRUB_IEEE1275_MODULE_BASE): Removed.
They move GRUB from being able to initialise and fire up the menu (although
still unable to access disks), to abort with:
kern/mm.c: grub_error (GRUB_ERR_OUT_OF_MEMORY, "out of memory");
Unfortunately my limited expertise doesn't let me figure out what these changes
are doing. I'm attaching a reverse diff of the commit, such that when applied
to HEAD makes GRUB work again (verified) [1]. Perhaps someone can make sense
of it.
[1] Provided that the other regression caused by MacWorld hack is also fixed,
of course.
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
[-- Attachment #2: memory.diff --]
[-- Type: text/x-diff, Size: 8605 bytes --]
-2007-02-21 Hollis Blanchard <hollis@penguinppc.org>
-
- * kern/powerpc/ieee1275/init.c (HEAP_SIZE): Removed.
- (HEAP_LIMIT): New macro.
- (grub_claim_heap): Claim memory up to `heaplimit'.
-
-2007-02-21 Hollis Blanchard <hollis@penguinppc.org>
-
- * conf/powerpc-ieee1275.rmk (kernel_elf_LDFLAGS): Link at 64KB.
- * kern/powerpc/ieee1275/init.c (_end): Add declaration.
- (_start): Likewise.
- (grub_arch_modules_addr): Return address after `_end'.
- * util/powerpc/ieee1275/grub-mkimage.c: Include grub/misc.h.
- (load_modules): Use new parameter as `p_paddr' and `p_vaddr'.
- (add_segments): Calculate `_end' from phdr size and location.
- (ALIGN_UP): Moved to ...
- * include/grub/misc.h: here.
- * include/grub/powerpc/ieee1275/kernel.h (GRUB_IEEE1275_MOD_ALIGN):
- New macro.
- (GRUB_IEEE1275_MODULE_BASE): Removed.
diff -ur grub2-bad/conf/powerpc-ieee1275.mk grub2-good/conf/powerpc-ieee1275.mk
--- grub2-bad/conf/powerpc-ieee1275.mk 2007-02-22 00:22:20.000000000 +0100
+++ grub2-good/conf/powerpc-ieee1275.mk 2006-12-13 23:34:04.000000000 +0100
@@ -468,7 +468,7 @@
kernel_elf_CFLAGS = $(COMMON_CFLAGS)
kernel_elf_ASFLAGS = $(COMMON_ASFLAGS)
kernel_elf_LDFLAGS = $(COMMON_LDFLAGS) -static-libgcc -lgcc \
- -Wl,-N,-S,-Ttext,0x10000,-Bstatic
+ -Wl,-N,-S,-Ttext,0x200000,-Bstatic
# Scripts.
sbin_SCRIPTS = grub-install
@@ -1004,4 +1004,3 @@
halt_mod_LDFLAGS = $(COMMON_LDFLAGS)
include $(srcdir)/conf/common.mk
-
diff -ur grub2-bad/conf/powerpc-ieee1275.rmk grub2-good/conf/powerpc-ieee1275.rmk
--- grub2-bad/conf/powerpc-ieee1275.rmk 2007-02-22 00:22:20.000000000 +0100
+++ grub2-good/conf/powerpc-ieee1275.rmk 2006-12-13 23:30:19.000000000 +0100
@@ -74,7 +74,7 @@
kernel_elf_CFLAGS = $(COMMON_CFLAGS)
kernel_elf_ASFLAGS = $(COMMON_ASFLAGS)
kernel_elf_LDFLAGS = $(COMMON_LDFLAGS) -static-libgcc -lgcc \
- -Wl,-N,-S,-Ttext,0x10000,-Bstatic
+ -Wl,-N,-S,-Ttext,0x200000,-Bstatic
# Scripts.
sbin_SCRIPTS = grub-install
@@ -127,4 +127,3 @@
halt_mod_LDFLAGS = $(COMMON_LDFLAGS)
include $(srcdir)/conf/common.mk
-
diff -ur grub2-bad/include/grub/misc.h grub2-good/include/grub/misc.h
--- grub2-bad/include/grub/misc.h 2007-02-22 00:22:20.000000000 +0100
+++ grub2-good/include/grub/misc.h 2006-10-14 17:24:52.000000000 +0200
@@ -26,8 +26,6 @@
#include <grub/symbol.h>
#include <grub/err.h>
-#define ALIGN_UP(addr, align) ((long)((char *)addr + align - 1) & ~(align - 1))
-
#define grub_dprintf(condition, fmt, args...) grub_real_dprintf(__FILE__, __LINE__, condition, fmt, ## args);
/* XXX: If grub_memmove is too slow, we must implement grub_memcpy. */
#define grub_memcpy(d,s,n) grub_memmove ((d), (s), (n))
diff -ur grub2-bad/include/grub/powerpc/ieee1275/kernel.h grub2-good/include/grub/powerpc/ieee1275/kernel.h
--- grub2-bad/include/grub/powerpc/ieee1275/kernel.h 2007-02-22 00:22:20.000000000 +0100
+++ grub2-good/include/grub/powerpc/ieee1275/kernel.h 2006-04-23 15:37:36.000000000 +0200
@@ -22,9 +22,10 @@
#include <grub/symbol.h>
-#define GRUB_IEEE1275_MOD_ALIGN 0x1000
-
void EXPORT_FUNC (grub_reboot) (void);
void EXPORT_FUNC (grub_halt) (void);
+/* Where grub-mkimage places the core modules in memory. */
+#define GRUB_IEEE1275_MODULE_BASE 0x00300000
+
#endif /* ! GRUB_KERNEL_MACHINE_HEADER */
diff -ur grub2-bad/kern/powerpc/ieee1275/init.c grub2-good/kern/powerpc/ieee1275/init.c
--- grub2-bad/kern/powerpc/ieee1275/init.c 2007-02-22 00:27:36.000000000 +0100
+++ grub2-good/kern/powerpc/ieee1275/init.c 2007-02-13 04:49:43.000000000 +0100
@@ -34,10 +34,7 @@
#include <grub/ieee1275/ofdisk.h>
#include <grub/ieee1275/ieee1275.h>
-#define HEAP_LIMIT (4<<20) /* 4 MiB */
-
-extern char _start[];
-extern char _end[];
+#define HEAP_SIZE (8<<20) /* 8 MiB */
void
grub_exit (void)
@@ -114,27 +111,29 @@
}
/* Claim some available memory in the first /memory node. */
-static void grub_claim_heap (unsigned long heaplimit)
+static void grub_claim_heap (unsigned long heapsize)
{
+ unsigned long total = 0;
+
auto int heap_init (grub_uint64_t addr, grub_uint64_t len);
int heap_init (grub_uint64_t addr, grub_uint64_t len)
{
len -= 1; /* Required for some firmware. */
- /* Don't claim anything above `heaplimit'. */
- if (addr + len > heaplimit)
- len = heaplimit - addr;
-
- if (len)
- {
- /* Claim and use it. */
- if (grub_claimmap (addr, len) < 0)
- return grub_error (GRUB_ERR_OUT_OF_MEMORY,
- "Failed to claim heap at 0x%llx, len 0x%llx\n",
- addr, len);
- grub_mm_init_region ((void *) (grub_addr_t) addr, len);
- }
-
+ /* Limit heap to `heapsize'. */
+ if (total + len > heapsize)
+ len = heapsize - total;
+
+ /* Claim and use it. */
+ if (grub_claimmap (addr, len) < 0)
+ return grub_error (GRUB_ERR_OUT_OF_MEMORY,
+ "Failed to claim heap at 0x%llx, len 0x%llx\n",
+ addr, len);
+ grub_mm_init_region ((void *) (grub_addr_t) addr, len);
+
+ total += len;
+ if (total >= heapsize)
+ return 1;
return 0;
}
@@ -148,7 +147,7 @@
int actual;
grub_console_init ();
- grub_claim_heap (HEAP_LIMIT);
+ grub_claim_heap (HEAP_SIZE);
grub_ofdisk_init ();
/* Process commandline. */
@@ -206,5 +205,5 @@
grub_addr_t
grub_arch_modules_addr (void)
{
- return ALIGN_UP(_end, GRUB_IEEE1275_MOD_ALIGN);
+ return GRUB_IEEE1275_MODULE_BASE;
}
diff -ur grub2-bad/util/powerpc/ieee1275/grub-mkimage.c grub2-good/util/powerpc/ieee1275/grub-mkimage.c
--- grub2-bad/util/powerpc/ieee1275/grub-mkimage.c 2007-02-22 00:22:20.000000000 +0100
+++ grub2-good/util/powerpc/ieee1275/grub-mkimage.c 2006-09-26 06:24:38.000000000 +0200
@@ -1,6 +1,6 @@
/*
* GRUB -- GRand Unified Bootloader
- * Copyright (C) 2004,2005,2006,2007 Free Software Foundation, Inc.
+ * Copyright (C) 2004,2005,2006 Free Software Foundation, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -27,12 +27,13 @@
#include <stdlib.h>
#include <string.h>
#include <grub/elf.h>
-#include <grub/misc.h>
#include <grub/util/misc.h>
#include <grub/util/resolve.h>
#include <grub/kernel.h>
#include <grub/machine/kernel.h>
+#define ALIGN_UP(addr, align) ((long)((char *)addr + align - 1) & ~(align - 1))
+
#define GRUB_IEEE1275_NOTE_NAME "PowerPC"
#define GRUB_IEEE1275_NOTE_TYPE 0x1275
@@ -97,8 +98,7 @@
}
void
-load_modules (grub_addr_t modbase, Elf32_Phdr *phdr, const char *dir,
- char *mods[], FILE *out)
+load_modules (Elf32_Phdr *phdr, const char *dir, char *mods[], FILE *out)
{
char *module_img;
struct grub_util_path_list *path_list;
@@ -152,8 +152,8 @@
phdr->p_type = grub_cpu_to_be32 (PT_LOAD);
phdr->p_flags = grub_cpu_to_be32 (PF_R | PF_W | PF_X);
phdr->p_align = grub_cpu_to_be32 (sizeof (long));
- phdr->p_vaddr = grub_cpu_to_be32 (modbase);
- phdr->p_paddr = grub_cpu_to_be32 (modbase);
+ phdr->p_vaddr = grub_cpu_to_be32 (GRUB_IEEE1275_MODULE_BASE);
+ phdr->p_paddr = grub_cpu_to_be32 (GRUB_IEEE1275_MODULE_BASE);
phdr->p_filesz = grub_cpu_to_be32 (total_module_size);
phdr->p_memsz = grub_cpu_to_be32 (total_module_size);
}
@@ -166,7 +166,6 @@
Elf32_Phdr *phdr;
FILE *in;
char *kernel_path;
- grub_addr_t grub_end = 0;
off_t phdroff;
int i;
@@ -184,7 +183,6 @@
for (i = 0; i < grub_be_to_cpu16 (ehdr.e_phnum); i++)
{
char *segment_img;
- grub_size_t segment_end;
phdr = phdrs + i;
@@ -196,13 +194,6 @@
grub_util_info ("copying segment %d, type %d", i,
grub_be_to_cpu32 (phdr->p_type));
- /* Locate _end. */
- segment_end = grub_be_to_cpu32 (phdr->p_paddr)
- + grub_be_to_cpu32 (phdr->p_memsz);
- grub_util_info ("segment %u end 0x%lx", i, segment_end);
- if (segment_end > grub_end)
- grub_end = segment_end;
-
/* Read segment data and write it to new file. */
segment_img = xmalloc (grub_be_to_cpu32 (phdr->p_filesz));
@@ -216,11 +207,6 @@
if (mods[0] != NULL)
{
- grub_addr_t modbase;
-
- /* Place modules just after grub segment. */
- modbase = ALIGN_UP(grub_end, GRUB_IEEE1275_MOD_ALIGN);
-
/* Construct new segment header for modules. */
phdr = phdrs + grub_be_to_cpu16 (ehdr.e_phnum);
ehdr.e_phnum = grub_cpu_to_be16 (grub_be_to_cpu16 (ehdr.e_phnum) + 1);
@@ -229,7 +215,7 @@
phdr->p_offset = grub_cpu_to_be32 (ALIGN_UP (grub_util_get_fp_size (out),
sizeof (long)));
- load_modules (modbase, phdr, dir, mods, out);
+ load_modules (phdr, dir, mods, out);
}
if (chrp)
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: another regression on Efika
2007-07-02 18:16 another regression on Efika Robert Millan
@ 2007-07-02 21:14 ` Robert Millan
2007-07-04 16:18 ` Hollis Blanchard
2007-08-05 10:03 ` updated regression diff (Re: another regression on Efika) Robert Millan
2 siblings, 0 replies; 35+ messages in thread
From: Robert Millan @ 2007-07-02 21:14 UTC (permalink / raw)
To: grub-devel
On Mon, Jul 02, 2007 at 08:16:35PM +0200, Robert Millan wrote:
>
> Hi,
>
> I spotted another regression, caused by the following commits:
>
> 2007-02-21 Hollis Blanchard <hollis@penguinppc.org>
>
> * kern/powerpc/ieee1275/init.c (HEAP_SIZE): Removed.
> (HEAP_LIMIT): New macro.
> (grub_claim_heap): Claim memory up to `heaplimit'.
>
> 2007-02-21 Hollis Blanchard <hollis@penguinppc.org>
>
> * conf/powerpc-ieee1275.rmk (kernel_elf_LDFLAGS): Link at 64KB.
> * kern/powerpc/ieee1275/init.c (_end): Add declaration.
> (_start): Likewise.
> (grub_arch_modules_addr): Return address after `_end'.
> * util/powerpc/ieee1275/grub-mkimage.c: Include grub/misc.h.
> (load_modules): Use new parameter as `p_paddr' and `p_vaddr'.
> (add_segments): Calculate `_end' from phdr size and location.
> (ALIGN_UP): Moved to ...
> * include/grub/misc.h: here.
> * include/grub/powerpc/ieee1275/kernel.h (GRUB_IEEE1275_MOD_ALIGN):
> New macro.
> (GRUB_IEEE1275_MODULE_BASE): Removed.
Btw, splitting the commits doesn't help. In-between version fails differently,
and just reverting one of them in any later version doesn't solve the problem.
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: another regression on Efika
2007-07-02 18:16 another regression on Efika Robert Millan
2007-07-02 21:14 ` Robert Millan
@ 2007-07-04 16:18 ` Hollis Blanchard
2007-07-10 10:04 ` Jordi Mallach
2007-08-05 10:03 ` updated regression diff (Re: another regression on Efika) Robert Millan
2 siblings, 1 reply; 35+ messages in thread
From: Hollis Blanchard @ 2007-07-04 16:18 UTC (permalink / raw)
To: Robert Millan; +Cc: grub-devel
On Mon, 2007-07-02 at 20:16 +0200, Robert Millan wrote:
> Hi,
>
> I spotted another regression, caused by the following commits:
>
> 2007-02-21 Hollis Blanchard <hollis@penguinppc.org>
>
> * kern/powerpc/ieee1275/init.c (HEAP_SIZE): Removed.
> (HEAP_LIMIT): New macro.
> (grub_claim_heap): Claim memory up to `heaplimit'.
>
> 2007-02-21 Hollis Blanchard <hollis@penguinppc.org>
>
> * conf/powerpc-ieee1275.rmk (kernel_elf_LDFLAGS): Link at 64KB.
> * kern/powerpc/ieee1275/init.c (_end): Add declaration.
> (_start): Likewise.
> (grub_arch_modules_addr): Return address after `_end'.
> * util/powerpc/ieee1275/grub-mkimage.c: Include grub/misc.h.
> (load_modules): Use new parameter as `p_paddr' and `p_vaddr'.
> (add_segments): Calculate `_end' from phdr size and location.
> (ALIGN_UP): Moved to ...
> * include/grub/misc.h: here.
> * include/grub/powerpc/ieee1275/kernel.h (GRUB_IEEE1275_MOD_ALIGN):
> New macro.
> (GRUB_IEEE1275_MODULE_BASE): Removed.
>
> They move GRUB from being able to initialise and fire up the menu (although
> still unable to access disks), to abort with:
>
> kern/mm.c: grub_error (GRUB_ERR_OUT_OF_MEMORY, "out of memory");
This is probably because grub_mm_init_region() was never called, or
wasn't called enough.
> Unfortunately my limited expertise doesn't let me figure out what these changes
> are doing. I'm attaching a reverse diff of the commit, such that when applied
> to HEAD makes GRUB work again (verified) [1]. Perhaps someone can make sense
> of it.
This problem could be caused by firmware presenting an
incorrect /memory/available property. I would instrument
grub_available_iterate() and heap_init() to confirm.
That property lists unclaimed areas of memory, which are free for us to
use as heap. The memory used for firmware itself (including exception
handlers at 0), and the memory used by the loaded ELF file (GRUB), are
missing from /memory/available, so we know not to try to use those
regions for the heap.
If that is in fact the problem (which wouldn't surprise me given this
particular firmware's track record), then we'll have to add some
hardcoded hack particularly for Efika in grub_machine_init(), bypassing
the more general code we have now.
-Hollis
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: another regression on Efika
2007-07-04 16:18 ` Hollis Blanchard
@ 2007-07-10 10:04 ` Jordi Mallach
2007-07-10 14:08 ` memory management issue (Re: another regression on Efika) Robert Millan
2007-07-10 14:10 ` OF disk naming scheme (Re: another regression on Efika) Robert Millan
0 siblings, 2 replies; 35+ messages in thread
From: Jordi Mallach @ 2007-07-10 10:04 UTC (permalink / raw)
To: grub-devel
Hey,
On Wed, Jul 04, 2007, Hollis said:
> This problem could be caused by firmware presenting an
> incorrect /memory/available property. I would instrument
> grub_available_iterate() and heap_init() to confirm.
>
> That property lists unclaimed areas of memory, which are free for us to
> use as heap. The memory used for firmware itself (including exception
> handlers at 0), and the memory used by the loaded ELF file (GRUB), are
> missing from /memory/available, so we know not to try to use those
> regions for the heap.
>
> If that is in fact the problem (which wouldn't surprise me given this
> particular firmware's track record), then we'll have to add some
> hardcoded hack particularly for Efika in grub_machine_init(), bypassing
> the more general code we have now.
I'm afraid there must be more to this.
The last version of GRUB which worked for me was Debian's 1.95-5, albeit
it wouldn't show a valid menu (but that was caused by another bug, more
or less fixed now). At that time, I could at least type in my
linux+initrd commands to make the laptop boot.
When the package was later on updated to a CVS snapshot of 20070505,
GRUB started dropping me to OF at boot time. On Saturday, Robert helped
me track this regression down to this same commit. After reverting and
regenerating grub, I'm happy to report that for the first time my
Powerbook G4 laptop was able to boot with me pressing no keys at all,
using GRUB.
In short, whatever is causing these crashes is not only an Efika issue.
I suspect Apple, or Apple powerbooks at least, are also affected. I got
Sjoerd to try this on his powerbook, and he confirms this fixes for him.
Paul also tried, with the same results. Not all the powerbooks are the
very same model, there are different model revisions involved.
The biggest issue now is that we all had to fix our generated
configurations, as grub-probe and update-grub won't cope with a
device.map that looks like this:
(hd) /dev/hda
This is a minor issue that I can fix by hand, luckily.
Thanks,
Jordi
--
Jordi Mallach <jordi@gnu.org>
^ permalink raw reply [flat|nested] 35+ messages in thread
* memory management issue (Re: another regression on Efika)
2007-07-10 10:04 ` Jordi Mallach
@ 2007-07-10 14:08 ` Robert Millan
2007-07-10 20:32 ` Hollis Blanchard
2007-07-10 14:10 ` OF disk naming scheme (Re: another regression on Efika) Robert Millan
1 sibling, 1 reply; 35+ messages in thread
From: Robert Millan @ 2007-07-10 14:08 UTC (permalink / raw)
To: The development of GRUB 2
On Tue, Jul 10, 2007 at 12:04:44PM +0200, Jordi Mallach wrote:
> Hey,
>
> On Wed, Jul 04, 2007, Hollis said:
> > This problem could be caused by firmware presenting an
> > incorrect /memory/available property. I would instrument
> > grub_available_iterate() and heap_init() to confirm.
> >
> > That property lists unclaimed areas of memory, which are free for us to
> > use as heap. The memory used for firmware itself (including exception
> > handlers at 0), and the memory used by the loaded ELF file (GRUB), are
> > missing from /memory/available, so we know not to try to use those
> > regions for the heap.
> >
> > If that is in fact the problem (which wouldn't surprise me given this
> > particular firmware's track record), then we'll have to add some
> > hardcoded hack particularly for Efika in grub_machine_init(), bypassing
> > the more general code we have now.
>
> I'm afraid there must be more to this.
>
> [...]
>
> When the package was later on updated to a CVS snapshot of 20070505,
> GRUB started dropping me to OF at boot time. On Saturday, Robert helped
> me track this regression down to this same commit. After reverting and
> regenerating grub, I'm happy to report that for the first time my
> Powerbook G4 laptop was able to boot with me pressing no keys at all,
> using GRUB.
>
> In short, whatever is causing these crashes is not only an Efika issue.
> I suspect Apple, or Apple powerbooks at least, are also affected. I got
> Sjoerd to try this on his powerbook, and he confirms this fixes for him.
> Paul also tried, with the same results. Not all the powerbooks are the
> very same model, there are different model revisions involved.
The error Jordi was seeing before reverting your commits was very similar to
what I get on my Efika (something like "claim failed").
Hollis, do you still think this is a firmware bug?
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: memory management issue (Re: another regression on Efika)
2007-07-10 14:08 ` memory management issue (Re: another regression on Efika) Robert Millan
@ 2007-07-10 20:32 ` Hollis Blanchard
2007-07-13 22:08 ` Robert Millan
0 siblings, 1 reply; 35+ messages in thread
From: Hollis Blanchard @ 2007-07-10 20:32 UTC (permalink / raw)
To: The development of GRUB 2
On Tue, 2007-07-10 at 16:08 +0200, Robert Millan wrote:
> On Tue, Jul 10, 2007 at 12:04:44PM +0200, Jordi Mallach wrote:
> > Hey,
> >
> > On Wed, Jul 04, 2007, Hollis said:
> > > This problem could be caused by firmware presenting an
> > > incorrect /memory/available property. I would instrument
> > > grub_available_iterate() and heap_init() to confirm.
> > >
> > > That property lists unclaimed areas of memory, which are free for us to
> > > use as heap. The memory used for firmware itself (including exception
> > > handlers at 0), and the memory used by the loaded ELF file (GRUB), are
> > > missing from /memory/available, so we know not to try to use those
> > > regions for the heap.
> > >
> > > If that is in fact the problem (which wouldn't surprise me given this
> > > particular firmware's track record), then we'll have to add some
> > > hardcoded hack particularly for Efika in grub_machine_init(), bypassing
> > > the more general code we have now.
> >
> > I'm afraid there must be more to this.
> >
> > [...]
> >
> > When the package was later on updated to a CVS snapshot of 20070505,
> > GRUB started dropping me to OF at boot time. On Saturday, Robert helped
> > me track this regression down to this same commit. After reverting and
> > regenerating grub, I'm happy to report that for the first time my
> > Powerbook G4 laptop was able to boot with me pressing no keys at all,
> > using GRUB.
So you're talking about a completely different failure mode, correct?
> > In short, whatever is causing these crashes is not only an Efika issue.
> > I suspect Apple, or Apple powerbooks at least, are also affected. I got
> > Sjoerd to try this on his powerbook, and he confirms this fixes for him.
> > Paul also tried, with the same results. Not all the powerbooks are the
> > very same model, there are different model revisions involved.
>
> The error Jordi was seeing before reverting your commits was very similar to
> what I get on my Efika (something like "claim failed").
>
> Hollis, do you still think this is a firmware bug?
Could somebody please debug it and report back if it is really a GRUB
issue? It could be as simple as adjusting the link address, or it could
mean instrumenting grub_available_iterate() and checking that output
with the contents of /memory/available.
-Hollis
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: memory management issue (Re: another regression on Efika)
2007-07-10 20:32 ` Hollis Blanchard
@ 2007-07-13 22:08 ` Robert Millan
2007-07-24 19:59 ` Robert Millan
0 siblings, 1 reply; 35+ messages in thread
From: Robert Millan @ 2007-07-13 22:08 UTC (permalink / raw)
To: The development of GRUB 2
On Tue, Jul 10, 2007 at 03:32:30PM -0500, Hollis Blanchard wrote:
> > > In short, whatever is causing these crashes is not only an Efika issue.
> > > I suspect Apple, or Apple powerbooks at least, are also affected. I got
> > > Sjoerd to try this on his powerbook, and he confirms this fixes for him.
> > > Paul also tried, with the same results. Not all the powerbooks are the
> > > very same model, there are different model revisions involved.
> >
> > The error Jordi was seeing before reverting your commits was very similar to
> > what I get on my Efika (something like "claim failed").
> >
> > Hollis, do you still think this is a firmware bug?
>
> Could somebody please debug it and report back if it is really a GRUB
> issue? It could be as simple as adjusting the link address, or it could
> mean instrumenting grub_available_iterate() and checking that output
> with the contents of /memory/available.
It turns out that grub_claim_heap() was asked to claim a region that starts
after the heap limit. The start address (0x19111e4) is correctly obtained
from /memory/available.
Should heap limit be increased?
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: memory management issue (Re: another regression on Efika)
2007-07-13 22:08 ` Robert Millan
@ 2007-07-24 19:59 ` Robert Millan
2007-07-25 17:51 ` Hollis Blanchard
0 siblings, 1 reply; 35+ messages in thread
From: Robert Millan @ 2007-07-24 19:59 UTC (permalink / raw)
To: The development of GRUB 2
[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]
On Sat, Jul 14, 2007 at 12:08:30AM +0200, Robert Millan wrote:
> On Tue, Jul 10, 2007 at 03:32:30PM -0500, Hollis Blanchard wrote:
> > > > In short, whatever is causing these crashes is not only an Efika issue.
> > > > I suspect Apple, or Apple powerbooks at least, are also affected. I got
> > > > Sjoerd to try this on his powerbook, and he confirms this fixes for him.
> > > > Paul also tried, with the same results. Not all the powerbooks are the
> > > > very same model, there are different model revisions involved.
> > >
> > > The error Jordi was seeing before reverting your commits was very similar to
> > > what I get on my Efika (something like "claim failed").
> > >
> > > Hollis, do you still think this is a firmware bug?
> >
> > Could somebody please debug it and report back if it is really a GRUB
> > issue? It could be as simple as adjusting the link address, or it could
> > mean instrumenting grub_available_iterate() and checking that output
> > with the contents of /memory/available.
>
> It turns out that grub_claim_heap() was asked to claim a region that starts
> after the heap limit. The start address (0x19111e4) is correctly obtained
> from /memory/available.
>
> Should heap limit be increased?
The attached patch fixes the problem for Efika, although I'm not 1:1 sure of
its correctness.
It seems to me that heaplimit is meant to be used as a relative offset, not
as an absolute memory address. This makes the current code fail when the
start address in /memory/available is higher than heaplimit, and I don't
think there's anything that can grant us this won't happen. From this POV,
it's clear that moving from relative to absolute address is wrong.
OTOH, your commit indicates (as per variable names, etc) that this change
was done intentionally; so I have to assume there would be a reason for that.
Please can you clarify?
Btw, the attached patch doesn't fix the problem for Jordi (Mac). Maybe
we're talking about two separate bugs after all.
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
[-- Attachment #2: memory_fix.diff --]
[-- Type: text/x-diff, Size: 1072 bytes --]
Index: kern/powerpc/ieee1275/init.c
===================================================================
RCS file: /sources/grub/grub2/kern/powerpc/ieee1275/init.c,v
retrieving revision 1.31
diff -u -r1.31 init.c
--- kern/powerpc/ieee1275/init.c 21 Jul 2007 23:32:27 -0000 1.31
+++ kern/powerpc/ieee1275/init.c 23 Jul 2007 19:49:44 -0000
@@ -115,14 +115,16 @@
/* Claim some available memory in the first /memory node. */
static void grub_claim_heap (unsigned long heaplimit)
{
+ unsigned long total = 0;
+
auto int heap_init (grub_uint64_t addr, grub_uint64_t len);
int heap_init (grub_uint64_t addr, grub_uint64_t len)
{
len -= 1; /* Required for some firmware. */
/* Don't claim anything above `heaplimit'. */
- if (addr + len > heaplimit)
- len = heaplimit - addr;
+ if (total + len > heaplimit)
+ len = heaplimit - total;
if (len)
{
@@ -134,6 +136,10 @@
grub_mm_init_region ((void *) (grub_addr_t) addr, len);
}
+ total += len;
+ if (total >= heaplimit)
+ return 1;
+
return 0;
}
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: memory management issue (Re: another regression on Efika)
2007-07-24 19:59 ` Robert Millan
@ 2007-07-25 17:51 ` Hollis Blanchard
2007-07-25 20:08 ` Robert Millan
0 siblings, 1 reply; 35+ messages in thread
From: Hollis Blanchard @ 2007-07-25 17:51 UTC (permalink / raw)
To: Robert Millan; +Cc: The development of GRUB 2
On 7/24/07, Robert Millan <rmh@aybabtu.com> wrote:
> On Sat, Jul 14, 2007 at 12:08:30AM +0200, Robert Millan wrote:
> > On Tue, Jul 10, 2007 at 03:32:30PM -0500, Hollis Blanchard wrote:
> > > > > In short, whatever is causing these crashes is not only an Efika issue.
> > > > > I suspect Apple, or Apple powerbooks at least, are also affected. I got
> > > > > Sjoerd to try this on his powerbook, and he confirms this fixes for him.
> > > > > Paul also tried, with the same results. Not all the powerbooks are the
> > > > > very same model, there are different model revisions involved.
> > > >
> > > > The error Jordi was seeing before reverting your commits was very similar to
> > > > what I get on my Efika (something like "claim failed").
> > > >
> > > > Hollis, do you still think this is a firmware bug?
> > >
> > > Could somebody please debug it and report back if it is really a GRUB
> > > issue? It could be as simple as adjusting the link address, or it could
> > > mean instrumenting grub_available_iterate() and checking that output
> > > with the contents of /memory/available.
> >
> > It turns out that grub_claim_heap() was asked to claim a region that starts
> > after the heap limit. The start address (0x19111e4) is correctly obtained
> > from /memory/available.
> >
> > Should heap limit be increased?
>
> The attached patch fixes the problem for Efika, although I'm not 1:1 sure of
> its correctness.
>
> It seems to me that heaplimit is meant to be used as a relative offset, not
> as an absolute memory address. This makes the current code fail when the
> start address in /memory/available is higher than heaplimit, and I don't
> think there's anything that can grant us this won't happen. From this POV,
> it's clear that moving from relative to absolute address is wrong.
>
> OTOH, your commit indicates (as per variable names, etc) that this change
> was done intentionally; so I have to assume there would be a reason for that.
> Please can you clarify?
>
> Btw, the attached patch doesn't fix the problem for Jordi (Mac). Maybe
> we're talking about two separate bugs after all.
I was indeed trying to make it absolute. GRUB is linked at 0x10000, or
64KB. Add in all the modules and you still are only using a couple
hundred KB.
I don't remember *why* I was trying to make it absolute; I'm sure it
was to fix a problem (rather than I was bored). If we could get away
from this anachronistic Changelog crap, the commit message would have
told us exactly what we need to know.
I *think* it was because we have a relocation problem with OSes that
are linked at 4MB, which is the case with Xen (and I believe yaboot).
If GRUB is using that memory, we simply can't load anything there.
I think we can add some somewhat-special-case logic that says if there
is nothing available below HEAP_LIMIT, claim something beginning as
low as we can. That reduces functionality on such platforms (as
described above), but there's little we can do about that unless
firmware is fixed.
My big question is this: why is Efika firmware saying that 0x19111e4
(around 25MB) is the first available address?
BTW, does Jordi have any details on this Mac problem?
-Hollis
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: memory management issue (Re: another regression on Efika)
2007-07-25 17:51 ` Hollis Blanchard
@ 2007-07-25 20:08 ` Robert Millan
2007-07-25 23:25 ` Hollis Blanchard
0 siblings, 1 reply; 35+ messages in thread
From: Robert Millan @ 2007-07-25 20:08 UTC (permalink / raw)
To: The development of GRUB 2; +Cc: Jordi Mallach
On Wed, Jul 25, 2007 at 12:51:27PM -0500, Hollis Blanchard wrote:
>
> I was indeed trying to make it absolute. GRUB is linked at 0x10000, or
> 64KB. Add in all the modules and you still are only using a couple
> hundred KB.
But if GRUB is linked at 0x10000, how come the firmware loads it since
that's below the 0x19111e4 limit? (or am I missing some physical vs logical
issue here?)
> I don't remember *why* I was trying to make it absolute; I'm sure it
> was to fix a problem (rather than I was bored). If we could get away
> from this anachronistic Changelog crap, the commit message would have
> told us exactly what we need to know.
I pasted the ChangeLog entries in an earlier mail. Do you mean the CVS commit
message might have more information?
> I *think* it was because we have a relocation problem with OSes that
> are linked at 4MB, which is the case with Xen (and I believe yaboot).
> If GRUB is using that memory, we simply can't load anything there.
>
> I think we can add some somewhat-special-case logic that says if there
> is nothing available below HEAP_LIMIT, claim something beginning as
> low as we can. That reduces functionality on such platforms (as
> described above), but there's little we can do about that unless
> firmware is fixed.
So the purpose of HEAP_LIMIT is to support code that is linked at fixed
addresses?
> My big question is this: why is Efika firmware saying that 0x19111e4
> (around 25MB) is the first available address?
What is wrong with that? Is it general practice that all firmwares load
at low addresses so that non-relocatable code can be linked at 4MB or such?
> BTW, does Jordi have any details on this Mac problem?
He said that after appliing the patch that makes heaplimit a relative address
it still won't work. /memory/available:
00003000 0000d000 0002d000 007d3000 00848000 1f3b8000
I'm CCing him.
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: memory management issue (Re: another regression on Efika)
2007-07-25 20:08 ` Robert Millan
@ 2007-07-25 23:25 ` Hollis Blanchard
2007-07-27 8:05 ` Robert Millan
0 siblings, 1 reply; 35+ messages in thread
From: Hollis Blanchard @ 2007-07-25 23:25 UTC (permalink / raw)
To: The development of GRUB 2
On 7/25/07, Robert Millan <rmh@aybabtu.com> wrote:
> On Wed, Jul 25, 2007 at 12:51:27PM -0500, Hollis Blanchard wrote:
> >
> > I was indeed trying to make it absolute. GRUB is linked at 0x10000, or
> > 64KB. Add in all the modules and you still are only using a couple
> > hundred KB.
>
> But if GRUB is linked at 0x10000, how come the firmware loads it since
> that's below the 0x19111e4 limit? (or am I missing some physical vs logical
> issue here?)
No, you are correct; obviously firmware is doing something wrong. The
question is can we accommodate it, and if so, how?
> > I don't remember *why* I was trying to make it absolute; I'm sure it
> > was to fix a problem (rather than I was bored). If we could get away
> > from this anachronistic Changelog crap, the commit message would have
> > told us exactly what we need to know.
>
> I pasted the ChangeLog entries in an earlier mail. Do you mean the CVS commit
> message might have more information?
I mean if this were any other project I participate in, I would have
explicitly spelled out why the commit was done.
> > I *think* it was because we have a relocation problem with OSes that
> > are linked at 4MB, which is the case with Xen (and I believe yaboot).
> > If GRUB is using that memory, we simply can't load anything there.
> >
> > I think we can add some somewhat-special-case logic that says if there
> > is nothing available below HEAP_LIMIT, claim something beginning as
> > low as we can. That reduces functionality on such platforms (as
> > described above), but there's little we can do about that unless
> > firmware is fixed.
>
> So the purpose of HEAP_LIMIT is to support code that is linked at fixed
> addresses?
Yes. This includes yaboot, Xen, and Linux zImages. I think zImages
relocate themselves no matter where they were loaded though.
> > My big question is this: why is Efika firmware saying that 0x19111e4
> > (around 25MB) is the first available address?
>
> What is wrong with that? Is it general practice that all firmwares load
> at low addresses so that non-relocatable code can be linked at 4MB or such?
Not at all. IBM pSeries firmwares load at a default of 12MB, and I've
seen others that load at the top of RAM to stay out of the way.
It's clear that Efika firmware isn't *really* using all memory below
25MB; we know this because we managed to load grub there. This
undoubtedly an Efika firmware bug, but as I described earlier I think
we can devise another workaround for it without hurting the common
case.
-Hollis
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: memory management issue (Re: another regression on Efika)
2007-07-25 23:25 ` Hollis Blanchard
@ 2007-07-27 8:05 ` Robert Millan
[not found] ` <20070727103310.GA1539@powerlinux.fr>
0 siblings, 1 reply; 35+ messages in thread
From: Robert Millan @ 2007-07-27 8:05 UTC (permalink / raw)
To: The development of GRUB 2; +Cc: Sven Luther
On Wed, Jul 25, 2007 at 06:25:24PM -0500, Hollis Blanchard wrote:
> On 7/25/07, Robert Millan <rmh@aybabtu.com> wrote:
> >On Wed, Jul 25, 2007 at 12:51:27PM -0500, Hollis Blanchard wrote:
> >>
> >> I was indeed trying to make it absolute. GRUB is linked at 0x10000, or
> >> 64KB. Add in all the modules and you still are only using a couple
> >> hundred KB.
> >
> >But if GRUB is linked at 0x10000, how come the firmware loads it since
> >that's below the 0x19111e4 limit? (or am I missing some physical vs
> >logical
> >issue here?)
>
> No, you are correct; obviously firmware is doing something wrong. The
> question is can we accommodate it, and if so, how?
>
> [...]
>
> 25MB; we know this because we managed to load grub there. This
> undoubtedly an Efika firmware bug, but as I described earlier I think
> we can devise another workaround for it without hurting the common
> case.
I contacted Sven Luther (CCed) about it. This is what he said:
17:19 <svenl> nyu: this is another not really bug but ugly feature of the efika firmware, not present in the pegasos branch.
17:19 <svenl> the problem is that the graphic memory is mapped at the start, and the firmware is located from 16MB to 24MB or so, maybe a bit more with the
stack.
17:20 <svenl> normally; the area between 0 and 16MB, except for the interrupt vectors, should be available.
So we could do as you suggested before, and only claim memory below heaplimit
when possible, or we could register the area between end of grub image and
16MB as claimed. That is, assuming 0x1000000 (or whatever the exact address
is) is exactly the last unused address in that region.
Though, the idea of registering an area as claimed without telling the firmware
about it sounds like a no-no to me. What do you think? Is it really worth it?
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
^ permalink raw reply [flat|nested] 35+ messages in thread
* OF disk naming scheme (Re: another regression on Efika)
2007-07-10 10:04 ` Jordi Mallach
2007-07-10 14:08 ` memory management issue (Re: another regression on Efika) Robert Millan
@ 2007-07-10 14:10 ` Robert Millan
2007-07-10 19:26 ` Jordi Mallach
1 sibling, 1 reply; 35+ messages in thread
From: Robert Millan @ 2007-07-10 14:10 UTC (permalink / raw)
To: The development of GRUB 2
On Tue, Jul 10, 2007 at 12:04:44PM +0200, Jordi Mallach wrote:
>
> The biggest issue now is that we all had to fix our generated
> configurations, as grub-probe and update-grub won't cope with a
> device.map that looks like this:
>
> (hd) /dev/hda
>
> This is a minor issue that I can fix by hand, luckily.
What naming/numbering scheme does this follow when you add more disks?
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: OF disk naming scheme (Re: another regression on Efika)
2007-07-10 14:10 ` OF disk naming scheme (Re: another regression on Efika) Robert Millan
@ 2007-07-10 19:26 ` Jordi Mallach
2007-07-13 22:16 ` Robert Millan
0 siblings, 1 reply; 35+ messages in thread
From: Jordi Mallach @ 2007-07-10 19:26 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 406 bytes --]
On Tue, Jul 10, 2007 at 04:10:52PM +0200, Robert Millan wrote:
> What naming/numbering scheme does this follow when you add more disks?
hd, hd1, hd2. Luckily Mozillion has Firewire disks.
--
Jordi Mallach Pérez -- Debian developer http://www.debian.org/
jordi@sindominio.net jordi@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: OF disk naming scheme (Re: another regression on Efika)
2007-07-10 19:26 ` Jordi Mallach
@ 2007-07-13 22:16 ` Robert Millan
2007-07-22 9:33 ` Robert Millan
0 siblings, 1 reply; 35+ messages in thread
From: Robert Millan @ 2007-07-13 22:16 UTC (permalink / raw)
To: The development of GRUB 2
On Tue, Jul 10, 2007 at 09:26:27PM +0200, Jordi Mallach wrote:
> On Tue, Jul 10, 2007 at 04:10:52PM +0200, Robert Millan wrote:
> > What naming/numbering scheme does this follow when you add more disks?
>
> hd, hd1, hd2. Luckily Mozillion has Firewire disks.
My Efika counts: hd, hd0 ...
IEEE 1275 does not seem to cover this. What scheme should we follow when
generating device.map ?
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: OF disk naming scheme (Re: another regression on Efika)
2007-07-13 22:16 ` Robert Millan
@ 2007-07-22 9:33 ` Robert Millan
2007-07-22 14:37 ` Marco Gerards
0 siblings, 1 reply; 35+ messages in thread
From: Robert Millan @ 2007-07-22 9:33 UTC (permalink / raw)
To: The development of GRUB 2
[-- Attachment #1: Type: text/plain, Size: 858 bytes --]
On Sat, Jul 14, 2007 at 12:16:16AM +0200, Robert Millan wrote:
> On Tue, Jul 10, 2007 at 09:26:27PM +0200, Jordi Mallach wrote:
> > On Tue, Jul 10, 2007 at 04:10:52PM +0200, Robert Millan wrote:
> > > What naming/numbering scheme does this follow when you add more disks?
> >
> > hd, hd1, hd2. Luckily Mozillion has Firewire disks.
>
> My Efika counts: hd, hd0 ...
>
> IEEE 1275 does not seem to cover this. What scheme should we follow when
> generating device.map ?
Since "hd, hd1, hd2 ..." seems to be much more common, I propose we use that
and let user override it via device.map in case of disparity (which may only
happen in systems with more than 1 disk).
See attached patch.
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
[-- Attachment #2: device_numbering.diff --]
[-- Type: text/x-diff, Size: 6406 bytes --]
diff -Nur grub2/conf/i386-efi.rmk grub2.new/conf/i386-efi.rmk
--- grub2/conf/i386-efi.rmk 2007-07-22 11:32:51.000000000 +0200
+++ grub2.new/conf/i386-efi.rmk 2007-07-22 11:32:57.000000000 +0200
@@ -24,7 +24,8 @@
# kern/fs.c kern/env.c fs/fshelp.c
# For grub-mkdevicemap.
-grub_mkdevicemap_SOURCES = util/grub-mkdevicemap.c util/misc.c
+grub_mkdevicemap_SOURCES = util/grub-mkdevicemap.c util/misc.c \
+ util/i386/get_disk_name.c
# For grub-probe.
grub_probe_SOURCES = util/grub-probe.c \
diff -Nur grub2/conf/i386-pc.rmk grub2.new/conf/i386-pc.rmk
--- grub2/conf/i386-pc.rmk 2007-07-22 11:32:51.000000000 +0200
+++ grub2.new/conf/i386-pc.rmk 2007-07-22 11:32:57.000000000 +0200
@@ -71,7 +71,8 @@
util/raid.c util/lvm.c
# For grub-mkdevicemap.
-grub_mkdevicemap_SOURCES = util/grub-mkdevicemap.c util/misc.c
+grub_mkdevicemap_SOURCES = util/grub-mkdevicemap.c util/misc.c \
+ util/i386/get_disk_name.c
# For grub-probe.
grub_probe_SOURCES = util/grub-probe.c \
diff -Nur grub2/conf/powerpc-ieee1275.rmk grub2.new/conf/powerpc-ieee1275.rmk
--- grub2/conf/powerpc-ieee1275.rmk 2007-07-02 21:50:41.000000000 +0200
+++ grub2.new/conf/powerpc-ieee1275.rmk 2007-07-22 11:20:37.000000000 +0200
@@ -36,7 +36,8 @@
util/resolve.c
# For grub-mkdevicemap.
-grub_mkdevicemap_SOURCES = util/grub-mkdevicemap.c util/misc.c
+grub_mkdevicemap_SOURCES = util/grub-mkdevicemap.c util/misc.c \
+ util/ieee1275/get_disk_name.c
# For grub-probe.
grub_probe_SOURCES = util/grub-probe.c \
diff -Nur grub2/include/grub/util/misc.h grub2.new/include/grub/util/misc.h
--- grub2/include/grub/util/misc.h 2007-07-22 06:50:10.000000000 +0200
+++ grub2.new/include/grub/util/misc.h 2007-07-22 11:20:37.000000000 +0200
@@ -53,5 +53,6 @@
void grub_util_write_image (const char *img, size_t size, FILE *out);
void grub_util_write_image_at (const void *img, size_t size, off_t offset,
FILE *out);
+char *grub_util_get_disk_name (int disk);
#endif /* ! GRUB_UTIL_MISC_HEADER */
diff -Nur grub2/util/grub-mkdevicemap.c grub2.new/util/grub-mkdevicemap.c
--- grub2/util/grub-mkdevicemap.c 2007-07-22 06:50:10.000000000 +0200
+++ grub2.new/util/grub-mkdevicemap.c 2007-07-22 11:20:37.000000000 +0200
@@ -402,8 +402,11 @@
if (realpath (discn, name))
{
+ char *p;
strcat (name, "/disc");
- fprintf (fp, "(hd%d)\t%s\n", num_hd, name);
+ p = grub_util_get_disk_name (num_hd);
+ fprintf (fp, "(%s)\t%s\n", p, name);
+ free (p);
}
num_hd++;
@@ -421,7 +424,10 @@
get_ide_disk_name (name, i);
if (check_device (name))
{
- fprintf (fp, "(hd%d)\t%s\n", num_hd, name);
+ char *p;
+ p = grub_util_get_disk_name (num_hd);
+ fprintf (fp, "(%s)\t%s\n", p, name);
+ free (p);
num_hd++;
}
}
@@ -435,7 +441,10 @@
get_ataraid_disk_name (name, i);
if (check_device (name))
{
- fprintf (fp, "(hd%d)\t%s\n", num_hd, name);
+ char *p;
+ p = grub_util_get_disk_name (num_hd);
+ fprintf (fp, "(%s)\t%s\n", p, name);
+ free (p);
num_hd++;
}
}
@@ -449,7 +458,10 @@
get_scsi_disk_name (name, i);
if (check_device (name))
{
- fprintf (fp, "(hd%d)\t%s\n", num_hd, name);
+ char *p;
+ p = grub_util_get_disk_name (num_hd);
+ fprintf (fp, "(%s)\t%s\n", p, name);
+ free (p);
num_hd++;
}
}
@@ -472,7 +484,10 @@
get_dac960_disk_name (name, controller, drive);
if (check_device (name))
{
- fprintf (fp, "(hd%d)\t%s\n", num_hd, name);
+ char *p;
+ p = grub_util_get_disk_name (num_hd);
+ fprintf (fp, "(%s)\t%s\n", p, name);
+ free (p);
num_hd++;
}
}
@@ -490,7 +505,10 @@
get_i2o_disk_name (name, unit);
if (check_device (name))
{
- fprintf (fp, "(hd%d)\t%s\n", num_hd, name);
+ char *p;
+ p = grub_util_get_disk_name (num_hd);
+ fprintf (fp, "(%s)\t%s\n", p, name);
+ free (p);
num_hd++;
}
}
diff -Nur grub2/util/i386/get_disk_name.c grub2.new/util/i386/get_disk_name.c
--- grub2/util/i386/get_disk_name.c 1970-01-01 01:00:00.000000000 +0100
+++ grub2.new/util/i386/get_disk_name.c 2007-07-22 11:29:07.000000000 +0200
@@ -0,0 +1,31 @@
+/* get_disk_name.c */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2007 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <grub/util/misc.h>
+
+char *
+grub_util_get_disk_name (int disk)
+{
+ char *p;
+
+ p = xmalloc (16);
+ sprintf (p, "hd%d", disk);
+
+ return p;
+}
diff -Nur grub2/util/ieee1275/get_disk_name.c grub2.new/util/ieee1275/get_disk_name.c
--- grub2/util/ieee1275/get_disk_name.c 1970-01-01 01:00:00.000000000 +0100
+++ grub2.new/util/ieee1275/get_disk_name.c 2007-07-22 11:26:45.000000000 +0200
@@ -0,0 +1,36 @@
+/* get_disk_name.c */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2007 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <grub/util/misc.h>
+
+#include <string.h>
+
+char *
+grub_util_get_disk_name (int disk)
+{
+ char *p;
+
+ p = xmalloc (16);
+ sprintf (p, "hd");
+
+ if (disk > 0)
+ sprintf (p + strlen (p), "%d", disk);
+
+ return p;
+}
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: OF disk naming scheme (Re: another regression on Efika)
2007-07-22 9:33 ` Robert Millan
@ 2007-07-22 14:37 ` Marco Gerards
2007-07-22 20:25 ` Robert Millan
0 siblings, 1 reply; 35+ messages in thread
From: Marco Gerards @ 2007-07-22 14:37 UTC (permalink / raw)
To: The development of GRUB 2
Robert Millan <rmh@aybabtu.com> writes:
> On Sat, Jul 14, 2007 at 12:16:16AM +0200, Robert Millan wrote:
>> On Tue, Jul 10, 2007 at 09:26:27PM +0200, Jordi Mallach wrote:
>> > On Tue, Jul 10, 2007 at 04:10:52PM +0200, Robert Millan wrote:
>> > > What naming/numbering scheme does this follow when you add more disks?
>> >
>> > hd, hd1, hd2. Luckily Mozillion has Firewire disks.
>>
>> My Efika counts: hd, hd0 ...
>>
>> IEEE 1275 does not seem to cover this. What scheme should we follow when
>> generating device.map ?
>
> Since "hd, hd1, hd2 ..." seems to be much more common, I propose we use that
> and let user override it via device.map in case of disparity (which may only
> happen in systems with more than 1 disk).
Can we actually read via /proc or so how this mapping in reality is
realised?
--
Marco
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: OF disk naming scheme (Re: another regression on Efika)
2007-07-22 14:37 ` Marco Gerards
@ 2007-07-22 20:25 ` Robert Millan
2007-08-12 14:56 ` proposed solution using "ofpathname -a" (Re: OF disk naming scheme) Robert Millan
0 siblings, 1 reply; 35+ messages in thread
From: Robert Millan @ 2007-07-22 20:25 UTC (permalink / raw)
To: The development of GRUB 2
On Sun, Jul 22, 2007 at 04:37:41PM +0200, Marco Gerards wrote:
> Robert Millan <rmh@aybabtu.com> writes:
>
> > On Sat, Jul 14, 2007 at 12:16:16AM +0200, Robert Millan wrote:
> >> On Tue, Jul 10, 2007 at 09:26:27PM +0200, Jordi Mallach wrote:
> >> > On Tue, Jul 10, 2007 at 04:10:52PM +0200, Robert Millan wrote:
> >> > > What naming/numbering scheme does this follow when you add more disks?
> >> >
> >> > hd, hd1, hd2. Luckily Mozillion has Firewire disks.
> >>
> >> My Efika counts: hd, hd0 ...
> >>
> >> IEEE 1275 does not seem to cover this. What scheme should we follow when
> >> generating device.map ?
> >
> > Since "hd, hd1, hd2 ..." seems to be much more common, I propose we use that
> > and let user override it via device.map in case of disparity (which may only
> > happen in systems with more than 1 disk).
>
> Can we actually read via /proc or so how this mapping in reality is
> realised?
AFAIK we can only read the full OF path from /proc (with helper tools like
ofpath / ofpathname), but not the short alias which grub uses. These can only
be obtained when grub is running.
If the proposed solution is not good, maybe we could instead remap all disks
to "standard" grub device names (hd0, hd1..), which grub-mkdevicemap already
knows how to guess reasonably well.
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
^ permalink raw reply [flat|nested] 35+ messages in thread
* proposed solution using "ofpathname -a" (Re: OF disk naming scheme)
2007-07-22 20:25 ` Robert Millan
@ 2007-08-12 14:56 ` Robert Millan
0 siblings, 0 replies; 35+ messages in thread
From: Robert Millan @ 2007-08-12 14:56 UTC (permalink / raw)
To: The development of GRUB 2
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
On Sun, Jul 22, 2007 at 10:25:05PM +0200, Robert Millan wrote:
>
> AFAIK we can only read the full OF path from /proc (with helper tools like
> ofpath / ofpathname), but not the short alias which grub uses. These can only
> be obtained when grub is running.
>
> If the proposed solution is not good, maybe we could instead remap all disks
> to "standard" grub device names (hd0, hd1..), which grub-mkdevicemap already
> knows how to guess reasonably well.
Ok, I think I finally managed to make it work the way you wanted. Please see
attached patch.
You will also need alias.diff for ofpathname (I've sent it to the author
already).
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)
[-- Attachment #2: mkdevicemap.diff --]
[-- Type: text/x-diff, Size: 8351 bytes --]
2007-08-12 Robert Millan <rmh@aybabtu.com>
* util/i386/get_disk_name.c: New. Implement grub_util_get_disk_name()
to tell grub-mkdevicemap how to name devices.
* util/ieee1275/get_disk_name.c: Likewise (using "ofpathname -a"
feature).
* conf/i386-efi.rmk (grub_mkdevicemap_SOURCES): Add
util/i386/get_disk_name.c.
* conf/i386-pc.rmk (grub_mkdevicemap_SOURCES): Likewise.
* conf/powerpc-ieee1275.rmk (grub_mkdevicemap_SOURCES): Add
util/ieee1275/get_disk_name.c.
* include/grub/util/misc.h: grub_util_get_disk_name() declaration.
* DISTLIST: Add util/i386/get_disk_name.c and
util/ieee1275/get_disk_name.c.
* util/grub-mkdevicemap.c: Replace device naming logic with
grub_util_get_disk_name() calls.
diff -Nur grub2/conf/i386-efi.rmk grub2.mkdevicemap/conf/i386-efi.rmk
--- grub2/conf/i386-efi.rmk 2007-08-02 22:42:19.000000000 +0200
+++ grub2.mkdevicemap/conf/i386-efi.rmk 2007-08-12 15:26:42.000000000 +0200
@@ -24,7 +24,8 @@
# kern/fs.c kern/env.c fs/fshelp.c
# For grub-mkdevicemap.
-grub_mkdevicemap_SOURCES = util/grub-mkdevicemap.c util/misc.c
+grub_mkdevicemap_SOURCES = util/grub-mkdevicemap.c util/misc.c \
+ util/i386/get_disk_name.c
# For grub-probe.
grub_probe_DEPENDENCIES = grub_probe_init.h
diff -Nur grub2/conf/i386-pc.rmk grub2.mkdevicemap/conf/i386-pc.rmk
--- grub2/conf/i386-pc.rmk 2007-08-02 22:42:19.000000000 +0200
+++ grub2.mkdevicemap/conf/i386-pc.rmk 2007-08-12 15:26:42.000000000 +0200
@@ -72,7 +72,8 @@
util/raid.c util/lvm.c grub_setup_init.c
# For grub-mkdevicemap.
-grub_mkdevicemap_SOURCES = util/grub-mkdevicemap.c util/misc.c
+grub_mkdevicemap_SOURCES = util/grub-mkdevicemap.c util/misc.c \
+ util/i386/get_disk_name.c
# For grub-probe.
grub_probe_DEPENDENCIES = grub_probe_init.h
diff -Nur grub2/conf/powerpc-ieee1275.rmk grub2.mkdevicemap/conf/powerpc-ieee1275.rmk
--- grub2/conf/powerpc-ieee1275.rmk 2007-08-02 22:42:19.000000000 +0200
+++ grub2.mkdevicemap/conf/powerpc-ieee1275.rmk 2007-08-12 15:26:42.000000000 +0200
@@ -36,7 +36,8 @@
util/resolve.c
# For grub-mkdevicemap.
-grub_mkdevicemap_SOURCES = util/grub-mkdevicemap.c util/misc.c
+grub_mkdevicemap_SOURCES = util/grub-mkdevicemap.c util/misc.c \
+ util/ieee1275/get_disk_name.c
# For grub-probe.
grub_probe_DEPENDENCIES = grub_probe_init.h
diff -Nur grub2/include/grub/util/misc.h grub2.mkdevicemap/include/grub/util/misc.h
--- grub2/include/grub/util/misc.h 2007-07-22 01:32:25.000000000 +0200
+++ grub2.mkdevicemap/include/grub/util/misc.h 2007-08-12 15:26:42.000000000 +0200
@@ -53,5 +53,6 @@
void grub_util_write_image (const char *img, size_t size, FILE *out);
void grub_util_write_image_at (const void *img, size_t size, off_t offset,
FILE *out);
+char *grub_util_get_disk_name (int disk, char *name);
#endif /* ! GRUB_UTIL_MISC_HEADER */
diff -Nur grub2/util/grub-mkdevicemap.c grub2.mkdevicemap/util/grub-mkdevicemap.c
--- grub2/util/grub-mkdevicemap.c 2007-07-22 01:32:31.000000000 +0200
+++ grub2.mkdevicemap/util/grub-mkdevicemap.c 2007-08-12 15:26:42.000000000 +0200
@@ -402,8 +402,11 @@
if (realpath (discn, name))
{
+ char *p;
strcat (name, "/disc");
- fprintf (fp, "(hd%d)\t%s\n", num_hd, name);
+ p = grub_util_get_disk_name (num_hd, name);
+ fprintf (fp, "(%s)\t%s\n", p, name);
+ free (p);
}
num_hd++;
@@ -421,7 +424,10 @@
get_ide_disk_name (name, i);
if (check_device (name))
{
- fprintf (fp, "(hd%d)\t%s\n", num_hd, name);
+ char *p;
+ p = grub_util_get_disk_name (num_hd, name);
+ fprintf (fp, "(%s)\t%s\n", p, name);
+ free (p);
num_hd++;
}
}
@@ -435,7 +441,10 @@
get_ataraid_disk_name (name, i);
if (check_device (name))
{
- fprintf (fp, "(hd%d)\t%s\n", num_hd, name);
+ char *p;
+ p = grub_util_get_disk_name (num_hd, name);
+ fprintf (fp, "(%s)\t%s\n", p, name);
+ free (p);
num_hd++;
}
}
@@ -449,7 +458,10 @@
get_scsi_disk_name (name, i);
if (check_device (name))
{
- fprintf (fp, "(hd%d)\t%s\n", num_hd, name);
+ char *p;
+ p = grub_util_get_disk_name (num_hd, name);
+ fprintf (fp, "(%s)\t%s\n", p, name);
+ free (p);
num_hd++;
}
}
@@ -472,7 +484,10 @@
get_dac960_disk_name (name, controller, drive);
if (check_device (name))
{
- fprintf (fp, "(hd%d)\t%s\n", num_hd, name);
+ char *p;
+ p = grub_util_get_disk_name (num_hd, name);
+ fprintf (fp, "(%s)\t%s\n", p, name);
+ free (p);
num_hd++;
}
}
@@ -490,7 +505,10 @@
get_i2o_disk_name (name, unit);
if (check_device (name))
{
- fprintf (fp, "(hd%d)\t%s\n", num_hd, name);
+ char *p;
+ p = grub_util_get_disk_name (num_hd, name);
+ fprintf (fp, "(%s)\t%s\n", p, name);
+ free (p);
num_hd++;
}
}
diff -Nur grub2/util/i386/get_disk_name.c grub2.mkdevicemap/util/i386/get_disk_name.c
--- grub2/util/i386/get_disk_name.c 1970-01-01 01:00:00.000000000 +0100
+++ grub2.mkdevicemap/util/i386/get_disk_name.c 2007-08-12 15:26:42.000000000 +0200
@@ -0,0 +1,31 @@
+/* get_disk_name.c */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2007 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <grub/util/misc.h>
+
+char *
+grub_util_get_disk_name (int disk, char *name)
+{
+ char *p;
+
+ p = xmalloc (16);
+ sprintf (p, "hd%d", disk);
+
+ return p;
+}
diff -Nur grub2/util/ieee1275/get_disk_name.c grub2.mkdevicemap/util/ieee1275/get_disk_name.c
--- grub2/util/ieee1275/get_disk_name.c 1970-01-01 01:00:00.000000000 +0100
+++ grub2.mkdevicemap/util/ieee1275/get_disk_name.c 2007-08-12 16:16:56.000000000 +0200
@@ -0,0 +1,60 @@
+/* get_disk_name.c */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2007 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <stdio.h>
+#include <grub/util/misc.h>
+
+char *
+grub_util_get_disk_name (int disk, char *name)
+{
+ int p[2];
+
+ char *line = NULL;
+ int zero = 0;
+ int len;
+
+ pipe (p);
+
+ switch (fork ())
+ {
+ case -1:
+ perror ("fork");
+ exit (1);
+ case 0:
+ close (1);
+ dup (p[1]);
+ close (p[0]);
+ close (p[1]);
+ execlp ("ofpathname", "ofpathname", "-a", name, NULL);
+ perror ("execlp");
+ default:
+ close (0);
+ dup (p[0]);
+ close (p[0]);
+ close (p[1]);
+ }
+
+ len = getline (&line, &zero, stdin);
+ if (len < 2)
+ grub_util_error ("ofpathname didn't print a meaningful alias name");
+
+ line[len - 1] = '\0';
+
+ return line;
+}
--- grub2/DISTLIST 2007-08-02 22:42:19.000000000 +0200
+++ grub2.mkdevicemap/DISTLIST 2007-08-12 16:33:22.000000000 +0200
@@ -285,11 +285,13 @@
util/grub.d/README
util/i386/efi/grub-install.in
util/i386/efi/grub-mkimage.c
+util/i386/get_disk_name.c
util/i386/pc/grub-install.in
util/i386/pc/grub-mkimage.c
util/i386/pc/grub-setup.c
util/i386/pc/misc.c
util/i386/pc/grub-mkrescue.in
+util/ieee1275/get_disk_name.c
util/powerpc/ieee1275/grub-install.in
util/powerpc/ieee1275/grub-mkimage.c
util/powerpc/ieee1275/misc.c
[-- Attachment #3: alias.diff --]
[-- Type: text/x-diff, Size: 1315 bytes --]
--- ofpathname.orig 2007-07-17 16:10:47.000000000 +0200
+++ ofpathname 2007-08-12 13:00:21.000000000 +0200
@@ -27,6 +33,7 @@
echo "Optional arguments."
echo " -l Convert Open Firmware device pathname to"
echo " logical device name."
+ echo " -a Find matching Open Firmware device alias[es]."
echo " -q, --quiet do not report failures, exit quietly"
echo " -V, --version display version information and exit"
echo " -h, --help display this help information and exit"
@@ -226,7 +234,16 @@
OF_PATH=$OFPATH:1\\ppc\\bootinfo.txt
fi
- echo $OF_PATH
+ if [[ $do_alias = "0" ]]; then
+ echo $OF_PATH
+ else
+ (shopt -s nullglob
+ for i in /proc/device-tree/aliases/* ; do
+ if sed -e "s/\x00$//g" $i | grep -qx "$OF_PATH" ; then
+ basename $i
+ fi
+ done)
+ fi
}
#
@@ -613,10 +638,14 @@
# default: convert logical => OFpath
do_of2l=0
+# default: do not alias-ize
+do_alias=0
getopt -o "l:Vqh" -l "help,version,quiet" $@ > /dev/null 2>&1
while [[ -n $1 ]]; do
case "$1" in
+ -a) do_alias=1 ;;
+
-l) do_of2l=1
DEVNAME_ARG=$2
shift ;;
^ permalink raw reply [flat|nested] 35+ messages in thread
* updated regression diff (Re: another regression on Efika)
2007-07-02 18:16 another regression on Efika Robert Millan
2007-07-02 21:14 ` Robert Millan
2007-07-04 16:18 ` Hollis Blanchard
@ 2007-08-05 10:03 ` Robert Millan
2 siblings, 0 replies; 35+ messages in thread
From: Robert Millan @ 2007-08-05 10:03 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
On Mon, Jul 02, 2007 at 08:16:35PM +0200, Robert Millan wrote:
> [...] I'm attaching a reverse diff of the commit, such that when applied
> to HEAD makes GRUB work again (verified) [1].
This patch broke. I'm updating it to HEAD. Removed some cosmetical changes
to make it less error-prone.
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)
[-- Attachment #2: regression.diff --]
[-- Type: text/x-diff, Size: 7058 bytes --]
-2007-02-21 Hollis Blanchard <hollis@penguinppc.org>
-
- * kern/powerpc/ieee1275/init.c (HEAP_SIZE): Removed.
- (HEAP_LIMIT): New macro.
- (grub_claim_heap): Claim memory up to `heaplimit'.
-
-2007-02-21 Hollis Blanchard <hollis@penguinppc.org>
-
- * conf/powerpc-ieee1275.rmk (kernel_elf_LDFLAGS): Link at 64KB.
- * kern/powerpc/ieee1275/init.c (_end): Add declaration.
- (_start): Likewise.
- (grub_arch_modules_addr): Return address after `_end'.
- * util/powerpc/ieee1275/grub-mkimage.c: Include grub/misc.h.
- (load_modules): Use new parameter as `p_paddr' and `p_vaddr'.
- (add_segments): Calculate `_end' from phdr size and location.
- (ALIGN_UP): Moved to ...
- * include/grub/misc.h: here.
- * include/grub/powerpc/ieee1275/kernel.h (GRUB_IEEE1275_MOD_ALIGN):
- New macro.
- (GRUB_IEEE1275_MODULE_BASE): Removed.
diff -ur grub2-bad/conf/powerpc-ieee1275.mk grub2-good/conf/powerpc-ieee1275.mk
--- grub2-bad/conf/powerpc-ieee1275.mk 2007-02-22 00:22:20.000000000 +0100
+++ grub2-good/conf/powerpc-ieee1275.mk 2006-12-13 23:34:04.000000000 +0100
@@ -468,7 +468,7 @@
kernel_elf_CFLAGS = $(COMMON_CFLAGS)
kernel_elf_ASFLAGS = $(COMMON_ASFLAGS)
kernel_elf_LDFLAGS = $(COMMON_LDFLAGS) -static-libgcc -lgcc \
- -Wl,-N,-S,-Ttext,0x10000,-Bstatic
+ -Wl,-N,-S,-Ttext,0x200000,-Bstatic
# Scripts.
sbin_SCRIPTS = grub-install
diff -ur grub2-bad/conf/powerpc-ieee1275.rmk grub2-good/conf/powerpc-ieee1275.rmk
--- grub2-bad/conf/powerpc-ieee1275.rmk 2007-02-22 00:22:20.000000000 +0100
+++ grub2-good/conf/powerpc-ieee1275.rmk 2006-12-13 23:30:19.000000000 +0100
@@ -74,7 +74,7 @@
kernel_elf_CFLAGS = $(COMMON_CFLAGS)
kernel_elf_ASFLAGS = $(COMMON_ASFLAGS)
kernel_elf_LDFLAGS = $(COMMON_LDFLAGS) -static-libgcc -lgcc \
- -Wl,-N,-S,-Ttext,0x10000,-Bstatic
+ -Wl,-N,-S,-Ttext,0x200000,-Bstatic
# Scripts.
sbin_SCRIPTS = grub-install
diff -ur grub2-bad/include/grub/powerpc/ieee1275/kernel.h grub2-good/include/grub/powerpc/ieee1275/kernel.h
--- grub2-bad/include/grub/powerpc/ieee1275/kernel.h 2007-02-22 00:22:20.000000000 +0100
+++ grub2-good/include/grub/powerpc/ieee1275/kernel.h 2006-04-23 15:37:36.000000000 +0200
@@ -22,9 +22,10 @@
#include <grub/symbol.h>
-#define GRUB_IEEE1275_MOD_ALIGN 0x1000
-
void EXPORT_FUNC (grub_reboot) (void);
void EXPORT_FUNC (grub_halt) (void);
+/* Where grub-mkimage places the core modules in memory. */
+#define GRUB_IEEE1275_MODULE_BASE 0x00300000
+
#endif /* ! GRUB_KERNEL_MACHINE_HEADER */
diff -ur grub2-bad/kern/powerpc/ieee1275/init.c grub2-good/kern/powerpc/ieee1275/init.c
--- grub2-bad/kern/powerpc/ieee1275/init.c 2007-02-22 00:27:36.000000000 +0100
+++ grub2-good/kern/powerpc/ieee1275/init.c 2007-02-13 04:49:43.000000000 +0100
@@ -34,10 +34,7 @@
#include <grub/ieee1275/ofdisk.h>
#include <grub/ieee1275/ieee1275.h>
-#define HEAP_LIMIT (4<<20) /* 4 MiB */
-
-extern char _start[];
-extern char _end[];
+#define HEAP_SIZE (8<<20) /* 8 MiB */
void
grub_exit (void)
@@ -114,27 +111,29 @@
}
/* Claim some available memory in the first /memory node. */
-static void grub_claim_heap (unsigned long heaplimit)
+static void grub_claim_heap (unsigned long heapsize)
{
+ unsigned long total = 0;
+
auto int heap_init (grub_uint64_t addr, grub_uint64_t len);
int heap_init (grub_uint64_t addr, grub_uint64_t len)
{
len -= 1; /* Required for some firmware. */
- /* Don't claim anything above `heaplimit'. */
- if (addr + len > heaplimit)
- len = heaplimit - addr;
-
- if (len)
- {
- /* Claim and use it. */
- if (grub_claimmap (addr, len) < 0)
- return grub_error (GRUB_ERR_OUT_OF_MEMORY,
- "Failed to claim heap at 0x%llx, len 0x%llx\n",
- addr, len);
- grub_mm_init_region ((void *) (grub_addr_t) addr, len);
- }
-
+ /* Limit heap to `heapsize'. */
+ if (total + len > heapsize)
+ len = heapsize - total;
+
+ /* Claim and use it. */
+ if (grub_claimmap (addr, len) < 0)
+ return grub_error (GRUB_ERR_OUT_OF_MEMORY,
+ "Failed to claim heap at 0x%llx, len 0x%llx\n",
+ addr, len);
+ grub_mm_init_region ((void *) (grub_addr_t) addr, len);
+
+ total += len;
+ if (total >= heapsize)
+ return 1;
return 0;
}
@@ -148,7 +147,7 @@
int actual;
grub_console_init ();
- grub_claim_heap (HEAP_LIMIT);
+ grub_claim_heap (HEAP_SIZE);
grub_ofdisk_init ();
/* Process commandline. */
@@ -206,5 +205,5 @@
grub_addr_t
grub_arch_modules_addr (void)
{
- return ALIGN_UP(_end, GRUB_IEEE1275_MOD_ALIGN);
+ return GRUB_IEEE1275_MODULE_BASE;
}
diff -ur grub2-bad/util/powerpc/ieee1275/grub-mkimage.c grub2-good/util/powerpc/ieee1275/grub-mkimage.c
--- grub2-bad/util/powerpc/ieee1275/grub-mkimage.c 2007-02-22 00:22:20.000000000 +0100
+++ grub2-good/util/powerpc/ieee1275/grub-mkimage.c 2006-09-26 06:24:38.000000000 +0200
@@ -97,8 +98,7 @@
}
void
-load_modules (grub_addr_t modbase, Elf32_Phdr *phdr, const char *dir,
- char *mods[], FILE *out)
+load_modules (Elf32_Phdr *phdr, const char *dir, char *mods[], FILE *out)
{
char *module_img;
struct grub_util_path_list *path_list;
@@ -152,8 +152,8 @@
phdr->p_type = grub_cpu_to_be32 (PT_LOAD);
phdr->p_flags = grub_cpu_to_be32 (PF_R | PF_W | PF_X);
phdr->p_align = grub_cpu_to_be32 (sizeof (long));
- phdr->p_vaddr = grub_cpu_to_be32 (modbase);
- phdr->p_paddr = grub_cpu_to_be32 (modbase);
+ phdr->p_vaddr = grub_cpu_to_be32 (GRUB_IEEE1275_MODULE_BASE);
+ phdr->p_paddr = grub_cpu_to_be32 (GRUB_IEEE1275_MODULE_BASE);
phdr->p_filesz = grub_cpu_to_be32 (total_module_size);
phdr->p_memsz = grub_cpu_to_be32 (total_module_size);
}
@@ -166,7 +166,6 @@
Elf32_Phdr *phdr;
FILE *in;
char *kernel_path;
- grub_addr_t grub_end = 0;
off_t phdroff;
int i;
@@ -184,7 +183,6 @@
for (i = 0; i < grub_be_to_cpu16 (ehdr.e_phnum); i++)
{
char *segment_img;
- grub_size_t segment_end;
phdr = phdrs + i;
@@ -196,13 +194,6 @@
grub_util_info ("copying segment %d, type %d", i,
grub_be_to_cpu32 (phdr->p_type));
- /* Locate _end. */
- segment_end = grub_be_to_cpu32 (phdr->p_paddr)
- + grub_be_to_cpu32 (phdr->p_memsz);
- grub_util_info ("segment %u end 0x%lx", i, segment_end);
- if (segment_end > grub_end)
- grub_end = segment_end;
-
/* Read segment data and write it to new file. */
segment_img = xmalloc (grub_be_to_cpu32 (phdr->p_filesz));
@@ -216,11 +207,6 @@
if (mods[0] != NULL)
{
- grub_addr_t modbase;
-
- /* Place modules just after grub segment. */
- modbase = ALIGN_UP(grub_end, GRUB_IEEE1275_MOD_ALIGN);
-
/* Construct new segment header for modules. */
phdr = phdrs + grub_be_to_cpu16 (ehdr.e_phnum);
ehdr.e_phnum = grub_cpu_to_be16 (grub_be_to_cpu16 (ehdr.e_phnum) + 1);
@@ -229,7 +215,7 @@
phdr->p_offset = grub_cpu_to_be32 (ALIGN_UP (grub_util_get_fp_size (out),
sizeof (long)));
- load_modules (modbase, phdr, dir, mods, out);
+ load_modules (phdr, dir, mods, out);
}
if (chrp)
^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2007-10-04 20:47 UTC | newest]
Thread overview: 35+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-02 18:16 another regression on Efika Robert Millan
2007-07-02 21:14 ` Robert Millan
2007-07-04 16:18 ` Hollis Blanchard
2007-07-10 10:04 ` Jordi Mallach
2007-07-10 14:08 ` memory management issue (Re: another regression on Efika) Robert Millan
2007-07-10 20:32 ` Hollis Blanchard
2007-07-13 22:08 ` Robert Millan
2007-07-24 19:59 ` Robert Millan
2007-07-25 17:51 ` Hollis Blanchard
2007-07-25 20:08 ` Robert Millan
2007-07-25 23:25 ` Hollis Blanchard
2007-07-27 8:05 ` Robert Millan
[not found] ` <20070727103310.GA1539@powerlinux.fr>
2007-07-27 19:15 ` Robert Millan
2007-07-29 19:30 ` Robert Millan
2007-07-30 20:11 ` [PATCH] efika memory issues Robert Millan
2007-07-30 22:35 ` Hollis Blanchard
2007-07-31 14:38 ` Robert Millan
2007-07-31 15:55 ` Hollis Blanchard
2007-07-31 19:42 ` Robert Millan
2007-08-01 17:34 ` Hollis Blanchard
2007-08-01 18:27 ` Robert Millan
2007-09-30 20:10 ` [PATCH] fix memory management on efika/pegasos Robert Millan
2007-10-01 18:18 ` Marcin Kurek
2007-10-01 22:25 ` Marcin Kurek
2007-10-02 19:42 ` Robert Millan
2007-10-03 23:38 ` Marcin Kurek
2007-10-04 20:47 ` Robert Millan
2007-07-10 14:10 ` OF disk naming scheme (Re: another regression on Efika) Robert Millan
2007-07-10 19:26 ` Jordi Mallach
2007-07-13 22:16 ` Robert Millan
2007-07-22 9:33 ` Robert Millan
2007-07-22 14:37 ` Marco Gerards
2007-07-22 20:25 ` Robert Millan
2007-08-12 14:56 ` proposed solution using "ofpathname -a" (Re: OF disk naming scheme) Robert Millan
2007-08-05 10:03 ` updated regression diff (Re: another regression on Efika) Robert Millan
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.