Add support for the 32 bit boot protocol to the x86 zboot command.

This change conditionally modifies the zboot command so that it can use the 32 bit boot protocol. This is necessary because the 16 bit realmode entry point assumes that it can call BIOS services which neither coreboot nor u-boot provide.

Signed-off-by Gabe Black <[email protected]>

---

?arch/x86/include/asm/zimage.h | ? ?4 +-
?arch/x86/lib/bootm.c ? ? ? ? ?| ? ?6 +++-
?arch/x86/lib/zimage.c ? ? ? ? | ? 49 +++++++++++++++++++++++++++++++---------

?3 files changed, 44 insertions(+), 15 deletions(-)

arch/x86/include/asm/zimage.h +2 -2

index 1a77e00..8ee6a74 100644
@@ -46,8 +46,8 @@
 
 ?void *load_zimage(char *image, unsigned long kernel_size,
 ? ? ? ? ? ? ? ? ?unsigned long initrd_addr, unsigned long initrd_size,
- ? ? ? ? ? ? ? ? int auto_boot);
+ ? ? ? ? ? ? ? ? int auto_boot, void **load_address);
 
-void boot_zimage(void *setup_base);
+void boot_zimage(void *setup_base, void *load_address);
 

?#endif

arch/x86/lib/bootm.c +1 -0

index bac7b4f..0905809 100644
@@ -38,6 +38,7 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
 ? ? ? ?void ? ? ? ? ? ?*base_ptr = NULL;
 ? ? ? ?ulong ? ? ? ? ? os_data, os_len;
 ? ? ? ?image_header_t ?*hdr;
+ ? ? ? void ? ? ? ? ? ?*load_address;
 
 ?#if defined(CONFIG_FIT)
 ? ? ? ?const void ? ? ?*data;

@@ -75,7 +76,8 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
 

?#ifdef CONFIG_CMD_ZBOOT
? ? ? ?base_ptr = load_zimage((void *)os_data, os_len,
- ? ? ? ? ? ? ? ? ? ? ? images->rd_start, images->rd_end - images->rd_start, 0);
+ ? ? ? ? ? ? ? ? ? ? ? images->rd_start, images->rd_end - images->rd_start,
+ ? ? ? ? ? ? ? ? ? ? ? 0, &load_address);
?#endif

