Commit 8ee2f2dfdbdfe1851fcc0191b2d4faa4c26a39fb

Authored by Yinghai Lu
Committed by H. Peter Anvin
1 parent ee92d81502

x86, boot: Update comments about entries for 64bit image

Now 64bit entry is fixed on 0x200, can not be changed anymore.

Update the comments to reflect that.

Also put info about it in boot.txt

-v2: fix some grammar error

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1359058816-7615-27-git-send-email-yinghai@kernel.org
Cc: Rob Landley <rob@landley.net>
Cc: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

Showing 2 changed files with 51 additions and 9 deletions Side-by-side Diff

Documentation/x86/boot.txt
... ... @@ -1054,6 +1054,44 @@
1054 1054 must be __BOOT_DS; interrupt must be disabled; %esi must hold the base
1055 1055 address of the struct boot_params; %ebp, %edi and %ebx must be zero.
1056 1056  
  1057 +**** 64-bit BOOT PROTOCOL
  1058 +
  1059 +For machine with 64bit cpus and 64bit kernel, we could use 64bit bootloader
  1060 +and we need a 64-bit boot protocol.
  1061 +
  1062 +In 64-bit boot protocol, the first step in loading a Linux kernel
  1063 +should be to setup the boot parameters (struct boot_params,
  1064 +traditionally known as "zero page"). The memory for struct boot_params
  1065 +could be allocated anywhere (even above 4G) and initialized to all zero.
  1066 +Then, the setup header at offset 0x01f1 of kernel image on should be
  1067 +loaded into struct boot_params and examined. The end of setup header
  1068 +can be calculated as follows:
  1069 +
  1070 + 0x0202 + byte value at offset 0x0201
  1071 +
  1072 +In addition to read/modify/write the setup header of the struct
  1073 +boot_params as that of 16-bit boot protocol, the boot loader should
  1074 +also fill the additional fields of the struct boot_params as described
  1075 +in zero-page.txt.
  1076 +
  1077 +After setting up the struct boot_params, the boot loader can load
  1078 +64-bit kernel in the same way as that of 16-bit boot protocol, but
  1079 +kernel could be loaded above 4G.
  1080 +
  1081 +In 64-bit boot protocol, the kernel is started by jumping to the
  1082 +64-bit kernel entry point, which is the start address of loaded
  1083 +64-bit kernel plus 0x200.
  1084 +
  1085 +At entry, the CPU must be in 64-bit mode with paging enabled.
  1086 +The range with setup_header.init_size from start address of loaded
  1087 +kernel and zero page and command line buffer get ident mapping;
  1088 +a GDT must be loaded with the descriptors for selectors
  1089 +__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
  1090 +segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
  1091 +must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
  1092 +must be __BOOT_DS; interrupt must be disabled; %rsi must hold the base
  1093 +address of the struct boot_params.
  1094 +
1057 1095 **** EFI HANDOVER PROTOCOL
1058 1096  
1059 1097 This protocol allows boot loaders to defer initialisation to the EFI
arch/x86/boot/compressed/head_64.S
... ... @@ -37,6 +37,12 @@
37 37 __HEAD
38 38 .code32
39 39 ENTRY(startup_32)
  40 + /*
  41 + * 32bit entry is 0 and it is ABI so immutable!
  42 + * If we come here directly from a bootloader,
  43 + * kernel(text+data+bss+brk) ramdisk, zero_page, command line
  44 + * all need to be under the 4G limit.
  45 + */
40 46 cld
41 47 /*
42 48 * Test KEEP_SEGMENTS flag to see if the bootloader is asking
43 49  
44 50  
... ... @@ -182,20 +188,18 @@
182 188 lret
183 189 ENDPROC(startup_32)
184 190  
185   - /*
186   - * Be careful here startup_64 needs to be at a predictable
187   - * address so I can export it in an ELF header. Bootloaders
188   - * should look at the ELF header to find this address, as
189   - * it may change in the future.
190   - */
191 191 .code64
192 192 .org 0x200
193 193 ENTRY(startup_64)
194 194 /*
  195 + * 64bit entry is 0x200 and it is ABI so immutable!
195 196 * We come here either from startup_32 or directly from a
196   - * 64bit bootloader. If we come here from a bootloader we depend on
197   - * an identity mapped page table being provied that maps our
198   - * entire text+data+bss and hopefully all of memory.
  197 + * 64bit bootloader.
  198 + * If we come here from a bootloader, kernel(text+data+bss+brk),
  199 + * ramdisk, zero_page, command line could be above 4G.
  200 + * We depend on an identity mapped page table being provided
  201 + * that maps our entire kernel(text+data+bss+brk), zero page
  202 + * and command line.
199 203 */
200 204 #ifdef CONFIG_EFI_STUB
201 205 /*