On Thu, Jan 03, 2008 at 03:09:17AM -0500, Pavel Roskin wrote: > 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.
Ok, so you mean this setting: phdr->p_vaddr = grub_host_to_target32 (modbase); phdr->p_paddr = grub_host_to_target32 (modbase); is not what it's used to calculate _end ? I thought _end was calculated by the ELF loader (our own ELF loader, multiboot.c seems to calculate _end and pass it to its payload). > 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. Isn't build ID a recent change in binutils? We had this problem for a while. > I actually doubt that it's the right behavior to go through segments. No idea about that I'm afraid :-( > 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. Looks good. But I guess you'll have to convince Marco and Okuji about this :-) > The linear ChangeLog with everybody changing it in the same place (in > the beginning) doesn't work well with parallel development. It's not that much of a problem, I just write them in the patch header and copy them at the last minute before commit. > >>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. Does a snapshot from 2007-02-21 also have this problem? > But maybe it's because in the normal mode with all modules loaded, > unlike bare kernel.elf. But you don't need modules for ofdisk to work, it's built into the kernel. -- 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 /.) _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel