Quoting Robert Millan <[EMAIL PROTECTED]>:
just take the grub-mkimage.c part of it and try to revert it on CVS HEAD,
that would confirm it's a grub-mkimage problem. Then apply the hunks
selectively untill you find the exact change that broke it. And finally
it's just a matter of "looking hard" at that hunk untill it's coerced to
reveal the problem :-)
OK, here's what I have so far. The patch tries to make the memory
layout more compact. Two changes are make to the layout. kernel.elf
is loaded at 64k instead of 2M and the modules are loaded at the
lowest 4k boundary after kernel.elf rather that at 3M.
Moving the kernel.elf load address is fine. Moving the modules is not.
The module base address is calculated separately in kernel.elf and in
grub-mkimage. kernel.elf uses the "_end" symbol, whereas grub-mkimage
looks for the ELF segment with the highest end address.
One problem in grub-mkimage is the infamous build ID, which is present
in kernel.elf. It is located in a loadable segment starting at
0x10000d4 (i.e. just about 256M). That's what confuses objcopy, and
it must be confusing grub-mkimage as well.
I actually doubt that it's the right behavior to go through segments.
The "_end" marker should be located in a specific segment. And if the
search through segments is correct, then maybe grub-mkimage should
hardcore the module base into the output, rather than rely on
kernel.elf doing the same calculation and getting the same result.
All I need to to do fix the problem is to make kernel.elf and
grub-mkimage come to the same value of the module base address.
(Not to put any pressure of anyone, but GNU ChangeLog shows its age
here - the detailed changes are described, but the motivation behind
the whole patch is not, yet the details can be recovered with the
version control, whereas the motivation has to be guessed)
Full ack. But, you didn't mention any alternative.
Linux style description. The first line is the synopsis. If it
doesn't fit 72 characters, the patch is a candidate for splitting.
Then an empty line. Then a more detailed description of the patch,
including the motivation behind the changes. The list of the affected
files can be generated by the version control system.
The linear ChangeLog with everybody changing it in the same place (in
the beginning) doesn't work well with parallel development.
Both ide0/disk and cd refer to the CD-ROM. The messages are not shown
if there is a CD in the drive.
>What happens if you set debug=disk ?
Typing from another monitor, sorry for possible typos.
disk/ieee1275/ofdisk.c:65: Opening `ide1/disk:0'.
disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00.
kern/disk.c:299: Opening `ide1/disk' failed.
kern/disk.c:312: Closing `ide1/disk'.
This seems to be contradictory. If OF returned a handle, why does the
open fail ? Looks like GRUB doesn't like something but isn't telling you
what. I'd investigate that part; at the least it can mean our error
handling isn't good enough.
Actually, there are no "failures" with the version from 2007-02-20.
But maybe it's because in the normal mode with all modules loaded,
unlike bare kernel.elf.
--
Regards,
Pavel Roskin
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
