lkml.org 
[lkml]   [2012]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH v3 11/12] x86, boot: add fields to support load bzImage and ramdisk high
On 11/20/2012 11:16 PM, Yinghai Lu wrote:
>
> diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
> index 9efceff..a8263f7 100644
> --- a/Documentation/x86/boot.txt
> +++ b/Documentation/x86/boot.txt
> @@ -57,6 +57,9 @@ 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 three fields for loading bzImage and
> + ramdisk above 4G with 64bit.
> +
> **** MEMORY LAYOUT
>
> The traditional memory map for the kernel loader, used for Image or
> @@ -182,7 +185,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 protocal 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
> @@ -193,6 +196,9 @@ Offset Proto Name Meaning
> 0258/8 2.10+ pref_address Preferred loading address
> 0260/4 2.10+ init_size Linear memory required during initialization
> 0264/4 2.11+ handover_offset Offset of handover entry point
> +0268/4 2.12+ ext_ramdisk_image ramdisk_image 32 bits

"high 32 bits" presumably...

> +026C/4 2.12+ ext_ramdisk_size ramdisk_size high 32 bits
> +0270/4 2.12+ ext_cmd_line_ptr cmd_line_ptr high 32 bits

I'm looking at these three fields and I'm getting worried about space --
there are only two more word-sized fields possible in this structure.
Since these fields are not initialized (default to zero) and almost
certainly aren't useful for people entering via the 16-bit entry point I
think we should move them out of struct setup_header and into the
remainder of struct boot_param.
> diff --git a/arch/x86/boot/compressed/cmdline.c b/arch/x86/boot/compressed/cmdline.c
> index b4c913c..00678d3 100644
> --- a/arch/x86/boot/compressed/cmdline.c
> +++ b/arch/x86/boot/compressed/cmdline.c
> @@ -17,6 +17,9 @@ static unsigned long get_cmd_line_ptr(void)
> {
> unsigned long cmd_line_ptr = real_mode->hdr.cmd_line_ptr;
>
> + if (real_mode->hdr.version >= 0x020c)
> + cmd_line_ptr |= (u64)real_mode->hdr.ext_cmd_line_ptr << 32;
> +
> return cmd_line_ptr;
> }

No. hdr.version is information from the kernel to the bootloader; it is
meaningless to look at it inside the kernel.

Same in a bunch of other places.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.



\
 
 \ /
  Last update: 2012-11-21 19:01    [W:0.130 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site