* bzImage 2.12
@ 2013-01-27 19:02 H. Peter Anvin
2013-01-27 19:10 ` David Woodhouse
0 siblings, 1 reply; 12+ messages in thread
From: H. Peter Anvin @ 2013-01-27 19:02 UTC (permalink / raw)
To: Yinghai Lu, David Woodhouse
Cc: Linux Kernel Mailing List, Matt Fleming, Ingo Molnar,
Thomas Gleixner, Gokul Caushik, Josh Triplett, Joe Millenbach
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
Hi guys,
This is what I would like to do for bzImage 2.12. This is *different*
than either one of you have, but it should be a unification of both...
please let me know if you have any objections as soon as possible.
This is intentionally a protocol only patch, which may be possible to
push into 3.8 as an urgent patch. David, if I understand our
discussions right it might be better to not export XLF_EFI_HANDOFF_32 at
this time?
Please comment as soon as possible.
Thanks,
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
[-- Attachment #2: 0001-x86-boot-Define-the-2.12-bzImage-boot-protocol.patch --]
[-- Type: text/x-patch, Size: 9070 bytes --]
>From 05e7535e2c26b97380319c37c1290883b553e35d Mon Sep 17 00:00:00 2001
From: "H. Peter Anvin" <hpa@linux.intel.com>
Date: Sun, 27 Jan 2013 10:43:28 -0800
Subject: [PATCH] x86, boot: Define the 2.12 bzImage boot protocol
Define the 2.12 bzImage boot protocol: add xloadflags and additional
fields to allow the command line, initramfs and struct boot_params to
live above the 4 GiB mark.
The xloadflags now communicates if this is a 64-bit kernel with the
legacy 64-bit entry point and which of the EFI handover entry points
are supported.
Avoid adding new read flags to loadflags because of claimed
bootloaders testing the whole byte for == 1 to determine bzImageness
at least until the issue can be researched further.
This is based on patches by Yinghai Lu and David Woodhouse.
Originally-by: Yinghai Lu <yinghai@kernel.org>
Originally-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/1359058816-7615-26-git-send-email-yinghai@kernel.org
Cc: Rob Landley <rob@landley.net>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Gokul Caushik <caushik1@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Joe Millenbach <jmillenbach@gmail.com>
---
Documentation/x86/boot.txt | 27 ++++++++++++++++++++++++++-
Documentation/x86/zero-page.txt | 4 ++++
| 27 ++++++++++++++++++++++++---
arch/x86/boot/setup.ld | 2 +-
arch/x86/include/uapi/asm/bootparam.h | 27 ++++++++++++++++++++++++---
5 files changed, 79 insertions(+), 8 deletions(-)
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index 406d82d..e28f2f7 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -57,6 +57,10 @@ Protocol 2.10: (Kernel 2.6.31) Added a protocol for relaxed alignment
Protocol 2.11: (Kernel 3.6) Added a field for offset of EFI handover
protocol entry point.
+Protocol 2.12: (Kernel 3.9) Added the xloadflags field and extension fields
+ to struct boot_params for for loading bzImage and ramdisk
+ above 4G in 64bit.
+
**** MEMORY LAYOUT
The traditional memory map for the kernel loader, used for Image or
@@ -182,7 +186,7 @@ Offset Proto Name Meaning
0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel
0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not
0235/1 2.10+ min_alignment Minimum alignment, as a power of two
-0236/2 N/A pad3 Unused
+0236/2 2.12+ xloadflags Boot protocol option flags
0238/4 2.06+ cmdline_size Maximum size of the kernel command line
023C/4 2.07+ hardware_subarch Hardware subarchitecture
0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data
@@ -582,6 +586,27 @@ Protocol: 2.10+
misaligned kernel. Therefore, a loader should typically try each
power-of-two alignment from kernel_alignment down to this alignment.
+Field name: xloadflags
+Type: read
+Offset/size: 0x236/2
+Protocol: 2.12+
+
+ This field is a bitmask.
+
+ Bit 0 (read): XLF_KERNEL_64
+ - If 1, this kernel has the legacy 64-bit entry point at 0x200.
+
+ Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G
+ - If 1, kernel/boot_params/cmdline/ramdisk can be above 4G.
+
+ Bit 2 (read): XLF_EFI_HANDOFF_32
+ - If 1, the kernel supports the 32-bit EFI handoff entry point
+ given at handover_offset.
+
+ Bit 3 (read): XLF_EFI_HANDOFF_64
+ - If 1, the kernel supports the 32-bit EFI handoff entry point
+ given at handover_offset + 0x200.
+
Field name: cmdline_size
Type: read
Offset/size: 0x238/4
diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index cf5437d..199f453 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -19,6 +19,9 @@ Offset Proto Name Meaning
090/010 ALL hd1_info hd1 disk parameter, OBSOLETE!!
0A0/010 ALL sys_desc_table System description table (struct sys_desc_table)
0B0/010 ALL olpc_ofw_header OLPC's OpenFirmware CIF and friends
+0C0/004 ALL ext_ramdisk_image ramdisk_image high 32bits
+0C4/004 ALL ext_ramdisk_size ramdisk_size high 32bits
+0C8/004 ALL ext_cmd_line_ptr cmd_line_ptr high 32bits
140/080 ALL edid_info Video mode setup (struct edid_info)
1C0/020 ALL efi_info EFI 32 information (struct efi_info)
1E0/004 ALL alk_mem_k Alternative mem check, in KB
@@ -27,6 +30,7 @@ Offset Proto Name Meaning
1E9/001 ALL eddbuf_entries Number of entries in eddbuf (below)
1EA/001 ALL edd_mbr_sig_buf_entries Number of entries in edd_mbr_sig_buffer
(below)
+1EF/001 ALL sentinel Used to detect broken bootloaders
290/040 ALL edd_mbr_sig_buffer EDD MBR signatures
2D0/A00 ALL e820_map E820 memory map table
(array of struct e820entry)
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 8c132a6..40cef3d 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -255,6 +255,9 @@ section_table:
# header, from the old boot sector.
.section ".header", "a"
+ .globl sentinel
+sentinel: .byte 0xff, 0xff /* Used to detect broken loaders */
+
.globl hdr
hdr:
setup_sects: .byte 0 /* Filled in by build.c */
@@ -279,7 +282,7 @@ _start:
# Part 2 of the header, from the old setup.S
.ascii "HdrS" # header signature
- .word 0x020b # header version number (>= 0x0105)
+ .word 0x020c # header version number (>= 0x0105)
# or else old loadlin-1.5 will fail)
.globl realmode_swtch
realmode_swtch: .word 0, 0 # default_switch, SETUPSEG
@@ -369,7 +372,20 @@ relocatable_kernel: .byte 1
relocatable_kernel: .byte 0
#endif
min_alignment: .byte MIN_KERNEL_ALIGN_LG2 # minimum alignment
-pad3: .word 0
+
+xloadflags:
+xloadflags_val = 0
+#ifdef CONFIG_X86_64
+xloadflags_val = xloadflags_val | XLF_KERNEL_64
+#endif
+#ifdef CONFIG_EFI_STUB
+# ifdef CONFIG_X86_64
+xloadflags_val = xloadflags_val | XLF_EFI_HANDOFF_64
+# else
+xloadflags_val = xloadflags_val | XLF_EFI_HANDOFF_32
+# endif
+#endif
+ .word xloadflags_val
cmdline_size: .long COMMAND_LINE_SIZE-1 #length of the command line,
#added with boot protocol
@@ -397,8 +413,13 @@ pref_address: .quad LOAD_PHYSICAL_ADDR # preferred load addr
#define INIT_SIZE VO_INIT_SIZE
#endif
init_size: .long INIT_SIZE # kernel initialization size
-handover_offset: .long 0x30 # offset to the handover
+handover_offset:
+#ifdef CONFIG_EFI_STUB
+ .long 0x30 # offset to the handover
# protocol entry point
+#else
+ .long 0
+#endif
# End of setup header #####################################################
diff --git a/arch/x86/boot/setup.ld b/arch/x86/boot/setup.ld
index 03c0683..96a6c75 100644
--- a/arch/x86/boot/setup.ld
+++ b/arch/x86/boot/setup.ld
@@ -13,7 +13,7 @@ SECTIONS
.bstext : { *(.bstext) }
.bsdata : { *(.bsdata) }
- . = 497;
+ . = 495;
.header : { *(.header) }
.entrytext : { *(.entrytext) }
.inittext : { *(.inittext) }
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 92862cd..00d282e 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -58,7 +58,12 @@ struct setup_header {
__u32 initrd_addr_max;
__u32 kernel_alignment;
__u8 relocatable_kernel;
- __u8 _pad2[3];
+ __u8 min_alignment;
+ __u16 xloadflags;
+#define XLF_KERNEL_64 (1<<0)
+#define XLF_CAN_BE_LOADED_ABOVE_4G (1<<1)
+#define XLF_EFI_HANDOFF_32 (1<<2)
+#define XLF_EFI_HANDOFF_64 (1<<3)
__u32 cmdline_size;
__u32 hardware_subarch;
__u64 hardware_subarch_data;
@@ -106,7 +111,10 @@ struct boot_params {
__u8 hd1_info[16]; /* obsolete! */ /* 0x090 */
struct sys_desc_table sys_desc_table; /* 0x0a0 */
struct olpc_ofw_header olpc_ofw_header; /* 0x0b0 */
- __u8 _pad4[128]; /* 0x0c0 */
+ __u32 ext_ramdisk_image; /* 0x0c0 */
+ __u32 ext_ramdisk_size; /* 0x0c4 */
+ __u32 ext_cmd_line_ptr; /* 0x0c8 */
+ __u8 _pad4[116]; /* 0x0cc */
struct edid_info edid_info; /* 0x140 */
struct efi_info efi_info; /* 0x1c0 */
__u32 alt_mem_k; /* 0x1e0 */
@@ -115,7 +123,20 @@ struct boot_params {
__u8 eddbuf_entries; /* 0x1e9 */
__u8 edd_mbr_sig_buf_entries; /* 0x1ea */
__u8 kbd_status; /* 0x1eb */
- __u8 _pad6[5]; /* 0x1ec */
+ __u8 _pad5[3]; /* 0x1ec */
+ /*
+ * The sentinel is set to a nonzero value (0xff) in header.S.
+ *
+ * A bootloader is supposed to only take setup_header and put
+ * it into a clean boot_params buffer. If it turns out that
+ * it is clumsy or too generous with the buffer, it most
+ * probably will pick up the sentinel variable too. The fact
+ * that this variable then is still 0xff will let kernel
+ * know that some variables in boot_params are invalid and
+ * kernel should zero out certain portions of boot_params.
+ */
+ __u8 sentinel; /* 0x1ef */
+ __u8 _pad6[1]; /* 0x1f0 */
struct setup_header hdr; /* setup header */ /* 0x1f1 */
__u8 _pad7[0x290-0x1f1-sizeof(struct setup_header)];
__u32 edd_mbr_sig_buffer[EDD_MBR_SIG_MAX]; /* 0x290 */
--
1.7.11.7
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: bzImage 2.12
2013-01-27 19:02 bzImage 2.12 H. Peter Anvin
@ 2013-01-27 19:10 ` David Woodhouse
2013-01-27 19:19 ` H. Peter Anvin
0 siblings, 1 reply; 12+ messages in thread
From: David Woodhouse @ 2013-01-27 19:10 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Yinghai Lu, Linux Kernel Mailing List, Matt Fleming, Ingo Molnar,
Thomas Gleixner, Gokul Caushik, Josh Triplett, Joe Millenbach
[-- Attachment #1: Type: text/plain, Size: 837 bytes --]
On Sun, 2013-01-27 at 11:02 -0800, H. Peter Anvin wrote:
> This is intentionally a protocol only patch, which may be possible to
> push into 3.8 as an urgent patch. David, if I understand our
> discussions right it might be better to not export XLF_EFI_HANDOFF_32
> at this time?
That won't stop broken bootloaders from jumping to $handover_offset
anyway. Anyone who was daft enough to implement EFI boot stub in their
bootloader *despite* its obvious brokenness, rather than insisting on
fixing it before it could be considered usable, will still be jumping
into hyperspace. I have little sympathy for them, but I'm told we need
to care.
It'd probably be better to just mark CONFIG_EFI_STUB as 'depends on
BROKEN' for 32-bit.
Or, and perhaps this is heresy, merge the patches which bloody fix it?
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bzImage 2.12
2013-01-27 19:10 ` David Woodhouse
@ 2013-01-27 19:19 ` H. Peter Anvin
2013-01-27 19:25 ` Matt Fleming
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: H. Peter Anvin @ 2013-01-27 19:19 UTC (permalink / raw)
To: David Woodhouse
Cc: Yinghai Lu, Linux Kernel Mailing List, Matt Fleming, Ingo Molnar,
Thomas Gleixner, Gokul Caushik, Josh Triplett, Joe Millenbach
[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]
On 01/27/2013 11:10 AM, David Woodhouse wrote:
> On Sun, 2013-01-27 at 11:02 -0800, H. Peter Anvin wrote:
>> This is intentionally a protocol only patch, which may be possible to
>> push into 3.8 as an urgent patch. David, if I understand our
>> discussions right it might be better to not export XLF_EFI_HANDOFF_32
>> at this time?
>
> That won't stop broken bootloaders from jumping to $handover_offset
> anyway. Anyone who was daft enough to implement EFI boot stub in their
> bootloader *despite* its obvious brokenness, rather than insisting on
> fixing it before it could be considered usable, will still be jumping
> into hyperspace. I have little sympathy for them, but I'm told we need
> to care.
At the moment I'm concerned with a new updated bootloader, which knows
the 2.12 protocol, encountering an old kernel.
> It'd probably be better to just mark CONFIG_EFI_STUB as 'depends on
> BROKEN' for 32-bit.
>
> Or, and perhaps this is heresy, merge the patches which bloody fix it?
I think we can probably do that, since it doesn't affect anything
non-broken at this point. I'm sorting out what can be done for 3.8 vs
3.9 at this point.
Anyway, as you can tell I'm spending this weekend working for a reason.
It turns out the patch I sent out doesn't actually build. Here is an
updated patch. Can I get your ack for this so I can do the appropriate
hacks to your and Yinghai's patchsets?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
[-- Attachment #2: 0001-x86-boot-Define-the-2.12-bzImage-boot-protocol.patch --]
[-- Type: text/x-patch, Size: 9132 bytes --]
>From fb28b02a097389b937c5ed5c74a7b811a10a6615 Mon Sep 17 00:00:00 2001
From: "H. Peter Anvin" <hpa@linux.intel.com>
Date: Sun, 27 Jan 2013 10:43:28 -0800
Subject: [PATCH] x86, boot: Define the 2.12 bzImage boot protocol
Define the 2.12 bzImage boot protocol: add xloadflags and additional
fields to allow the command line, initramfs and struct boot_params to
live above the 4 GiB mark.
The xloadflags now communicates if this is a 64-bit kernel with the
legacy 64-bit entry point and which of the EFI handover entry points
are supported.
Avoid adding new read flags to loadflags because of claimed
bootloaders testing the whole byte for == 1 to determine bzImageness
at least until the issue can be researched further.
This is based on patches by Yinghai Lu and David Woodhouse.
Originally-by: Yinghai Lu <yinghai@kernel.org>
Originally-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/1359058816-7615-26-git-send-email-yinghai@kernel.org
Cc: Rob Landley <rob@landley.net>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Gokul Caushik <caushik1@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Joe Millenbach <jmillenbach@gmail.com>
---
Documentation/x86/boot.txt | 27 ++++++++++++++++++++++++++-
Documentation/x86/zero-page.txt | 4 ++++
| 30 +++++++++++++++++++++++++++---
arch/x86/boot/setup.ld | 2 +-
arch/x86/include/uapi/asm/bootparam.h | 27 ++++++++++++++++++++++++---
5 files changed, 82 insertions(+), 8 deletions(-)
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index 406d82d..86bd3e9 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -57,6 +57,10 @@ Protocol 2.10: (Kernel 2.6.31) Added a protocol for relaxed alignment
Protocol 2.11: (Kernel 3.6) Added a field for offset of EFI handover
protocol entry point.
+Protocol 2.12: (Kernel 3.9) Added the xloadflags field and extension fields
+ to struct boot_params for for loading bzImage and ramdisk
+ above 4G in 64bit.
+
**** MEMORY LAYOUT
The traditional memory map for the kernel loader, used for Image or
@@ -182,7 +186,7 @@ Offset Proto Name Meaning
0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel
0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not
0235/1 2.10+ min_alignment Minimum alignment, as a power of two
-0236/2 N/A pad3 Unused
+0236/2 2.12+ xloadflags Boot protocol option flags
0238/4 2.06+ cmdline_size Maximum size of the kernel command line
023C/4 2.07+ hardware_subarch Hardware subarchitecture
0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data
@@ -582,6 +586,27 @@ Protocol: 2.10+
misaligned kernel. Therefore, a loader should typically try each
power-of-two alignment from kernel_alignment down to this alignment.
+Field name: xloadflags
+Type: read
+Offset/size: 0x236/2
+Protocol: 2.12+
+
+ This field is a bitmask.
+
+ Bit 0 (read): XLF_KERNEL_64
+ - If 1, this kernel has the legacy 64-bit entry point at 0x200.
+
+ Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G
+ - If 1, kernel/boot_params/cmdline/ramdisk can be above 4G.
+
+ Bit 2 (read): XLF_EFI_HANDOVER_32
+ - If 1, the kernel supports the 32-bit EFI handoff entry point
+ given at handover_offset.
+
+ Bit 3 (read): XLF_EFI_HANDOVER_64
+ - If 1, the kernel supports the 32-bit EFI handoff entry point
+ given at handover_offset + 0x200.
+
Field name: cmdline_size
Type: read
Offset/size: 0x238/4
diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index cf5437d..199f453 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -19,6 +19,9 @@ Offset Proto Name Meaning
090/010 ALL hd1_info hd1 disk parameter, OBSOLETE!!
0A0/010 ALL sys_desc_table System description table (struct sys_desc_table)
0B0/010 ALL olpc_ofw_header OLPC's OpenFirmware CIF and friends
+0C0/004 ALL ext_ramdisk_image ramdisk_image high 32bits
+0C4/004 ALL ext_ramdisk_size ramdisk_size high 32bits
+0C8/004 ALL ext_cmd_line_ptr cmd_line_ptr high 32bits
140/080 ALL edid_info Video mode setup (struct edid_info)
1C0/020 ALL efi_info EFI 32 information (struct efi_info)
1E0/004 ALL alk_mem_k Alternative mem check, in KB
@@ -27,6 +30,7 @@ Offset Proto Name Meaning
1E9/001 ALL eddbuf_entries Number of entries in eddbuf (below)
1EA/001 ALL edd_mbr_sig_buf_entries Number of entries in edd_mbr_sig_buffer
(below)
+1EF/001 ALL sentinel Used to detect broken bootloaders
290/040 ALL edd_mbr_sig_buffer EDD MBR signatures
2D0/A00 ALL e820_map E820 memory map table
(array of struct e820entry)
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 8c132a6..65a8778 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -255,6 +255,9 @@ section_table:
# header, from the old boot sector.
.section ".header", "a"
+ .globl sentinel
+sentinel: .byte 0xff, 0xff /* Used to detect broken loaders */
+
.globl hdr
hdr:
setup_sects: .byte 0 /* Filled in by build.c */
@@ -279,7 +282,7 @@ _start:
# Part 2 of the header, from the old setup.S
.ascii "HdrS" # header signature
- .word 0x020b # header version number (>= 0x0105)
+ .word 0x020c # header version number (>= 0x0105)
# or else old loadlin-1.5 will fail)
.globl realmode_swtch
realmode_swtch: .word 0, 0 # default_switch, SETUPSEG
@@ -369,7 +372,23 @@ relocatable_kernel: .byte 1
relocatable_kernel: .byte 0
#endif
min_alignment: .byte MIN_KERNEL_ALIGN_LG2 # minimum alignment
-pad3: .word 0
+
+xloadflags:
+#ifdef CONFIG_X86_64
+# define XLF0 XLF_KERNEL_64 /* 64-bit kernel */
+#else
+# define XLF0 0
+#endif
+#ifdef CONFIG_EFI_STUB
+# ifdef CONFIG_X86_64
+# define XLF23 XLF_EFI_HANDOVER_64 /* 64-bit EFI handover ok */
+# else
+# define XLF23 XLF_EFI_HANDOVER_32 /* 32-bit EFI handover ok */
+# endif
+#else
+# define XLF23 0
+#endif
+ .word XLF0 | XLF23
cmdline_size: .long COMMAND_LINE_SIZE-1 #length of the command line,
#added with boot protocol
@@ -397,8 +416,13 @@ pref_address: .quad LOAD_PHYSICAL_ADDR # preferred load addr
#define INIT_SIZE VO_INIT_SIZE
#endif
init_size: .long INIT_SIZE # kernel initialization size
-handover_offset: .long 0x30 # offset to the handover
+handover_offset:
+#ifdef CONFIG_EFI_STUB
+ .long 0x30 # offset to the handover
# protocol entry point
+#else
+ .long 0
+#endif
# End of setup header #####################################################
diff --git a/arch/x86/boot/setup.ld b/arch/x86/boot/setup.ld
index 03c0683..96a6c75 100644
--- a/arch/x86/boot/setup.ld
+++ b/arch/x86/boot/setup.ld
@@ -13,7 +13,7 @@ SECTIONS
.bstext : { *(.bstext) }
.bsdata : { *(.bsdata) }
- . = 497;
+ . = 495;
.header : { *(.header) }
.entrytext : { *(.entrytext) }
.inittext : { *(.inittext) }
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 92862cd..1934b05 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -58,7 +58,12 @@ struct setup_header {
__u32 initrd_addr_max;
__u32 kernel_alignment;
__u8 relocatable_kernel;
- __u8 _pad2[3];
+ __u8 min_alignment;
+ __u16 xloadflags;
+#define XLF_KERNEL_64 (1<<0)
+#define XLF_CAN_BE_LOADED_ABOVE_4G (1<<1)
+#define XLF_EFI_HANDOVER_32 (1<<2)
+#define XLF_EFI_HANDOVER_64 (1<<3)
__u32 cmdline_size;
__u32 hardware_subarch;
__u64 hardware_subarch_data;
@@ -106,7 +111,10 @@ struct boot_params {
__u8 hd1_info[16]; /* obsolete! */ /* 0x090 */
struct sys_desc_table sys_desc_table; /* 0x0a0 */
struct olpc_ofw_header olpc_ofw_header; /* 0x0b0 */
- __u8 _pad4[128]; /* 0x0c0 */
+ __u32 ext_ramdisk_image; /* 0x0c0 */
+ __u32 ext_ramdisk_size; /* 0x0c4 */
+ __u32 ext_cmd_line_ptr; /* 0x0c8 */
+ __u8 _pad4[116]; /* 0x0cc */
struct edid_info edid_info; /* 0x140 */
struct efi_info efi_info; /* 0x1c0 */
__u32 alt_mem_k; /* 0x1e0 */
@@ -115,7 +123,20 @@ struct boot_params {
__u8 eddbuf_entries; /* 0x1e9 */
__u8 edd_mbr_sig_buf_entries; /* 0x1ea */
__u8 kbd_status; /* 0x1eb */
- __u8 _pad6[5]; /* 0x1ec */
+ __u8 _pad5[3]; /* 0x1ec */
+ /*
+ * The sentinel is set to a nonzero value (0xff) in header.S.
+ *
+ * A bootloader is supposed to only take setup_header and put
+ * it into a clean boot_params buffer. If it turns out that
+ * it is clumsy or too generous with the buffer, it most
+ * probably will pick up the sentinel variable too. The fact
+ * that this variable then is still 0xff will let kernel
+ * know that some variables in boot_params are invalid and
+ * kernel should zero out certain portions of boot_params.
+ */
+ __u8 sentinel; /* 0x1ef */
+ __u8 _pad6[1]; /* 0x1f0 */
struct setup_header hdr; /* setup header */ /* 0x1f1 */
__u8 _pad7[0x290-0x1f1-sizeof(struct setup_header)];
__u32 edd_mbr_sig_buffer[EDD_MBR_SIG_MAX]; /* 0x290 */
--
1.7.11.7
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: bzImage 2.12
2013-01-27 19:19 ` H. Peter Anvin
@ 2013-01-27 19:25 ` Matt Fleming
2013-01-27 19:38 ` Yinghai Lu
2013-01-27 22:08 ` David Woodhouse
2 siblings, 0 replies; 12+ messages in thread
From: Matt Fleming @ 2013-01-27 19:25 UTC (permalink / raw)
To: H. Peter Anvin
Cc: David Woodhouse, Yinghai Lu, Linux Kernel Mailing List,
Ingo Molnar, Thomas Gleixner, Gokul Caushik, Josh Triplett,
Joe Millenbach
On Sun, 2013-01-27 at 11:19 -0800, H. Peter Anvin wrote:
> It turns out the patch I sent out doesn't actually build. Here is an
> updated patch. Can I get your ack for this so I can do the appropriate
> hacks to your and Yinghai's patchsets?
>
> -hpa
>
Acked-by: Matt Fleming <matt.fleming@intel.com>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bzImage 2.12
2013-01-27 19:19 ` H. Peter Anvin
2013-01-27 19:25 ` Matt Fleming
@ 2013-01-27 19:38 ` Yinghai Lu
2013-01-27 19:39 ` H. Peter Anvin
2013-01-27 22:08 ` David Woodhouse
2 siblings, 1 reply; 12+ messages in thread
From: Yinghai Lu @ 2013-01-27 19:38 UTC (permalink / raw)
To: H. Peter Anvin
Cc: David Woodhouse, Linux Kernel Mailing List, Matt Fleming,
Ingo Molnar, Thomas Gleixner, Gokul Caushik, Josh Triplett,
Joe Millenbach
On Sun, Jan 27, 2013 at 11:19 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> I think we can probably do that, since it doesn't affect anything non-broken
> at this point. I'm sorting out what can be done for 3.8 vs 3.9 at this
> point.
>
> Anyway, as you can tell I'm spending this weekend working for a reason.
>
> It turns out the patch I sent out doesn't actually build. Here is an
> updated patch. Can I get your ack for this so I can do the appropriate
> hacks to your and Yinghai's patchsets?
Acked-by: Yinghai Lu <yinghai@kernel.org>
Do you want to me to update my patchset on top it and resend?
or you are going to sort it out by you self?
Thanks
Yinghai
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bzImage 2.12
2013-01-27 19:38 ` Yinghai Lu
@ 2013-01-27 19:39 ` H. Peter Anvin
2013-01-28 2:14 ` Yinghai Lu
0 siblings, 1 reply; 12+ messages in thread
From: H. Peter Anvin @ 2013-01-27 19:39 UTC (permalink / raw)
To: Yinghai Lu
Cc: David Woodhouse, Linux Kernel Mailing List, Matt Fleming,
Ingo Molnar, Thomas Gleixner, Gokul Caushik, Josh Triplett,
Joe Millenbach
I'm planning to sort it out... I'll let you know if I run out of bandwidth.
Yinghai Lu <yinghai@kernel.org> wrote:
>On Sun, Jan 27, 2013 at 11:19 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> I think we can probably do that, since it doesn't affect anything
>non-broken
>> at this point. I'm sorting out what can be done for 3.8 vs 3.9 at
>this
>> point.
>>
>> Anyway, as you can tell I'm spending this weekend working for a
>reason.
>>
>> It turns out the patch I sent out doesn't actually build. Here is an
>> updated patch. Can I get your ack for this so I can do the
>appropriate
>> hacks to your and Yinghai's patchsets?
>
>Acked-by: Yinghai Lu <yinghai@kernel.org>
>
>Do you want to me to update my patchset on top it and resend?
>
>or you are going to sort it out by you self?
>
>Thanks
>
>Yinghai
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bzImage 2.12
2013-01-27 19:39 ` H. Peter Anvin
@ 2013-01-28 2:14 ` Yinghai Lu
2013-01-28 3:36 ` H. Peter Anvin
0 siblings, 1 reply; 12+ messages in thread
From: Yinghai Lu @ 2013-01-28 2:14 UTC (permalink / raw)
To: H. Peter Anvin
Cc: David Woodhouse, Linux Kernel Mailing List, Matt Fleming,
Ingo Molnar, Thomas Gleixner, Gokul Caushik, Josh Triplett,
Joe Millenbach
[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]
On Sun, Jan 27, 2013 at 11:39 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> I'm planning to sort it out... I'll let you know if I run out of bandwidth.
>
> Yinghai Lu <yinghai@kernel.org> wrote:
>
>>On Sun, Jan 27, 2013 at 11:19 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>>
>>> I think we can probably do that, since it doesn't affect anything
>>non-broken
>>> at this point. I'm sorting out what can be done for 3.8 vs 3.9 at
>>this
>>> point.
>>>
>>> Anyway, as you can tell I'm spending this weekend working for a
>>reason.
>>>
>>> It turns out the patch I sent out doesn't actually build. Here is an
>>> updated patch. Can I get your ack for this so I can do the
>>appropriate
>>> hacks to your and Yinghai's patchsets?
>>
>>Acked-by: Yinghai Lu <yinghai@kernel.org>
>>
>>Do you want to me to update my patchset on top it and resend?
>>
>>or you are going to sort it out by you self?
>>
To save your some time, please check attached patch.
It would take position of
https://patchwork.kernel.org/patch/2035731/
[25/35] x86, boot: Add fields to support load bzImage and ramdisk above 4G
Thanks
Yinghai
[-- Attachment #2: ext_ramdisk_image_on_top_of_hpa.patch --]
[-- Type: application/octet-stream, Size: 4706 bytes --]
Subject: [PATCH v5 10/11] x86, boot: enable support load bzImage and ramdisk above 4G
xloadflags bit1 is set if kernel is relocatable and 64bit.
bootloader will check if xloadflags bit1 is set to decicde if
it could load ramdisk and kernel high above 4G.
bootloader will fill value to ext_ramdisk_image/size for high 32bits
when it load ramdisk above 4G.
kernel use get_ramdisk_image/size to use ext_ramdisk_image/size to get
right positon for ramdisk.
sentinel is used so kernel could find out if ext_* and other fields have
valid values set in boot_params from bootloader.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Rob Landley <rob@landley.net>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Gokul Caushik <caushik1@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Joe Millenbach <jmillenbach@gmail.com>
---
arch/x86/boot/compressed/cmdline.c | 2 ++
arch/x86/boot/compressed/misc.c | 19 +++++++++++++++++++
| 10 +++++++++-
arch/x86/kernel/head64.c | 2 ++
arch/x86/kernel/setup.c | 4 ++++
5 files changed, 36 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/x86/boot/header.S
===================================================================
--- linux-2.6.orig/arch/x86/boot/header.S
+++ linux-2.6/arch/x86/boot/header.S
@@ -374,6 +374,14 @@ xloadflags:
#else
# define XLF0 0
#endif
+
+#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_X86_64)
+ /* kernel/boot_param/ramdisk could be loaded above 4g */
+# define XLF1 XLF_CAN_BE_LOADED_ABOVE_4G
+#else
+# define XLF1 0
+#endif
+
#ifdef CONFIG_EFI_STUB
# ifdef CONFIG_X86_64
# define XLF23 XLF_EFI_HANDOVER_64 /* 64-bit EFI handover ok */
@@ -383,7 +391,7 @@ xloadflags:
#else
# define XLF23 0
#endif
- .word XLF0 | XLF23
+ .word XLF0 | XLF1 | XLF23
cmdline_size: .long COMMAND_LINE_SIZE-1 #length of the command line,
#added with boot protocol
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -298,12 +298,16 @@ static u64 __init get_ramdisk_image(void
{
u64 ramdisk_image = boot_params.hdr.ramdisk_image;
+ ramdisk_image |= (u64)boot_params.ext_ramdisk_image << 32;
+
return ramdisk_image;
}
static u64 __init get_ramdisk_size(void)
{
u64 ramdisk_size = boot_params.hdr.ramdisk_size;
+ ramdisk_size |= (u64)boot_params.ext_ramdisk_size << 32;
+
return ramdisk_size;
}
Index: linux-2.6/arch/x86/boot/compressed/cmdline.c
===================================================================
--- linux-2.6.orig/arch/x86/boot/compressed/cmdline.c
+++ linux-2.6/arch/x86/boot/compressed/cmdline.c
@@ -17,6 +17,8 @@ static unsigned long get_cmd_line_ptr(vo
{
unsigned long cmd_line_ptr = real_mode->hdr.cmd_line_ptr;
+ cmd_line_ptr |= (u64)real_mode->ext_cmd_line_ptr << 32;
+
return cmd_line_ptr;
}
int cmdline_find_option(const char *option, char *buffer, int bufsize)
Index: linux-2.6/arch/x86/kernel/head64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/head64.c
+++ linux-2.6/arch/x86/kernel/head64.c
@@ -115,6 +115,8 @@ static unsigned long get_cmd_line_ptr(vo
{
unsigned long cmd_line_ptr = boot_params.hdr.cmd_line_ptr;
+ cmd_line_ptr |= (u64)boot_params.ext_cmd_line_ptr << 32;
+
return cmd_line_ptr;
}
Index: linux-2.6/arch/x86/boot/compressed/misc.c
===================================================================
--- linux-2.6.orig/arch/x86/boot/compressed/misc.c
+++ linux-2.6/arch/x86/boot/compressed/misc.c
@@ -318,6 +318,23 @@ static void parse_elf(void *output)
free(phdrs);
}
+static void sanitize_real_mode(struct boot_params *real_mode)
+{
+ if (real_mode->sentinel) {
+ /*fields in boot_params are not valid, clear them */
+ memset(&real_mode->olpc_ofw_header, 0,
+ (char *)&real_mode->alt_mem_k -
+ (char *)&real_mode->olpc_ofw_header);
+ memset(&real_mode->_pad7[0], 0,
+ (char *)&real_mode->edd_mbr_sig_buffer[0] -
+ (char *)&real_mode->_pad7[0]);
+ memset(&real_mode->_pad8[0], 0,
+ (char *)&real_mode->eddbuf[0] -
+ (char *)&real_mode->_pad8[0]);
+ memset(&real_mode->_pad9[0], 0, sizeof(real_mode->_pad9));
+ }
+}
+
asmlinkage void decompress_kernel(void *rmode, memptr heap,
unsigned char *input_data,
unsigned long input_len,
@@ -325,6 +342,8 @@ asmlinkage void decompress_kernel(void *
{
real_mode = rmode;
+ sanitize_real_mode(real_mode);
+
if (real_mode->screen_info.orig_video_mode == 7) {
vidmem = (char *) 0xb0000;
vidport = 0x3b4;
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bzImage 2.12
2013-01-28 2:14 ` Yinghai Lu
@ 2013-01-28 3:36 ` H. Peter Anvin
2013-01-29 3:50 ` Yinghai Lu
0 siblings, 1 reply; 12+ messages in thread
From: H. Peter Anvin @ 2013-01-28 3:36 UTC (permalink / raw)
To: Yinghai Lu
Cc: David Woodhouse, Linux Kernel Mailing List, Matt Fleming,
Ingo Molnar, Thomas Gleixner, Gokul Caushik, Josh Triplett,
Joe Millenbach
Thanks.
Yinghai Lu <yinghai@kernel.org> wrote:
>On Sun, Jan 27, 2013 at 11:39 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>> I'm planning to sort it out... I'll let you know if I run out of
>bandwidth.
>>
>> Yinghai Lu <yinghai@kernel.org> wrote:
>>
>>>On Sun, Jan 27, 2013 at 11:19 AM, H. Peter Anvin <hpa@zytor.com>
>wrote:
>>>>
>>>> I think we can probably do that, since it doesn't affect anything
>>>non-broken
>>>> at this point. I'm sorting out what can be done for 3.8 vs 3.9 at
>>>this
>>>> point.
>>>>
>>>> Anyway, as you can tell I'm spending this weekend working for a
>>>reason.
>>>>
>>>> It turns out the patch I sent out doesn't actually build. Here is
>an
>>>> updated patch. Can I get your ack for this so I can do the
>>>appropriate
>>>> hacks to your and Yinghai's patchsets?
>>>
>>>Acked-by: Yinghai Lu <yinghai@kernel.org>
>>>
>>>Do you want to me to update my patchset on top it and resend?
>>>
>>>or you are going to sort it out by you self?
>>>
>
>To save your some time, please check attached patch.
>
>It would take position of
>
>https://patchwork.kernel.org/patch/2035731/
>
>[25/35] x86, boot: Add fields to support load bzImage and ramdisk above
>4G
>
>Thanks
>
>Yinghai
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bzImage 2.12
2013-01-28 3:36 ` H. Peter Anvin
@ 2013-01-29 3:50 ` Yinghai Lu
2013-01-29 4:22 ` Yinghai Lu
0 siblings, 1 reply; 12+ messages in thread
From: Yinghai Lu @ 2013-01-29 3:50 UTC (permalink / raw)
To: H. Peter Anvin
Cc: David Woodhouse, Linux Kernel Mailing List, Matt Fleming,
Ingo Molnar, Thomas Gleixner, Gokul Caushik, Josh Triplett,
Joe Millenbach
On Sun, Jan 27, 2013 at 7:36 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Thanks.
>
> Yinghai Lu <yinghai@kernel.org> wrote:
>
>>On Sun, Jan 27, 2013 at 11:39 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> I'm planning to sort it out... I'll let you know if I run out of
>>bandwidth.
>>>
>>> Yinghai Lu <yinghai@kernel.org> wrote:
>>>
>>>>On Sun, Jan 27, 2013 at 11:19 AM, H. Peter Anvin <hpa@zytor.com>
>>wrote:
>>>>>
>>>>> I think we can probably do that, since it doesn't affect anything
>>>>non-broken
>>>>> at this point. I'm sorting out what can be done for 3.8 vs 3.9 at
>>>>this
>>>>> point.
>>>>>
>>>>> Anyway, as you can tell I'm spending this weekend working for a
>>>>reason.
>>>>>
>>>>> It turns out the patch I sent out doesn't actually build. Here is
>>an
>>>>> updated patch. Can I get your ack for this so I can do the
>>>>appropriate
>>>>> hacks to your and Yinghai's patchsets?
>>>>
>>>>Acked-by: Yinghai Lu <yinghai@kernel.org>
>>>>
>>>>Do you want to me to update my patchset on top it and resend?
>>>>
>>>>or you are going to sort it out by you self?
>>>>
>>
>>To save your some time, please check attached patch.
>>
>>It would take position of
>>
>>https://patchwork.kernel.org/patch/2035731/
>>
>>[25/35] x86, boot: Add fields to support load bzImage and ramdisk above
>>4G
>>
Did you get chance to put them into for-x86-boot?
You need to skip the first two about memmap= exactmap and reserveram ...
Thanks
Yinghai
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bzImage 2.12
2013-01-29 3:50 ` Yinghai Lu
@ 2013-01-29 4:22 ` Yinghai Lu
2013-01-29 19:36 ` Yinghai Lu
0 siblings, 1 reply; 12+ messages in thread
From: Yinghai Lu @ 2013-01-29 4:22 UTC (permalink / raw)
To: H. Peter Anvin
Cc: David Woodhouse, Linux Kernel Mailing List, Matt Fleming,
Ingo Molnar, Thomas Gleixner, Gokul Caushik, Josh Triplett,
Joe Millenbach
On Mon, Jan 28, 2013 at 7:50 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Sun, Jan 27, 2013 at 7:36 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Did you get chance to put them into for-x86-boot?
>
> You need to skip the first two about memmap= exactmap and reserveram ...
>
put updated version in
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-x86-boot for-x86-boot-v7u4
and it is based on Linus tree + tip:x86/mm, tip:x86/mm2,
tip:x86/urgent, tip:x86/boot
Yinghai
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bzImage 2.12
2013-01-29 4:22 ` Yinghai Lu
@ 2013-01-29 19:36 ` Yinghai Lu
0 siblings, 0 replies; 12+ messages in thread
From: Yinghai Lu @ 2013-01-29 19:36 UTC (permalink / raw)
To: H. Peter Anvin
Cc: David Woodhouse, Linux Kernel Mailing List, Matt Fleming,
Ingo Molnar, Thomas Gleixner, Gokul Caushik, Josh Triplett,
Joe Millenbach
On Mon, Jan 28, 2013 at 8:22 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Mon, Jan 28, 2013 at 7:50 PM, Yinghai Lu <yinghai@kernel.org> wrote:
>> On Sun, Jan 27, 2013 at 7:36 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> Did you get chance to put them into for-x86-boot?
>>
>> You need to skip the first two about memmap= exactmap and reserveram ...
>>
>
please check
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-x86-boot for-x86-boot-v7u5
and it is based on Linus tree + tip:x86/mm2 + tip:x86/boot
Also put Konrad Ack into last swiotlb patch.
Thanks
Yinghai
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bzImage 2.12
2013-01-27 19:19 ` H. Peter Anvin
2013-01-27 19:25 ` Matt Fleming
2013-01-27 19:38 ` Yinghai Lu
@ 2013-01-27 22:08 ` David Woodhouse
2 siblings, 0 replies; 12+ messages in thread
From: David Woodhouse @ 2013-01-27 22:08 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Yinghai Lu, Linux Kernel Mailing List, Matt Fleming, Ingo Molnar,
Thomas Gleixner, Gokul Caushik, Josh Triplett, Joe Millenbach
[-- Attachment #1: Type: text/plain, Size: 588 bytes --]
On Sun, 2013-01-27 at 11:19 -0800, H. Peter Anvin wrote:
> It turns out the patch I sent out doesn't actually build. Here is an
> updated patch. Can I get your ack for this so I can do the
> appropriate hacks to your and Yinghai's patchsets?
The new flags are supposed to indicate that the EFI stub is present and
usable. So please do NOT add it for 32-bit unless you've also merged the
outstanding patches which actually fix it. Or at least marked EFI_STUB
as 'depends on BROKEN'.
Other than that,
Acked-by: David Woodhouse <David.Woodhouse@intel.com>
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-01-29 19:36 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-27 19:02 bzImage 2.12 H. Peter Anvin
2013-01-27 19:10 ` David Woodhouse
2013-01-27 19:19 ` H. Peter Anvin
2013-01-27 19:25 ` Matt Fleming
2013-01-27 19:38 ` Yinghai Lu
2013-01-27 19:39 ` H. Peter Anvin
2013-01-28 2:14 ` Yinghai Lu
2013-01-28 3:36 ` H. Peter Anvin
2013-01-29 3:50 ` Yinghai Lu
2013-01-29 4:22 ` Yinghai Lu
2013-01-29 19:36 ` Yinghai Lu
2013-01-27 22:08 ` David Woodhouse
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).