? ? ? ?if (NULL == base_ptr) {

arch/x86/lib/bootm.c +0 -0

@@ -92,7 +94,7 @@ int do_bootm_linux(int flag, int argc, char * const argv[],

? ? ? ?/* we assume that the kernel is in place */ ? ? ? ?printf("\nStarting kernel ...\n\n");

- ? ? ? boot_zimage(base_ptr);
+ ? ? ? boot_zimage(base_ptr, load_address);
? ? ? ?/* does not return */

?error:

arch/x86/lib/zimage.c +1 -2

index 3b33486..1003929 100644
@@ -83,13 +83,12 @@ static void build_command_line(char *command_line, int auto_boot)
 
 ?void *load_zimage(char *image, unsigned long kernel_size,
 ? ? ? ? ? ? ? ? ?unsigned long initrd_addr, unsigned long initrd_size,
- ? ? ? ? ? ? ? ? int auto_boot)
+ ? ? ? ? ? ? ? ? int auto_boot, void **load_address)
 ?{
 ? ? ? ?struct boot_params *setup_base;
 ? ? ? ?int setup_size;
 ? ? ? ?int bootproto;
 ? ? ? ?int big_image;
- ? ? ? void *load_address;
 
 ? ? ? ?struct boot_params *params = (struct boot_params *)image;
 ? ? ? ?struct setup_header *hdr = &params->hdr;

@@ -136,14 +135,23 @@ void *load_zimage(char *image, unsigned long kernel_size,
 

? ? ? ?/* Determine load address */
? ? ? ?if (big_image)
- ? ? ? ? ? ? ? load_address = (void *)BZIMAGE_LOAD_ADDR;
+ ? ? ? ? ? ? ? *load_address = (void *)BZIMAGE_LOAD_ADDR; ? ? ? ?else
- ? ? ? ? ? ? ? load_address = (void *)ZIMAGE_LOAD_ADDR;
+ ? ? ? ? ? ? ? *load_address = (void *)ZIMAGE_LOAD_ADDR;

+#else
? ? ? ?/* load setup */
? ? ? ?printf("Moving Real-Mode Code to 0x%8.8lx (%d bytes)\n", ? ? ? ? ? ? ? (ulong)setup_base, setup_size);
? ? ? ?memmove(setup_base, image, setup_size); +#endif

? ? ? ?printf("Using boot protocol version %x.%02x\n", ? ? ? ? ? ? ? (bootproto & 0xff00) >> 8, bootproto & 0xff);

arch/x86/lib/zimage.c +1 -1

@@ -182,7 +190,7 @@ void *load_zimage(char *image, unsigned long kernel_size,
 
 ? ? ? ? ? ? ? ?if (hdr->setup_sects >= 15) {
 ? ? ? ? ? ? ? ? ? ? ? ?printf("Linux kernel version %s\n",
- ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(char *)setup_base +
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(char *)params +
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? hdr->kernel_version + 0x200);
 ? ? ? ? ? ? ? ?} else {

? ? ? ? ? ? ? ? ? ? ? ?printf("Setup Sectors < 15 - "

arch/x86/lib/zimage.c +2 -3

@@ -237,17 +245,33 @@ void *load_zimage(char *image, unsigned long kernel_size,
 ? ? ? ?build_command_line((char *)setup_base + COMMAND_LINE_OFFSET, auto_boot);
 
 ? ? ? ?printf("Loading %czImage at address 0x%08x (%ld bytes)\n",
- ? ? ? ? ? ? ?big_image ? 'b' : ' ', (u32)load_address, kernel_size);
+ ? ? ? ? ? ? ?big_image ? 'b' : ' ', (u32)*load_address, kernel_size);
 
-
- ? ? ? memmove(load_address, image + setup_size, kernel_size);
+ ? ? ? memmove(*load_address, image + setup_size, kernel_size);
 

? ? ? ?/* ready for booting */
? ? ? ?return setup_base;
?}

arch/x86/lib/zimage.c +1 -1

-void boot_zimage(void *setup_base)
+void boot_zimage(void *setup_base, void *load_address)

?{

arch/x86/lib/zimage.c +17 -0

+#if defined CONFIG_ZBOOT_32
+ ? ? ? /*
+ ? ? ? ?* Set %ebx, %ebp, and %edi to 0, %esi to point to the boot_params
+ ? ? ? ?* structure, and then jump to the kernel. We assume that %cs is
+ ? ? ? ?* 0x10, 4GB flat, and read/execute, and the data segments are 0x18,
+ ? ? ? ?* 4GB flat, and read/write. U-boot is setting them up that way for
+ ? ? ? ?* itself in arch/i386/cpu/cpu.c.
+ ? ? ? ?*/
+ ? ? ? __asm__ __volatile__ (
+ ? ? ? "movl $0, %%ebp ? ? ? ? \n"
+ ? ? ? "cli ? ? ? ? ? ? ? ? ? ?\n"
+ ? ? ? "jmp %[kernel_entry] ? ?\n"
+ ? ? ? :: [kernel_entry]"r"(load_address),
+ ? ? ? ? ?[boot_params] "S"(setup_base),
+ ? ? ? ? ?"b"(0), "D"(0)
+ ? ? ? );
+#else

? ? ? ?struct pt_regs regs;

? ? ? ?memset(&regs, 0, sizeof(struct pt_regs));

arch/x86/lib/zimage.c +2 -0

@@ -258,12 +282,14 @@ void boot_zimage(void *setup_base)
 ? ? ? ?regs.eflags = 0;
 ? ? ? ?enter_realmode(((u32)setup_base + SETUP_START_OFFSET) >> 4, 0,
 ? ? ? ? ? ? ? ? ? ? ? &regs, &regs);
+#endif
 ?}
 
 ?int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
 ?{
 ? ? ? ?void *base_ptr;
 ? ? ? ?void *bzImage_addr = NULL;
+ ? ? ? void *load_address;
 ? ? ? ?char *s;
 ? ? ? ?ulong bzImage_size = 0;
 

@@ -287,7 +313,8 @@ int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
 ? ? ? ? ? ? ? ?bzImage_size = simple_strtoul(argv[2], NULL, 16);
 

? ? ? ?/* Lets look for */
- ? ? ? base_ptr = load_zimage(bzImage_addr, bzImage_size, 0, 0, 0);
+ ? ? ? base_ptr = load_zimage(bzImage_addr, bzImage_size, 0, 0, 0,
+ ? ? ? ? ? ? ? &load_address);

? ? ? ?if (!base_ptr) {
? ? ? ? ? ? ? ?printf("## Kernel loading failed ...\n");

arch/x86/lib/zimage.c +0 -0

@@ -299,7 +326,7 @@ int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])

? ? ? ? ? ? ? ?/* we assume that the kernel is in place */ ? ? ? ? ? ? ? ?printf("\nStarting kernel ...\n\n");

- ? ? ? ? ? ? ? boot_zimage(base_ptr);
+ ? ? ? ? ? ? ? boot_zimage(base_ptr, load_address); ? ? ? ? ? ? ? ?/* does not return */
? ? ? ?}

--
1.7.3.1

Hi Gabe,

Thanks, I've been itching for this :)

Quoted 1 line · Gabe Black

This change conditionally modifies the zboot command so that it can use

the

Quoted 9 lines

32 bit boot protocol. This is necessary because the 16 bit realmode entry point assumes that it can call BIOS services which neither coreboot nor u-boot provide.

Signed-off-by Gabe Black <[email protected]>

---
 arch/x86/include/asm/zimage.h |    4 +-
 arch/x86/lib/bootm.c          |    6 +++-
 arch/x86/lib/zimage.c         |   49

+++++++++++++++++++++++++++++++---------

Review

Quoted 3 lines

 3 files changed, 44 insertions(+), 15 deletions(-)

(quoted diff) +0 -0

b/arch/x86/include/asm/zimage.h

arch/x86/lib/bootm.c int do_bootm_linux(int flag, int argc, char * const

Quoted 19 lines

index 1a77e00..8ee6a74 100644

arch/x86/include/asm/zimage.h +2 -2

@@ -46,8 +46,8 @@
 
 void *load_zimage(char *image, unsigned long kernel_size,
                 unsigned long initrd_addr, unsigned long initrd_size,
-                 int auto_boot);
+                 int auto_boot, void **load_address);
 
-void boot_zimage(void *setup_base);
+void boot_zimage(void *setup_base, void *load_address);
 
 #endif

arch/x86/lib/bootm.c +0 -0

index bac7b4f..0905809 100644
@@ -38,6 +38,7 @@ int do_bootm_linux(int flag, int argc, char * const

argv[],

arch/x86/lib/bootm.c int do_bootm_linux(int flag, int argc, char * const

Quoted 8 lines

arch/x86/lib/bootm.c +1 -0

       void            *base_ptr = NULL;
       ulong           os_data, os_len;
       image_header_t  *hdr;
+       void            *load_address;
 
 #if defined(CONFIG_FIT)
       const void      *data;

@@ -75,7 +76,8 @@ int do_bootm_linux(int flag, int argc, char * const

argv[],

arch/x86/lib/bootm.c int do_bootm_linux(int flag, int argc, char * const argv[],

Quoted 4 lines

arch/x86/lib/bootm.c +0 -1

 #ifdef CONFIG_CMD_ZBOOT
       base_ptr = load_zimage((void *)os_data, os_len,
-                       images->rd_start, images->rd_end -

images->rd_start, 0);

arch/x86/lib/bootm.c int do_bootm_linux(int flag, int argc, char * const · line 78

Quoted 1 line

arch/x86/lib/bootm.c +1 -0

+                       images->rd_start, images->rd_end -

images->rd_start,

arch/x86/lib/bootm.c int do_bootm_linux(int flag, int argc, char * const

Quoted 5 lines

arch/x86/lib/bootm.c +1 -0

+                       0, &load_address);
 #endif
 
       if (NULL == base_ptr) {

@@ -92,7 +94,7 @@ int do_bootm_linux(int flag, int argc, char * const

argv[],

arch/x86/lib/zimage.c static void build_command_line(char *command_line,

Quoted 13 lines

arch/x86/lib/bootm.c +1 -1

       /* we assume that the kernel is in place */
       printf("\nStarting kernel ...\n\n");
 
-       boot_zimage(base_ptr);
+       boot_zimage(base_ptr, load_address);
       /* does not return */
 
 error:

arch/x86/lib/zimage.c +0 -0

index 3b33486..1003929 100644
@@ -83,13 +83,12 @@ static void build_command_line(char *command_line,

int auto_boot)

arch/x86/lib/zimage.c void *load_zimage(char *image, unsigned long

Quoted 15 lines

arch/x86/lib/zimage.c +1 -2

 void *load_zimage(char *image, unsigned long kernel_size,
                 unsigned long initrd_addr, unsigned long initrd_size,
-                 int auto_boot)
+                 int auto_boot, void **load_address)
 {
       struct boot_params *setup_base;
       int setup_size;
       int bootproto;
       int big_image;
-       void *load_address;
 
       struct boot_params *params = (struct boot_params *)image;
       struct setup_header *hdr = &params->hdr;

@@ -136,14 +135,23 @@ void *load_zimage(char *image, unsigned long

kernel_size,

Quoted 6 lines

arch/x86/lib/zimage.c +1 -1

       /* Determine load address */
       if (big_image)
-               load_address = (void *)BZIMAGE_LOAD_ADDR;
+               *load_address = (void *)BZIMAGE_LOAD_ADDR;
       else

arch/x86/lib/zimage.c void *load_zimage(char *image, unsigned long kernel_size, · line 148

Quoted 10 lines

arch/x86/lib/zimage.c +8 -1

-               load_address = (void *)ZIMAGE_LOAD_ADDR;
+               *load_address = (void *)ZIMAGE_LOAD_ADDR;
+
+#if defined CONFIG_ZBOOT_32
+       printf("Building boot_params at 0x%8.8lx\n", (ulong)setup_base);
+       memset(setup_base, 0, sizeof(*setup_base));
+       setup_base->hdr = params->hdr;
 
+       setup_base->e820_entries = install_e820_map(
+               ARRAY_SIZE(setup_base->e820_map), setup_base->e820_map);

Where is install_e820_map() defined?

arch/x86/lib/zimage.c void *load_zimage(char *image, unsigned long

Quoted 10 lines

arch/x86/lib/zimage.c +2 -0

+#else
       /* load setup */
       printf("Moving Real-Mode Code to 0x%8.8lx (%d bytes)\n",
              (ulong)setup_base, setup_size);
       memmove(setup_base, image, setup_size);
+#endif
 
       printf("Using boot protocol version %x.%02x\n",
              (bootproto & 0xff00) >> 8, bootproto & 0xff);

@@ -182,7 +190,7 @@ void *load_zimage(char *image, unsigned long

kernel_size,

arch/x86/lib/zimage.c void *load_zimage(char *image, unsigned long

Quoted 9 lines

arch/x86/lib/zimage.c +1 -1

               if (hdr->setup_sects >= 15) {
                       printf("Linux kernel version %s\n",
-                              (char *)setup_base +
+                              (char *)params +
                              hdr->kernel_version + 0x200);
               } else {
                       printf("Setup Sectors < 15 - "

@@ -237,17 +245,33 @@ void *load_zimage(char *image, unsigned long

kernel_size,

arch/x86/lib/zimage.c void *load_zimage(char *image, unsigned long · line 245

Quoted 1 line

arch/x86/lib/zimage.c +0 -0

       build_command_line((char *)setup_base + COMMAND_LINE_OFFSET,

auto_boot);

Quoted 9 lines

arch/x86/lib/zimage.c +2 -3

       printf("Loading %czImage at address 0x%08x (%ld bytes)\n",
-              big_image ? 'b' : ' ', (u32)load_address, kernel_size);
+              big_image ? 'b' : ' ', (u32)*load_address, kernel_size);
 
-
-       memmove(load_address, image + setup_size, kernel_size);
+       memmove(*load_address, image + setup_size, kernel_size);
 

arch/x86/lib/zimage.c void *load_zimage(char *image, unsigned long kernel_size,

Quoted 10 lines

arch/x86/lib/zimage.c +4 -1

       /* ready for booting */
       return setup_base;
 }
 
-void boot_zimage(void *setup_base)
+void boot_zimage(void *setup_base, void *load_address)
 {
+#if defined CONFIG_ZBOOT_32
+       /*
+        * Set %ebx, %ebp, and %edi to 0, %esi to point to the

boot_params

arch/x86/lib/zimage.c void *load_zimage(char *image, unsigned long · line 261

Quoted 2 lines

arch/x86/lib/zimage.c +2 -0

+        * structure, and then jump to the kernel. We assume that %cs is
+        * 0x10, 4GB flat, and read/execute, and the data segments are

0x18,

arch/x86/lib/zimage.c void *load_zimage(char *image, unsigned long · line 262

Quoted 1 line

arch/x86/lib/zimage.c +1 -0

+        * 4GB flat, and read/write. U-boot is setting them up that way

for

arch/x86/lib/zimage.c int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc,

Quoted 30 lines

arch/x86/lib/zimage.c +13 -0

+        * itself in arch/i386/cpu/cpu.c.
+        */
+       __asm__ __volatile__ (
+       "movl $0, %%ebp         \n"
+       "cli                    \n"
+       "jmp %[kernel_entry]    \n"
+       :: [kernel_entry]"r"(load_address),
+          [boot_params] "S"(setup_base),
+          "b"(0), "D"(0)
+       );
+#else
       struct pt_regs regs;
 
       memset(&regs, 0, sizeof(struct pt_regs));

@@ -258,12 +282,14 @@ void boot_zimage(void *setup_base)
       regs.eflags = 0;
       enter_realmode(((u32)setup_base + SETUP_START_OFFSET) >> 4, 0,
                      &regs, &regs);
+#endif
 }
 
 int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
 {
       void *base_ptr;
       void *bzImage_addr = NULL;
+       void *load_address;
       char *s;
       ulong bzImage_size = 0;
 

@@ -287,7 +313,8 @@ int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc,

char *const argv[])

arch/x86/lib/zimage.c int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc,

Quoted 10 lines

arch/x86/lib/zimage.c +2 -1

               bzImage_size = simple_strtoul(argv[2], NULL, 16);
 
       /* Lets look for */
-       base_ptr = load_zimage(bzImage_addr, bzImage_size, 0, 0, 0);
+       base_ptr = load_zimage(bzImage_addr, bzImage_size, 0, 0, 0,
+               &load_address);
 
       if (!base_ptr) {
               printf("## Kernel loading failed ...\n");

@@ -299,7 +326,7 @@ int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc,

char *const argv[])

Quoted 11 lines

arch/x86/lib/zimage.c +1 -2

               /* we assume that the kernel is in place */
               printf("\nStarting kernel ...\n\n");
 
-               boot_zimage(base_ptr);
+               boot_zimage(base_ptr, load_address);
               /* does not return */
       }
 
--

1.7.3.1

Regards,

Graeme

Hmm, that's in an intervening patch. I didn't think that one was necessary but apparently it is. I'll add that to the series and send this out again.

Hi Gabe,

Quoted 1 line · Gabe Black

Hmm, that's in an intervening patch. I didn't think that one was

necessary

Quoted 1 line

but apparently it is. I'll add that to the series and send this out

again.

That would be nice ;)

P.S. Please stop top-quoting...

Regards,

Graeme

Quoted 14 lines · Graeme Russ

Hi Gabe,

Quoted 4 lines · Gabe Black

Hmm, that's in an intervening patch. I didn't think that one was necessary
but apparently it is. I'll add that to the series and send this out again.

That would be nice ;)

P.S. Please stop top-quoting...

Quoted 3 lines

Regards,

Graeme

Actually that patch depends on another one too. Since those don't really go with these, I'll just send them out separately and they'll need to be applied first.

Hi Gabe,

Quoted 3 lines · Gabe Black

On Tue, Nov 29, 2011 at 7:39 PM, Graeme Russ <[email protected]>

Quoted 12 lines · wrote:

Quoted 12 lines

Hi Gabe,

Quoted 4 lines · Gabe Black

Hmm, that's in an intervening patch. I didn't think that one was necessary
but apparently it is. I'll add that to the series and send this out again.

That would be nice ;)

Quoted 8 lines

Quoted 5 lines

P.S. Please stop top-quoting...

Regards,

Graeme

Actually that patch depends on another one too. Since those don't really

go

Quoted 2 lines

with these, I'll just send them out separately and they'll need to be applied first.

Sounds good me

Regards,

Graeme

These two patches add support for the 32 bit Linux boot protocol to the zboot command.

Hi Gabe,

Quoted 2 lines · Gabe Black

These two patches add support for the 32 bit Linux boot protocol to the zboot command.

Going by our previous offline correspondence, I assume this approach still uses the bzImage's decompression stub?

Also, as I discussion offline previously, I'm going through the boot_params with a fine-tooth comb to get a complete picture of what the Linux kernel actually requires to be filled out in the boot_params structure - I expect this will result in a 'built_boot_params()' function which is called by zboot and bootm - possibly with some weak stubs to helper functions

Regards,

Graeme

Quoted 20 lines · Graeme Russ

Hi Gabe,

Quoted 2 lines · Gabe Black

These two patches add support for the 32 bit Linux boot protocol to the zboot command.

Going by our previous offline correspondence, I assume this approach still uses the bzImage's decompression stub?

Also, as I discussion offline previously, I'm going through the boot_params
with a fine-tooth comb to get a complete picture of what the Linux kernel actually requires to be filled out in the boot_params structure - I expect this will result in a 'built_boot_params()' function which is called by zboot and bootm - possibly with some weak stubs to helper functions

Regards,

Quoted 1 line

Graeme

Yes, this supports the 32 bit protocol which includes the decompression stub. I don't think a build_boot_params function which actually builds the bootstub would work for a number of reasons. First, that's not how the boot protocol works. The kernel provides information there that u-boot needs to

read, and u-boot shouldn't just make it up. An example of this is what boot protocol is expected. Second, you might find all the things a particular

version of the kernel wants right now, but that could easy change at any time and break booting. Third, the boot_params structure isn't compressed

(because otherwise the bootloader couldn't fill it out) and building our own wouldn't serve any purpose.

If you mean consolidating the existing boot_params code so that both zboot and bootm can use it, that seems reasonable. I'd point out, though, that filling out the table takes a trivial amount of time, so trying to cut corners and not fill it out completely would not only be dangerous, it would very likely not be worth the effort.

On Tue, Nov 29, 2011 at 7:48 PM, Graeme Russ <[email protected] <mailto:[email protected]>> wrote:

Hi Gabe,

On Wed, Nov 30, 2011 at 2:11 PM, Gabe Black <[email protected] <mailto:[email protected]>> wrote:
> These two patches add support for the 32 bit Linux boot protocol to the > zboot command.

Going by our previous offline correspondence, I assume this approach still uses the bzImage's decompression stub?

Also, as I discussion offline previously, I'm going through the boot_params with a fine-tooth comb to get a complete picture of what the Linux kernel actually requires to be filled out in the boot_params structure - I expect this will result in a 'built_boot_params()' function which is called by zboot and bootm - possibly with some weak stubs to helper functions

Regards,

Graeme

Yes, this supports the 32 bit protocol which includes the decompression stub. I don't think a build_boot_params function which actually builds the bootstub would work for a number of reasons. First, that's not how the boot protocol works. The kernel provides information there that u-boot needs to read, and u-boot shouldn't just make it up. An example of this is what boot protocol is expected. Second, you might find all the things a particular version of the kernel wants right now, but that could easy change at any time and break booting. Third, the boot_params structure isn't compressed (because otherwise the bootloader couldn't fill it out) and building our own wouldn't serve any purpose.

If you mean consolidating the existing boot_params code so that both zboot and bootm can use it, that seems reasonable. I'd point out, though, that filling out the table takes a trivial amount of time, so trying to cut corners and not fill it out completely would not only be dangerous, it would very likely not be worth the effort.

Hi Gabe,

Quoted 10 lines · Gabe Black

On Tue, Nov 29, 2011 at 7:48 PM, Graeme Russ <[email protected] <mailto:[email protected]>> wrote:

Hi Gabe,

On Wed, Nov 30, 2011 at 2:11 PM, Gabe Black <[email protected] <mailto:[email protected]>> wrote:
> These two patches add support for the 32 bit Linux boot protocol

to the

Quoted 3 lines

Quoted 1 line

zboot command.

Going by our previous offline correspondence, I assume this approach

still

Quoted 3 lines

uses the bzImage's decompression stub?

Also, as I discussion offline previously, I'm going through the

boot_params

Quoted 1 line

with a fine-tooth comb to get a complete picture of what the Linux

kernel

Quoted 1 line

actually requires to be filled out in the boot_params structure - I

expect

Quoted 1 line

this will result in a 'built_boot_params()' function which is called

by

Quoted 9 lines

zboot and bootm - possibly with some weak stubs to helper functions

Regards,

Graeme

Yes, this supports the 32 bit protocol which includes the decompression stub. I don't think a build_boot_params function which actually builds

the

Quoted 1 line

bootstub would work for a number of reasons. First, that's not how the

boot

Quoted 1 line

protocol works. The kernel provides information there that u-boot needs

to

Quoted 1 line

read, and u-boot shouldn't just make it up. An example of this is what

boot

Quoted 7 lines

protocol is expected. Second, you might find all the things a particular version of the kernel wants right now, but that could easy change at any time and break booting. Third, the boot_params structure isn't compressed (because otherwise the bootloader couldn't fill it out) and building our own wouldn't serve any purpose.

If you mean consolidating the existing boot_params code so that both

zboot

Quoted 4 lines

and bootm can use it, that seems reasonable. I'd point out, though, that filling out the table takes a trivial amount of time, so trying to cut corners and not fill it out completely would not only be dangerous, it would very likely not be worth the effort.

I've been playing around tonight and have managed to embed a gzip'd vmlinux and raw header (stripped from the associated bzImage) into my U-Boot image but I end up getting the same results - No RAM :(

So proof of concept is good

Regards

Graeme

Quoted 68 lines · Graeme Russ

Hi Gabe,

Quoted 48 lines · Gabe Black

On Tue, Nov 29, 2011 at 7:48 PM, Graeme Russ <[email protected] <mailto:[email protected]>> wrote:

? ? Hi Gabe,

? ? On Wed, Nov 30, 2011 at 2:11 PM, Gabe Black <[email protected] ? ? <mailto:[email protected]>> wrote:
? ? > These two patches add support for the 32 bit Linux boot protocol to the
? ? > zboot command.

? ? Going by our previous offline correspondence, I assume this approach still
? ? uses the bzImage's decompression stub?

? ? Also, as I discussion offline previously, I'm going through the boot_params
? ? with a fine-tooth comb to get a complete picture of what the Linux kernel
? ? actually requires to be filled out in the boot_params structure - I expect
? ? this will result in a 'built_boot_params()' function which is called by
? ? zboot and bootm - possibly with some weak stubs to helper functions

? ? Regards,

? ? Graeme

Yes, this supports the 32 bit protocol which includes the decompression stub. I don't think a build_boot_params function which actually builds the
bootstub would work for a number of reasons. First, that's not how the boot
protocol works. The kernel provides information there that u-boot needs to
read, and u-boot shouldn't just make it up. An example of this is what boot
protocol is expected. Second, you might find all the things a particular version of the kernel wants right now, but that could easy change at any time and break booting. Third, the boot_params structure isn't compressed
(because otherwise the bootloader couldn't fill it out) and building our own wouldn't serve any purpose.

Quoted 6 lines

If you mean consolidating the existing boot_params code so that both zboot
and bootm can use it, that seems reasonable. I'd point out, though, that filling out the table takes a trivial amount of time, so trying to cut corners and not fill it out completely would not only be dangerous, it would very likely not be worth the effort.

I've been playing around tonight and have managed to embed a gzip'd vmlinux
and raw header (stripped from the associated bzImage) into my U-Boot image but I end up getting the same results - No RAM :(

So proof of concept is good

Regards

Quoted 1 line

Graeme

You have to make sure you're using the 32 bit protocol. The 16 bit protocol should still work and is the default, but then the kernel tries to use other means to figure out what memory looks like. To use the 32 bit protocol, you need to define?CONFIG_ZBOOT_32.