Re: embedding filesystems in core image (Re: moving ata initialisation to a command)

[Robert Millan <rmh@aybabtu.com>]

On Mon, Dec 24, 2007 at 09:27:05PM +0800, Bean wrote:
> On Dec 24, 2007 9:09 PM, Robert Millan <rmh@aybabtu.com> wrote:
> > I was thinking in moving it to malloc'ed memory, which has the advantage that
> > you no longer need to remember a particular region is hardcoded for memdisk
> > (also, it hinders portability on platforms where top of memory is reserved).
> >
> > but this doesn't solve the problem about its original region being corrupted
> > (by payload loaders) before we have a chance to copy it.
> 
> In that case, you can copy the memdisk back to conventional memory,
> alongside with modules.
> In startup.S:
> 
> codestart:
> ...
> 	/* copy modules before cleaning out the bss */
> 	movl	EXT_C(grub_total_module_size), %ecx
> 	movl	EXT_C(grub_kernel_image_size), %esi
> 	addl	%ecx, %esi
> 
> ->
> 	movl	EXT_C(grub_total_module_size), %ecx
> +      addl    EXT_C(grub_memdisk_image_size), %ecx
> 	movl	EXT_C(grub_kernel_image_size), %esi
> 	addl	%ecx, %esi

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 ?

> > > 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..

-- 
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 /.)