[PATCH] memdisk plus lnxboot extension

[PATCH] memdisk plus lnxboot extension

[Bean]

Hi,

This patch is based on robert's memdisk patch. I also modify lnxboot
so that it can load the memdisk using initrd. Changes:

1, copy memdisk to grub_alloc'ed memory in grub_machine_init, so that
it won't be corrupted.
2, code cleanup for lnxboot.S, now it doesn't contain code that uses
32-bit address.
3, lnxboot.S will set the memdisk address to the initrd image
4, add option -x for grub-mkimage, it's used to build linux format
kernel directly.

./grub-mkimage -x -o grub2.bin modules

Now you can load memdisk using initrd:

kernel grub2.bin
initrd memdisk

or embed it in grub2.bin/core.img using -m option

./grub-mkimage -x -o grub2.bin -m memdisk modules

If both memdisk is used, external memdisk will take preference.

diff --git a/boot/i386/pc/lnxboot.S b/boot/i386/pc/lnxboot.S
index f1a4ded..6503e26 100644
--- a/boot/i386/pc/lnxboot.S
+++ b/boot/i386/pc/lnxboot.S
@@ -36,22 +36,7 @@
         .globl  start, _start

 data_start:
-	pushw	%cs
-	popw	%ds
-	xorl	%eax, %eax
-	xorl	%ebx, %ebx
-	call	data_next
-
-data_next:
-	popw	%bx
-	movw	%cs, %ax
-	shll	$4, %eax
-	leal	0x200 + data_start - data_next(%ebx,%eax), %eax
-	movzbl	setup_sects - data_next(%bx), %ecx
-	shll	$9, %ecx
-	addl	%ecx, %eax
-	movl	%eax, code32_start - data_next(%bx)
-
+	xorl	%ebp, %ebp
 	jmp	linux_next

 	. = data_start + 0x1F1
@@ -76,7 +61,7 @@ boot_flag:
 start:
 _start:

-	jmp linux_code
+	jmp linux_init

 	.ascii	"HdrS"			// Header signature
 	.word	0x0203			// Header version number
@@ -134,9 +119,10 @@ reg_edx:
 data_leng:
 	.long	0

-linux_code:
+linux_init:

 	movw	%cs:(reg_edx - start), %dx
+	movl	%cs:(code32_start - start), %ebp

 linux_next:

@@ -164,9 +150,6 @@ real_code:
 	movw	%si, %ss
 	movw	$(CODE_ADDR), %sp

-	pushl	%esi
-	pushl	%edi
-
 	// Move itself to 0:CODE_ADDR

 	cld
@@ -183,17 +166,26 @@ real_code:

 real_code_2:

+	xchgl	%ebp, %esi
+	orl	%esi, %esi
+	jnz	1f
+	movw	%ds, %si
+	shll	$4, %esi
+	addl	%ebp, %esi
+1:
+
 	pushw	%es
 	popw	%ds

-	movl	(ramdisk_image - start), %esi
-	or	%esi, %esi
+	movl	(data_leng - start), %ecx
+	or	%ecx, %ecx
 	jnz	1f
-	movl	(code32_start - start), %esi
+	movl	(ramdisk_image - start), %esi
+	movl	(ramdisk_size - start), %ecx
+	addl	$0x200, %esi
+	subl	$0x200, %ecx
 1:

-	movl	$0x200, %ecx
-	addl	%ecx, %esi
 	movl	$DATA_ADDR, %edi

 	call	move_memory
@@ -204,13 +196,17 @@ real_code_2:
 	movsbl	(reg_edx + 2 - start), %eax
 	movl	%eax, %ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_INSTALL_BSD_PART)

-	movl	%ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_COMPRESSED_SIZE), %ecx
-	addl	$(GRUB_KERNEL_MACHINE_RAW_SIZE - 0x200), %ecx
+	movl	(data_leng - start), %eax
+	or	%eax, %eax
+	jz	1f
+	movl	(ramdisk_size - start), %eax
+	or	%eax, %eax
+	jz	1f

-	call	move_memory
-
-	popl	%edi
-	popl	%esi
+	movl	%eax, %ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_MEMDISK_IMAGE_SIZE)
+	movl	(ramdisk_image - start), %eax
+	movl	%eax, %ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_MEMDISK_IMAGE_ADDR)
+1:

 	ljmp	$(DATA_ADDR >> 4), $0

@@ -261,8 +257,8 @@ move_memory:

 2:

-	leal	(%esi, %eax), %esi
-	leal	(%edi, %eax), %edi
+	addl	%eax, %esi
+	addl	%eax, %edi
 	subl	%eax, %ecx
 	jnz	1b

diff --git a/conf/i386-pc.rmk b/conf/i386-pc.rmk
index 2638ee5..b5f6a04 100644
--- a/conf/i386-pc.rmk
+++ b/conf/i386-pc.rmk
@@ -39,7 +39,7 @@ kernel_img_HEADERS = arg.h boot.h cache.h device.h
disk.h dl.h elf.h elfload.h \
 	env.h err.h file.h fs.h kernel.h loader.h misc.h mm.h net.h parser.h \
 	partition.h pc_partition.h rescue.h symbol.h term.h time.h types.h \
 	machine/biosdisk.h machine/boot.h machine/console.h machine/init.h \
-	machine/memory.h machine/loader.h machine/vga.h machine/vbe.h
+	machine/memory.h machine/loader.h machine/vga.h machine/vbe.h machine/kernel.h
 kernel_img_CFLAGS = $(COMMON_CFLAGS)
 kernel_img_ASFLAGS = $(COMMON_ASFLAGS)
 kernel_img_LDFLAGS = $(COMMON_LDFLAGS) -Wl,-N,-Ttext,8200 $(COMMON_CFLAGS)
@@ -136,7 +136,7 @@ pkglib_MODULES = biosdisk.mod _chain.mod
_linux.mod linux.mod normal.mod \
 	_multiboot.mod chain.mod multiboot.mod reboot.mod halt.mod	\
 	vbe.mod vbetest.mod vbeinfo.mod video.mod gfxterm.mod \
 	videotest.mod play.mod bitmap.mod tga.mod cpuid.mod serial.mod ata.mod \
-	vga.mod
+	vga.mod memdisk.mod

 # For biosdisk.mod.
 biosdisk_mod_SOURCES = disk/i386/pc/biosdisk.c
@@ -263,4 +263,9 @@ vga_mod_SOURCES = term/i386/pc/vga.c
 vga_mod_CFLAGS = $(COMMON_CFLAGS)
 vga_mod_LDFLAGS = $(COMMON_LDFLAGS)

+# For memdisk.mod.
+memdisk_mod_SOURCES = disk/memdisk.c
+memdisk_mod_CFLAGS = $(COMMON_CFLAGS)
+memdisk_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
 include $(srcdir)/conf/common.mk
diff --git a/include/grub/disk.h b/include/grub/disk.h
index 4301942..9891a9c 100644
--- a/include/grub/disk.h
+++ b/include/grub/disk.h
@@ -35,7 +35,8 @@ enum grub_disk_dev_id
     GRUB_DISK_DEVICE_RAID_ID,
     GRUB_DISK_DEVICE_LVM_ID,
     GRUB_DISK_DEVICE_HOST_ID,
-    GRUB_DISK_DEVICE_ATA_ID
+    GRUB_DISK_DEVICE_ATA_ID,
+    GRUB_DISK_DEVICE_MEMDISK_ID,
   };

 struct grub_disk;
diff --git a/include/grub/i386/pc/kernel.h b/include/grub/i386/pc/kernel.h
index ec207a5..126df2b 100644
--- a/include/grub/i386/pc/kernel.h
+++ b/include/grub/i386/pc/kernel.h
@@ -34,8 +34,14 @@
 /* The offset of GRUB_INSTALL_BSD_PART.  */
 #define GRUB_KERNEL_MACHINE_INSTALL_BSD_PART	0x18

+/* The offset of GRUB_MEMDISK_IMAGE_ADDR   */
+#define GRUB_KERNEL_MACHINE_MEMDISK_IMAGE_ADDR	0x1c
+
+/* The offset of GRUB_MEMDISK_IMAGE_SIZE.  */
+#define GRUB_KERNEL_MACHINE_MEMDISK_IMAGE_SIZE	0x20
+
 /* The offset of GRUB_PREFIX.  */
-#define GRUB_KERNEL_MACHINE_PREFIX		0x1c
+#define GRUB_KERNEL_MACHINE_PREFIX		0x24

 /* End of the data section. */
 #define GRUB_KERNEL_MACHINE_DATA_END		0x50
@@ -47,12 +53,24 @@

 #include <grub/types.h>

+/* The size of kernel image.  */
+extern grub_int32_t grub_kernel_image_size;
+
+/* The total size of module images following the kernel.  */
+extern grub_int32_t grub_total_module_size;
+
 /* The DOS partition number of the installed partition.  */
 extern grub_int32_t grub_install_dos_part;

 /* The BSD partition number of the installed partition.  */
 extern grub_int32_t grub_install_bsd_part;

+/* The address of memory disk image, if present.  */
+extern grub_int32_t grub_memdisk_image_addr;
+
+/* The size of memory disk image, if present.  */
+extern grub_int32_t grub_memdisk_image_size;
+
 /* The prefix which points to the directory where GRUB modules and its
    configuration file are located.  */
 extern char grub_prefix[];
