2007-07-11 23:18:54 +04:00
/ *
* header. S
*
* Copyright ( C ) 1 9 9 1 , 1 9 9 2 L i n u s T o r v a l d s
*
* Based o n b o o t s e c t . S a n d s e t u p . S
* modified b y m o r e p e o p l e t h a n c a n b e c o u n t e d
*
* Rewritten a s a c o m m o n f i l e b y H . P e t e r A n v i n ( A p r 2 0 0 7 )
*
* BIG F A T N O T E : W e ' r e i n r e a l m o d e u s i n g 6 4 k s e g m e n t s . T h e r e f o r e s e g m e n t
* addresses m u s t b e m u l t i p l i e d b y 1 6 t o o b t a i n t h e i r r e s p e c t i v e l i n e a r
* addresses. T o a v o i d c o n f u s i o n , l i n e a r a d d r e s s e s a r e w r i t t e n u s i n g l e a d i n g
* hex w h i l e s e g m e n t a d d r e s s e s a r e w r i t t e n a s s e g m e n t : o f f s e t .
*
* /
# include < a s m / s e g m e n t . h >
2009-10-18 02:52:28 +04:00
# include < g e n e r a t e d / u t s r e l e a s e . h >
2007-07-11 23:18:54 +04:00
# include < a s m / b o o t . h >
# include < a s m / e 8 2 0 . h >
2009-02-13 22:14:01 +03:00
# include < a s m / p a g e _ t y p e s . h >
2007-07-11 23:18:54 +04:00
# include < a s m / s e t u p . h >
2013-01-27 22:43:28 +04:00
# include < a s m / b o o t p a r a m . h >
2007-07-11 23:18:54 +04:00
# include " b o o t . h "
2009-05-12 01:21:12 +04:00
# include " v o f f s e t . h "
# include " z o f f s e t . h "
2007-07-11 23:18:54 +04:00
BOOTSEG = 0 x07 C 0 / * o r i g i n a l a d d r e s s o f b o o t - s e c t o r * /
2009-03-11 20:55:33 +03:00
SYSSEG = 0 x10 0 0 / * h i s t o r i c a l l o a d a d d r e s s > > 4 * /
2007-07-11 23:18:54 +04:00
# ifndef S V G A _ M O D E
# define S V G A _ M O D E A S K _ V G A
# endif
# ifndef R O O T _ R D O N L Y
# define R O O T _ R D O N L Y 1
# endif
.code16
.section " .bstext " , " ax"
.global bootsect_start
bootsect_start :
x86, efi: EFI boot stub support
There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,
"The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well."
This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.
The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.
Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
v7:
- Fix checkpatch warnings.
v6:
- Try to allocate initrd memory just below hdr->inird_addr_max.
v5:
- load_options_size is UTF-16, which needs dividing by 2 to convert
to the corresponding ASCII size.
v4:
- Don't read more than image->load_options_size
v3:
- Fix following warnings when compiling CONFIG_EFI_STUB=n
arch/x86/boot/tools/build.c: In function ‘main’:
arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
- As reported by Matthew Garrett, some Apple machines have GOPs that
don't have hardware attached. We need to weed these out by
searching for ones that handle the PCIIO protocol.
- Don't allocate memory if no initrds are on cmdline
- Don't trust image->load_options_size
Maarten Lankhorst noted:
- Don't strip first argument when booted from efibootmgr
- Don't allocate too much memory for cmdline
- Don't update cmdline_size, the kernel considers it read-only
- Don't accept '\n' for initrd names
v2:
- File alignment was too large, was 8192 should be 512. Reported by
Maarten Lankhorst on LKML.
- Added UGA support for graphics
- Use VIDEO_TYPE_EFI instead of hard-coded number.
- Move linelength assignment until after we've assigned depth
- Dynamically fill out AddressOfEntryPoint in tools/build.c
- Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
- The bzImage may need to be relocated as it may have been loaded at
a high address address by the firmware. This was required to get my
macbook booting because the firmware loaded it at 0x7cxxxxxx, which
triggers this error in decompress_kernel(),
if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
error("Destination address too large");
Cc: Mike Waychison <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
# ifdef C O N F I G _ E F I _ S T U B
# " MZ" , M S - D O S h e a d e r
.byte 0x4d
.byte 0x5a
# endif
2007-07-11 23:18:54 +04:00
# Normalize t h e s t a r t a d d r e s s
ljmp $ B O O T S E G , $ s t a r t 2
start2 :
movw % c s , % a x
movw % a x , % d s
movw % a x , % e s
movw % a x , % s s
xorw % s p , % s p
sti
cld
movw $ b u g g e r _ o f f _ m s g , % s i
msg_loop :
lodsb
andb % a l , % a l
jz b s _ d i e
movb $ 0 x e , % a h
movw $ 7 , % b x
int $ 0 x10
jmp m s g _ l o o p
bs_die :
# Allow t h e u s e r t o p r e s s a k e y , t h e n r e b o o t
xorw % a x , % a x
int $ 0 x16
int $ 0 x19
# int 0 x19 s h o u l d n e v e r r e t u r n . I n c a s e i t d o e s a n y w a y ,
# invoke t h e B I O S r e s e t c o d e . . .
ljmp $ 0 x f00 0 ,$ 0 x f f f0
x86, efi: EFI boot stub support
There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,
"The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well."
This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.
The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.
Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
v7:
- Fix checkpatch warnings.
v6:
- Try to allocate initrd memory just below hdr->inird_addr_max.
v5:
- load_options_size is UTF-16, which needs dividing by 2 to convert
to the corresponding ASCII size.
v4:
- Don't read more than image->load_options_size
v3:
- Fix following warnings when compiling CONFIG_EFI_STUB=n
arch/x86/boot/tools/build.c: In function ‘main’:
arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
- As reported by Matthew Garrett, some Apple machines have GOPs that
don't have hardware attached. We need to weed these out by
searching for ones that handle the PCIIO protocol.
- Don't allocate memory if no initrds are on cmdline
- Don't trust image->load_options_size
Maarten Lankhorst noted:
- Don't strip first argument when booted from efibootmgr
- Don't allocate too much memory for cmdline
- Don't update cmdline_size, the kernel considers it read-only
- Don't accept '\n' for initrd names
v2:
- File alignment was too large, was 8192 should be 512. Reported by
Maarten Lankhorst on LKML.
- Added UGA support for graphics
- Use VIDEO_TYPE_EFI instead of hard-coded number.
- Move linelength assignment until after we've assigned depth
- Dynamically fill out AddressOfEntryPoint in tools/build.c
- Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
- The bzImage may need to be relocated as it may have been loaded at
a high address address by the firmware. This was required to get my
macbook booting because the firmware loaded it at 0x7cxxxxxx, which
triggers this error in decompress_kernel(),
if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
error("Destination address too large");
Cc: Mike Waychison <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
# ifdef C O N F I G _ E F I _ S T U B
.org 0x3c
#
# Offset t o t h e P E h e a d e r .
#
.long pe_header
# endif / * C O N F I G _ E F I _ S T U B * /
2007-07-11 23:18:54 +04:00
.section " .bsdata " , " a"
bugger_off_msg :
2012-06-07 20:05:21 +04:00
.ascii " Direct f l o p p y b o o t i s n o t s u p p o r t e d . "
.ascii " Use a b o o t l o a d e r p r o g r a m i n s t e a d . \ r \ n "
2007-07-11 23:18:54 +04:00
.ascii " \ n"
2012-06-07 20:05:21 +04:00
.ascii " Remove d i s k a n d p r e s s a n y k e y t o r e b o o t . . . \ r \ n "
2007-07-11 23:18:54 +04:00
.byte 0
x86, efi: EFI boot stub support
There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,
"The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well."
This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.
The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.
Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
v7:
- Fix checkpatch warnings.
v6:
- Try to allocate initrd memory just below hdr->inird_addr_max.
v5:
- load_options_size is UTF-16, which needs dividing by 2 to convert
to the corresponding ASCII size.
v4:
- Don't read more than image->load_options_size
v3:
- Fix following warnings when compiling CONFIG_EFI_STUB=n
arch/x86/boot/tools/build.c: In function ‘main’:
arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
- As reported by Matthew Garrett, some Apple machines have GOPs that
don't have hardware attached. We need to weed these out by
searching for ones that handle the PCIIO protocol.
- Don't allocate memory if no initrds are on cmdline
- Don't trust image->load_options_size
Maarten Lankhorst noted:
- Don't strip first argument when booted from efibootmgr
- Don't allocate too much memory for cmdline
- Don't update cmdline_size, the kernel considers it read-only
- Don't accept '\n' for initrd names
v2:
- File alignment was too large, was 8192 should be 512. Reported by
Maarten Lankhorst on LKML.
- Added UGA support for graphics
- Use VIDEO_TYPE_EFI instead of hard-coded number.
- Move linelength assignment until after we've assigned depth
- Dynamically fill out AddressOfEntryPoint in tools/build.c
- Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
- The bzImage may need to be relocated as it may have been loaded at
a high address address by the firmware. This was required to get my
macbook booting because the firmware loaded it at 0x7cxxxxxx, which
triggers this error in decompress_kernel(),
if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
error("Destination address too large");
Cc: Mike Waychison <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
# ifdef C O N F I G _ E F I _ S T U B
pe_header :
.ascii " PE"
.word 0
coff_header :
# ifdef C O N F I G _ X 8 6 _ 3 2
.word 0x14c # i3 8 6
# else
.word 0x8664 # x8 6 - 6 4
# endif
2012-06-07 20:05:21 +04:00
.word 3 # nr_ s e c t i o n s
x86, efi: EFI boot stub support
There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,
"The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well."
This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.
The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.
Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
v7:
- Fix checkpatch warnings.
v6:
- Try to allocate initrd memory just below hdr->inird_addr_max.
v5:
- load_options_size is UTF-16, which needs dividing by 2 to convert
to the corresponding ASCII size.
v4:
- Don't read more than image->load_options_size
v3:
- Fix following warnings when compiling CONFIG_EFI_STUB=n
arch/x86/boot/tools/build.c: In function ‘main’:
arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
- As reported by Matthew Garrett, some Apple machines have GOPs that
don't have hardware attached. We need to weed these out by
searching for ones that handle the PCIIO protocol.
- Don't allocate memory if no initrds are on cmdline
- Don't trust image->load_options_size
Maarten Lankhorst noted:
- Don't strip first argument when booted from efibootmgr
- Don't allocate too much memory for cmdline
- Don't update cmdline_size, the kernel considers it read-only
- Don't accept '\n' for initrd names
v2:
- File alignment was too large, was 8192 should be 512. Reported by
Maarten Lankhorst on LKML.
- Added UGA support for graphics
- Use VIDEO_TYPE_EFI instead of hard-coded number.
- Move linelength assignment until after we've assigned depth
- Dynamically fill out AddressOfEntryPoint in tools/build.c
- Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
- The bzImage may need to be relocated as it may have been loaded at
a high address address by the firmware. This was required to get my
macbook booting because the firmware loaded it at 0x7cxxxxxx, which
triggers this error in decompress_kernel(),
if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
error("Destination address too large");
Cc: Mike Waychison <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
.long 0 # TimeDateStamp
.long 0 # PointerToSymbolTable
.long 1 # NumberOfSymbols
.word section_table - optional_ h e a d e r # S i z e O f O p t i o n a l H e a d e r
# ifdef C O N F I G _ X 8 6 _ 3 2
.word 0x306 # Characteristics.
# IMAGE_ F I L E _ 3 2 B I T _ M A C H I N E |
# IMAGE_ F I L E _ D E B U G _ S T R I P P E D |
# IMAGE_ F I L E _ E X E C U T A B L E _ I M A G E |
# IMAGE_ F I L E _ L I N E _ N U M S _ S T R I P P E D
# else
.word 0x206 # Characteristics
# IMAGE_ F I L E _ D E B U G _ S T R I P P E D |
# IMAGE_ F I L E _ E X E C U T A B L E _ I M A G E |
# IMAGE_ F I L E _ L I N E _ N U M S _ S T R I P P E D
# endif
optional_header :
# ifdef C O N F I G _ X 8 6 _ 3 2
.word 0x10b # PE3 2 f o r m a t
# else
.word 0x20b # PE3 2 + f o r m a t
# endif
.byte 0x02 # MajorLinkerVersion
.byte 0x14 # MinorLinkerVersion
# Filled i n b y b u i l d . c
.long 0 # SizeOfCode
.long 0 # SizeOfInitializedData
.long 0 # SizeOfUninitializedData
# Filled i n b y b u i l d . c
.long 0x0000 # AddressOfEntryPoint
2012-03-23 20:35:05 +04:00
.long 0x0200 # BaseOfCode
x86, efi: EFI boot stub support
There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,
"The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well."
This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.
The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.
Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
v7:
- Fix checkpatch warnings.
v6:
- Try to allocate initrd memory just below hdr->inird_addr_max.
v5:
- load_options_size is UTF-16, which needs dividing by 2 to convert
to the corresponding ASCII size.
v4:
- Don't read more than image->load_options_size
v3:
- Fix following warnings when compiling CONFIG_EFI_STUB=n
arch/x86/boot/tools/build.c: In function ‘main’:
arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
- As reported by Matthew Garrett, some Apple machines have GOPs that
don't have hardware attached. We need to weed these out by
searching for ones that handle the PCIIO protocol.
- Don't allocate memory if no initrds are on cmdline
- Don't trust image->load_options_size
Maarten Lankhorst noted:
- Don't strip first argument when booted from efibootmgr
- Don't allocate too much memory for cmdline
- Don't update cmdline_size, the kernel considers it read-only
- Don't accept '\n' for initrd names
v2:
- File alignment was too large, was 8192 should be 512. Reported by
Maarten Lankhorst on LKML.
- Added UGA support for graphics
- Use VIDEO_TYPE_EFI instead of hard-coded number.
- Move linelength assignment until after we've assigned depth
- Dynamically fill out AddressOfEntryPoint in tools/build.c
- Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
- The bzImage may need to be relocated as it may have been loaded at
a high address address by the firmware. This was required to get my
macbook booting because the firmware loaded it at 0x7cxxxxxx, which
triggers this error in decompress_kernel(),
if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
error("Destination address too large");
Cc: Mike Waychison <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
# ifdef C O N F I G _ X 8 6 _ 3 2
.long 0 # data
# endif
extra_header_fields :
# ifdef C O N F I G _ X 8 6 _ 3 2
.long 0 # ImageBase
# else
.quad 0 # ImageBase
# endif
2012-06-07 20:05:21 +04:00
.long 0x20 # SectionAlignment
.long 0x20 # FileAlignment
x86, efi: EFI boot stub support
There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,
"The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well."
This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.
The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.
Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
v7:
- Fix checkpatch warnings.
v6:
- Try to allocate initrd memory just below hdr->inird_addr_max.
v5:
- load_options_size is UTF-16, which needs dividing by 2 to convert
to the corresponding ASCII size.
v4:
- Don't read more than image->load_options_size
v3:
- Fix following warnings when compiling CONFIG_EFI_STUB=n
arch/x86/boot/tools/build.c: In function ‘main’:
arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
- As reported by Matthew Garrett, some Apple machines have GOPs that
don't have hardware attached. We need to weed these out by
searching for ones that handle the PCIIO protocol.
- Don't allocate memory if no initrds are on cmdline
- Don't trust image->load_options_size
Maarten Lankhorst noted:
- Don't strip first argument when booted from efibootmgr
- Don't allocate too much memory for cmdline
- Don't update cmdline_size, the kernel considers it read-only
- Don't accept '\n' for initrd names
v2:
- File alignment was too large, was 8192 should be 512. Reported by
Maarten Lankhorst on LKML.
- Added UGA support for graphics
- Use VIDEO_TYPE_EFI instead of hard-coded number.
- Move linelength assignment until after we've assigned depth
- Dynamically fill out AddressOfEntryPoint in tools/build.c
- Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
- The bzImage may need to be relocated as it may have been loaded at
a high address address by the firmware. This was required to get my
macbook booting because the firmware loaded it at 0x7cxxxxxx, which
triggers this error in decompress_kernel(),
if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
error("Destination address too large");
Cc: Mike Waychison <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
.word 0 # MajorOperatingSystemVersion
.word 0 # MinorOperatingSystemVersion
.word 0 # MajorImageVersion
.word 0 # MinorImageVersion
.word 0 # MajorSubsystemVersion
.word 0 # MinorSubsystemVersion
.long 0 # Win3 2 V e r s i o n V a l u e
#
# The s i z e o f t h e b z I m a g e i s w r i t t e n i n t o o l s / b u i l d . c
#
.long 0 # SizeOfImage
.long 0x200 # SizeOfHeaders
.long 0 # CheckSum
.word 0xa # Subsystem ( E F I a p p l i c a t i o n )
.word 0 # DllCharacteristics
# ifdef C O N F I G _ X 8 6 _ 3 2
.long 0 # SizeOfStackReserve
.long 0 # SizeOfStackCommit
.long 0 # SizeOfHeapReserve
.long 0 # SizeOfHeapCommit
# else
.quad 0 # SizeOfStackReserve
.quad 0 # SizeOfStackCommit
.quad 0 # SizeOfHeapReserve
.quad 0 # SizeOfHeapCommit
# endif
.long 0 # LoaderFlags
2012-03-23 20:35:06 +04:00
.long 0x6 # NumberOfRvaAndSizes
x86, efi: EFI boot stub support
There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,
"The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well."
This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.
The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.
Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
v7:
- Fix checkpatch warnings.
v6:
- Try to allocate initrd memory just below hdr->inird_addr_max.
v5:
- load_options_size is UTF-16, which needs dividing by 2 to convert
to the corresponding ASCII size.
v4:
- Don't read more than image->load_options_size
v3:
- Fix following warnings when compiling CONFIG_EFI_STUB=n
arch/x86/boot/tools/build.c: In function ‘main’:
arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
- As reported by Matthew Garrett, some Apple machines have GOPs that
don't have hardware attached. We need to weed these out by
searching for ones that handle the PCIIO protocol.
- Don't allocate memory if no initrds are on cmdline
- Don't trust image->load_options_size
Maarten Lankhorst noted:
- Don't strip first argument when booted from efibootmgr
- Don't allocate too much memory for cmdline
- Don't update cmdline_size, the kernel considers it read-only
- Don't accept '\n' for initrd names
v2:
- File alignment was too large, was 8192 should be 512. Reported by
Maarten Lankhorst on LKML.
- Added UGA support for graphics
- Use VIDEO_TYPE_EFI instead of hard-coded number.
- Move linelength assignment until after we've assigned depth
- Dynamically fill out AddressOfEntryPoint in tools/build.c
- Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
- The bzImage may need to be relocated as it may have been loaded at
a high address address by the firmware. This was required to get my
macbook booting because the firmware loaded it at 0x7cxxxxxx, which
triggers this error in decompress_kernel(),
if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
error("Destination address too large");
Cc: Mike Waychison <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
.quad 0 # ExportTable
.quad 0 # ImportTable
.quad 0 # ResourceTable
.quad 0 # ExceptionTable
.quad 0 # CertificationTable
.quad 0 # BaseRelocationTable
# Section t a b l e
section_table :
2012-06-07 20:05:21 +04:00
#
# The o f f s e t & s i z e f i e l d s a r e f i l l e d i n b y b u i l d . c .
#
.ascii " .setup "
x86, efi: EFI boot stub support
There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,
"The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well."
This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.
The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.
Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
v7:
- Fix checkpatch warnings.
v6:
- Try to allocate initrd memory just below hdr->inird_addr_max.
v5:
- load_options_size is UTF-16, which needs dividing by 2 to convert
to the corresponding ASCII size.
v4:
- Don't read more than image->load_options_size
v3:
- Fix following warnings when compiling CONFIG_EFI_STUB=n
arch/x86/boot/tools/build.c: In function ‘main’:
arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
- As reported by Matthew Garrett, some Apple machines have GOPs that
don't have hardware attached. We need to weed these out by
searching for ones that handle the PCIIO protocol.
- Don't allocate memory if no initrds are on cmdline
- Don't trust image->load_options_size
Maarten Lankhorst noted:
- Don't strip first argument when booted from efibootmgr
- Don't allocate too much memory for cmdline
- Don't update cmdline_size, the kernel considers it read-only
- Don't accept '\n' for initrd names
v2:
- File alignment was too large, was 8192 should be 512. Reported by
Maarten Lankhorst on LKML.
- Added UGA support for graphics
- Use VIDEO_TYPE_EFI instead of hard-coded number.
- Move linelength assignment until after we've assigned depth
- Dynamically fill out AddressOfEntryPoint in tools/build.c
- Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
- The bzImage may need to be relocated as it may have been loaded at
a high address address by the firmware. This was required to get my
macbook booting because the firmware loaded it at 0x7cxxxxxx, which
triggers this error in decompress_kernel(),
if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
error("Destination address too large");
Cc: Mike Waychison <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
.byte 0
.byte 0
.long 0
.long 0x0 # startup_ { 3 2 ,6 4 }
.long 0 # Size o f i n i t i a l i z e d d a t a
# on d i s k
.long 0x0 # startup_ { 3 2 ,6 4 }
.long 0 # PointerToRelocations
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
.long 0x60500020 # Characteristics ( s e c t i o n f l a g s )
#
# The E F I a p p l i c a t i o n l o a d e r r e q u i r e s a r e l o c a t i o n s e c t i o n
2012-06-07 20:05:21 +04:00
# because E F I a p p l i c a t i o n s m u s t b e r e l o c a t a b l e . T h e . r e l o c
# offset & s i z e f i e l d s a r e f i l l e d i n b y b u i l d . c .
x86, efi: EFI boot stub support
There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,
"The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well."
This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.
The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.
Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
v7:
- Fix checkpatch warnings.
v6:
- Try to allocate initrd memory just below hdr->inird_addr_max.
v5:
- load_options_size is UTF-16, which needs dividing by 2 to convert
to the corresponding ASCII size.
v4:
- Don't read more than image->load_options_size
v3:
- Fix following warnings when compiling CONFIG_EFI_STUB=n
arch/x86/boot/tools/build.c: In function ‘main’:
arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
- As reported by Matthew Garrett, some Apple machines have GOPs that
don't have hardware attached. We need to weed these out by
searching for ones that handle the PCIIO protocol.
- Don't allocate memory if no initrds are on cmdline
- Don't trust image->load_options_size
Maarten Lankhorst noted:
- Don't strip first argument when booted from efibootmgr
- Don't allocate too much memory for cmdline
- Don't update cmdline_size, the kernel considers it read-only
- Don't accept '\n' for initrd names
v2:
- File alignment was too large, was 8192 should be 512. Reported by
Maarten Lankhorst on LKML.
- Added UGA support for graphics
- Use VIDEO_TYPE_EFI instead of hard-coded number.
- Move linelength assignment until after we've assigned depth
- Dynamically fill out AddressOfEntryPoint in tools/build.c
- Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
- The bzImage may need to be relocated as it may have been loaded at
a high address address by the firmware. This was required to get my
macbook booting because the firmware loaded it at 0x7cxxxxxx, which
triggers this error in decompress_kernel(),
if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
error("Destination address too large");
Cc: Mike Waychison <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
#
.ascii " .reloc "
.byte 0
.byte 0
2012-03-23 20:35:04 +04:00
.long 0
.long 0
.long 0 # SizeOfRawData
.long 0 # PointerToRawData
x86, efi: EFI boot stub support
There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,
"The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well."
This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.
The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.
Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
v7:
- Fix checkpatch warnings.
v6:
- Try to allocate initrd memory just below hdr->inird_addr_max.
v5:
- load_options_size is UTF-16, which needs dividing by 2 to convert
to the corresponding ASCII size.
v4:
- Don't read more than image->load_options_size
v3:
- Fix following warnings when compiling CONFIG_EFI_STUB=n
arch/x86/boot/tools/build.c: In function ‘main’:
arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
- As reported by Matthew Garrett, some Apple machines have GOPs that
don't have hardware attached. We need to weed these out by
searching for ones that handle the PCIIO protocol.
- Don't allocate memory if no initrds are on cmdline
- Don't trust image->load_options_size
Maarten Lankhorst noted:
- Don't strip first argument when booted from efibootmgr
- Don't allocate too much memory for cmdline
- Don't update cmdline_size, the kernel considers it read-only
- Don't accept '\n' for initrd names
v2:
- File alignment was too large, was 8192 should be 512. Reported by
Maarten Lankhorst on LKML.
- Added UGA support for graphics
- Use VIDEO_TYPE_EFI instead of hard-coded number.
- Move linelength assignment until after we've assigned depth
- Dynamically fill out AddressOfEntryPoint in tools/build.c
- Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
- The bzImage may need to be relocated as it may have been loaded at
a high address address by the firmware. This was required to get my
macbook booting because the firmware loaded it at 0x7cxxxxxx, which
triggers this error in decompress_kernel(),
if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
error("Destination address too large");
Cc: Mike Waychison <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
.long 0 # PointerToRelocations
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
.long 0x42100040 # Characteristics ( s e c t i o n f l a g s )
2012-06-07 20:05:21 +04:00
#
# The o f f s e t & s i z e f i e l d s a r e f i l l e d i n b y b u i l d . c .
#
.ascii " .text "
.byte 0
.byte 0
.byte 0
.long 0
.long 0x0 # startup_ { 3 2 ,6 4 }
.long 0 # Size o f i n i t i a l i z e d d a t a
# on d i s k
.long 0x0 # startup_ { 3 2 ,6 4 }
.long 0 # PointerToRelocations
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
.long 0x60500020 # Characteristics ( s e c t i o n f l a g s )
x86, efi: EFI boot stub support
There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,
"The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well."
This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.
The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.
Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
v7:
- Fix checkpatch warnings.
v6:
- Try to allocate initrd memory just below hdr->inird_addr_max.
v5:
- load_options_size is UTF-16, which needs dividing by 2 to convert
to the corresponding ASCII size.
v4:
- Don't read more than image->load_options_size
v3:
- Fix following warnings when compiling CONFIG_EFI_STUB=n
arch/x86/boot/tools/build.c: In function ‘main’:
arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
- As reported by Matthew Garrett, some Apple machines have GOPs that
don't have hardware attached. We need to weed these out by
searching for ones that handle the PCIIO protocol.
- Don't allocate memory if no initrds are on cmdline
- Don't trust image->load_options_size
Maarten Lankhorst noted:
- Don't strip first argument when booted from efibootmgr
- Don't allocate too much memory for cmdline
- Don't update cmdline_size, the kernel considers it read-only
- Don't accept '\n' for initrd names
v2:
- File alignment was too large, was 8192 should be 512. Reported by
Maarten Lankhorst on LKML.
- Added UGA support for graphics
- Use VIDEO_TYPE_EFI instead of hard-coded number.
- Move linelength assignment until after we've assigned depth
- Dynamically fill out AddressOfEntryPoint in tools/build.c
- Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
- The bzImage may need to be relocated as it may have been loaded at
a high address address by the firmware. This was required to get my
macbook booting because the firmware loaded it at 0x7cxxxxxx, which
triggers this error in decompress_kernel(),
if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
error("Destination address too large");
Cc: Mike Waychison <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
# endif / * C O N F I G _ E F I _ S T U B * /
2007-07-11 23:18:54 +04:00
# Kernel a t t r i b u t e s ; used by setup. This is part 1 of the
# header, f r o m t h e o l d b o o t s e c t o r .
.section " .header " , " a"
2013-01-27 22:43:28 +04:00
.globl sentinel
sentinel : .byte 0xff , 0 xff / * U s e d t o d e t e c t b r o k e n l o a d e r s * /
2007-07-11 23:18:54 +04:00
.globl hdr
hdr :
2009-03-11 20:55:33 +03:00
setup_sects : .byte 0 /* Filled in by build.c */
2007-07-11 23:18:54 +04:00
root_flags : .word R O O T _ R D O N L Y
2009-03-11 20:55:33 +03:00
syssize : .long 0 /* Filled in by build.c */
ram_size : .word 0 /* Obsolete */
2007-07-11 23:18:54 +04:00
vid_mode : .word S V G A _ M O D E
2009-03-11 20:55:33 +03:00
root_dev : .word 0 /* Filled in by build.c */
2007-07-11 23:18:54 +04:00
boot_flag : .word 0xAA55
# offset 5 1 2 , e n t r y p o i n t
.globl _start
_start :
# Explicitly e n t e r t h i s a s b y t e s , o r t h e a s s e m b l e r
# tries t o g e n e r a t e a 3 - b y t e j u m p h e r e , w h i c h c a u s e s
# everything e l s e t o p u s h o f f t o t h e w r o n g o f f s e t .
.byte 0xeb # short ( 2 - b y t e ) j u m p
.byte start_ o f _ s e t u p - 1 f
1 :
# Part 2 o f t h e h e a d e r , f r o m t h e o l d s e t u p . S
.ascii " HdrS" # h e a d e r s i g n a t u r e
2013-01-27 22:43:28 +04:00
.word 0x020c # header v e r s i o n n u m b e r ( > = 0 x01 0 5 )
2007-07-11 23:18:54 +04:00
# or e l s e o l d l o a d l i n - 1 . 5 w i l l f a i l )
.globl realmode_swtch
realmode_swtch : .word 0 , 0 # default_ s w i t c h , S E T U P S E G
2009-03-11 20:55:33 +03:00
start_sys_seg : .word S Y S S E G # o b s o l e t e a n d m e a n i n g l e s s , b u t j u s t
# in c a s e s o m e t h i n g d e c i d e d t o " u s e " i t
2007-07-11 23:18:54 +04:00
.word kernel_ v e r s i o n - 5 1 2 # p o i n t i n g t o k e r n e l v e r s i o n s t r i n g
# above s e c t i o n o f h e a d e r i s c o m p a t i b l e
# with l o a d l i n - 1 . 5 ( h e a d e r v1 . 5 ) . D o n ' t
# change i t .
2009-03-11 20:55:33 +03:00
type_of_loader : .byte 0 # 0 means a n c i e n t b o o t l o a d e r , n e w e r
# bootloaders k n o w t o c h a n g e t h i s .
2011-08-15 04:02:26 +04:00
# See D o c u m e n t a t i o n / x86 / b o o t . t x t f o r
2007-07-11 23:18:54 +04:00
# assigned i d s
# flags, u n u s e d b i t s m u s t b e z e r o ( R F U ) b i t w i t h i n l o a d f l a g s
loadflags :
2013-01-27 22:43:28 +04:00
.byte LOADED_HIGH # The k e r n e l i s t o b e l o a d e d h i g h
2007-07-11 23:18:54 +04:00
setup_move_size : .word 0x8000 # size t o m o v e , w h e n s e t u p i s n o t
# loaded a t 0 x90 0 0 0 . W e w i l l m o v e s e t u p
# to 0 x90 0 0 0 t h e n j u s t b e f o r e j u m p i n g
# into t h e k e r n e l . H o w e v e r , o n l y t h e
# loader k n o w s h o w m u c h d a t a b e h i n d
# us a l s o n e e d s t o b e l o a d e d .
code32_start : # here l o a d e r s c a n p u t a d i f f e r e n t
# start a d d r e s s f o r 3 2 - b i t c o d e .
.long 0x100000 # 0 x1 0 0 0 0 0 = d e f a u l t f o r b i g k e r n e l
ramdisk_image : .long 0 # address o f l o a d e d r a m d i s k i m a g e
# Here t h e l o a d e r p u t s t h e 3 2 - b i t
# address w h e r e i t l o a d e d t h e i m a g e .
# This o n l y w i l l b e r e a d b y t h e k e r n e l .
ramdisk_size : .long 0 # its s i z e i n b y t e s
bootsect_kludge :
.long 0 # obsolete
2007-10-26 03:11:33 +04:00
heap_end_ptr : .word _ e n d + S T A C K _ S I Z E - 512
# ( Header v e r s i o n 0 x02 0 1 o r l a t e r )
2007-07-11 23:18:54 +04:00
# space f r o m h e r e ( e x c l u s i v e ) d o w n t o
# end o f s e t u p c o d e c a n b e u s e d b y s e t u p
# for l o c a l h e a p p u r p o s e s .
2009-05-08 03:54:11 +04:00
ext_loader_ver :
.byte 0 # Extended b o o t l o a d e r v e r s i o n
ext_loader_type :
.byte 0 # Extended b o o t l o a d e r t y p e
2007-07-11 23:18:54 +04:00
cmd_line_ptr : .long 0 # ( Header v e r s i o n 0 x02 0 2 o r l a t e r )
# If n o n z e r o , a 3 2 - b i t p o i n t e r
# to t h e k e r n e l c o m m a n d l i n e .
# The c o m m a n d l i n e s h o u l d b e
# located b e t w e e n t h e s t a r t o f
# setup a n d t h e e n d o f l o w
# memory ( 0 x a00 0 0 ) , o r i t m a y
# get o v e r w r i t t e n b e f o r e i t
# gets r e a d . I f t h i s f i e l d i s
# used, t h e r e i s n o l o n g e r
# anything m a g i c a l a b o u t t h e
# 0 x9 0 0 0 0 s e g m e n t ; the setup
# can b e l o c a t e d a n y w h e r e i n
# low m e m o r y 0 x10 0 0 0 o r h i g h e r .
2008-01-30 15:32:51 +03:00
ramdisk_max : .long 0x7fffffff
2007-07-11 23:18:54 +04:00
# ( Header v e r s i o n 0 x02 0 3 o r l a t e r )
# The h i g h e s t s a f e a d d r e s s f o r
# the c o n t e n t s o f a n i n i t r d
2008-01-30 15:32:51 +03:00
# The c u r r e n t k e r n e l a l l o w s u p t o 4 G B ,
# but l e a v e i t a t 2 G B t o a v o i d
# possible b o o t l o a d e r b u g s .
2007-07-11 23:18:54 +04:00
kernel_alignment : .long C O N F I G _ P H Y S I C A L _ A L I G N # p h y s i c a l a d d r a l i g n m e n t
# required f o r p r o t e c t e d m o d e
# kernel
# ifdef C O N F I G _ R E L O C A T A B L E
relocatable_kernel : .byte 1
# else
relocatable_kernel : .byte 0
# endif
2009-05-12 02:56:08 +04:00
min_alignment : .byte M I N _ K E R N E L _ A L I G N _ L G 2 # minimum a l i g n m e n t
2013-01-27 22:43:28 +04:00
xloadflags :
# ifdef C O N F I G _ X 8 6 _ 6 4
# define X L F 0 X L F _ K E R N E L _ 6 4 / * 6 4 - b i t k e r n e l * /
# else
# define X L F 0 0
# endif
2013-01-29 08:16:44 +04:00
# if d e f i n e d ( C O N F I G _ R E L O C A T A B L E ) & & d e f i n e d ( C O N F I G _ X 8 6 _ 6 4 )
/* kernel/boot_param/ramdisk could be loaded above 4g */
# define X L F 1 X L F _ C A N _ B E _ L O A D E D _ A B O V E _ 4 G
# else
# define X L F 1 0
# endif
2013-01-27 22:43:28 +04:00
# ifdef C O N F I G _ E F I _ S T U B
# ifdef C O N F I G _ X 8 6 _ 6 4
# define X L F 2 3 X L F _ E F I _ H A N D O V E R _ 6 4 / * 6 4 - b i t E F I h a n d o v e r o k * /
# else
# define X L F 2 3 X L F _ E F I _ H A N D O V E R _ 3 2 / * 3 2 - b i t E F I h a n d o v e r o k * /
# endif
# else
# define X L F 2 3 0
# endif
2013-12-20 14:02:20 +04:00
# if d e f i n e d ( C O N F I G _ X 8 6 _ 6 4 ) & & d e f i n e d ( C O N F I G _ E F I ) & & d e f i n e d ( C O N F I G _ K E X E C )
# define X L F 4 X L F _ E F I _ K E X E C
# else
# define X L F 4 0
# endif
.word XLF0 | XLF1 | X L F 2 3 | X L F 4
2007-07-11 23:18:54 +04:00
cmdline_size : .long C O M M A N D _ L I N E _ S I Z E - 1 # length o f t h e c o m m a n d l i n e ,
# added w i t h b o o t p r o t o c o l
# version 2 . 0 6
2007-10-22 03:41:35 +04:00
hardware_subarch : .long 0 # subarchitecture, a d d e d w i t h 2 . 0 7
# default t o 0 f o r n o r m a l x86 P C
hardware_subarch_data : .quad 0
2009-05-12 01:21:12 +04:00
payload_offset : .long Z O _ i n p u t _ d a t a
payload_length : .long Z O _ z _ i n p u t _ l e n
2008-02-13 23:54:58 +03:00
2008-03-28 05:49:44 +03:00
setup_data : .quad 0 # 6 4 - bit p h y s i c a l p o i n t e r t o
# single l i n k e d l i s t o f
# struct s e t u p _ d a t a
2009-05-12 02:56:08 +04:00
pref_address : .quad L O A D _ P H Y S I C A L _ A D D R # p r e f e r r e d l o a d a d d r
2009-05-20 22:26:09 +04:00
# define Z O _ I N I T _ S I Z E ( Z O _ _ e n d - Z O _ s t a r t u p _ 3 2 + Z O _ z _ e x t r a c t _ o f f s e t )
2009-05-12 02:56:08 +04:00
# define V O _ I N I T _ S I Z E ( V O _ _ e n d - V O _ _ t e x t )
# if Z O _ I N I T _ S I Z E > V O _ I N I T _ S I Z E
# define I N I T _ S I Z E Z O _ I N I T _ S I Z E
# else
# define I N I T _ S I Z E V O _ I N I T _ S I Z E
# endif
init_size : .long I N I T _ S I Z E # k e r n e l i n i t i a l i z a t i o n s i z e
2013-01-27 22:43:28 +04:00
handover_offset :
# ifdef C O N F I G _ E F I _ S T U B
.long 0x30 # offset t o t h e h a n d o v e r
2012-07-19 13:23:48 +04:00
# protocol e n t r y p o i n t
2013-01-27 22:43:28 +04:00
# else
.long 0
# endif
2009-05-12 02:56:08 +04:00
2007-07-11 23:18:54 +04:00
# End o f s e t u p h e a d e r ## # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
2009-04-02 05:08:28 +04:00
.section " .entrytext " , " ax"
2007-07-11 23:18:54 +04:00
start_of_setup :
# Force % e s = % d s
movw % d s , % a x
movw % a x , % e s
cld
2007-11-27 14:35:13 +03:00
# Apparently s o m e a n c i e n t v e r s i o n s o f L I L O i n v o k e d t h e k e r n e l w i t h % s s ! = % d s ,
# which h a p p e n e d t o w o r k b y a c c i d e n t f o r t h e o l d c o d e . R e c a l c u l a t e t h e s t a c k
# pointer i f % s s i s i n v a l i d . O t h e r w i s e l e a v e i t a l o n e , L O A D L I N s e t s u p t h e
# stack b e h i n d i t s o w n c o d e , s o w e c a n ' t b l i n d l y p u t i t d i r e c t l y p a s t t h e h e a p .
2007-10-26 03:11:33 +04:00
movw % s s , % d x
cmpw % a x , % d x # % d s = = % s s ?
movw % s p , % d x
2007-11-27 14:35:13 +03:00
je 2 f # - > a s s u m e % s p i s r e a s o n a b l y s e t
# Invalid % s s , m a k e u p a n e w s t a c k
movw $ _ e n d , % d x
testb $ C A N _ U S E _ H E A P , l o a d f l a g s
jz 1 f
movw h e a p _ e n d _ p t r , % d x
1 : addw $ S T A C K _ S I Z E , % d x
jnc 2 f
xorw % d x , % d x # P r e v e n t w r a p a r o u n d
2007-10-26 03:11:33 +04:00
2007-11-27 14:35:13 +03:00
2 : # Now % d x s h o u l d p o i n t t o t h e e n d o f o u r s t a c k s p a c e
2007-10-26 03:11:33 +04:00
andw $ ~ 3 , % d x # d w o r d a l i g n ( m i g h t a s w e l l . . . )
jnz 3 f
movw $ 0 x f f f c , % d x # M a k e s u r e w e ' r e n o t z e r o
2007-11-27 14:35:13 +03:00
3 : movw % a x , % s s
2007-10-26 03:11:33 +04:00
movzwl % d x , % e s p # C l e a r u p p e r h a l f o f % e s p
sti # N o w w e s h o u l d h a v e a w o r k i n g s t a c k
# We w i l l h a v e e n t e r e d w i t h % c s = % d s + 0 x20 , n o r m a l i z e % c s s o
# it i s o n p a r w i t h t h e o t h e r s e g m e n t s .
pushw % d s
pushw $ 6 f
lretw
6 :
2007-07-11 23:18:54 +04:00
# Check s i g n a t u r e a t e n d o f s e t u p
cmpl $ 0 x5 a5 a a a55 , s e t u p _ s i g
jne s e t u p _ b a d
# Zero t h e b s s
movw $ _ _ b s s _ s t a r t , % d i
movw $ _ e n d + 3 , % c x
xorl % e a x , % e a x
subw % d i , % c x
shrw $ 2 , % c x
rep; stosl
# Jump t o C c o d e ( s h o u l d n o t r e t u r n )
calll m a i n
# Setup c o r r u p t s o m e h o w . . .
setup_bad :
movl $ s e t u p _ c o r r u p t , % e a x
calll p u t s
# Fall t h r o u g h . . .
.globl die
.type die, @function
die :
hlt
jmp d i e
2007-09-11 01:39:02 +04:00
.size die, . - d i e
2007-07-11 23:18:54 +04:00
.section " .initdata " , " a"
setup_corrupt :
.byte 7
2007-07-27 03:10:22 +04:00
.string " No s e t u p s i g n a t u r e f o u n d . . . \ n "