On Dec 25, 2007 12:24 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> Doesn't this add a restriction on the maximum usable size, when it collides
> with the assorted amenities in the 640 kiB / 1024 kiB area ?
yes, that's true. but i think the memdisk is not corrupted before
module initialization, so you can malloc and copy it safely in
grub_main:
void
grub_main (void)
{
/* First of all, initialize the machine. */
grub_machine_init ();
// malloc and copy memdisk
...
/* Load pre-loaded modules and free the space. */
grub_register_exported_symbols ();
grub_load_modules ();
..
}
>
> > > > I also recommend to add a variable grub_memdisk_image_base in
> > > > startup.S, normally, this value will be zero,
> > >
> > > That's in my patch already. Or did you mean something else?
> >
> > But i only see the grub_memdisk_image_size, not the base address.
>
> Ah right; well it's still there, just not directly:
>
> + return 0x100000 + (grub_kernel_image_size - GRUB_KERNEL_MACHINE_RAW_SIZE)
> + grub_total_module_size;
>
> those two variables are from startup.S as well, IIRC. Although it might make
> sense to move them as a precalculated address. The code to compute it
> probably
> takes more kernel space than the address itself..
What i mean is that you can add an variable grub_total_module_addr, if
grub_total_module_addr=0, calculate the addr using the above fomula,
and if it's not, use it directly as the base address of memdisk. The
reason for this extra variable is that you can set it in pre loader,
for example,
kernel grub2.bin
initrd memdisk
lnxboot can extract the address of initrd image, and set
grub_total_module_addr before jumping to core.img.
--
Bean
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