diff --git a/include/grub/kernel.h b/include/grub/kernel.h
index 77d209a..7413e19 100644
--- a/include/grub/kernel.h
+++ b/include/grub/kernel.h
@@ -20,6 +20,7 @@
 #define GRUB_KERNEL_HEADER	1

 #include <grub/types.h>
+#include <grub/symbol.h>

 /* The module header.  */
 struct grub_module_header
@@ -44,6 +45,8 @@ struct grub_module_info
 };

 extern grub_addr_t grub_arch_modules_addr (void);
+extern grub_addr_t EXPORT_FUNC(grub_arch_memdisk_addr) (void);
+extern grub_off_t EXPORT_FUNC(grub_arch_memdisk_size) (void);

 /* The start point of the C code.  */
 void grub_main (void);
diff --git a/kern/i386/pc/init.c b/kern/i386/pc/init.c
index 72ff9a2..2bdbc49 100644
--- a/kern/i386/pc/init.c
+++ b/kern/i386/pc/init.c
@@ -229,9 +229,26 @@ grub_machine_init (void)
       }
     else
       grub_mm_init_region ((void *) mem_regions[i].addr, mem_regions[i].size);
-
+
   if (! grub_os_area_addr)
     grub_fatal ("no upper memory");
+
+  if (grub_memdisk_image_size)
+    {
+      char *p;
+
+      if (! grub_memdisk_image_addr)
+        grub_memdisk_image_addr = 0x100000 + (grub_kernel_image_size
- GRUB_KERNEL_MACHINE_RAW_SIZE) + grub_total_module_size;
+
+      p = grub_malloc (grub_memdisk_image_size);
+      if (! p)
+        grub_memdisk_image_size = 0;  // Not enough memory, dump the memdisk
+      else
+        {
+          grub_memcpy (p, (char*) grub_memdisk_image_addr,
grub_memdisk_image_size);
+	  grub_memdisk_image_addr = (grub_uint32_t) p;
+	}
+    }
 }

 void
@@ -253,3 +270,17 @@ grub_arch_modules_addr (void)
 {
   return grub_end_addr;
 }
+
+/* Return the start of the memdisk image.  */
+grub_addr_t
+grub_arch_memdisk_addr (void)
+{
+  return grub_memdisk_image_addr;
+}
+
+/* Return the size of the memdisk image.  */
+grub_off_t
+grub_arch_memdisk_size (void)
+{
+  return grub_memdisk_image_size;
+}
diff --git a/kern/i386/pc/startup.S b/kern/i386/pc/startup.S
index 4267f5b..33b301c 100644
--- a/kern/i386/pc/startup.S
+++ b/kern/i386/pc/startup.S
@@ -95,6 +95,10 @@ VARIABLE(grub_install_dos_part)
 	.long	0xFFFFFFFF
 VARIABLE(grub_install_bsd_part)
 	.long	0xFFFFFFFF
+VARIABLE(grub_memdisk_image_addr)
+	.long	0
+VARIABLE(grub_memdisk_image_size)
+	.long	0
 VARIABLE(grub_prefix)
 	/* to be filled by grub-mkimage */

diff --git a/util/i386/pc/grub-mkimage.c b/util/i386/pc/grub-mkimage.c
index e19649d..dd48509 100644
--- a/util/i386/pc/grub-mkimage.c
+++ b/util/i386/pc/grub-mkimage.c
@@ -25,6 +25,7 @@
 #include <grub/disk.h>
 #include <grub/util/misc.h>
 #include <grub/util/resolve.h>
+#include <grub/misc.h>

 #include <stdio.h>
 #include <unistd.h>
@@ -75,11 +76,11 @@ compress_kernel (char *kernel_img, size_t kernel_size,
 }

 static void
-generate_image (const char *dir, char *prefix, FILE *out, char *mods[])
+generate_image (const char *dir, char *prefix, FILE *out, char
*mods[], char *memdisk_path, int is_linux)
 {
   grub_addr_t module_addr = 0;
   char *kernel_img, *boot_img, *core_img;
-  size_t kernel_size, boot_size, total_module_size, core_size;
+  size_t kernel_size, boot_size, total_module_size, core_size,
memdisk_size = 0;
   char *kernel_path, *boot_path;
   unsigned num;
   size_t offset;
@@ -98,7 +99,13 @@ generate_image (const char *dir, char *prefix, FILE
*out, char *mods[])

   grub_util_info ("the total module size is 0x%x", total_module_size);

-  kernel_img = xmalloc (kernel_size + total_module_size);
+  if (memdisk_path)
+    {
+      memdisk_size = ALIGN_UP(grub_util_get_image_size (memdisk_path), 512);
+      grub_util_info ("the size of memory disk is 0x%x", memdisk_size);
+    }
+
+  kernel_img = xmalloc (kernel_size + total_module_size + memdisk_size);
   grub_util_load_image (kernel_path, kernel_img);

   if (GRUB_KERNEL_MACHINE_PREFIX + strlen (prefix) + 1 >
GRUB_KERNEL_MACHINE_DATA_END)
@@ -122,13 +129,19 @@ generate_image (const char *dir, char *prefix,
FILE *out, char *mods[])
       header = (struct grub_module_header *) (kernel_img + offset);
       header->offset = grub_cpu_to_le32 (sizeof (*header));
       header->size = grub_cpu_to_le32 (mod_size + sizeof (*header));
-
-      grub_util_load_image (p->name, kernel_img + offset + sizeof (*header));
+      offset += sizeof (*header);
+
+      grub_util_load_image (p->name, kernel_img + offset);
+      offset += mod_size;
+    }

-      offset += sizeof (*header) + mod_size;
+  if (memdisk_path)
+    {
+      grub_util_load_image (memdisk_path, kernel_img + offset);
+      offset += memdisk_size;
     }

-  compress_kernel (kernel_img, kernel_size + total_module_size,
+  compress_kernel (kernel_img, kernel_size + total_module_size + memdisk_size,
 		   &core_img, &core_size);

   grub_util_info ("the core size is 0x%x", core_size);
@@ -137,17 +150,25 @@ generate_image (const char *dir, char *prefix,
FILE *out, char *mods[])
   if (num > 0xffff)
     grub_util_error ("the core image is too big");

-  boot_path = grub_util_get_path (dir, "diskboot.img");
+  boot_path = grub_util_get_path (dir, (is_linux)?
"lnxboot.img":"diskboot.img");
   boot_size = grub_util_get_image_size (boot_path);
-  if (boot_size != GRUB_DISK_SECTOR_SIZE)
+  if ((! is_linux) && (boot_size != GRUB_DISK_SECTOR_SIZE))
     grub_util_error ("diskboot.img is not one sector size");

   boot_img = grub_util_read_image (boot_path);
-
-  /* i386 is a little endian architecture.  */
-  *((grub_uint16_t *) (boot_img + GRUB_DISK_SECTOR_SIZE
+
+  if (is_linux)
+    {
+      *((grub_uint32_t *) (boot_img + 0x264))
+      = grub_cpu_to_le32 (core_size);
+    }
+  else
+    {
+      /* i386 is a little endian architecture.  */
+      *((grub_uint16_t *) (boot_img + GRUB_DISK_SECTOR_SIZE
 		       - GRUB_BOOT_MACHINE_LIST_SIZE + 8))
-    = grub_cpu_to_le16 (num);
+      = grub_cpu_to_le16 (num);
+    }

   grub_util_write_image (boot_img, boot_size, out);
   free (boot_img);
@@ -163,6 +184,8 @@ generate_image (const char *dir, char *prefix,
FILE *out, char *mods[])
     = grub_cpu_to_le32 (total_module_size);
   *((grub_uint32_t *) (core_img + GRUB_KERNEL_MACHINE_KERNEL_IMAGE_SIZE))
     = grub_cpu_to_le32 (kernel_size);
+  *((grub_uint32_t *) (core_img + GRUB_KERNEL_MACHINE_MEMDISK_IMAGE_SIZE))
+    = grub_cpu_to_le32 (memdisk_size);
   *((grub_uint32_t *) (core_img + GRUB_KERNEL_MACHINE_COMPRESSED_SIZE))
     = grub_cpu_to_le32 (core_size - GRUB_KERNEL_MACHINE_RAW_SIZE);

@@ -186,7 +209,9 @@ static struct option options[] =
   {
     {"directory", required_argument, 0, 'd'},
     {"prefix", required_argument, 0, 'p'},
+    {"memdisk", required_argument, 0, 'm'},
     {"output", required_argument, 0, 'o'},
+    {"linux", no_argument, 0, 'x'},
     {"help", no_argument, 0, 'h'},
     {"version", no_argument, 0, 'V'},
     {"verbose", no_argument, 0, 'v'},
@@ -206,7 +231,9 @@ Make a bootable image of GRUB.\n\
 \n\
   -d, --directory=DIR     use images and modules under DIR [default=%s]\n\
   -p, --prefix=DIR        set grub_prefix directory [default=%s]\n\
+  -m, --memdisk=FILE      embed FILE as a memdisk image\n\
   -o, --output=FILE       output a generated image to FILE [default=stdout]\n\
+  -x, --linux             add linux header\n\
   -h, --help              display this message and exit\n\
   -V, --version           print version information and exit\n\
   -v, --verbose           print verbose messages\n\
@@ -223,13 +250,15 @@ main (int argc, char *argv[])
   char *output = NULL;
   char *dir = NULL;
   char *prefix = NULL;
+  char *memdisk = NULL;
   FILE *fp = stdout;
+  int is_linux = 0;

   progname = "grub-mkimage";

   while (1)
     {
-      int c = getopt_long (argc, argv, "d:p:o:hVv", options, 0);
+      int c = getopt_long (argc, argv, "d:p:m:o:hVvx", options, 0);

       if (c == -1)
 	break;
@@ -250,6 +279,17 @@ main (int argc, char *argv[])
 	    dir = xstrdup (optarg);
 	    break;

+	  case 'm':
+	    if (memdisk)
+	      free (memdisk);
+
+	    memdisk = xstrdup (optarg);
+	    break;
+
+	  case 'x':
+	    is_linux = 1;
+	    break;
+
 	  case 'h':
 	    usage (0);
 	    break;
@@ -282,7 +322,7 @@ main (int argc, char *argv[])
 	grub_util_error ("cannot open %s", output);
     }

-  generate_image (dir ? : GRUB_LIBDIR, prefix ? : DEFAULT_DIRECTORY,
fp, argv + optind);
+  generate_image (dir ? : GRUB_LIBDIR, prefix ? : DEFAULT_DIRECTORY,
fp, argv + optind, memdisk, is_linux);

   fclose (fp);

diff --git a/disk/memdisk.c b/disk/memdisk.c
new file mode 100755
index 0000000..48e0514
--- /dev/null
+++ b/disk/memdisk.c
@@ -0,0 +1,94 @@
+/* memdisk.c - Access embedded memory disk.  */
+/*
+ *  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/disk.h>
+#include <grub/dl.h>
+#include <grub/kernel.h>
+#include <grub/misc.h>
+#include <grub/mm.h>
+#include <grub/types.h>
+
+static grub_addr_t memdisk_addr;
+
+static int
+grub_memdisk_iterate (int (*hook) (const char *name))
+{
+  return hook ("memdisk");
+}
+
+static grub_err_t
+grub_memdisk_open (const char *name, grub_disk_t disk)
+{
+  if (grub_strcmp (name, "memdisk"))
+      return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "not a memdisk");
+
+  disk->total_sectors = grub_arch_memdisk_size () / GRUB_DISK_SECTOR_SIZE;
+  disk->id = (int) 'mdsk';
+  disk->has_partitions = 0;
+
+  return GRUB_ERR_NONE;
+}
+
+static void
+grub_memdisk_close (grub_disk_t disk __attribute((unused)))
+{
+}
+
+static grub_err_t
+grub_memdisk_read (grub_disk_t disk __attribute((unused)),
grub_disk_addr_t sector,
+		    grub_size_t size, char *buf)
+{
+  grub_memcpy (buf, memdisk_addr + (sector << GRUB_DISK_SECTOR_BITS),
size << GRUB_DISK_SECTOR_BITS);
+  return 0;
+}
+
+static grub_err_t
+grub_memdisk_write (grub_disk_t disk __attribute((unused)),
grub_disk_addr_t sector,
+		     grub_size_t size, const char *buf)
+{
+  grub_memcpy (memdisk_addr + (sector << GRUB_DISK_SECTOR_BITS), buf,
size << GRUB_DISK_SECTOR_BITS);
+  return 0;
+}
+
+static struct grub_disk_dev grub_memdisk_dev =
+  {
+    .name = "memdisk",
+    .id = GRUB_DISK_DEVICE_MEMDISK_ID,
+    .iterate = grub_memdisk_iterate,
+    .open = grub_memdisk_open,
+    .close = grub_memdisk_close,
+    .read = grub_memdisk_read,
+    .write = grub_memdisk_write,
+    .next = 0
+  };
+
+GRUB_MOD_INIT(memdisk)
+{
+  if (! grub_arch_memdisk_size ())
+    return;
+  memdisk_addr = grub_arch_memdisk_addr ();
+  grub_disk_dev_register (&grub_memdisk_dev);
+}
+
+GRUB_MOD_FINI(memdisk)
+{
+  if (! grub_arch_memdisk_size ())
+    return;
+  grub_disk_dev_unregister (&grub_memdisk_dev);
+}


-- 
Bean

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Sat, Dec 29, 2007 at 05:05:16PM +0800, Bean wrote:
> Hi,
> 
> This patch is based on robert's memdisk patch. I also modify lnxboot
> so that it can load the memdisk using initrd. Changes:

I'd really like to keep this separate, and get memdisk merged first.

I recall Marco had some objections to memdisk, so I'd like to get that sorted
out before we start building on it.

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

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Sun, Dec 30, 2007 at 02:48:24PM +0100, Robert Millan wrote:
> On Sat, Dec 29, 2007 at 05:05:16PM +0800, Bean wrote:
> > Hi,
> > 
> > This patch is based on robert's memdisk patch. I also modify lnxboot
> > so that it can load the memdisk using initrd. Changes:
> 
> I'd really like to keep this separate, and get memdisk merged first.
> 
> I recall Marco had some objections to memdisk, so I'd like to get that sorted
> out before we start building on it.

memdisk is merged now, but as for supporting an initrd hack to load it, I'm not
sure if that's a good idea.

Currently, you can do:

  grub-mkimage -m filesystem -o core.img
  cat lnxboot.img core.img > linux_image

what you propose would be:

  grub-mkimage -o core.img
  cat lnxboot.img core.img > linux_image
  [ use filesystem as initrd ]

but, what is the advantage in that?  Is there any use case in which the first
option is not good but the second is?

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

Re: [PATCH] memdisk plus lnxboot extension

[Bean]

On Jan 21, 2008 7:24 AM, Robert Millan <rmh@aybabtu.com> wrote:
> On Sun, Dec 30, 2007 at 02:48:24PM +0100, Robert Millan wrote:
> > On Sat, Dec 29, 2007 at 05:05:16PM +0800, Bean wrote:
> > > Hi,
> > >
> > > This patch is based on robert's memdisk patch. I also modify lnxboot
> > > so that it can load the memdisk using initrd. Changes:
> >
> > I'd really like to keep this separate, and get memdisk merged first.
> >
> > I recall Marco had some objections to memdisk, so I'd like to get that sorted
> > out before we start building on it.
>
> memdisk is merged now, but as for supporting an initrd hack to load it, I'm not
> sure if that's a good idea.
>
> Currently, you can do:
>
>   grub-mkimage -m filesystem -o core.img
>   cat lnxboot.img core.img > linux_image
>
> what you propose would be:
>
>   grub-mkimage -o core.img
>   cat lnxboot.img core.img > linux_image
>   [ use filesystem as initrd ]
>
> but, what is the advantage in that?  Is there any use case in which the first
> option is not good but the second is?

Some advantages of using external initrd:

1, Resolve size limit for core.img
core.img can't be too large, otherwise it doesn't fit inside
conventional memory. external initrd doesn't have this problem.

2. Easy to modify
users may not know how to create core.img, but modifying files in a,
say, tar or cpio archive is very easy. They can do simple tasks like
replacing splash image without too much knowledge of grub2.

3. Multiple configuration
We can use the same core.img, but different initrd to start grub2 with
different configuration.

-- 
Bean

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Tue, Jan 22, 2008 at 12:25:49PM +0800, Bean wrote:
> > but, what is the advantage in that?  Is there any use case in which the first
> > option is not good but the second is?
> 
> Some advantages of using external initrd:
> 
> 1, Resolve size limit for core.img
> core.img can't be too large, otherwise it doesn't fit inside
> conventional memory. external initrd doesn't have this problem.

Ok.

> 2. Easy to modify
> users may not know how to create core.img, but modifying files in a,
> say, tar or cpio archive is very easy. They can do simple tasks like
> replacing splash image without too much knowledge of grub2.
>
> 3. Multiple configuration
> We can use the same core.img, but different initrd to start grub2 with
> different configuration.

I don't think these two make a big difference, but well.

No objection from me, then.

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

Re: [PATCH] memdisk plus lnxboot extension

[Bean]

On Jan 22, 2008 9:57 PM, Robert Millan <rmh@aybabtu.com> wrote:
> On Tue, Jan 22, 2008 at 12:25:49PM +0800, Bean wrote:
> > > but, what is the advantage in that?  Is there any use case in which the first
> > > option is not good but the second is?
> >
> > Some advantages of using external initrd:
> >
> > 1, Resolve size limit for core.img
> > core.img can't be too large, otherwise it doesn't fit inside
> > conventional memory. external initrd doesn't have this problem.
>
> Ok.
>
> > 2. Easy to modify
> > users may not know how to create core.img, but modifying files in a,
> > say, tar or cpio archive is very easy. They can do simple tasks like
> > replacing splash image without too much knowledge of grub2.
> >
> > 3. Multiple configuration
> > We can use the same core.img, but different initrd to start grub2 with
> > different configuration.
>
> I don't think these two make a big difference, but well.
>
> No objection from me, then.

this is the patch, please try it.

	* boot/i386/pc/lnxboot.S (data_start) : Simplify code.
	(real_code_2) : Set grub_memdisk_image_addr using initrd address.

	* include/grub/i386/pc/boot.h : New constant
	GRUB_BOOT_MACHINE_LNX_LENG_OFFSET.

	* include/grub/i386/pc/kernel.h : New constant
	GRUB_KENRL_MACHINE_MEMDISK_IMAGE_ADDR.
	New variable grub_memdisk_image_addr.

	* kern/i386/pc/init.c (grub_arch_memdisk_addr) : Use
	grub_memdisk_image_addr if it isn't zero.

	* kern/i386/pc/startup.S : New variable grub_memdisk_image_addr.

	* util/i386/pc/grub-mkimage.c (generate_image) : Add is_linux parameter.
	If it's set, use lnxboot.img as header instead of diskboot.img.
	(options): Add "linux"|'x' option
	(main): Parse --linux|-x option, and pass its value to generate_image.


diff --git a/boot/i386/pc/lnxboot.S b/boot/i386/pc/lnxboot.S
index f1a4ded..6503e26 100644
--- a/boot/i386/pc/lnxboot.S
+++ b/boot/i386/pc/lnxboot.S
@@ -36,22 +36,7 @@
         .globl  start, _start

 data_start:
-	pushw	%cs
-	popw	%ds
-	xorl	%eax, %eax
-	xorl	%ebx, %ebx
-	call	data_next
-
-data_next:
-	popw	%bx
-	movw	%cs, %ax
-	shll	$4, %eax
-	leal	0x200 + data_start - data_next(%ebx,%eax), %eax
-	movzbl	setup_sects - data_next(%bx), %ecx
-	shll	$9, %ecx
-	addl	%ecx, %eax
-	movl	%eax, code32_start - data_next(%bx)
-
+	xorl	%ebp, %ebp
 	jmp	linux_next

 	. = data_start + 0x1F1
@@ -76,7 +61,7 @@ boot_flag:
 start:
 _start:

-	jmp linux_code
+	jmp linux_init

 	.ascii	"HdrS"			// Header signature
 	.word	0x0203			// Header version number
@@ -134,9 +119,10 @@ reg_edx:
 data_leng:
 	.long	0

-linux_code:
+linux_init:

 	movw	%cs:(reg_edx - start), %dx
+	movl	%cs:(code32_start - start), %ebp

 linux_next:

@@ -164,9 +150,6 @@ real_code:
 	movw	%si, %ss
 	movw	$(CODE_ADDR), %sp

-	pushl	%esi
-	pushl	%edi
-
 	// Move itself to 0:CODE_ADDR

 	cld
@@ -183,17 +166,26 @@ real_code:

 real_code_2:

+	xchgl	%ebp, %esi
+	orl	%esi, %esi
+	jnz	1f
+	movw	%ds, %si
+	shll	$4, %esi
+	addl	%ebp, %esi
+1:
+
 	pushw	%es
 	popw	%ds

-	movl	(ramdisk_image - start), %esi
-	or	%esi, %esi
+	movl	(data_leng - start), %ecx
+	or	%ecx, %ecx
 	jnz	1f
-	movl	(code32_start - start), %esi
+	movl	(ramdisk_image - start), %esi
+	movl	(ramdisk_size - start), %ecx
+	addl	$0x200, %esi
+	subl	$0x200, %ecx
 1:

-	movl	$0x200, %ecx
-	addl	%ecx, %esi
 	movl	$DATA_ADDR, %edi

 	call	move_memory
@@ -204,13 +196,17 @@ real_code_2:
 	movsbl	(reg_edx + 2 - start), %eax
 	movl	%eax, %ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_INSTALL_BSD_PART)

-	movl	%ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_COMPRESSED_SIZE), %ecx
-	addl	$(GRUB_KERNEL_MACHINE_RAW_SIZE - 0x200), %ecx
+	movl	(data_leng - start), %eax
+	or	%eax, %eax
+	jz	1f
+	movl	(ramdisk_size - start), %eax
+	or	%eax, %eax
+	jz	1f

-	call	move_memory
-
-	popl	%edi
-	popl	%esi
+	movl	%eax, %ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_MEMDISK_IMAGE_SIZE)
+	movl	(ramdisk_image - start), %eax
+	movl	%eax, %ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_MEMDISK_IMAGE_ADDR)
+1:

 	ljmp	$(DATA_ADDR >> 4), $0

@@ -261,8 +257,8 @@ move_memory:

 2:

-	leal	(%esi, %eax), %esi
-	leal	(%edi, %eax), %edi
+	addl	%eax, %esi
+	addl	%eax, %edi
 	subl	%eax, %ecx
 	jnz	1b

diff --git a/include/grub/i386/pc/boot.h b/include/grub/i386/pc/boot.h
index fcc961b..4cc9a04 100644
--- a/include/grub/i386/pc/boot.h
+++ b/include/grub/i386/pc/boot.h
@@ -75,4 +75,7 @@
 /* The size of a block list used in the kernel startup code.  */
 #define GRUB_BOOT_MACHINE_LIST_SIZE	12

+/* The offset of variable data_leng in lnxboot.S.  */
+#define GRUB_BOOT_MACHINE_LNX_LENG_OFFSET	0x264
+
 #endif /* ! BOOT_MACHINE_HEADER */
diff --git a/include/grub/i386/pc/kernel.h b/include/grub/i386/pc/kernel.h
index ca16df7..f5d8438 100644
--- a/include/grub/i386/pc/kernel.h
+++ b/include/grub/i386/pc/kernel.h
@@ -37,8 +37,11 @@
 /* The offset of GRUB_MEMDISK_IMAGE_SIZE.  */
 #define GRUB_KERNEL_MACHINE_MEMDISK_IMAGE_SIZE	0x1c

+/* The offset of GRUB_MEMDISK_IMAGE_ADDR.  */
+#define GRUB_KERNEL_MACHINE_MEMDISK_IMAGE_ADDR	0x20
+
 /* The offset of GRUB_PREFIX.  */
-#define GRUB_KERNEL_MACHINE_PREFIX		0x20
+#define GRUB_KERNEL_MACHINE_PREFIX		0x24

 /* End of the data section. */
 #define GRUB_KERNEL_MACHINE_DATA_END		0x50
@@ -66,6 +69,9 @@ extern grub_int32_t grub_install_bsd_part;
 /* The size of memory disk image, if present.  */
 extern grub_int32_t grub_memdisk_image_size;

+/* The address of memory disk image, if present.  */
+extern grub_int32_t grub_memdisk_image_addr;
+
 /* The prefix which points to the directory where GRUB modules and its
    configuration file are located.  */
 extern char grub_prefix[];
diff --git a/kern/i386/pc/init.c b/kern/i386/pc/init.c
index 0cf81d7..af6deda 100644
--- a/kern/i386/pc/init.c
+++ b/kern/i386/pc/init.c
@@ -253,9 +253,10 @@ grub_arch_modules_addr (void)
 grub_addr_t
 grub_arch_memdisk_addr (void)
 {
-  return GRUB_MEMORY_MACHINE_DECOMPRESSION_ADDR
+  return (grub_memdisk_image_addr) ? grub_memdisk_image_addr :
+    (GRUB_MEMORY_MACHINE_DECOMPRESSION_ADDR
     + (grub_kernel_image_size - GRUB_KERNEL_MACHINE_RAW_SIZE)
-    + grub_total_module_size;
+    + grub_total_module_size);
 }

 /* Return the size of the memdisk image.  */
diff --git a/kern/i386/pc/startup.S b/kern/i386/pc/startup.S
index e4101a6..5dd2e67 100644
--- a/kern/i386/pc/startup.S
+++ b/kern/i386/pc/startup.S
@@ -97,6 +97,8 @@ VARIABLE(grub_install_bsd_part)
 	.long	0xFFFFFFFF
 VARIABLE(grub_memdisk_image_size)
 	.long	0
+VARIABLE(grub_memdisk_image_addr)
+	.long	0
 VARIABLE(grub_prefix)
 	/* to be filled by grub-mkimage */

diff --git a/util/i386/pc/grub-mkimage.c b/util/i386/pc/grub-mkimage.c
index 48d6dfc..eee6b34 100644
--- a/util/i386/pc/grub-mkimage.c
+++ b/util/i386/pc/grub-mkimage.c
@@ -77,7 +77,7 @@ compress_kernel (char *kernel_img, size_t kernel_size,
 }

 static void
-generate_image (const char *dir, char *prefix, FILE *out, char
*mods[], char *memdisk_path)
+generate_image (const char *dir, char *prefix, FILE *out, char
*mods[], char *memdisk_path, int is_linux)
 {
   grub_addr_t module_addr = 0;
   char *kernel_img, *boot_img, *core_img;
@@ -151,17 +151,25 @@ generate_image (const char *dir, char *prefix,
FILE *out, char *mods[], char *me
   if (num > 0xffff)
     grub_util_error ("the core image is too big");

-  boot_path = grub_util_get_path (dir, "diskboot.img");
+  boot_path = grub_util_get_path (dir, (is_linux) ? "lnxboot.img" :
"diskboot.img");
   boot_size = grub_util_get_image_size (boot_path);
-  if (boot_size != GRUB_DISK_SECTOR_SIZE)
+  if ((! is_linux) && (boot_size != GRUB_DISK_SECTOR_SIZE))
     grub_util_error ("diskboot.img is not one sector size");

   boot_img = grub_util_read_image (boot_path);

-  /* i386 is a little endian architecture.  */
-  *((grub_uint16_t *) (boot_img + GRUB_DISK_SECTOR_SIZE
+  if (is_linux)
+    {
+      *((grub_uint32_t *) (boot_img + GRUB_BOOT_MACHINE_LNX_LENG_OFFSET))
+      = grub_cpu_to_le32 (core_size);
+    }
+  else
+    {
+      /* i386 is a little endian architecture.  */
+      *((grub_uint16_t *) (boot_img + GRUB_DISK_SECTOR_SIZE
 		       - GRUB_BOOT_MACHINE_LIST_SIZE + 8))
-    = grub_cpu_to_le16 (num);
+      = grub_cpu_to_le16 (num);
+    }

   grub_util_write_image (boot_img, boot_size, out);
   free (boot_img);
@@ -208,6 +216,7 @@ static struct option options[] =
     {"prefix", required_argument, 0, 'p'},
     {"memdisk", required_argument, 0, 'm'},
     {"output", required_argument, 0, 'o'},
+    {"linux", no_argument, 0, 'x'},
     {"help", no_argument, 0, 'h'},
     {"version", no_argument, 0, 'V'},
     {"verbose", no_argument, 0, 'v'},
@@ -229,6 +238,7 @@ Make a bootable image of GRUB.\n\
   -p, --prefix=DIR        set grub_prefix directory [default=%s]\n\
   -m, --memdisk=FILE      embed FILE as a memdisk image\n\
   -o, --output=FILE       output a generated image to FILE [default=stdout]\n\
+  -x, --linux             add linux kernel header to output file\n\
   -h, --help              display this message and exit\n\
   -V, --version           print version information and exit\n\
   -v, --verbose           print verbose messages\n\
@@ -247,12 +257,13 @@ main (int argc, char *argv[])
   char *prefix = NULL;
   char *memdisk = NULL;
   FILE *fp = stdout;
+  int is_linux = 0;

   progname = "grub-mkimage";

   while (1)
     {
-      int c = getopt_long (argc, argv, "d:p:m:o:hVv", options, 0);
+      int c = getopt_long (argc, argv, "d:p:m:o:xhVv", options, 0);

       if (c == -1)
 	break;
@@ -280,6 +291,10 @@ main (int argc, char *argv[])
 	    memdisk = xstrdup (optarg);
 	    break;

+	  case 'x':
+	    is_linux = 1;
+	    break;
+
 	  case 'h':
 	    usage (0);
 	    break;
@@ -312,7 +327,7 @@ main (int argc, char *argv[])
 	grub_util_error ("cannot open %s", output);
     }

-  generate_image (dir ? : GRUB_LIBDIR, prefix ? : DEFAULT_DIRECTORY,
fp, argv + optind, memdisk);
+  generate_image (dir ? : GRUB_LIBDIR, prefix ? : DEFAULT_DIRECTORY,
fp, argv + optind, memdisk, is_linux);

   fclose (fp);




-- 
Bean

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Wed, Jan 23, 2008 at 12:22:32AM +0800, Bean wrote:
> 	* util/i386/pc/grub-mkimage.c (generate_image) : Add is_linux parameter.
> 	If it's set, use lnxboot.img as header instead of diskboot.img.
> 	(options): Add "linux"|'x' option
> 	(main): Parse --linux|-x option, and pass its value to generate_image.

I don't like this very much.  We don't have grub-mkimage options to concatenate
it with boot.img, so why with lnxboot.img ?

Also, I can only think of very specific situations in which this interface
would be useful (that is, when firmware has only a linux loader).  It makes
sense to me as a compatibility layer, yes.

But it seems you want it as a general-purpose option; for that, why not make
it saner like multiboot?  I don't think it's a good idea to compromise our
boot semantics because of the ones legacy Linux has.

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

Re: [PATCH] memdisk plus lnxboot extension

[Bean]

On Jan 23, 2008 12:51 AM, Robert Millan <rmh@aybabtu.com> wrote:
> I don't like this very much.  We don't have grub-mkimage options to concatenate
> it with boot.img, so why with lnxboot.img ?

The reason for new option is that the length of core.img needs to
stored in lnxboot.img. Previously, i calculate the size using
information in core.img header, but now there is issue, for example,

1.
kernel lnxboot.img
initrd core.img

2.
cat lnxboot.img core.img > grub2.bin
kernel grub2.bin
initrd memdisk

1 and 2 looks the same to lnxboot header, it can't decide initrd is
used as memdisk or core.img. However, 1 may not be that useful after
all, we can disable this kind of usage.

> Also, I can only think of very specific situations in which this interface
> would be useful (that is, when firmware has only a linux loader).  It makes
> sense to me as a compatibility layer, yes.
>
> But it seems you want it as a general-purpose option; for that, why not make
> it saner like multiboot?  I don't think it's a good idea to compromise our
> boot semantics because of the ones legacy Linux has.

is multiboot support memdisk or something similar ?

-- 
Bean

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Wed, Jan 23, 2008 at 01:17:43AM +0800, Bean wrote:
> On Jan 23, 2008 12:51 AM, Robert Millan <rmh@aybabtu.com> wrote:
> > I don't like this very much.  We don't have grub-mkimage options to concatenate
> > it with boot.img, so why with lnxboot.img ?
> 
> The reason for new option is that the length of core.img needs to
> stored in lnxboot.img. Previously, i calculate the size using
> information in core.img header, but now there is issue, for example,
> 
> 1.
> kernel lnxboot.img
> initrd core.img
> 
> 2.
> cat lnxboot.img core.img > grub2.bin
> kernel grub2.bin
> initrd memdisk
> 
> 1 and 2 looks the same to lnxboot header, it can't decide initrd is
> used as memdisk or core.img. However, 1 may not be that useful after
> all, we can disable this kind of usage.

I didn't know you had 1 in mind.  Yes, I think it's better to restrict us
to 2 for now.  I don't really see a big benefit in 2 vs just using
"grub-mkimage -m", but I suppose if it's not too intrusive it doesn't harm.

> > Also, I can only think of very specific situations in which this interface
> > would be useful (that is, when firmware has only a linux loader).  It makes
> > sense to me as a compatibility layer, yes.
> >
> > But it seems you want it as a general-purpose option; for that, why not make
> > it saner like multiboot?  I don't think it's a good idea to compromise our
> > boot semantics because of the ones legacy Linux has.
> 
> is multiboot support memdisk or something similar ?

I'm not very familiar with multiboot, but it supports modules (an arbitrary
number of them, I think).  Then again, we still need a use case before adding
a feature.  The obvious use case for having lnxboot is booting from firmware
that only supports booting Linux, but for other stuff I still don't see it.

I mean, the initial purpose of memdisk was that you could _embed_ data in
core.img itself.  Using it as a loader feature sounds a bit contradictory to
me... perhaps if you explain what situations do you have in mind where this
would be helpful, I'd understand your point better.

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

Re: [PATCH] memdisk plus lnxboot extension

[Marco Gerards]

Bean <bean123ch@gmail.com> writes:

[...]

> 2. Easy to modify
> users may not know how to create core.img, but modifying files in a,
> say, tar or cpio archive is very easy. They can do simple tasks like
> replacing splash image without too much knowledge of grub2.

It seems easier, but isn't.  First of all, if people want to use GRUB,
they have to learn how to use it.  It is not difficult.

More importantly, when doing the manually, people might forget modules
which are required as a dependancy.  For example fshelp.mod.

--
Marco

Re: [PATCH] memdisk plus lnxboot extension

[Marco Gerards]

Robert Millan <rmh@aybabtu.com> writes:

>> 2. Easy to modify
>> users may not know how to create core.img, but modifying files in a,
>> say, tar or cpio archive is very easy. They can do simple tasks like
>> replacing splash image without too much knowledge of grub2.
>>
>> 3. Multiple configuration
>> We can use the same core.img, but different initrd to start grub2 with
>> different configuration.
>
> I don't think these two make a big difference, but well.
>
> No objection from me, then.

Personally I do not want to add every feature everyone comes up with,
just because there is a patch.

When is this feature useful?  Can you give an example?  More features
can mean more bugs, more maintainance work, etc.  If the feature is
not worthwhile for more than one person, I am not sure if it should be
included.  Perhaps a better explaination of the problem to solve,
instead of what the patch does might help here.

--
Marco

Re: [PATCH] memdisk plus lnxboot extension

[Bean]

On Jan 23, 2008 4:54 PM, Marco Gerards <mgerards@xs4all.nl> wrote:
> When is this feature useful?  Can you give an example?  More features
> can mean more bugs, more maintainance work, etc.  If the feature is
> not worthwhile for more than one person, I am not sure if it should be
> included.  Perhaps a better explaination of the problem to solve,
> instead of what the patch does might help here.

the most important usage of external initrd is to overcome the size
limit of core.img.

-- 
Bean

Re: [PATCH] memdisk plus lnxboot extension

[Bean]

On Jan 24, 2008 12:18 AM, Bean <bean123ch@gmail.com> wrote:
> On Jan 23, 2008 4:54 PM, Marco Gerards <mgerards@xs4all.nl> wrote:
> > When is this feature useful?  Can you give an example?  More features
> > can mean more bugs, more maintainance work, etc.  If the feature is
> > not worthwhile for more than one person, I am not sure if it should be
> > included.  Perhaps a better explaination of the problem to solve,
> > instead of what the patch does might help here.
>
> the most important usage of external initrd is to overcome the size
> limit of core.img.

this is the new patch, now no need to modify grub-mkimage, use cat
just as before.


	* boot/i386/pc/lnxboot.S (data_start) : Simplify code.
	(real_code_2) : Set grub_memdisk_image_addr using initrd address.

	* include/grub/i386/pc/kernel.h : New constant
	GRUB_KENRL_MACHINE_MEMDISK_IMAGE_ADDR.
	New variable grub_memdisk_image_addr.

	* kern/i386/pc/init.c (grub_arch_memdisk_addr) : Use
	grub_memdisk_image_addr if it isn't zero.

	* kern/i386/pc/startup.S : New variable grub_memdisk_image_addr.

diff --git a/boot/i386/pc/lnxboot.S b/boot/i386/pc/lnxboot.S
index f1a4ded..25554d7 100644
--- a/boot/i386/pc/lnxboot.S
+++ b/boot/i386/pc/lnxboot.S
@@ -36,22 +36,7 @@
         .globl  start, _start

 data_start:
-	pushw	%cs
-	popw	%ds
-	xorl	%eax, %eax
-	xorl	%ebx, %ebx
-	call	data_next
-
-data_next:
-	popw	%bx
-	movw	%cs, %ax
-	shll	$4, %eax
-	leal	0x200 + data_start - data_next(%ebx,%eax), %eax
-	movzbl	setup_sects - data_next(%bx), %ecx
-	shll	$9, %ecx
-	addl	%ecx, %eax
-	movl	%eax, code32_start - data_next(%bx)
-
+	xorl	%ebp, %ebp
 	jmp	linux_next

 	. = data_start + 0x1F1
@@ -76,7 +61,7 @@ boot_flag:
 start:
 _start:

-	jmp linux_code
+	jmp linux_init

 	.ascii	"HdrS"			// Header signature
 	.word	0x0203			// Header version number
@@ -134,9 +119,10 @@ reg_edx:
 data_leng:
 	.long	0

-linux_code:
+linux_init:

 	movw	%cs:(reg_edx - start), %dx
+	movl	%cs:(code32_start - start), %ebp

 linux_next:

@@ -164,9 +150,6 @@ real_code:
 	movw	%si, %ss
 	movw	$(CODE_ADDR), %sp

-	pushl	%esi
-	pushl	%edi
-
 	// Move itself to 0:CODE_ADDR

 	cld
@@ -183,34 +166,53 @@ real_code:

 real_code_2:

-	pushw	%es
-	popw	%ds
-
-	movl	(ramdisk_image - start), %esi
-	or	%esi, %esi
+	xchgl	%ebp, %esi
+	orl	%esi, %esi
 	jnz	1f
-	movl	(code32_start - start), %esi
+	movw	%ds, %si
+	shll	$4, %esi
+	addl	%ebp, %esi
 1:

+	pushw	%es
+	popw	%ds
+
 	movl	$0x200, %ecx
 	addl	%ecx, %esi
 	movl	$DATA_ADDR, %edi

 	call	move_memory

-	movsbl	%dh, %eax
-	movl	%eax, %ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_INSTALL_DOS_PART)
+	// Check for the multiboot signature
+	cmpl	$0x1badb002, %ss:(DATA_ADDR + 0x50)
+	jz	1f

-	movsbl	(reg_edx + 2 - start), %eax
-	movl	%eax, %ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_INSTALL_BSD_PART)
+	movl	(ramdisk_image - start), %esi
+	movl	(ramdisk_size - start), %ecx
+	movl	$(DATA_ADDR - 0x200), %edi
+	jmp	2f
+
+1:
+	movl	(ramdisk_size - start), %eax
+	or	%eax, %eax
+	jz	1f
+
+	movl	%eax, %ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_MEMDISK_IMAGE_SIZE)
+	movl	(ramdisk_image - start), %eax
+	movl	%eax, %ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_MEMDISK_IMAGE_ADDR)
+1:

 	movl	%ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_COMPRESSED_SIZE), %ecx
 	addl	$(GRUB_KERNEL_MACHINE_RAW_SIZE - 0x200), %ecx

+2:
 	call	move_memory

-	popl	%edi
-	popl	%esi
+	movsbl	%dh, %eax
+	movl	%eax, %ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_INSTALL_DOS_PART)
+
+	movsbl	(reg_edx + 2 - start), %eax
+	movl	%eax, %ss:(DATA_ADDR + GRUB_KERNEL_MACHINE_INSTALL_BSD_PART)

 	ljmp	$(DATA_ADDR >> 4), $0

@@ -261,8 +263,8 @@ move_memory:

 2:

-	leal	(%esi, %eax), %esi
-	leal	(%edi, %eax), %edi
+	addl	%eax, %esi
+	addl	%eax, %edi
 	subl	%eax, %ecx
 	jnz	1b

diff --git a/include/grub/i386/pc/kernel.h b/include/grub/i386/pc/kernel.h
index ca16df7..f5d8438 100644
--- a/include/grub/i386/pc/kernel.h
+++ b/include/grub/i386/pc/kernel.h
@@ -37,8 +37,11 @@
 /* The offset of GRUB_MEMDISK_IMAGE_SIZE.  */
 #define GRUB_KERNEL_MACHINE_MEMDISK_IMAGE_SIZE	0x1c

+/* The offset of GRUB_MEMDISK_IMAGE_ADDR.  */
+#define GRUB_KERNEL_MACHINE_MEMDISK_IMAGE_ADDR	0x20
+
 /* The offset of GRUB_PREFIX.  */
-#define GRUB_KERNEL_MACHINE_PREFIX		0x20
+#define GRUB_KERNEL_MACHINE_PREFIX		0x24

 /* End of the data section. */
 #define GRUB_KERNEL_MACHINE_DATA_END		0x50
@@ -66,6 +69,9 @@ extern grub_int32_t grub_install_bsd_part;
 /* The size of memory disk image, if present.  */
 extern grub_int32_t grub_memdisk_image_size;

+/* The address of memory disk image, if present.  */
+extern grub_int32_t grub_memdisk_image_addr;
+
 /* The prefix which points to the directory where GRUB modules and its
    configuration file are located.  */
 extern char grub_prefix[];
diff --git a/kern/i386/pc/init.c b/kern/i386/pc/init.c
index 0cf81d7..af6deda 100644
--- a/kern/i386/pc/init.c
+++ b/kern/i386/pc/init.c
@@ -253,9 +253,10 @@ grub_arch_modules_addr (void)
 grub_addr_t
 grub_arch_memdisk_addr (void)
 {
-  return GRUB_MEMORY_MACHINE_DECOMPRESSION_ADDR
+  return (grub_memdisk_image_addr) ? grub_memdisk_image_addr :
+    (GRUB_MEMORY_MACHINE_DECOMPRESSION_ADDR
     + (grub_kernel_image_size - GRUB_KERNEL_MACHINE_RAW_SIZE)
-    + grub_total_module_size;
+    + grub_total_module_size);
 }

 /* Return the size of the memdisk image.  */
diff --git a/kern/i386/pc/startup.S b/kern/i386/pc/startup.S
index e4101a6..5dd2e67 100644
--- a/kern/i386/pc/startup.S
+++ b/kern/i386/pc/startup.S
@@ -97,6 +97,8 @@ VARIABLE(grub_install_bsd_part)
 	.long	0xFFFFFFFF
 VARIABLE(grub_memdisk_image_size)
 	.long	0
+VARIABLE(grub_memdisk_image_addr)
+	.long	0
 VARIABLE(grub_prefix)
 	/* to be filled by grub-mkimage */



-- 
Bean

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Thu, Jan 24, 2008 at 12:18:43AM +0800, Bean wrote:
> On Jan 23, 2008 4:54 PM, Marco Gerards <mgerards@xs4all.nl> wrote:
> > When is this feature useful?  Can you give an example?  More features
> > can mean more bugs, more maintainance work, etc.  If the feature is
> > not worthwhile for more than one person, I am not sure if it should be
> > included.  Perhaps a better explaination of the problem to solve,
> > instead of what the patch does might help here.
> 
> the most important usage of external initrd is to overcome the size
> limit of core.img.

I understand that it overcomes a size limit, but, in which situations would
this be used?  core.img is primarily targetted at being used with grub-setup
(where memdisk isn't needed), to be chainloaded from GRUB Legacy (where
memdisk isn't necessary either), or to build a rescue floppy (where this
feature, in principle, can't be used).  Do you have other uses of core.img
in mind?

And in the case of rescue floppies, if we find a way to overcome the size
limit via loading memdisk image separately, I don't think using Linux boot
semantics is the best way to do it.  Linux excels at a lot of things, but its
boot mechanism is full of legacy cruft.  I don't think it's the best option
to take as a reference to implement GRUB.

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

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Thu, Jan 24, 2008 at 03:01:33AM +0800, Bean wrote:
> On Jan 24, 2008 12:18 AM, Bean <bean123ch@gmail.com> wrote:
> > On Jan 23, 2008 4:54 PM, Marco Gerards <mgerards@xs4all.nl> wrote:
> > > When is this feature useful?  Can you give an example?  More features
> > > can mean more bugs, more maintainance work, etc.  If the feature is
> > > not worthwhile for more than one person, I am not sure if it should be
> > > included.  Perhaps a better explaination of the problem to solve,
> > > instead of what the patch does might help here.
> >
> > the most important usage of external initrd is to overcome the size
> > limit of core.img.
> 
> this is the new patch, now no need to modify grub-mkimage, use cat
> just as before.

Well..  even though I still don't see the motivation, I'm less concerned about
this if it's just added to lnxboot.img.

> +VARIABLE(grub_memdisk_image_addr)
> +	.long	0

I recall you said use of this variable could be avoided ?

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

Re: [PATCH] memdisk plus lnxboot extension

[Bean]

On Jan 24, 2008 3:14 AM, Robert Millan <rmh@aybabtu.com> wrote:
> On Thu, Jan 24, 2008 at 03:01:33AM +0800, Bean wrote:
> > On Jan 24, 2008 12:18 AM, Bean <bean123ch@gmail.com> wrote:
> > > On Jan 23, 2008 4:54 PM, Marco Gerards <mgerards@xs4all.nl> wrote:
> > > > When is this feature useful?  Can you give an example?  More features
> > > > can mean more bugs, more maintainance work, etc.  If the feature is
> > > > not worthwhile for more than one person, I am not sure if it should be
> > > > included.  Perhaps a better explaination of the problem to solve,
> > > > instead of what the patch does might help here.
> > >
> > > the most important usage of external initrd is to overcome the size
> > > limit of core.img.
> >
> > this is the new patch, now no need to modify grub-mkimage, use cat
> > just as before.
>
> Well..  even though I still don't see the motivation, I'm less concerned about
> this if it's just added to lnxboot.img.
>
> > +VARIABLE(grub_memdisk_image_addr)
> > +     .long   0
>
> I recall you said use of this variable could be avoided ?

This variable can't be avoided. it's used by grub_arch_memdisk_addr to
return the address of initrd. however, i can copy initrd to the
location to make it look like core.img load it, but that means an
extra memory copy.


-- 
Bean

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Thu, Jan 24, 2008 at 03:24:37AM +0800, Bean wrote:
> On Jan 24, 2008 3:14 AM, Robert Millan <rmh@aybabtu.com> wrote:
> > On Thu, Jan 24, 2008 at 03:01:33AM +0800, Bean wrote:
> > > On Jan 24, 2008 12:18 AM, Bean <bean123ch@gmail.com> wrote:
> > > > On Jan 23, 2008 4:54 PM, Marco Gerards <mgerards@xs4all.nl> wrote:
> > > > > When is this feature useful?  Can you give an example?  More features
> > > > > can mean more bugs, more maintainance work, etc.  If the feature is
> > > > > not worthwhile for more than one person, I am not sure if it should be
> > > > > included.  Perhaps a better explaination of the problem to solve,
> > > > > instead of what the patch does might help here.
> > > >
> > > > the most important usage of external initrd is to overcome the size
> > > > limit of core.img.
> > >
> > > this is the new patch, now no need to modify grub-mkimage, use cat
> > > just as before.
> >
> > Well..  even though I still don't see the motivation, I'm less concerned about
> > this if it's just added to lnxboot.img.
> >
> > > +VARIABLE(grub_memdisk_image_addr)
> > > +     .long   0
> >
> > I recall you said use of this variable could be avoided ?
> 
> This variable can't be avoided. it's used by grub_arch_memdisk_addr to
> return the address of initrd. however, i can copy initrd to the
> location to make it look like core.img load it, but that means an
> extra memory copy.

The region where memdisk is normally put has no size limit, only the core
image itself does.  Why not load it at the same address?

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

Re: [PATCH] memdisk plus lnxboot extension

[Bean]

On Jan 24, 2008 4:15 AM, Robert Millan <rmh@aybabtu.com> wrote:
> The region where memdisk is normally put has no size limit, only the core
> image itself does.  Why not load it at the same address?

I just check, the lzo decompression will overwrite the area, so we
can't copy initrd there.

-- 
Bean

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Thu, Jan 24, 2008 at 05:04:56AM +0800, Bean wrote:
> On Jan 24, 2008 4:15 AM, Robert Millan <rmh@aybabtu.com> wrote:
> > The region where memdisk is normally put has no size limit, only the core
> > image itself does.  Why not load it at the same address?
> 
> I just check, the lzo decompression will overwrite the area, so we
> can't copy initrd there.

So where does your code copy it?

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

Re: [PATCH] memdisk plus lnxboot extension

[Bean]

On Jan 24, 2008 5:15 AM, Robert Millan <rmh@aybabtu.com> wrote:
>
> On Thu, Jan 24, 2008 at 05:04:56AM +0800, Bean wrote:
> > On Jan 24, 2008 4:15 AM, Robert Millan <rmh@aybabtu.com> wrote:
> > > The region where memdisk is normally put has no size limit, only the core
> > > image itself does.  Why not load it at the same address?
> >
> > I just check, the lzo decompression will overwrite the area, so we
> > can't copy initrd there.
>
> So where does your code copy it?

currently, i don't copy it. i save the initrd address to variable
grub_memdisk_image_addr, which is then used by grub_arch_memdisk_addr
to locate the memdisk.

-- 
Bean

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Thu, Jan 24, 2008 at 11:40:25AM +0800, Bean wrote:
> On Jan 24, 2008 5:15 AM, Robert Millan <rmh@aybabtu.com> wrote:
> >
> > On Thu, Jan 24, 2008 at 05:04:56AM +0800, Bean wrote:
> > > On Jan 24, 2008 4:15 AM, Robert Millan <rmh@aybabtu.com> wrote:
> > > > The region where memdisk is normally put has no size limit, only the core
> > > > image itself does.  Why not load it at the same address?
> > >
> > > I just check, the lzo decompression will overwrite the area, so we
> > > can't copy initrd there.
> >
> > So where does your code copy it?
> 
> currently, i don't copy it. i save the initrd address to variable
> grub_memdisk_image_addr, which is then used by grub_arch_memdisk_addr
> to locate the memdisk.

Sorry, my question was confusing;  what I meant is, where is it located when
core.img is started.  But Just checked in our Linux loader, and it seems to be
at a very high address.

However, a very high address doesn't garantee that it won't be overwritten by
lzo decompression, just makes it less likely.

Overall, this is why I don't like having to stick to a particular boot
mechanism.  If our goal is overcome the size limit in memdisk, why not design
the boot mechanism ourselves?

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

Re: [PATCH] memdisk plus lnxboot extension

[Bean]

On Jan 24, 2008 7:32 PM, Robert Millan <rmh@aybabtu.com> wrote:
> Sorry, my question was confusing;  what I meant is, where is it located when
> core.img is started.  But Just checked in our Linux loader, and it seems to be
> at a very high address.
>
> However, a very high address doesn't garantee that it won't be overwritten by
> lzo decompression, just makes it less likely.
>
> Overall, this is why I don't like having to stick to a particular boot
> mechanism.  If our goal is overcome the size limit in memdisk, why not design
> the boot mechanism ourselves?

I'm not familiar with multiboot spec, does it support arbitrary kernel size ?

-- 
Bean

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Thu, Jan 24, 2008 at 07:49:23PM +0800, Bean wrote:
> On Jan 24, 2008 7:32 PM, Robert Millan <rmh@aybabtu.com> wrote:
> > Sorry, my question was confusing;  what I meant is, where is it located when
> > core.img is started.  But Just checked in our Linux loader, and it seems to be
> > at a very high address.
> >
> > However, a very high address doesn't garantee that it won't be overwritten by
> > lzo decompression, just makes it less likely.
> >
> > Overall, this is why I don't like having to stick to a particular boot
> > mechanism.  If our goal is overcome the size limit in memdisk, why not design
> > the boot mechanism ourselves?
> 
> I'm not familiar with multiboot spec, does it support arbitrary kernel size ?

Sorry I don't know, you'd have to check.

However, my point is more about the loadee than the loader.  We provide a
multiboot image, which can also be a linux image with lnxboot.img, however,
this image needs to be very small, because it's intended usage is with
grub-setup, and that is why we only put the minimal stuff in it, and compress
it.

You want to add a feature that only works when you have the ability to load
images of an arbitrary size.  However, if we had this ability we wouldn't have
to compress core.img, or make it small in the first place.  We would then
just create core.img of an arbitrary size, and include a memdisk of an
arbitrary size in it.  But then we wouldn't need a feature to work around the
size restriction in memdisk!

I think we need to discuss more about the situation you want to solve.  Who
is going to load GRUB in lnxboot form + memdisk image?  Where is it going to
load that from?  If GRUB can access the same media, why not use loopback
to add a virtual disk based on the filesystem image, instead of loading it
in memory?

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

Re: [PATCH] memdisk plus lnxboot extension

[Bean]

On Jan 24, 2008 10:25 PM, Robert Millan <rmh@aybabtu.com> wrote:
>
> On Thu, Jan 24, 2008 at 07:49:23PM +0800, Bean wrote:
> > On Jan 24, 2008 7:32 PM, Robert Millan <rmh@aybabtu.com> wrote:
> > > Sorry, my question was confusing;  what I meant is, where is it located when
> > > core.img is started.  But Just checked in our Linux loader, and it seems to be
> > > at a very high address.
> > >
> > > However, a very high address doesn't garantee that it won't be overwritten by
> > > lzo decompression, just makes it less likely.
> > >
> > > Overall, this is why I don't like having to stick to a particular boot
> > > mechanism.  If our goal is overcome the size limit in memdisk, why not design
> > > the boot mechanism ourselves?
> >
> > I'm not familiar with multiboot spec, does it support arbitrary kernel size ?
>
> Sorry I don't know, you'd have to check.
>
> However, my point is more about the loadee than the loader.  We provide a
> multiboot image, which can also be a linux image with lnxboot.img, however,
> this image needs to be very small, because it's intended usage is with
> grub-setup, and that is why we only put the minimal stuff in it, and compress
> it.
>
> You want to add a feature that only works when you have the ability to load
> images of an arbitrary size.  However, if we had this ability we wouldn't have
> to compress core.img, or make it small in the first place.  We would then
> just create core.img of an arbitrary size, and include a memdisk of an
> arbitrary size in it.  But then we wouldn't need a feature to work around the
> size restriction in memdisk!
>
> I think we need to discuss more about the situation you want to solve.  Who
> is going to load GRUB in lnxboot form + memdisk image?  Where is it going to
> load that from?  If GRUB can access the same media, why not use loopback
> to add a virtual disk based on the filesystem image, instead of loading it
> in memory?

i'm thinking about the situation where the boot media is not
accessible, like pxe/cdrom. in this case, we can create core.img that
contain minimum modules, and initrd that contain other modules plus
font files and other data file. then, we can use loader like
pxelinux/isolinux to load them at the same time.

-- 
Bean

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Thu, Jan 24, 2008 at 10:57:46PM +0800, Bean wrote:
> >
> > However, my point is more about the loadee than the loader.  We provide a
> > multiboot image, which can also be a linux image with lnxboot.img, however,
> > this image needs to be very small, because it's intended usage is with
> > grub-setup, and that is why we only put the minimal stuff in it, and compress
> > it.
> >
> > You want to add a feature that only works when you have the ability to load
> > images of an arbitrary size.  However, if we had this ability we wouldn't have
> > to compress core.img, or make it small in the first place.  We would then
> > just create core.img of an arbitrary size, and include a memdisk of an
> > arbitrary size in it.  But then we wouldn't need a feature to work around the
> > size restriction in memdisk!
> >
> > I think we need to discuss more about the situation you want to solve.  Who
> > is going to load GRUB in lnxboot form + memdisk image?  Where is it going to
> > load that from?  If GRUB can access the same media, why not use loopback
> > to add a virtual disk based on the filesystem image, instead of loading it
> > in memory?
> 
> i'm thinking about the situation where the boot media is not
> accessible, like pxe/cdrom. in this case, we can create core.img that
> contain minimum modules, and initrd that contain other modules plus
> font files and other data file. then, we can use loader like
> pxelinux/isolinux to load them at the same time.

We almost have support for cdrom already: ata.mod can access it, although it
lacks PCI support, but Marco is working on that.

As for PXE, it's a planned feature.  I'm not sure if it makes sense to add
this hack as a workaround for our lack of proper PXE support.

How useful is having this feature in the described situation?  If I'm guessing
right, what you want is to do the same pxelinux can do for you, but with the
added beauty of graphical menu or utf-8 charset support?  (I recall grub4dos
had Chinese charset support; do we have those characters in grub2's unifont?)

Marco, Okuji, what do you have to say?

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

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Thu, Jan 24, 2008 at 03:25:51PM +0100, Robert Millan wrote:
> 
> You want to add a feature that only works when you have the ability to load
> images of an arbitrary size.  However, if we had this ability we wouldn't have
> to compress core.img, or make it small in the first place.  We would then
> just create core.img of an arbitrary size, and include a memdisk of an
> arbitrary size in it.  But then we wouldn't need a feature to work around the
> size restriction in memdisk!

Just discussed it with Marco on IRC, and he said we could load core.img in high
memory, like in 0x100000 right away.  This solves the size limit in memdisk
which I think is the source of the problem.

Of course, this collides with the OS load area, so we'd also need to add
relocation in loader, as described in the "grub_dl_unload_all()" thread.  I
do even have unfinished code for this, although it may take a while to get it
done properly (maybe we need to add features to memory manager or so).  Does
this work for you?

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

Re: [PATCH] memdisk plus lnxboot extension

[Bean]

On Jan 25, 2008 12:55 AM, Robert Millan <rmh@aybabtu.com> wrote:
> On Thu, Jan 24, 2008 at 03:25:51PM +0100, Robert Millan wrote:
> >
> > You want to add a feature that only works when you have the ability to load
> > images of an arbitrary size.  However, if we had this ability we wouldn't have
> > to compress core.img, or make it small in the first place.  We would then
> > just create core.img of an arbitrary size, and include a memdisk of an
> > arbitrary size in it.  But then we wouldn't need a feature to work around the
> > size restriction in memdisk!
>
> Just discussed it with Marco on IRC, and he said we could load core.img in high
> memory, like in 0x100000 right away.  This solves the size limit in memdisk
> which I think is the source of the problem.
>
> Of course, this collides with the OS load area, so we'd also need to add
> relocation in loader, as described in the "grub_dl_unload_all()" thread.  I
> do even have unfinished code for this, although it may take a while to get it
> done properly (maybe we need to add features to memory manager or so).  Does
> this work for you?

i think this is great, we don't have to worry about memdisk size, and
no need for the initrd hack anymore.

-- 
Bean

Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan]

On Fri, Jan 25, 2008 at 01:04:34AM +0800, Bean wrote:
> On Jan 25, 2008 12:55 AM, Robert Millan <rmh@aybabtu.com> wrote:
> > On Thu, Jan 24, 2008 at 03:25:51PM +0100, Robert Millan wrote:
> > >
> > > You want to add a feature that only works when you have the ability to load
> > > images of an arbitrary size.  However, if we had this ability we wouldn't have
> > > to compress core.img, or make it small in the first place.  We would then
> > > just create core.img of an arbitrary size, and include a memdisk of an
> > > arbitrary size in it.  But then we wouldn't need a feature to work around the
> > > size restriction in memdisk!
> >
> > Just discussed it with Marco on IRC, and he said we could load core.img in high
> > memory, like in 0x100000 right away.  This solves the size limit in memdisk
> > which I think is the source of the problem.
> >
> > Of course, this collides with the OS load area, so we'd also need to add
> > relocation in loader, as described in the "grub_dl_unload_all()" thread.  I
> > do even have unfinished code for this, although it may take a while to get it
> > done properly (maybe we need to add features to memory manager or so).  Does
> > this work for you?
> 
> i think this is great, we don't have to worry about memdisk size, and
> no need for the initrd hack anymore.

Ok.  I'll send my patch to the list later (not as a proposal for commit, but to
start a discussion on what is the right way to do it).

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

Re: [PATCH] memdisk plus lnxboot extension

[Marco Gerards]

Robert Millan <rmh@aybabtu.com> writes:

> On Fri, Jan 25, 2008 at 01:04:34AM +0800, Bean wrote:
>> On Jan 25, 2008 12:55 AM, Robert Millan <rmh@aybabtu.com> wrote:
>> > On Thu, Jan 24, 2008 at 03:25:51PM +0100, Robert Millan wrote:
>> > >
>> > > You want to add a feature that only works when you have the ability to load
>> > > images of an arbitrary size.  However, if we had this ability we wouldn't have
>> > > to compress core.img, or make it small in the first place.  We would then
>> > > just create core.img of an arbitrary size, and include a memdisk of an
>> > > arbitrary size in it.  But then we wouldn't need a feature to work around the
>> > > size restriction in memdisk!
>> >
>> > Just discussed it with Marco on IRC, and he said we could load core.img in high
>> > memory, like in 0x100000 right away.  This solves the size limit in memdisk
>> > which I think is the source of the problem.
>> >
>> > Of course, this collides with the OS load area, so we'd also need to add
>> > relocation in loader, as described in the "grub_dl_unload_all()" thread.  I
>> > do even have unfinished code for this, although it may take a while to get it
>> > done properly (maybe we need to add features to memory manager or so).  Does
>> > this work for you?
>> 
>> i think this is great, we don't have to worry about memdisk size, and
>> no need for the initrd hack anymore.
>
> Ok.  I'll send my patch to the list later (not as a proposal for commit, but to
> start a discussion on what is the right way to do it).

Great!  This will solve many issues at once :-)

Thanks to both of you! :-)

--
Marco

Re: [PATCH] memdisk plus lnxboot extension

[Yoshinori K. Okuji]

On Thursday 24 January 2008 12:49, Bean wrote:
> On Jan 24, 2008 7:32 PM, Robert Millan <rmh@aybabtu.com> wrote:
> > Sorry, my question was confusing;  what I meant is, where is it located
> > when core.img is started.  But Just checked in our Linux loader, and it
> > seems to be at a very high address.
> >
> > However, a very high address doesn't garantee that it won't be
> > overwritten by lzo decompression, just makes it less likely.
> >
> > Overall, this is why I don't like having to stick to a particular boot
> > mechanism.  If our goal is overcome the size limit in memdisk, why not
> > design the boot mechanism ourselves?
>
> I'm not familiar with multiboot spec, does it support arbitrary kernel size
> ?

Why not? ;)

The theoretical limit is that defined by an architecture, such as 4GB in 
32-bit addressing. If you find a stronger limit, it must be an implementation 
limit.

Okuji