Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 2 May 2019 14:59:25 +0800
From:   Changbin Du <changbin.du@gmail.com>
To:     Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc:     Changbin Du <changbin.du@gmail.com>,
        Jonathan Corbet <corbet@lwn.net>, tglx@linutronix.de,
        mingo@redhat.com, bp@alien8.de, x86@kernel.org,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/27] Documentation: x86: convert boot.txt to reST
Message-ID: <20190502065921.fqrthr5tne2ulao4@mail.google.com>
References: <20190426153150.21228-1-changbin.du@gmail.com>
 <20190426153150.21228-3-changbin.du@gmail.com>
 <20190427113153.44058656@coco.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190427113153.44058656@coco.lan>
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Mauro, I have resolved all of your comments here. Now git recognizes it as a
renaming.

Please check update version later. Many thanks!

On Sat, Apr 27, 2019 at 11:31:53AM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 26 Apr 2019 23:31:25 +0800
> Changbin Du <changbin.du@gmail.com> escreveu:
> 
> > This converts the plain text documentation to reStructuredText format and
> > add it to Sphinx TOC tree. No essential content change.
> > 
> > Signed-off-by: Changbin Du <changbin.du@gmail.com>
> > Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> >  Documentation/x86/boot.rst  | 1238 +++++++++++++++++++++++++++++++++++
> >  Documentation/x86/boot.txt  | 1130 --------------------------------
> 
> See, one of the problems of not having a git tree where we could
> pull and a changeset that was not detected as a rename is that
> conflicts happen:
> 
> patching file Documentation/x86/boot.rst
> patching file Documentation/x86/boot.txt
> Hunk #1 FAILED at 1.
> Not deleting file Documentation/x86/boot.txt as content differs from patch
> 1 out of 1 hunk FAILED -- saving rejects to file Documentation/x86/boot.txt.rej
> 
> (tried to apply this on the top of docs-next and linux-next - didn't try to
> apply directly on the top of x86 tree)
> 
> This indicates that you should probably rebase your tree.
> 
> This was not detected as a rename because of this:
> 
> 	diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.rst
> 	similarity index 47%
> 
> If you use "-M40" on git send-email, it will properly detect
> this one as a rename.
> 
> >  Documentation/x86/index.rst |    2 +
> >  3 files changed, 1240 insertions(+), 1130 deletions(-)
> >  create mode 100644 Documentation/x86/boot.rst
> >  delete mode 100644 Documentation/x86/boot.txt
> > 
> > diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
> > new file mode 100644
> > index 000000000000..9b289a72b53f
> > --- /dev/null
> > +++ b/Documentation/x86/boot.rst
> > @@ -0,0 +1,1238 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +===========================
> > +The Linux/x86 Boot Protocol
> > +===========================
> > +
> > +On the x86 platform, the Linux kernel uses a rather complicated boot
> > +convention.  This has evolved partially due to historical aspects, as
> > +well as the desire in the early days to have the kernel itself be a
> > +bootable image, the complicated PC memory model and due to changed
> > +expectations in the PC industry caused by the effective demise of
> > +real-mode DOS as a mainstream operating system.
> > +
> > +Currently, the following versions of the Linux/x86 boot protocol exist.
> > +
> > +=============	============================================================
> > +Old kernels	zImage/Image support only.  Some very early kernels
> > +		may not even support a command line.
> > +
> > +Protocol 2.00	(Kernel 1.3.73) Added bzImage and initrd support, as
> > +		well as a formalized way to communicate between the
> > +		boot loader and the kernel.  setup.S made relocatable,
> > +		although the traditional setup area still assumed
> > +		writable.
> > +
> > +Protocol 2.01	(Kernel 1.3.76) Added a heap overrun warning.
> > +
> > +Protocol 2.02	(Kernel 2.4.0-test3-pre3) New command line protocol.
> > +		Lower the conventional memory ceiling.	No overwrite
> > +		of the traditional setup area, thus making booting
> > +		safe for systems which use the EBDA from SMM or 32-bit
> > +		BIOS entry points.  zImage deprecated but still
> > +		supported.
> > +
> > +Protocol 2.03	(Kernel 2.4.18-pre1) Explicitly makes the highest possible
> > +		initrd address available to the bootloader.
> > +
> > +Protocol 2.04	(Kernel 2.6.14) Extend the syssize field to four bytes.
> > +
> > +Protocol 2.05	(Kernel 2.6.20) Make protected mode kernel relocatable.
> > +		Introduce relocatable_kernel and kernel_alignment fields.
> > +
> > +Protocol 2.06	(Kernel 2.6.22) Added a field that contains the size of
> > +		the boot command line.
> > +
> > +Protocol 2.07	(Kernel 2.6.24) Added paravirtualised boot protocol.
> > +		Introduced hardware_subarch and hardware_subarch_data
> > +		and KEEP_SEGMENTS flag in load_flags.
> > +
> > +Protocol 2.08	(Kernel 2.6.26) Added crc32 checksum and ELF format
> > +		payload. Introduced payload_offset and payload_length
> > +		fields to aid in locating the payload.
> > +
> > +Protocol 2.09	(Kernel 2.6.26) Added a field of 64-bit physical
> > +		pointer to single linked list of struct	setup_data.
> > +
> > +Protocol 2.10	(Kernel 2.6.31) Added a protocol for relaxed alignment
> > +		beyond the kernel_alignment added, new init_size and
> > +		pref_address fields.  Added extended boot loader IDs.
> > +
> > +Protocol 2.11	(Kernel 3.6) Added a field for offset of EFI handover
> > +		protocol entry point.
> > +
> > +Protocol 2.12	(Kernel 3.8) Added the xloadflags field and extension fields
> > +		to struct boot_params for loading bzImage and ramdisk
> > +		above 4G in 64bit.
> > +=============	============================================================
> > +
> > +MEMORY LAYOUT
> > +=============
> 
> I would place all the titles in camel case, in order to standardize
> to the style we're using on other documents. Same applies to other
> titles on this document (and along this series, if any).
> 
> > +
> > +The traditional memory map for the kernel loader, used for Image or
> > +zImage kernels, typically looks like::
> > +
> > +		|			 |
> > +	0A0000	+------------------------+
> > +		|  Reserved for BIOS	 |	Do not use.  Reserved for BIOS EBDA.
> > +	09A000	+------------------------+
> > +		|  Command line		 |
> > +		|  Stack/heap		 |	For use by the kernel real-mode code.
> > +	098000	+------------------------+
> > +		|  Kernel setup		 |	The kernel real-mode code.
> > +	090200	+------------------------+
> > +		|  Kernel boot sector	 |	The kernel legacy boot sector.
> > +	090000	+------------------------+
> > +		|  Protected-mode kernel |	The bulk of the kernel image.
> > +	010000	+------------------------+
> > +		|  Boot loader		 |	<- Boot sector entry point 0000:7C00
> > +	001000	+------------------------+
> > +		|  Reserved for MBR/BIOS |
> > +	000800	+------------------------+
> > +		|  Typically used by MBR |
> > +	000600	+------------------------+
> > +		|  BIOS use only	 |
> > +	000000	+------------------------+
> > +
> > +When using bzImage, the protected-mode kernel was relocated to
> > +0x100000 ("high memory"), and the kernel real-mode block (boot sector,
> > +setup, and stack/heap) was made relocatable to any address between
> > +0x10000 and end of low memory. Unfortunately, in protocols 2.00 and
> > +2.01 the 0x90000+ memory range is still used internally by the kernel;
> > +the 2.02 protocol resolves that problem.
> > +
> > +It is desirable to keep the "memory ceiling" -- the highest point in
> > +low memory touched by the boot loader -- as low as possible, since
> > +some newer BIOSes have begun to allocate some rather large amounts of
> > +memory, called the Extended BIOS Data Area, near the top of low
> > +memory.	 The boot loader should use the "INT 12h" BIOS call to verify
> > +how much low memory is available.
> > +
> > +Unfortunately, if INT 12h reports that the amount of memory is too
> > +low, there is usually nothing the boot loader can do but to report an
> > +error to the user.  The boot loader should therefore be designed to
> > +take up as little space in low memory as it reasonably can.  For
> > +zImage or old bzImage kernels, which need data written into the
> > +0x90000 segment, the boot loader should make sure not to use memory
> > +above the 0x9A000 point; too many BIOSes will break above that point.
> > +
> > +For a modern bzImage kernel with boot protocol version >= 2.02, a
> > +memory layout like the following is suggested::
> > +
> > +		~                        ~
> > +		|  Protected-mode kernel |
> > +	100000  +------------------------+
> > +		|  I/O memory hole	 |
> > +	0A0000	+------------------------+
> > +		|  Reserved for BIOS	 |	Leave as much as possible unused
> > +		~                        ~
> > +		|  Command line		 |	(Can also be below the X+10000 mark)
> > +	X+10000	+------------------------+
> > +		|  Stack/heap		 |	For use by the kernel real-mode code.
> > +	X+08000	+------------------------+
> > +		|  Kernel setup		 |	The kernel real-mode code.
> > +		|  Kernel boot sector	 |	The kernel legacy boot sector.
> > +	X       +------------------------+
> > +		|  Boot loader		 |	<- Boot sector entry point 0000:7C00
> > +	001000	+------------------------+
> > +		|  Reserved for MBR/BIOS |
> > +	000800	+------------------------+
> > +		|  Typically used by MBR |
> > +	000600	+------------------------+ 
> 
> There's an extra tail whitespace on the above line.
> 
> > +		|  BIOS use only	 |
> > +	000000	+------------------------+
> > +
> > +  ... where the address X is as low as the design of the boot loader permits.
> > +
> > +
> > +THE REAL-MODE KERNEL HEADER
> > +===========================
> > +
> > +In the following text, and anywhere in the kernel boot sequence, "a
> > +sector" refers to 512 bytes.  It is independent of the actual sector
> > +size of the underlying medium.
> > +
> > +The first step in loading a Linux kernel should be to load the
> > +real-mode code (boot sector and setup code) and then examine the
> > +following header at offset 0x01f1.  The real-mode code can total up to
> > +32K, although the boot loader may choose to load only the first two
> > +sectors (1K) and then examine the bootup sector size.
> > +
> > +The header looks like::
> > +  ===========	=======	=====================	================================
> > +  Offset/Size	Proto	Name			Meaning
> > +  ===========	=======	=====================	================================
> > +  01F1/1	ALL(1	setup_sects		The size of the setup in sectors
> > +  01F2/2	ALL	root_flags		If set, the root is mounted readonly
> > +  01F4/4	2.04+(2	syssize			The size of the 32-bit code in 16-byte paras
> 
> While I have no idea about the origin of this table, at least on my eyes,
> it sounds to me that this table got truncated. That (1 and (2 really seems
> to be, instead (1) and (2), matching the footnotes after this table. The
> same applies to (3 below. So, I would add an extra space at the Proto column
> and add the close parenthesis.
> 
> Those patches:
> 
> 	f8eeaaf41803 ("[PATCH] Make the bzImage format self-terminating") 
> 	5031296c5702 ("x86: add extension fields for bootloader type and version")
> 
> Seem to indicate that.
> 
> > +  01F8/2	ALL	ram_size		DO NOT USE - for bootsect.S use only
> > +  01FA/2	ALL	vid_mode		Video mode control
> > +  01FC/2	ALL	root_dev		Default root device number
> > +  01FE/2	ALL	boot_flag		0xAA55 magic number
> > +  0200/2	2.00+	jump			Jump instruction
> > +  0202/4	2.00+	header			Magic signature "HdrS"
> > +  0206/2	2.00+	version			Boot protocol version supported
> > +  0208/4	2.00+	realmode_swtch		Boot loader hook (see below)
> > +  020C/2	2.00+	start_sys_seg		The load-low segment (0x1000) (obsolete)
> > +  020E/2	2.00+	kernel_version		Pointer to kernel version string
> > +  0210/1	2.00+	type_of_loader		Boot loader identifier
> > +  0211/1	2.00+	loadflags		Boot protocol option flags
> > +  0212/2	2.00+	setup_move_size		Move to high memory size (used with hooks)
> > +  0214/4	2.00+	code32_start		Boot loader hook (see below)
> > +  0218/4	2.00+	ramdisk_image		initrd load address (set by boot loader)
> > +  021C/4	2.00+	ramdisk_size		initrd size (set by boot loader)
> > +  0220/4	2.00+	bootsect_kludge		DO NOT USE - for bootsect.S use only
> > +  0224/2	2.01+	heap_end_ptr		Free memory after setup end
> > +  0226/1	2.02+(3 ext_loader_ver		Extended boot loader version
> > +  0227/1	2.02+(3	ext_loader_type		Extended boot loader ID
> > +  0228/4	2.02+	cmd_line_ptr		32-bit pointer to the kernel command line
> > +  022C/4	2.03+	initrd_addr_max		Highest legal initrd address
> > +  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	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
> > +  0248/4	2.08+	payload_offset		Offset of kernel payload
> > +  024C/4	2.08+	payload_length		Length of kernel payload
> > +  0250/8	2.09+	setup_data		64-bit physical pointer to linked list
> > +						of struct setup_data
> > +  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
> > +  ===========	=======	=====================	================================
> > +
> > +.. note::
> > +  (1) For backwards compatibility, if the setup_sects field contains 0, the
> > +      real value is 4.
> > +
> > +  (2) For boot protocol prior to 2.04, the upper two bytes of the syssize
> > +      field are unusable, which means the size of a bzImage kernel
> > +      cannot be determined.
> > +
> > +  (3) Ignored, but safe to set, for boot protocols 2.02-2.09.
> 
> Perhaps a footnote markup here would work better - if ok for x86
> maintainers.
> 
> > +
> > +If the "HdrS" (0x53726448) magic number is not found at offset 0x202,
> > +the boot protocol version is "old".  Loading an old kernel, the
> > +following parameters should be assumed::
> > +
> > +	Image type = zImage
> > +	initrd not supported
> > +	Real-mode kernel must be located at 0x90000.
> > +
> > +Otherwise, the "version" field contains the protocol version,
> > +e.g. protocol version 2.01 will contain 0x0201 in this field.  When
> > +setting fields in the header, you must make sure only to set fields
> > +supported by the protocol version in use.
> > +
> > +
> > +DETAILS OF HEADER FIELDS
> > +========================
> > +
> > +For each field, some are information from the kernel to the bootloader
> > +("read"), some are expected to be filled out by the bootloader
> > +("write"), and some are expected to be read and modified by the
> > +bootloader ("modify").
> > +
> > +All general purpose boot loaders should write the fields marked
> > +(obligatory).  Boot loaders who want to load the kernel at a
> > +nonstandard address should fill in the fields marked (reloc); other
> > +boot loaders can ignore those fields.
> > +
> > +The byte order of all fields is littleendian (this is x86, after all.)
> > +  ============	=======
> > +  Field name:	setup_sects
> > +  Type:		read
> > +  Offset/size:	0x1f1/1
> > +  Protocol:	ALL
> > +  ============	=======
> 
> 
> Hmm... Sphinx 1.7 doesn't seem to be complaining[1], but this is actually a
> violation of ReST. as the markup line is too short. It should longer,
> like:
> 
>   ============	===========
>   Field name:	setup_sects
>   Type:		read
>   Offset/size:	0x1f1/1
>   Protocol:	ALL
>   ============	===========
> 
> For people reading this in plain text, this also makes it a lot better
> to read.
> 
> Same applies to all other tables here.
> 
> [1] Btw, I guess this is new on Sphinx. I'm pretty sure I had warnings on
> older versions on the tail table markup. You should remember that the
> minimal Sphinx version we support is 1.3, as stated at
> Documentation/conf.py (see needs_sphinx var there).
> 
> > +
> > +The size of the setup code in 512-byte sectors.  If this field is
> > +0, the real value is 4.  The real-mode code consists of the boot
> > +sector (always one 512-byte sector) plus the setup code.
> > +
> 
> 
> > +  ============	=======
> > +  Field name:	root_flags
> > +  Type:		modify (optional)
> > +  Offset/size:	0x1f2/2
> > +  Protocol:	ALL
> > +  ============	=======
> > +
> > +If this field is nonzero, the root defaults to readonly.  The use of
> > +this field is deprecated; use the "ro" or "rw" options on the
> > +command line instead.
> 
> This comment is general for all bootloader fields. I would, instead,
> do:
> 
> ============	=================
> Field name:     root_flags
> Type:           modify (optional)
> Offset/size:    0x1f2/2
> Protocol:       ALL
> ============	=================
> 
>   If this field is nonzero, the root defaults to readonly.  The use of
>   this field is deprecated; use the "ro" or "rw" options on the
>   command line instead.
> 
> 
> E.g. keep the original indentation of both the table and the text
> below. There are some good reasons for that:
> 
> 1) The explanation below each table belongs to the table. By doing
> such indentation, it becomes clearer;
> 
> 2) The number of changes will be a lot less, making easier for reviewers
> to notice if you changed something;
> 
> 3) the "similarity" used at git rename algorithm will increase a lot,
> making this to show as a rename at the git stats;
> 
> 4) it would avoid miss-formatting issues (line the one for "loadflags"
> below), as a new table will end any previous literal block.
> 
> 
> > +
> > +  ============	=======
> > +  Field name:	syssize
> > +  Type:		read
> > +  Offset/size:	0x1f4/4 (protocol 2.04+) 0x1f4/2 (protocol ALL)
> > +  Protocol:	2.04+
> > +  ============	=======
> > +
> > +The size of the protected-mode code in units of 16-byte paragraphs.
> > +For protocol versions older than 2.04 this field is only two bytes
> > +wide, and therefore cannot be trusted for the size of a kernel if
> > +the LOAD_HIGH flag is set.
> > +
> > +  ============	=======
> > +  Field name:	ram_size
> > +  Type:		kernel internal
> > +  Offset/size:	0x1f8/2
> > +  Protocol:	ALL
> > +  ============	=======
> > +
> > +This field is obsolete.
> > +
> > +  ============	=======
> > +  Field name:	vid_mode
> > +  Type:		modify (obligatory)
> > +  Offset/size:	0x1fa/2
> > +  ============	=======
> > +
> > +Please see the section on SPECIAL COMMAND LINE OPTIONS.
> > +
> > +  ============	=======
> > +  Field name:	root_dev
> > +  Type:		modify (optional)
> > +  Offset/size:	0x1fc/2
> > +  Protocol:	ALL
> > +  ============	=======
> > +
> > +The default root device device number.  The use of this field is
> > +deprecated, use the "root=" option on the command line instead.
> > +
> > +  ============	=======
> > +  Field name:	boot_flag
> > +  Type:		read
> > +  Offset/size:	0x1fe/2
> > +  Protocol:	ALL
> > +  ============	=======
> > +
> > +Contains 0xAA55.  This is the closest thing old Linux kernels have
> > +to a magic number.
> > +
> > +  ============	=======
> > +  Field name:	jump
> > +  Type:		read
> > +  Offset/size:	0x200/2
> > +  Protocol:	2.00+
> > +  ============	=======
> > +
> > +Contains an x86 jump instruction, 0xEB followed by a signed offset
> > +relative to byte 0x202.  This can be used to determine the size of
> > +the header.
> > +
> > +  ============	=======
> > +  Field name:	header
> > +  Type:		read
> > +  Offset/size:	0x202/4
> > +  Protocol:	2.00+
> > +  ============	=======
> > +
> > +Contains the magic number "HdrS" (0x53726448).
> > +
> > +  ============	=======
> > +  Field name:	version
> > +  Type:		read
> > +  Offset/size:	0x206/2
> > +  Protocol:	2.00+
> > +  ============	=======
> > +
> > +Contains the boot protocol version, in (major << 8)+minor format,
> > +e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version
> > +10.17.
> > +
> > +  ============	=======
> > +  Field name:	realmode_swtch
> > +  Type:		modify (optional)
> > +  Offset/size:	0x208/4
> > +  Protocol:	2.00+
> > +  ============	=======
> > +
> > +Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.)
> 
> Hmm... this book have some references based on chapter names.
> 
> > +
> > +  ============	=======
> > +  Field name:	start_sys_seg
> > +  Type:		read
> > +  Offset/size:	0x20c/2
> > +  Protocol:	2.00+
> > +  ============	=======
> > +
> > +The load low segment (0x1000).  Obsolete.
> > +
> > +  ============	=======
> > +  Field name:	kernel_version
> > +  Type:		read
> > +  Offset/size:	0x20e/2
> > +  Protocol:	2.00+
> > +  ============	=======
> > +
> > +If set to a nonzero value, contains a pointer to a NUL-terminated
> > +human-readable kernel version number string, less 0x200.  This can
> > +be used to display the kernel version to the user.  This value
> > +should be less than (0x200*setup_sects).
> > +
> > +For example, if this value is set to 0x1c00, the kernel version
> > +number string can be found at offset 0x1e00 in the kernel file.
> > +This is a valid value if and only if the "setup_sects" field
> > +contains the value 15 or higher, as::
> > +
> 
> 
> > +	0x1c00  < 15*0x200 (= 0x1e00) but
> > +	0x1c00 >= 14*0x200 (= 0x1c00)
> > +
> > +	0x1c00 >> 9 = 14
> > +
> > +So the minimum value for setup_secs is 15.
> 
> I would keep it the way it was before, e. g.:
> 
>         0x1c00  < 15*0x200 (= 0x1e00) but
>         0x1c00 >= 14*0x200 (= 0x1c00)
>  
>         0x1c00 >> 9 = 14, so the minimum value for setup_secs is 15.
> 
> As moving the last line out of the literal block makes it harder to
> understand.
> 
> > +
> > +  ============	=======
> > +  Field name:	type_of_loader
> > +  Type:		write (obligatory)
> > +  Offset/size:	0x210/1
> > +  Protocol:	2.00+
> > +  ============	=======
> > +
> > +If your boot loader has an assigned id (see table below), enter
> > +0xTV here, where T is an identifier for the boot loader and V is
> > +a version number.  Otherwise, enter 0xFF here.
> > +
> > +For boot loader IDs above T = 0xD, write T = 0xE to this field and
> > +write the extended ID minus 0x10 to the ext_loader_type field.
> > +Similarly, the ext_loader_ver field can be used to provide more than
> > +four bits for the bootloader version.
> > +
> > +For example, for T = 0x15, V = 0x234, write::
> > +
> > +  type_of_loader  <- 0xE4
> > +  ext_loader_type <- 0x05
> > +  ext_loader_ver  <- 0x23
> > +
> > +Assigned boot loader ids (hexadecimal):
> > +
> > +	== ==============================
> 
> Same here: markup too short
> 
> > +	0  LILO
> > +	   (0x00 reserved for pre-2.00 bootloader)
> > +	1  Loadlin
> > +	2  bootsect-loader
> > +	   (0x20, all other values reserved)
> > +	3  Syslinux
> > +	4  Etherboot/gPXE/iPXE
> > +	5  ELILO
> > +	7  GRUB
> > +	8  U-Boot
> > +	9  Xen
> > +	A  Gujin
> > +	B  Qemu
> > +	C  Arcturus Networks uCbootloader
> > +	D  kexec-tools
> > +	E  Extended (see ext_loader_type)
> > +	F  Special (0xFF = undefined)
> > +	10 Reserved
> > +	11 Minimal Linux Bootloader
> > +	   <http://sebastian-plotz.blogspot.de>
> > +	12 OVMF UEFI virtualization stack
> > +	== ==============================
> > +
> > +Please contact <hpa@zytor.com> if you need a bootloader ID value assigned.
> > +
> > +  ============	=======
> > +  Field name:	loadflags
> > +  Type:		modify (obligatory)
> > +  Offset/size:	0x211/1
> > +  Protocol:	2.00+
> > +  ============	=======
> > +
> > +This field is a bitmask.
> > +::
> 
> I don't see any reason why converting the stuff below into a literal block.
> Just removing the "::" and add a few blank lines in order to avoid Sphinx
> to change the font of the previous line to bold would likely produce a
> better output (IMHO).
> 
> > +
> > +  Bit 0 (read):	LOADED_HIGH
> > +	- If 0, the protected-mode code is loaded at 0x10000.
> > +	- If 1, the protected-mode code is loaded at 0x100000.
> > +
> > +  Bit 1 (kernel internal): KASLR_FLAG
> > +	- Used internally by the compressed kernel to communicate
> > +	  KASLR status to kernel proper.
> > +	    - If 1, KASLR enabled.
> > +	    - If 0, KASLR disabled.
> > +
> > +  Bit 5 (write): QUIET_FLAG
> > +	- If 0, print early messages.
> > +	- If 1, suppress early messages.
> > +		This requests to the kernel (decompressor and early
> > +		kernel) to not write early messages that require
> > +		accessing the display hardware directly.
> > +
> > +  Bit 6 (write): KEEP_SEGMENTS
> > +	Protocol: 2.07+
> > +	- If 0, reload the segment registers in the 32bit entry point.
> > +	- If 1, do not reload the segment registers in the 32bit entry point.
> > +		Assume that %cs %ds %ss %es are all set to flat segments with
> > +		a base of 0 (or the equivalent for their environment).
> > +
> > +  Bit 7 (write): CAN_USE_HEAP
> > +	Set this bit to 1 to indicate that the value entered in the
> > +	heap_end_ptr is valid.  If this field is clear, some setup code
> > +	functionality will be disabled.
> > +
> > +
> > +  ============	=======
> > +  Field name:	setup_move_size
> > +  Type:		modify (obligatory)
> > +  Offset/size:	0x212/2
> > +  Protocol:	2.00-2.01
> > +  ============	=======
> 
> Due to its alignment, this table will be displayed as part of the
> previous code-block.
> 
> > +
> > +When using protocol 2.00 or 2.01, if the real mode kernel is not
> > +loaded at 0x90000, it gets moved there later in the loading
> > +sequence.  Fill in this field if you want additional data (such as
> > +the kernel command line) moved in addition to the real-mode kernel
> > +itself.
> > +
> > +The unit is bytes starting with the beginning of the boot sector.
> > +  
> > +This field is can be ignored when the protocol is 2.02 or higher, or
> > +if the real-mode code is loaded at 0x90000.
> > +
> > +  ============	=======
> > +  Field name:	code32_start
> > +  Type:		modify (optional, reloc)
> > +  Offset/size:	0x214/4
> > +  Protocol:	2.00+
> > +  ============	=======
> > +
> > +The address to jump to in protected mode.  This defaults to the load
> > +address of the kernel, and can be used by the boot loader to
> > +determine the proper load address.
> > +
> > +This field can be modified for two purposes:
> > +
> > +  1. as a boot loader hook (see ADVANCED BOOT LOADER HOOKS below.)
> > +
> > +  2. if a bootloader which does not install a hook loads a
> > +     relocatable kernel at a nonstandard address it will have to modify
> > +     this field to point to the load address.
> > +
> > +  ============	=======
> > +  Field name:	ramdisk_image
> > +  Type:		write (obligatory)
> > +  Offset/size:	0x218/4
> > +  Protocol:	2.00+
> > +  ============	=======
> > +
> 
> As I mentioned before, the identation for those tables make it 
> confusing to read.
> 
> In this specific case, both in HTML and in text mode, it sounds 
> that ramdisk_image field has something related to the code32_start
> field.
> 
> > +The 32-bit linear address of the initial ramdisk or ramfs.  Leave at
> > +zero if there is no initial ramdisk/ramfs.
> > +
> > +  ============	=======
> > +  Field name:	ramdisk_size
> > +  Type:		write (obligatory)
> > +  Offset/size:	0x21c/4
> > +  Protocol:	2.00+
> > +  ============	=======
> > +
> > +Size of the initial ramdisk or ramfs.  Leave at zero if there is no
> > +initial ramdisk/ramfs.
> > +
> > +  ============	=======
> > +  Field name:	bootsect_kludge
> > +  Type:		kernel internal
> > +  Offset/size:	0x220/4
> > +  Protocol:	2.00+
> > +  ============	=======
> > +
> > +This field is obsolete.
> > +
> > +  ============	=======
> > +  Field name:	heap_end_ptr
> > +  Type:		write (obligatory)
> > +  Offset/size:	0x224/2
> > +  Protocol:	2.01+
> > +  ============	=======
> > +
> > +Set this field to the offset (from the beginning of the real-mode
> > +code) of the end of the setup stack/heap, minus 0x0200.
> > +
> > +  ============	=======
> > +  Field name:	ext_loader_ver
> > +  Type:		write (optional)
> > +  Offset/size:	0x226/1
> > +  Protocol:	2.02+
> > +  ============	=======
> > +
> > +This field is used as an extension of the version number in the
> > +type_of_loader field.  The total version number is considered to be
> > +(type_of_loader & 0x0f) + (ext_loader_ver << 4).
> > +
> > +The use of this field is boot loader specific.  If not written, it
> > +is zero.
> > +
> > +Kernels prior to 2.6.31 did not recognize this field, but it is safe
> > +to write for protocol version 2.02 or higher.
> > +
> > +  ============	=======
> > +  Field name:	ext_loader_type
> > +  Type:		write (obligatory if (type_of_loader & 0xf0) == 0xe0)
> > +  Offset/size:	0x227/1
> > +  Protocol:	2.02+
> > +  ============	=======
> > +
> > +This field is used as an extension of the type number in
> > +type_of_loader field.  If the type in type_of_loader is 0xE, then
> > +the actual type is (ext_loader_type + 0x10).
> > +
> > +This field is ignored if the type in type_of_loader is not 0xE.
> > +
> > +Kernels prior to 2.6.31 did not recognize this field, but it is safe
> > +to write for protocol version 2.02 or higher.
> > +
> > +  ============	=======
> > +  Field name:	cmd_line_ptr
> > +  Type:		write (obligatory)
> > +  Offset/size:	0x228/4
> > +  Protocol:	2.02+
> > +  ============	=======
> > +
> > +Set this field to the linear address of the kernel command line.
> > +The kernel command line can be located anywhere between the end of
> > +the setup heap and 0xA0000; it does not have to be located in the
> > +same 64K segment as the real-mode code itself.
> > +
> > +Fill in this field even if your boot loader does not support a
> > +command line, in which case you can point this to an empty string
> > +(or better yet, to the string "auto".)  If this field is left at
> > +zero, the kernel will assume that your boot loader does not support
> > +the 2.02+ protocol.
> > +
> > +  ============	=======
> > +  Field name:	initrd_addr_max
> > +  Type:		read
> > +  Offset/size:	0x22c/4
> > +  Protocol:	2.03+
> > +  ============	=======
> > +
> > +The maximum address that may be occupied by the initial
> > +ramdisk/ramfs contents.  For boot protocols 2.02 or earlier, this
> > +field is not present, and the maximum address is 0x37FFFFFF.  (This
> > +address is defined as the address of the highest safe byte, so if
> > +your ramdisk is exactly 131072 bytes long and this field is
> > +0x37FFFFFF, you can start your ramdisk at 0x37FE0000.)
> > +
> > +  ============	=======
> > +  Field name:	kernel_alignment
> > +  Type:		read/modify (reloc)
> > +  Offset/size:	0x230/4
> > +  Protocol:	2.05+ (read), 2.10+ (modify)
> > +  ============	=======
> > +
> > +Alignment unit required by the kernel (if relocatable_kernel is
> > +true.)  A relocatable kernel that is loaded at an alignment
> > +incompatible with the value in this field will be realigned during
> > +kernel initialization.
> > +
> > +Starting with protocol version 2.10, this reflects the kernel
> > +alignment preferred for optimal performance; it is possible for the
> > +loader to modify this field to permit a lesser alignment.  See the
> > +min_alignment and pref_address field below.
> > +
> > +  ============	=======
> > +  Field name:	relocatable_kernel
> > +  Type:		read (reloc)
> > +  Offset/size:	0x234/1
> > +  Protocol:	2.05+
> > +  ============	=======
> > +
> > +If this field is nonzero, the protected-mode part of the kernel can
> > +be loaded at any address that satisfies the kernel_alignment field.
> > +After loading, the boot loader must set the code32_start field to
> > +point to the loaded code, or to a boot loader hook.
> > +
> > +  ============	=======
> > +  Field name:	min_alignment
> > +  Type:		read (reloc)
> > +  Offset/size:	0x235/1
> > +  Protocol:	2.10+
> > +  ============	=======
> > +
> > +This field, if nonzero, indicates as a power of two the minimum
> > +alignment required, as opposed to preferred, by the kernel to boot.
> > +If a boot loader makes use of this field, it should update the
> > +kernel_alignment field with the alignment unit desired; typically::
> > +
> > +	kernel_alignment = 1 << min_alignment
> > +
> > +There may be a considerable performance cost with an excessively
> > +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.
> > +::
> 
> Again, no reason why converting this to a literal block...
> 
> > +
> > +  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 64-bit EFI handoff entry point
> > +          given at handover_offset + 0x200.
> > +
> > +  Bit 4 (read): XLF_EFI_KEXEC
> > +	- If 1, the kernel supports kexec EFI boot with EFI runtime support.
> > +
> > +  ============	=======
> > +  Field name:	cmdline_size
> > +  Type:		read
> > +  Offset/size:	0x238/4
> > +  Protocol:	2.06+
> > +  ============	=======
> 
> ... and this table will now be part of the literal block.
> 
> > +
> > +The maximum size of the command line without the terminating
> > +zero. This means that the command line can contain at most
> > +cmdline_size characters. With protocol version 2.05 and earlier, the
> > +maximum size was 255.
> > +
> > +  ============	=======
> > +  Field name:	hardware_subarch
> > +  Type:		write (optional, defaults to x86/PC)
> > +  Offset/size:	0x23c/4
> > +  Protocol:	2.07+
> > +  ============	=======
> > +
> > +In a paravirtualized environment the hardware low level architectural
> > +pieces such as interrupt handling, page table handling, and
> > +accessing process control registers needs to be done differently.
> > +
> > +This field allows the bootloader to inform the kernel we are in one
> > +one of those environments.
> > +
> > +  ==========	=======
> > +  0x00000000	The default x86/PC environment
> > +  0x00000001	lguest
> > +  0x00000002	Xen
> > +  0x00000003	Moorestown MID
> > +  0x00000004	CE4100 TV Platform
> > +  ==========	=======
> > +
> > +  ============	=======
> > +  Field name:	hardware_subarch_data
> > +  Type:		write (subarch-dependent)
> > +  Offset/size:	0x240/8
> > +  Protocol:	2.07+
> > +  ============	=======
> > +
> > +A pointer to data that is specific to hardware subarch
> > +This field is currently unused for the default x86/PC environment,
> > +do not modify.
> > +
> > +  ============	=======
> > +  Field name:	payload_offset
> > +  Type:		read
> > +  Offset/size:	0x248/4
> > +  Protocol:	2.08+
> > +  ============	=======
> > +
> > +If non-zero then this field contains the offset from the beginning
> > +of the protected-mode code to the payload.
> > +
> > +The payload may be compressed. The format of both the compressed and
> > +uncompressed data should be determined using the standard magic
> > +numbers.  The currently supported compression formats are gzip
> > +(magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
> > +(magic number 5D 00), XZ (magic number FD 37), and LZ4 (magic number
> > +02 21).  The uncompressed payload is currently always ELF (magic
> > +number 7F 45 4C 46).
> > +
> > +  ============	=======
> > +  Field name:	payload_length
> > +  Type:		read
> > +  Offset/size:	0x24c/4
> > +  Protocol:	2.08+
> > +  ============	=======
> > +
> > +The length of the payload.
> > +
> > +  ============	=======
> > +  Field name:	setup_data
> > +  Type:		write (special)
> > +  Offset/size:	0x250/8
> > +  Protocol:	2.09+
> > +  ============	=======
> > +
> > +The 64-bit physical pointer to NULL terminated single linked list of
> > +struct setup_data. This is used to define a more extensible boot
> > +parameters passing mechanism. The definition of struct setup_data is
> > +as follow::
> > +
> > +  struct setup_data {
> > +	  u64 next;
> > +	  u32 type;
> > +	  u32 len;
> > +	  u8  data[0];
> > +  };
> > +
> > +Where, the next is a 64-bit physical pointer to the next node of
> > +linked list, the next field of the last node is 0; the type is used
> > +to identify the contents of data; the len is the length of data
> > +field; the data holds the real payload.
> > +
> > +This list may be modified at a number of points during the bootup
> > +process.  Therefore, when modifying this list one should always make
> > +sure to consider the case where the linked list already contains
> > +entries.
> > +
> > +  ============	=======
> > +  Field name:	pref_address
> > +  Type:		read (reloc)
> > +  Offset/size:	0x258/8
> > +  Protocol:	2.10+
> > +  ============	=======
> > +
> > +This field, if nonzero, represents a preferred load address for the
> > +kernel.  A relocating bootloader should attempt to load at this
> > +address if possible.
> > +
> > +A non-relocatable kernel will unconditionally move itself and to run
> > +at this address.
> > +
> > +  ============	=======
> > +  Field name:	init_size
> > +  Type:		read
> > +  Offset/size:	0x260/4
> > +  ============	=======
> > +
> > +This field indicates the amount of linear contiguous memory starting
> > +at the kernel runtime start address that the kernel needs before it
> > +is capable of examining its memory map.  This is not the same thing
> > +as the total amount of memory the kernel needs to boot, but it can
> > +be used by a relocating boot loader to help select a safe load
> > +address for the kernel.
> > +
> > +The kernel runtime start address is determined by the following algorithm::
> > +
> > +  if (relocatable_kernel)
> > +    runtime_start = align_up(load_address, kernel_alignment)
> > +  else
> > +    runtime_start = pref_address
> > +
> > +  ============	=======
> > +  Field name:	handover_offset
> > +  Type:		read
> > +  Offset/size:	0x264/4
> > +  ============	=======
> 
> This table is also part of the preceding literal block, due to its
> indent.
> 
> > +
> > +This field is the offset from the beginning of the kernel image to
> > +the EFI handover protocol entry point. Boot loaders using the EFI
> > +handover protocol to boot the kernel should jump to this offset.
> > +
> > +See EFI HANDOVER PROTOCOL below for more details.
> > +
> > +
> > +THE IMAGE CHECKSUM
> > +==================
> > +
> > +From boot protocol version 2.08 onwards the CRC-32 is calculated over
> > +the entire file using the characteristic polynomial 0x04C11DB7 and an
> > +initial remainder of 0xffffffff.  The checksum is appended to the
> > +file; therefore the CRC of the file up to the limit specified in the
> > +syssize field of the header is always 0.
> > +
> > +
> > +THE KERNEL COMMAND LINE
> > +=======================
> > +
> > +The kernel command line has become an important way for the boot
> > +loader to communicate with the kernel.  Some of its options are also
> > +relevant to the boot loader itself, see "special command line options"
> > +below.
> > +
> > +The kernel command line is a null-terminated string. The maximum
> > +length can be retrieved from the field cmdline_size.  Before protocol
> > +version 2.06, the maximum was 255 characters.  A string that is too
> > +long will be automatically truncated by the kernel.
> > +
> > +If the boot protocol version is 2.02 or later, the address of the
> > +kernel command line is given by the header field cmd_line_ptr (see
> > +above.)  This address can be anywhere between the end of the setup
> > +heap and 0xA0000.
> > +
> > +If the protocol version is *not* 2.02 or higher, the kernel
> > +command line is entered using the following protocol:
> > +
> > +  - At offset 0x0020 (word), "cmd_line_magic", enter the magic
> > +    number 0xA33F.
> > +
> > +  - At offset 0x0022 (word), "cmd_line_offset", enter the offset
> > +    of the kernel command line (relative to the start of the
> > +    real-mode kernel).
> > +
> > +  - The kernel command line *must* be within the memory region
> > +    covered by setup_move_size, so you may need to adjust this
> > +    field.
> > +
> > +
> > +MEMORY LAYOUT OF THE REAL-MODE CODE
> > +===================================
> > +
> > +The real-mode code requires a stack/heap to be set up, as well as
> > +memory allocated for the kernel command line.  This needs to be done
> > +in the real-mode accessible memory in bottom megabyte.
> > +
> > +It should be noted that modern machines often have a sizable Extended
> > +BIOS Data Area (EBDA).  As a result, it is advisable to use as little
> > +of the low megabyte as possible.
> > +
> > +Unfortunately, under the following circumstances the 0x90000 memory
> > +segment has to be used:
> > +
> > +	- When loading a zImage kernel ((loadflags & 0x01) == 0).
> > +	- When loading a 2.01 or earlier boot protocol kernel.
> > +
> > +	     For the 2.00 and 2.01 boot protocols, the real-mode code
> 
> The actual diff here is:
> 	
> -         -> For the 2.00 and 2.01 boot protocols, the real-mode code
> +            For the 2.00 and 2.01 boot protocols, the real-mode code
> 
> I suspect that the reason for the "->" that used to be here is to
> mark this comment as a note.
> 
> You should probably be doing either:
> 
> 	Note:
> 	     For the 2.00 and 2.01 boot protocols, the real-mode code
> 
> Or use some note markup here.
> 
> > +	     can be loaded at another address, but it is internally
> > +	     relocated to 0x90000.  For the "old" protocol, the
> > +	     real-mode code must be loaded at 0x90000.
> > +
> > +When loading at 0x90000, avoid using memory above 0x9a000.
> > +
> > +For boot protocol 2.02 or higher, the command line does not have to be
> > +located in the same 64K segment as the real-mode setup code; it is
> > +thus permitted to give the stack/heap the full 64K segment and locate
> > +the command line above it.
> > +
> > +The kernel command line should not be located below the real-mode
> > +code, nor should it be located in high memory.
> > +
> > +
> > +SAMPLE BOOT CONFIGURATION
> > +=========================
> > +
> > +As a sample configuration, assume the following layout of the real
> > +mode segment.
> > +
> > +When loading below 0x90000, use the entire segment:
> > +
> > +        =============	=======
> > +	0x0000-0x7fff	Real mode kernel
> > +	0x8000-0xdfff	Stack and heap
> > +	0xe000-0xffff	Kernel command line
> > +	=============	=======
> > +
> > +When loading at 0x90000 OR the protocol version is 2.01 or earlier:
> > +
> > +	=============	=======
> > +	0x0000-0x7fff	Real mode kernel
> > +	0x8000-0x97ff	Stack and heap
> > +	0x9800-0x9fff	Kernel command line
> > +	=============	=======
> > +
> > +Such a boot loader should enter the following fields in the header::
> > +
> > +	unsigned long base_ptr;	/* base address for real-mode segment */
> > +
> > +	if ( setup_sects == 0 ) {
> > +		setup_sects = 4;
> > +	}
> > +
> > +	if ( protocol >= 0x0200 ) {
> > +		type_of_loader = <type code>;
> > +		if ( loading_initrd ) {
> > +			ramdisk_image = <initrd_address>;
> > +			ramdisk_size = <initrd_size>;
> > +		}
> > +
> > +		if ( protocol >= 0x0202 && loadflags & 0x01 )
> > +			heap_end = 0xe000;
> > +		else
> > +			heap_end = 0x9800;
> > +
> > +		if ( protocol >= 0x0201 ) {
> > +			heap_end_ptr = heap_end - 0x200;
> > +			loadflags |= 0x80; /* CAN_USE_HEAP */
> > +		}
> > +
> > +		if ( protocol >= 0x0202 ) {
> > +			cmd_line_ptr = base_ptr + heap_end;
> > +			strcpy(cmd_line_ptr, cmdline);
> > +		} else {
> > +			cmd_line_magic	= 0xA33F;
> > +			cmd_line_offset = heap_end;
> > +			setup_move_size = heap_end + strlen(cmdline)+1;
> > +			strcpy(base_ptr+cmd_line_offset, cmdline);
> > +		}
> > +	} else {
> > +		/* Very old kernel */
> > +
> > +		heap_end = 0x9800;
> > +
> > +		cmd_line_magic	= 0xA33F;
> > +		cmd_line_offset = heap_end;
> > +
> > +		/* A very old kernel MUST have its real-mode code
> > +		   loaded at 0x90000 */
> > +
> > +		if ( base_ptr != 0x90000 ) {
> > +			/* Copy the real-mode kernel */
> > +			memcpy(0x90000, base_ptr, (setup_sects+1)*512);
> > +			base_ptr = 0x90000;		 /* Relocated */
> > +		}
> > +
> > +		strcpy(0x90000+cmd_line_offset, cmdline);
> > +
> > +		/* It is recommended to clear memory up to the 32K mark */
> > +		memset(0x90000 + (setup_sects+1)*512, 0,
> > +		       (64-(setup_sects+1))*512);
> > +	}
> > +
> > +
> > +LOADING THE REST OF THE KERNEL
> > +==============================
> > +
> > +The 32-bit (non-real-mode) kernel starts at offset (setup_sects+1)*512
> > +in the kernel file (again, if setup_sects == 0 the real value is 4.)
> > +It should be loaded at address 0x10000 for Image/zImage kernels and
> > +0x100000 for bzImage kernels.
> > +
> > +The kernel is a bzImage kernel if the protocol >= 2.00 and the 0x01
> > +bit (LOAD_HIGH) in the loadflags field is set::
> > +
> > +	is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01);
> > +	load_address = is_bzImage ? 0x100000 : 0x10000;
> > +
> > +Note that Image/zImage kernels can be up to 512K in size, and thus use
> > +the entire 0x10000-0x90000 range of memory.  This means it is pretty
> > +much a requirement for these kernels to load the real-mode part at
> > +0x90000.  bzImage kernels allow much more flexibility.
> > +
> > +
> > +SPECIAL COMMAND LINE OPTIONS
> > +============================
> > +
> > +If the command line provided by the boot loader is entered by the
> > +user, the user may expect the following command line options to work.
> > +They should normally not be deleted from the kernel command line even
> > +though not all of them are actually meaningful to the kernel.  Boot
> > +loader authors who need additional command line options for the boot
> > +loader itself should get them registered in
> > +Documentation/admin-guide/kernel-parameters.rst to make sure they will not
> > +conflict with actual kernel options now or in the future.
> > +
> > +  vga=<mode>
> > +	<mode> here is either an integer (in C notation, either
> > +	decimal, octal, or hexadecimal) or one of the strings
> > +	"normal" (meaning 0xFFFF), "ext" (meaning 0xFFFE) or "ask"
> > +	(meaning 0xFFFD).  This value should be entered into the
> > +	vid_mode field, as it is used by the kernel before the command
> > +	line is parsed.
> > +
> > +  mem=<size>
> > +	<size> is an integer in C notation optionally followed by
> > +	(case insensitive) K, M, G, T, P or E (meaning << 10, << 20,
> > +	<< 30, << 40, << 50 or << 60).  This specifies the end of
> > +	memory to the kernel. This affects the possible placement of
> > +	an initrd, since an initrd should be placed near end of
> > +	memory.  Note that this is an option to *both* the kernel and
> > +	the bootloader!
> > +
> > +  initrd=<file>
> > +	An initrd should be loaded.  The meaning of <file> is
> > +	obviously bootloader-dependent, and some boot loaders
> > +	(e.g. LILO) do not have such a command.
> > +
> > +In addition, some boot loaders add the following options to the
> > +user-specified command line:
> > +
> > +  BOOT_IMAGE=<file>
> > +	The boot image which was loaded.  Again, the meaning of <file>
> > +	is obviously bootloader-dependent.
> > +
> > +  auto
> > +	The kernel was booted without explicit user intervention.
> > +
> > +If these options are added by the boot loader, it is highly
> > +recommended that they are located *first*, before the user-specified
> > +or configuration-specified command line.  Otherwise, "init=/bin/sh"
> > +gets confused by the "auto" option.
> > +
> > +
> > +RUNNING THE KERNEL
> > +==================
> > +
> > +The kernel is started by jumping to the kernel entry point, which is
> > +located at *segment* offset 0x20 from the start of the real mode
> > +kernel.  This means that if you loaded your real-mode kernel code at
> > +0x90000, the kernel entry point is 9020:0000.
> > +
> > +At entry, ds = es = ss should point to the start of the real-mode
> > +kernel code (0x9000 if the code is loaded at 0x90000), sp should be
> > +set up properly, normally pointing to the top of the heap, and
> > +interrupts should be disabled.  Furthermore, to guard against bugs in
> > +the kernel, it is recommended that the boot loader sets fs = gs = ds =
> > +es = ss.
> > +
> > +In our example from above, we would do::
> > +
> > +	/* Note: in the case of the "old" kernel protocol, base_ptr must
> > +	   be == 0x90000 at this point; see the previous sample code */
> > +
> > +	seg = base_ptr >> 4;
> > +
> > +	cli();	/* Enter with interrupts disabled! */
> > +
> > +	/* Set up the real-mode kernel stack */
> > +	_SS = seg;
> > +	_SP = heap_end;
> > +
> > +	_DS = _ES = _FS = _GS = seg;
> > +	jmp_far(seg+0x20, 0);	/* Run the kernel */
> > +
> > +If your boot sector accesses a floppy drive, it is recommended to
> > +switch off the floppy motor before running the kernel, since the
> > +kernel boot leaves interrupts off and thus the motor will not be
> > +switched off, especially if the loaded kernel has the floppy driver as
> > +a demand-loaded module!
> > +
> > +
> > +ADVANCED BOOT LOADER HOOKS
> > +==========================
> > +
> > +If the boot loader runs in a particularly hostile environment (such as
> > +LOADLIN, which runs under DOS) it may be impossible to follow the
> > +standard memory location requirements.  Such a boot loader may use the
> > +following hooks that, if set, are invoked by the kernel at the
> > +appropriate time.  The use of these hooks should probably be
> > +considered an absolutely last resort!
> > +
> > +IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and
> > +%edi across invocation.
> > +
> > +  realmode_swtch:
> > +	A 16-bit real mode far subroutine invoked immediately before
> > +	entering protected mode.  The default routine disables NMI, so
> > +	your routine should probably do so, too.
> > +
> > +  code32_start:
> > +	A 32-bit flat-mode routine *jumped* to immediately after the
> > +	transition to protected mode, but before the kernel is
> > +	uncompressed.  No segments, except CS, are guaranteed to be
> > +	set up (current kernels do, but older ones do not); you should
> > +	set them up to BOOT_DS (0x18) yourself.
> > +
> > +	After completing your hook, you should jump to the address
> > +	that was in this field before your boot loader overwrote it
> > +	(relocated, if appropriate.)
> > +
> > +
> > +32-bit BOOT PROTOCOL
> > +====================
> > +
> > +For machine with some new BIOS other than legacy BIOS, such as EFI,
> > +LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel
> > +based on legacy BIOS can not be used, so a 32-bit boot protocol needs
> > +to be defined.
> > +
> > +In 32-bit boot protocol, the first step in loading a Linux kernel
> > +should be to setup the boot parameters (struct boot_params,
> > +traditionally known as "zero page"). The memory for struct boot_params
> > +should be allocated and initialized to all zero. Then the setup header
> > +from offset 0x01f1 of kernel image on should be loaded into struct
> > +boot_params and examined. The end of setup header can be calculated as
> > +follow::
> > +
> > +	0x0202 + byte value at offset 0x0201
> > +
> > +In addition to read/modify/write the setup header of the struct
> > +boot_params as that of 16-bit boot protocol, the boot loader should
> > +also fill the additional fields of the struct boot_params as that
> > +described in zero-page.txt.
> > +
> > +After setting up the struct boot_params, the boot loader can load the
> > +32/64-bit kernel in the same way as that of 16-bit boot protocol.
> > +
> > +In 32-bit boot protocol, the kernel is started by jumping to the
> > +32-bit kernel entry point, which is the start address of loaded
> > +32/64-bit kernel.
> > +
> > +At entry, the CPU must be in 32-bit protected mode with paging
> > +disabled; a GDT must be loaded with the descriptors for selectors
> > +__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
> > +segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
> > +must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
> > +must be __BOOT_DS; interrupt must be disabled; %esi must hold the base
> > +address of the struct boot_params; %ebp, %edi and %ebx must be zero.
> > +
> > +64-bit BOOT PROTOCOL
> > +====================
> > +
> > +For machine with 64bit cpus and 64bit kernel, we could use 64bit bootloader
> > +and we need a 64-bit boot protocol.
> > +
> > +In 64-bit boot protocol, the first step in loading a Linux kernel
> > +should be to setup the boot parameters (struct boot_params,
> > +traditionally known as "zero page"). The memory for struct boot_params
> > +could be allocated anywhere (even above 4G) and initialized to all zero.
> > +Then, the setup header at offset 0x01f1 of kernel image on should be
> > +loaded into struct boot_params and examined. The end of setup header
> > +can be calculated as follows::
> > +
> > +	0x0202 + byte value at offset 0x0201
> > +
> > +In addition to read/modify/write the setup header of the struct
> > +boot_params as that of 16-bit boot protocol, the boot loader should
> > +also fill the additional fields of the struct boot_params as described
> > +in zero-page.txt.
> > +
> > +After setting up the struct boot_params, the boot loader can load
> > +64-bit kernel in the same way as that of 16-bit boot protocol, but
> > +kernel could be loaded above 4G.
> > +
> > +In 64-bit boot protocol, the kernel is started by jumping to the
> > +64-bit kernel entry point, which is the start address of loaded
> > +64-bit kernel plus 0x200.
> > +
> > +At entry, the CPU must be in 64-bit mode with paging enabled.
> > +The range with setup_header.init_size from start address of loaded
> > +kernel and zero page and command line buffer get ident mapping;
> > +a GDT must be loaded with the descriptors for selectors
> > +__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
> > +segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
> > +must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
> > +must be __BOOT_DS; interrupt must be disabled; %rsi must hold the base
> > +address of the struct boot_params.
> > +
> > +EFI HANDOVER PROTOCOL
> > +=====================
> > +
> > +This protocol allows boot loaders to defer initialisation to the EFI
> > +boot stub. The boot loader is required to load the kernel/initrd(s)
> > +from the boot media and jump to the EFI handover protocol entry point
> > +which is hdr->handover_offset bytes from the beginning of
> > +startup_{32,64}.
> > +
> > +The function prototype for the handover entry point looks like this::
> > +
> > +    efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp)
> > +
> > +'handle' is the EFI image handle passed to the boot loader by the EFI
> > +firmware, 'table' is the EFI system table - these are the first two
> > +arguments of the "handoff state" as described in section 2.3 of the
> > +UEFI specification. 'bp' is the boot loader-allocated boot params.
> > +
> > +The boot loader *must* fill out the following fields in bp::
> > +
> > +  - hdr.code32_start
> > +  - hdr.cmd_line_ptr
> > +  - hdr.ramdisk_image (if applicable)
> > +  - hdr.ramdisk_size  (if applicable)
> > +
> > +All other fields should be zero.
> > diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
> > deleted file mode 100644
> > index f4c2a97bfdbd..000000000000
> > --- a/Documentation/x86/boot.txt
> > +++ /dev/null
> > @@ -1,1130 +0,0 @@
> > -		     THE LINUX/x86 BOOT PROTOCOL
> > -		     ---------------------------
> > -
> > -On the x86 platform, the Linux kernel uses a rather complicated boot
> > -convention.  This has evolved partially due to historical aspects, as
> > -well as the desire in the early days to have the kernel itself be a
> > -bootable image, the complicated PC memory model and due to changed
> > -expectations in the PC industry caused by the effective demise of
> > -real-mode DOS as a mainstream operating system.
> > -
> > -Currently, the following versions of the Linux/x86 boot protocol exist.
> > -
> > -Old kernels:	zImage/Image support only.  Some very early kernels
> > -		may not even support a command line.
> > -
> > -Protocol 2.00:	(Kernel 1.3.73) Added bzImage and initrd support, as
> > -		well as a formalized way to communicate between the
> > -		boot loader and the kernel.  setup.S made relocatable,
> > -		although the traditional setup area still assumed
> > -		writable.
> > -
> > -Protocol 2.01:	(Kernel 1.3.76) Added a heap overrun warning.
> > -
> > -Protocol 2.02:	(Kernel 2.4.0-test3-pre3) New command line protocol.
> > -		Lower the conventional memory ceiling.	No overwrite
> > -		of the traditional setup area, thus making booting
> > -		safe for systems which use the EBDA from SMM or 32-bit
> > -		BIOS entry points.  zImage deprecated but still
> > -		supported.
> > -
> > -Protocol 2.03:	(Kernel 2.4.18-pre1) Explicitly makes the highest possible
> > -		initrd address available to the bootloader.
> > -
> > -Protocol 2.04:	(Kernel 2.6.14) Extend the syssize field to four bytes.
> > -
> > -Protocol 2.05:	(Kernel 2.6.20) Make protected mode kernel relocatable.
> > -		Introduce relocatable_kernel and kernel_alignment fields.
> > -
> > -Protocol 2.06:	(Kernel 2.6.22) Added a field that contains the size of
> > -		the boot command line.
> > -
> > -Protocol 2.07:	(Kernel 2.6.24) Added paravirtualised boot protocol.
> > -		Introduced hardware_subarch and hardware_subarch_data
> > -		and KEEP_SEGMENTS flag in load_flags.
> > -
> > -Protocol 2.08:	(Kernel 2.6.26) Added crc32 checksum and ELF format
> > -		payload. Introduced payload_offset and payload_length
> > -		fields to aid in locating the payload.
> > -
> > -Protocol 2.09:	(Kernel 2.6.26) Added a field of 64-bit physical
> > -		pointer to single linked list of struct	setup_data.
> > -
> > -Protocol 2.10:	(Kernel 2.6.31) Added a protocol for relaxed alignment
> > -		beyond the kernel_alignment added, new init_size and
> > -		pref_address fields.  Added extended boot loader IDs.
> > -
> > -Protocol 2.11:	(Kernel 3.6) Added a field for offset of EFI handover
> > -		protocol entry point.
> > -
> > -Protocol 2.12:	(Kernel 3.8) Added the xloadflags field and extension fields
> > -		to struct boot_params for loading bzImage and ramdisk
> > -		above 4G in 64bit.
> > -
> > -**** MEMORY LAYOUT
> > -
> > -The traditional memory map for the kernel loader, used for Image or
> > -zImage kernels, typically looks like:
> > -
> > -	|			 |
> > -0A0000	+------------------------+
> > -	|  Reserved for BIOS	 |	Do not use.  Reserved for BIOS EBDA.
> > -09A000	+------------------------+
> > -	|  Command line		 |
> > -	|  Stack/heap		 |	For use by the kernel real-mode code.
> > -098000	+------------------------+	
> > -	|  Kernel setup		 |	The kernel real-mode code.
> > -090200	+------------------------+
> > -	|  Kernel boot sector	 |	The kernel legacy boot sector.
> > -090000	+------------------------+
> > -	|  Protected-mode kernel |	The bulk of the kernel image.
> > -010000	+------------------------+
> > -	|  Boot loader		 |	<- Boot sector entry point 0000:7C00
> > -001000	+------------------------+
> > -	|  Reserved for MBR/BIOS |
> > -000800	+------------------------+
> > -	|  Typically used by MBR |
> > -000600	+------------------------+ 
> > -	|  BIOS use only	 |
> > -000000	+------------------------+
> > -
> > -
> > -When using bzImage, the protected-mode kernel was relocated to
> > -0x100000 ("high memory"), and the kernel real-mode block (boot sector,
> > -setup, and stack/heap) was made relocatable to any address between
> > -0x10000 and end of low memory. Unfortunately, in protocols 2.00 and
> > -2.01 the 0x90000+ memory range is still used internally by the kernel;
> > -the 2.02 protocol resolves that problem.
> > -
> > -It is desirable to keep the "memory ceiling" -- the highest point in
> > -low memory touched by the boot loader -- as low as possible, since
> > -some newer BIOSes have begun to allocate some rather large amounts of
> > -memory, called the Extended BIOS Data Area, near the top of low
> > -memory.	 The boot loader should use the "INT 12h" BIOS call to verify
> > -how much low memory is available.
> > -
> > -Unfortunately, if INT 12h reports that the amount of memory is too
> > -low, there is usually nothing the boot loader can do but to report an
> > -error to the user.  The boot loader should therefore be designed to
> > -take up as little space in low memory as it reasonably can.  For
> > -zImage or old bzImage kernels, which need data written into the
> > -0x90000 segment, the boot loader should make sure not to use memory
> > -above the 0x9A000 point; too many BIOSes will break above that point.
> > -
> > -For a modern bzImage kernel with boot protocol version >= 2.02, a
> > -memory layout like the following is suggested:
> > -
> > -	~                        ~
> > -        |  Protected-mode kernel |
> > -100000  +------------------------+
> > -	|  I/O memory hole	 |
> > -0A0000	+------------------------+
> > -	|  Reserved for BIOS	 |	Leave as much as possible unused
> > -	~                        ~
> > -	|  Command line		 |	(Can also be below the X+10000 mark)
> > -X+10000	+------------------------+
> > -	|  Stack/heap		 |	For use by the kernel real-mode code.
> > -X+08000	+------------------------+	
> > -	|  Kernel setup		 |	The kernel real-mode code.
> > -	|  Kernel boot sector	 |	The kernel legacy boot sector.
> > -X       +------------------------+
> > -	|  Boot loader		 |	<- Boot sector entry point 0000:7C00
> > -001000	+------------------------+
> > -	|  Reserved for MBR/BIOS |
> > -000800	+------------------------+
> > -	|  Typically used by MBR |
> > -000600	+------------------------+ 
> > -	|  BIOS use only	 |
> > -000000	+------------------------+
> > -
> > -... where the address X is as low as the design of the boot loader
> > -permits.
> > -
> > -
> > -**** THE REAL-MODE KERNEL HEADER
> > -
> > -In the following text, and anywhere in the kernel boot sequence, "a
> > -sector" refers to 512 bytes.  It is independent of the actual sector
> > -size of the underlying medium.
> > -
> > -The first step in loading a Linux kernel should be to load the
> > -real-mode code (boot sector and setup code) and then examine the
> > -following header at offset 0x01f1.  The real-mode code can total up to
> > -32K, although the boot loader may choose to load only the first two
> > -sectors (1K) and then examine the bootup sector size.
> > -
> > -The header looks like:
> > -
> > -Offset	Proto	Name		Meaning
> > -/Size
> > -
> > -01F1/1	ALL(1	setup_sects	The size of the setup in sectors
> > -01F2/2	ALL	root_flags	If set, the root is mounted readonly
> > -01F4/4	2.04+(2	syssize		The size of the 32-bit code in 16-byte paras
> > -01F8/2	ALL	ram_size	DO NOT USE - for bootsect.S use only
> > -01FA/2	ALL	vid_mode	Video mode control
> > -01FC/2	ALL	root_dev	Default root device number
> > -01FE/2	ALL	boot_flag	0xAA55 magic number
> > -0200/2	2.00+	jump		Jump instruction
> > -0202/4	2.00+	header		Magic signature "HdrS"
> > -0206/2	2.00+	version		Boot protocol version supported
> > -0208/4	2.00+	realmode_swtch	Boot loader hook (see below)
> > -020C/2	2.00+	start_sys_seg	The load-low segment (0x1000) (obsolete)
> > -020E/2	2.00+	kernel_version	Pointer to kernel version string
> > -0210/1	2.00+	type_of_loader	Boot loader identifier
> > -0211/1	2.00+	loadflags	Boot protocol option flags
> > -0212/2	2.00+	setup_move_size	Move to high memory size (used with hooks)
> > -0214/4	2.00+	code32_start	Boot loader hook (see below)
> > -0218/4	2.00+	ramdisk_image	initrd load address (set by boot loader)
> > -021C/4	2.00+	ramdisk_size	initrd size (set by boot loader)
> > -0220/4	2.00+	bootsect_kludge	DO NOT USE - for bootsect.S use only
> > -0224/2	2.01+	heap_end_ptr	Free memory after setup end
> > -0226/1	2.02+(3 ext_loader_ver	Extended boot loader version
> > -0227/1	2.02+(3	ext_loader_type	Extended boot loader ID
> > -0228/4	2.02+	cmd_line_ptr	32-bit pointer to the kernel command line
> > -022C/4	2.03+	initrd_addr_max	Highest legal initrd address
> > -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	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
> > -0248/4	2.08+	payload_offset	Offset of kernel payload
> > -024C/4	2.08+	payload_length	Length of kernel payload
> > -0250/8	2.09+	setup_data	64-bit physical pointer to linked list
> > -				of struct setup_data
> > -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
> > -
> > -(1) For backwards compatibility, if the setup_sects field contains 0, the
> > -    real value is 4.
> > -
> > -(2) For boot protocol prior to 2.04, the upper two bytes of the syssize
> > -    field are unusable, which means the size of a bzImage kernel
> > -    cannot be determined.
> > -
> > -(3) Ignored, but safe to set, for boot protocols 2.02-2.09.
> > -
> > -If the "HdrS" (0x53726448) magic number is not found at offset 0x202,
> > -the boot protocol version is "old".  Loading an old kernel, the
> > -following parameters should be assumed:
> > -
> > -	Image type = zImage
> > -	initrd not supported
> > -	Real-mode kernel must be located at 0x90000.
> > -
> > -Otherwise, the "version" field contains the protocol version,
> > -e.g. protocol version 2.01 will contain 0x0201 in this field.  When
> > -setting fields in the header, you must make sure only to set fields
> > -supported by the protocol version in use.
> > -
> > -
> > -**** DETAILS OF HEADER FIELDS
> > -
> > -For each field, some are information from the kernel to the bootloader
> > -("read"), some are expected to be filled out by the bootloader
> > -("write"), and some are expected to be read and modified by the
> > -bootloader ("modify").
> > -
> > -All general purpose boot loaders should write the fields marked
> > -(obligatory).  Boot loaders who want to load the kernel at a
> > -nonstandard address should fill in the fields marked (reloc); other
> > -boot loaders can ignore those fields.
> > -
> > -The byte order of all fields is littleendian (this is x86, after all.)
> > -
> > -Field name:	setup_sects
> > -Type:		read
> > -Offset/size:	0x1f1/1
> > -Protocol:	ALL
> > -
> > -  The size of the setup code in 512-byte sectors.  If this field is
> > -  0, the real value is 4.  The real-mode code consists of the boot
> > -  sector (always one 512-byte sector) plus the setup code.
> > -
> > -Field name:	 root_flags
> > -Type:		 modify (optional)
> > -Offset/size:	 0x1f2/2
> > -Protocol:	 ALL
> > -
> > -  If this field is nonzero, the root defaults to readonly.  The use of
> > -  this field is deprecated; use the "ro" or "rw" options on the
> > -  command line instead.
> > -
> > -Field name:	syssize
> > -Type:		read
> > -Offset/size:	0x1f4/4 (protocol 2.04+) 0x1f4/2 (protocol ALL)
> > -Protocol:	2.04+
> > -
> > -  The size of the protected-mode code in units of 16-byte paragraphs.
> > -  For protocol versions older than 2.04 this field is only two bytes
> > -  wide, and therefore cannot be trusted for the size of a kernel if
> > -  the LOAD_HIGH flag is set.
> > -
> > -Field name:	ram_size
> > -Type:		kernel internal
> > -Offset/size:	0x1f8/2
> > -Protocol:	ALL
> > -
> > -  This field is obsolete.
> > -
> > -Field name:	vid_mode
> > -Type:		modify (obligatory)
> > -Offset/size:	0x1fa/2
> > -
> > -  Please see the section on SPECIAL COMMAND LINE OPTIONS.
> > -
> > -Field name:	root_dev
> > -Type:		modify (optional)
> > -Offset/size:	0x1fc/2
> > -Protocol:	ALL
> > -
> > -  The default root device device number.  The use of this field is
> > -  deprecated, use the "root=" option on the command line instead.
> > -
> > -Field name:	boot_flag
> > -Type:		read
> > -Offset/size:	0x1fe/2
> > -Protocol:	ALL
> > -
> > -  Contains 0xAA55.  This is the closest thing old Linux kernels have
> > -  to a magic number.
> > -
> > -Field name:	jump
> > -Type:		read
> > -Offset/size:	0x200/2
> > -Protocol:	2.00+
> > -
> > -  Contains an x86 jump instruction, 0xEB followed by a signed offset
> > -  relative to byte 0x202.  This can be used to determine the size of
> > -  the header.
> > -
> > -Field name:	header
> > -Type:		read
> > -Offset/size:	0x202/4
> > -Protocol:	2.00+
> > -
> > -  Contains the magic number "HdrS" (0x53726448).
> > -
> > -Field name:	version
> > -Type:		read
> > -Offset/size:	0x206/2
> > -Protocol:	2.00+
> > -
> > -  Contains the boot protocol version, in (major << 8)+minor format,
> > -  e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version
> > -  10.17.
> > -
> > -Field name:	realmode_swtch
> > -Type:		modify (optional)
> > -Offset/size:	0x208/4
> > -Protocol:	2.00+
> > -
> > -  Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.)
> > -
> > -Field name:	start_sys_seg
> > -Type:		read
> > -Offset/size:	0x20c/2
> > -Protocol:	2.00+
> > -
> > -  The load low segment (0x1000).  Obsolete.
> > -
> > -Field name:	kernel_version
> > -Type:		read
> > -Offset/size:	0x20e/2
> > -Protocol:	2.00+
> > -
> > -  If set to a nonzero value, contains a pointer to a NUL-terminated
> > -  human-readable kernel version number string, less 0x200.  This can
> > -  be used to display the kernel version to the user.  This value
> > -  should be less than (0x200*setup_sects).
> > -
> > -  For example, if this value is set to 0x1c00, the kernel version
> > -  number string can be found at offset 0x1e00 in the kernel file.
> > -  This is a valid value if and only if the "setup_sects" field
> > -  contains the value 15 or higher, as:
> > -
> > -	0x1c00  < 15*0x200 (= 0x1e00) but
> > -	0x1c00 >= 14*0x200 (= 0x1c00)
> > -
> > -	0x1c00 >> 9 = 14, so the minimum value for setup_secs is 15.
> > -
> > -Field name:	type_of_loader
> > -Type:		write (obligatory)
> > -Offset/size:	0x210/1
> > -Protocol:	2.00+
> > -
> > -  If your boot loader has an assigned id (see table below), enter
> > -  0xTV here, where T is an identifier for the boot loader and V is
> > -  a version number.  Otherwise, enter 0xFF here.
> > -
> > -  For boot loader IDs above T = 0xD, write T = 0xE to this field and
> > -  write the extended ID minus 0x10 to the ext_loader_type field.
> > -  Similarly, the ext_loader_ver field can be used to provide more than
> > -  four bits for the bootloader version.
> > -
> > -  For example, for T = 0x15, V = 0x234, write:
> > -
> > -  type_of_loader  <- 0xE4
> > -  ext_loader_type <- 0x05
> > -  ext_loader_ver  <- 0x23
> > -
> > -  Assigned boot loader ids (hexadecimal):
> > -
> > -	0  LILO			(0x00 reserved for pre-2.00 bootloader)
> > -	1  Loadlin
> > -	2  bootsect-loader	(0x20, all other values reserved)
> > -	3  Syslinux
> > -	4  Etherboot/gPXE/iPXE
> > -	5  ELILO
> > -	7  GRUB
> > -	8  U-Boot
> > -	9  Xen
> > -	A  Gujin
> > -	B  Qemu
> > -	C  Arcturus Networks uCbootloader
> > -	D  kexec-tools
> > -	E  Extended		(see ext_loader_type)
> > -	F  Special		(0xFF = undefined)
> > -       10  Reserved
> > -       11  Minimal Linux Bootloader <http://sebastian-plotz.blogspot.de>
> > -       12  OVMF UEFI virtualization stack
> > -
> > -  Please contact <hpa@zytor.com> if you need a bootloader ID
> > -  value assigned.
> > -
> > -Field name:	loadflags
> > -Type:		modify (obligatory)
> > -Offset/size:	0x211/1
> > -Protocol:	2.00+
> > -
> > -  This field is a bitmask.
> > -
> > -  Bit 0 (read):	LOADED_HIGH
> > -	- If 0, the protected-mode code is loaded at 0x10000.
> > -	- If 1, the protected-mode code is loaded at 0x100000.
> > -
> > -  Bit 1 (kernel internal): KASLR_FLAG
> > -	- Used internally by the compressed kernel to communicate
> > -	  KASLR status to kernel proper.
> > -	  If 1, KASLR enabled.
> > -	  If 0, KASLR disabled.
> > -
> > -  Bit 5 (write): QUIET_FLAG
> > -	- If 0, print early messages.
> > -	- If 1, suppress early messages.
> > -		This requests to the kernel (decompressor and early
> > -		kernel) to not write early messages that require
> > -		accessing the display hardware directly.
> > -
> > -  Bit 6 (write): KEEP_SEGMENTS
> > -	Protocol: 2.07+
> > -	- If 0, reload the segment registers in the 32bit entry point.
> > -	- If 1, do not reload the segment registers in the 32bit entry point.
> > -		Assume that %cs %ds %ss %es are all set to flat segments with
> > -		a base of 0 (or the equivalent for their environment).
> > -
> > -  Bit 7 (write): CAN_USE_HEAP
> > -	Set this bit to 1 to indicate that the value entered in the
> > -	heap_end_ptr is valid.  If this field is clear, some setup code
> > -	functionality will be disabled.
> > -
> > -Field name:	setup_move_size
> > -Type:		modify (obligatory)
> > -Offset/size:	0x212/2
> > -Protocol:	2.00-2.01
> > -
> > -  When using protocol 2.00 or 2.01, if the real mode kernel is not
> > -  loaded at 0x90000, it gets moved there later in the loading
> > -  sequence.  Fill in this field if you want additional data (such as
> > -  the kernel command line) moved in addition to the real-mode kernel
> > -  itself.
> > -
> > -  The unit is bytes starting with the beginning of the boot sector.
> > -  
> > -  This field is can be ignored when the protocol is 2.02 or higher, or
> > -  if the real-mode code is loaded at 0x90000.
> > -
> > -Field name:	code32_start
> > -Type:		modify (optional, reloc)
> > -Offset/size:	0x214/4
> > -Protocol:	2.00+
> > -
> > -  The address to jump to in protected mode.  This defaults to the load
> > -  address of the kernel, and can be used by the boot loader to
> > -  determine the proper load address.
> > -
> > -  This field can be modified for two purposes:
> > -
> > -  1. as a boot loader hook (see ADVANCED BOOT LOADER HOOKS below.)
> > -
> > -  2. if a bootloader which does not install a hook loads a
> > -     relocatable kernel at a nonstandard address it will have to modify
> > -     this field to point to the load address.
> > -
> > -Field name:	ramdisk_image
> > -Type:		write (obligatory)
> > -Offset/size:	0x218/4
> > -Protocol:	2.00+
> > -
> > -  The 32-bit linear address of the initial ramdisk or ramfs.  Leave at
> > -  zero if there is no initial ramdisk/ramfs.
> > -
> > -Field name:	ramdisk_size
> > -Type:		write (obligatory)
> > -Offset/size:	0x21c/4
> > -Protocol:	2.00+
> > -
> > -  Size of the initial ramdisk or ramfs.  Leave at zero if there is no
> > -  initial ramdisk/ramfs.
> > -
> > -Field name:	bootsect_kludge
> > -Type:		kernel internal
> > -Offset/size:	0x220/4
> > -Protocol:	2.00+
> > -
> > -  This field is obsolete.
> > -
> > -Field name:	heap_end_ptr
> > -Type:		write (obligatory)
> > -Offset/size:	0x224/2
> > -Protocol:	2.01+
> > -
> > -  Set this field to the offset (from the beginning of the real-mode
> > -  code) of the end of the setup stack/heap, minus 0x0200.
> > -
> > -Field name:	ext_loader_ver
> > -Type:		write (optional)
> > -Offset/size:	0x226/1
> > -Protocol:	2.02+
> > -
> > -  This field is used as an extension of the version number in the
> > -  type_of_loader field.  The total version number is considered to be
> > -  (type_of_loader & 0x0f) + (ext_loader_ver << 4).
> > -
> > -  The use of this field is boot loader specific.  If not written, it
> > -  is zero.
> > -
> > -  Kernels prior to 2.6.31 did not recognize this field, but it is safe
> > -  to write for protocol version 2.02 or higher.
> > -
> > -Field name:	ext_loader_type
> > -Type:		write (obligatory if (type_of_loader & 0xf0) == 0xe0)
> > -Offset/size:	0x227/1
> > -Protocol:	2.02+
> > -
> > -  This field is used as an extension of the type number in
> > -  type_of_loader field.  If the type in type_of_loader is 0xE, then
> > -  the actual type is (ext_loader_type + 0x10).
> > -
> > -  This field is ignored if the type in type_of_loader is not 0xE.
> > -
> > -  Kernels prior to 2.6.31 did not recognize this field, but it is safe
> > -  to write for protocol version 2.02 or higher.
> > -
> > -Field name:	cmd_line_ptr
> > -Type:		write (obligatory)
> > -Offset/size:	0x228/4
> > -Protocol:	2.02+
> > -
> > -  Set this field to the linear address of the kernel command line.
> > -  The kernel command line can be located anywhere between the end of
> > -  the setup heap and 0xA0000; it does not have to be located in the
> > -  same 64K segment as the real-mode code itself.
> > -
> > -  Fill in this field even if your boot loader does not support a
> > -  command line, in which case you can point this to an empty string
> > -  (or better yet, to the string "auto".)  If this field is left at
> > -  zero, the kernel will assume that your boot loader does not support
> > -  the 2.02+ protocol.
> > -
> > -Field name:	initrd_addr_max
> > -Type:		read
> > -Offset/size:	0x22c/4
> > -Protocol:	2.03+
> > -
> > -  The maximum address that may be occupied by the initial
> > -  ramdisk/ramfs contents.  For boot protocols 2.02 or earlier, this
> > -  field is not present, and the maximum address is 0x37FFFFFF.  (This
> > -  address is defined as the address of the highest safe byte, so if
> > -  your ramdisk is exactly 131072 bytes long and this field is
> > -  0x37FFFFFF, you can start your ramdisk at 0x37FE0000.)
> > -
> > -Field name:	kernel_alignment
> > -Type:		read/modify (reloc)
> > -Offset/size:	0x230/4
> > -Protocol:	2.05+ (read), 2.10+ (modify)
> > -
> > -  Alignment unit required by the kernel (if relocatable_kernel is
> > -  true.)  A relocatable kernel that is loaded at an alignment
> > -  incompatible with the value in this field will be realigned during
> > -  kernel initialization.
> > -
> > -  Starting with protocol version 2.10, this reflects the kernel
> > -  alignment preferred for optimal performance; it is possible for the
> > -  loader to modify this field to permit a lesser alignment.  See the
> > -  min_alignment and pref_address field below.
> > -
> > -Field name:	relocatable_kernel
> > -Type:		read (reloc)
> > -Offset/size:	0x234/1
> > -Protocol:	2.05+
> > -
> > -  If this field is nonzero, the protected-mode part of the kernel can
> > -  be loaded at any address that satisfies the kernel_alignment field.
> > -  After loading, the boot loader must set the code32_start field to
> > -  point to the loaded code, or to a boot loader hook.
> > -
> > -Field name:	min_alignment
> > -Type:		read (reloc)
> > -Offset/size:	0x235/1
> > -Protocol:	2.10+
> > -
> > -  This field, if nonzero, indicates as a power of two the minimum
> > -  alignment required, as opposed to preferred, by the kernel to boot.
> > -  If a boot loader makes use of this field, it should update the
> > -  kernel_alignment field with the alignment unit desired; typically:
> > -
> > -	kernel_alignment = 1 << min_alignment
> > -
> > -  There may be a considerable performance cost with an excessively
> > -  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 64-bit EFI handoff entry point
> > -          given at handover_offset + 0x200.
> > -
> > -  Bit 4 (read): XLF_EFI_KEXEC
> > -	- If 1, the kernel supports kexec EFI boot with EFI runtime support.
> > -
> > -Field name:	cmdline_size
> > -Type:		read
> > -Offset/size:	0x238/4
> > -Protocol:	2.06+
> > -
> > -  The maximum size of the command line without the terminating
> > -  zero. This means that the command line can contain at most
> > -  cmdline_size characters. With protocol version 2.05 and earlier, the
> > -  maximum size was 255.
> > -
> > -Field name:	hardware_subarch
> > -Type:		write (optional, defaults to x86/PC)
> > -Offset/size:	0x23c/4
> > -Protocol:	2.07+
> > -
> > -  In a paravirtualized environment the hardware low level architectural
> > -  pieces such as interrupt handling, page table handling, and
> > -  accessing process control registers needs to be done differently.
> > -
> > -  This field allows the bootloader to inform the kernel we are in one
> > -  one of those environments.
> > -
> > -  0x00000000	The default x86/PC environment
> > -  0x00000001	lguest
> > -  0x00000002	Xen
> > -  0x00000003	Moorestown MID
> > -  0x00000004	CE4100 TV Platform
> > -
> > -Field name:	hardware_subarch_data
> > -Type:		write (subarch-dependent)
> > -Offset/size:	0x240/8
> > -Protocol:	2.07+
> > -
> > -  A pointer to data that is specific to hardware subarch
> > -  This field is currently unused for the default x86/PC environment,
> > -  do not modify.
> > -
> > -Field name:	payload_offset
> > -Type:		read
> > -Offset/size:	0x248/4
> > -Protocol:	2.08+
> > -
> > -  If non-zero then this field contains the offset from the beginning
> > -  of the protected-mode code to the payload.
> > -
> > -  The payload may be compressed. The format of both the compressed and
> > -  uncompressed data should be determined using the standard magic
> > -  numbers.  The currently supported compression formats are gzip
> > -  (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
> > -  (magic number 5D 00), XZ (magic number FD 37), and LZ4 (magic number
> > -  02 21).  The uncompressed payload is currently always ELF (magic
> > -  number 7F 45 4C 46).
> > -
> > -Field name:	payload_length
> > -Type:		read
> > -Offset/size:	0x24c/4
> > -Protocol:	2.08+
> > -
> > -  The length of the payload.
> > -
> > -Field name:	setup_data
> > -Type:		write (special)
> > -Offset/size:	0x250/8
> > -Protocol:	2.09+
> > -
> > -  The 64-bit physical pointer to NULL terminated single linked list of
> > -  struct setup_data. This is used to define a more extensible boot
> > -  parameters passing mechanism. The definition of struct setup_data is
> > -  as follow:
> > -
> > -  struct setup_data {
> > -	  u64 next;
> > -	  u32 type;
> > -	  u32 len;
> > -	  u8  data[0];
> > -  };
> > -
> > -  Where, the next is a 64-bit physical pointer to the next node of
> > -  linked list, the next field of the last node is 0; the type is used
> > -  to identify the contents of data; the len is the length of data
> > -  field; the data holds the real payload.
> > -
> > -  This list may be modified at a number of points during the bootup
> > -  process.  Therefore, when modifying this list one should always make
> > -  sure to consider the case where the linked list already contains
> > -  entries.
> > -
> > -Field name:	pref_address
> > -Type:		read (reloc)
> > -Offset/size:	0x258/8
> > -Protocol:	2.10+
> > -
> > -  This field, if nonzero, represents a preferred load address for the
> > -  kernel.  A relocating bootloader should attempt to load at this
> > -  address if possible.
> > -
> > -  A non-relocatable kernel will unconditionally move itself and to run
> > -  at this address.
> > -
> > -Field name:	init_size
> > -Type:		read
> > -Offset/size:	0x260/4
> > -
> > -  This field indicates the amount of linear contiguous memory starting
> > -  at the kernel runtime start address that the kernel needs before it
> > -  is capable of examining its memory map.  This is not the same thing
> > -  as the total amount of memory the kernel needs to boot, but it can
> > -  be used by a relocating boot loader to help select a safe load
> > -  address for the kernel.
> > -
> > -  The kernel runtime start address is determined by the following algorithm:
> > -
> > -  if (relocatable_kernel)
> > -	runtime_start = align_up(load_address, kernel_alignment)
> > -  else
> > -	runtime_start = pref_address
> > -
> > -Field name:	handover_offset
> > -Type:		read
> > -Offset/size:	0x264/4
> > -
> > -  This field is the offset from the beginning of the kernel image to
> > -  the EFI handover protocol entry point. Boot loaders using the EFI
> > -  handover protocol to boot the kernel should jump to this offset.
> > -
> > -  See EFI HANDOVER PROTOCOL below for more details.
> > -
> > -
> > -**** THE IMAGE CHECKSUM
> > -
> > -From boot protocol version 2.08 onwards the CRC-32 is calculated over
> > -the entire file using the characteristic polynomial 0x04C11DB7 and an
> > -initial remainder of 0xffffffff.  The checksum is appended to the
> > -file; therefore the CRC of the file up to the limit specified in the
> > -syssize field of the header is always 0.
> > -
> > -
> > -**** THE KERNEL COMMAND LINE
> > -
> > -The kernel command line has become an important way for the boot
> > -loader to communicate with the kernel.  Some of its options are also
> > -relevant to the boot loader itself, see "special command line options"
> > -below.
> > -
> > -The kernel command line is a null-terminated string. The maximum
> > -length can be retrieved from the field cmdline_size.  Before protocol
> > -version 2.06, the maximum was 255 characters.  A string that is too
> > -long will be automatically truncated by the kernel.
> > -
> > -If the boot protocol version is 2.02 or later, the address of the
> > -kernel command line is given by the header field cmd_line_ptr (see
> > -above.)  This address can be anywhere between the end of the setup
> > -heap and 0xA0000.
> > -
> > -If the protocol version is *not* 2.02 or higher, the kernel
> > -command line is entered using the following protocol:
> > -
> > -	At offset 0x0020 (word), "cmd_line_magic", enter the magic
> > -	number 0xA33F.
> > -
> > -	At offset 0x0022 (word), "cmd_line_offset", enter the offset
> > -	of the kernel command line (relative to the start of the
> > -	real-mode kernel).
> > -	
> > -	The kernel command line *must* be within the memory region
> > -	covered by setup_move_size, so you may need to adjust this
> > -	field.
> > -
> > -
> > -**** MEMORY LAYOUT OF THE REAL-MODE CODE
> > -
> > -The real-mode code requires a stack/heap to be set up, as well as
> > -memory allocated for the kernel command line.  This needs to be done
> > -in the real-mode accessible memory in bottom megabyte.
> > -
> > -It should be noted that modern machines often have a sizable Extended
> > -BIOS Data Area (EBDA).  As a result, it is advisable to use as little
> > -of the low megabyte as possible.
> > -
> > -Unfortunately, under the following circumstances the 0x90000 memory
> > -segment has to be used:
> > -
> > -	- When loading a zImage kernel ((loadflags & 0x01) == 0).
> > -	- When loading a 2.01 or earlier boot protocol kernel.
> > -
> > -	  -> For the 2.00 and 2.01 boot protocols, the real-mode code
> > -	     can be loaded at another address, but it is internally
> > -	     relocated to 0x90000.  For the "old" protocol, the
> > -	     real-mode code must be loaded at 0x90000.
> > -
> > -When loading at 0x90000, avoid using memory above 0x9a000.
> > -
> > -For boot protocol 2.02 or higher, the command line does not have to be
> > -located in the same 64K segment as the real-mode setup code; it is
> > -thus permitted to give the stack/heap the full 64K segment and locate
> > -the command line above it.
> > -
> > -The kernel command line should not be located below the real-mode
> > -code, nor should it be located in high memory.
> > -
> > -
> > -**** SAMPLE BOOT CONFIGURATION
> > -
> > -As a sample configuration, assume the following layout of the real
> > -mode segment:
> > -
> > -    When loading below 0x90000, use the entire segment:
> > -
> > -	0x0000-0x7fff	Real mode kernel
> > -	0x8000-0xdfff	Stack and heap
> > -	0xe000-0xffff	Kernel command line
> > -
> > -    When loading at 0x90000 OR the protocol version is 2.01 or earlier:
> > -
> > -	0x0000-0x7fff	Real mode kernel
> > -	0x8000-0x97ff	Stack and heap
> > -	0x9800-0x9fff	Kernel command line
> > -
> > -Such a boot loader should enter the following fields in the header:
> > -
> > -	unsigned long base_ptr;	/* base address for real-mode segment */
> > -
> > -	if ( setup_sects == 0 ) {
> > -		setup_sects = 4;
> > -	}
> > -
> > -	if ( protocol >= 0x0200 ) {
> > -		type_of_loader = <type code>;
> > -		if ( loading_initrd ) {
> > -			ramdisk_image = <initrd_address>;
> > -			ramdisk_size = <initrd_size>;
> > -		}
> > -
> > -		if ( protocol >= 0x0202 && loadflags & 0x01 )
> > -			heap_end = 0xe000;
> > -		else
> > -			heap_end = 0x9800;
> > -
> > -		if ( protocol >= 0x0201 ) {
> > -			heap_end_ptr = heap_end - 0x200;
> > -			loadflags |= 0x80; /* CAN_USE_HEAP */
> > -		}
> > -
> > -		if ( protocol >= 0x0202 ) {
> > -			cmd_line_ptr = base_ptr + heap_end;
> > -			strcpy(cmd_line_ptr, cmdline);
> > -		} else {
> > -			cmd_line_magic	= 0xA33F;
> > -			cmd_line_offset = heap_end;
> > -			setup_move_size = heap_end + strlen(cmdline)+1;
> > -			strcpy(base_ptr+cmd_line_offset, cmdline);
> > -		}
> > -	} else {
> > -		/* Very old kernel */
> > -
> > -		heap_end = 0x9800;
> > -
> > -		cmd_line_magic	= 0xA33F;
> > -		cmd_line_offset = heap_end;
> > -
> > -		/* A very old kernel MUST have its real-mode code
> > -		   loaded at 0x90000 */
> > -
> > -		if ( base_ptr != 0x90000 ) {
> > -			/* Copy the real-mode kernel */
> > -			memcpy(0x90000, base_ptr, (setup_sects+1)*512);
> > -			base_ptr = 0x90000;		 /* Relocated */
> > -		}
> > -
> > -		strcpy(0x90000+cmd_line_offset, cmdline);
> > -
> > -		/* It is recommended to clear memory up to the 32K mark */
> > -		memset(0x90000 + (setup_sects+1)*512, 0,
> > -		       (64-(setup_sects+1))*512);
> > -	}
> > -
> > -
> > -**** LOADING THE REST OF THE KERNEL
> > -
> > -The 32-bit (non-real-mode) kernel starts at offset (setup_sects+1)*512
> > -in the kernel file (again, if setup_sects == 0 the real value is 4.)
> > -It should be loaded at address 0x10000 for Image/zImage kernels and
> > -0x100000 for bzImage kernels.
> > -
> > -The kernel is a bzImage kernel if the protocol >= 2.00 and the 0x01
> > -bit (LOAD_HIGH) in the loadflags field is set:
> > -
> > -	is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01);
> > -	load_address = is_bzImage ? 0x100000 : 0x10000;
> > -
> > -Note that Image/zImage kernels can be up to 512K in size, and thus use
> > -the entire 0x10000-0x90000 range of memory.  This means it is pretty
> > -much a requirement for these kernels to load the real-mode part at
> > -0x90000.  bzImage kernels allow much more flexibility.
> > -
> > -
> > -**** SPECIAL COMMAND LINE OPTIONS
> > -
> > -If the command line provided by the boot loader is entered by the
> > -user, the user may expect the following command line options to work.
> > -They should normally not be deleted from the kernel command line even
> > -though not all of them are actually meaningful to the kernel.  Boot
> > -loader authors who need additional command line options for the boot
> > -loader itself should get them registered in
> > -Documentation/admin-guide/kernel-parameters.rst to make sure they will not
> > -conflict with actual kernel options now or in the future.
> > -
> > -  vga=<mode>
> > -	<mode> here is either an integer (in C notation, either
> > -	decimal, octal, or hexadecimal) or one of the strings
> > -	"normal" (meaning 0xFFFF), "ext" (meaning 0xFFFE) or "ask"
> > -	(meaning 0xFFFD).  This value should be entered into the
> > -	vid_mode field, as it is used by the kernel before the command
> > -	line is parsed.
> > -
> > -  mem=<size>
> > -	<size> is an integer in C notation optionally followed by
> > -	(case insensitive) K, M, G, T, P or E (meaning << 10, << 20,
> > -	<< 30, << 40, << 50 or << 60).  This specifies the end of
> > -	memory to the kernel. This affects the possible placement of
> > -	an initrd, since an initrd should be placed near end of
> > -	memory.  Note that this is an option to *both* the kernel and
> > -	the bootloader!
> > -
> > -  initrd=<file>
> > -	An initrd should be loaded.  The meaning of <file> is
> > -	obviously bootloader-dependent, and some boot loaders
> > -	(e.g. LILO) do not have such a command.
> > -
> > -In addition, some boot loaders add the following options to the
> > -user-specified command line:
> > -
> > -  BOOT_IMAGE=<file>
> > -	The boot image which was loaded.  Again, the meaning of <file>
> > -	is obviously bootloader-dependent.
> > -
> > -  auto
> > -	The kernel was booted without explicit user intervention.
> > -
> > -If these options are added by the boot loader, it is highly
> > -recommended that they are located *first*, before the user-specified
> > -or configuration-specified command line.  Otherwise, "init=/bin/sh"
> > -gets confused by the "auto" option.
> > -
> > -
> > -**** RUNNING THE KERNEL
> > -
> > -The kernel is started by jumping to the kernel entry point, which is
> > -located at *segment* offset 0x20 from the start of the real mode
> > -kernel.  This means that if you loaded your real-mode kernel code at
> > -0x90000, the kernel entry point is 9020:0000.
> > -
> > -At entry, ds = es = ss should point to the start of the real-mode
> > -kernel code (0x9000 if the code is loaded at 0x90000), sp should be
> > -set up properly, normally pointing to the top of the heap, and
> > -interrupts should be disabled.  Furthermore, to guard against bugs in
> > -the kernel, it is recommended that the boot loader sets fs = gs = ds =
> > -es = ss.
> > -
> > -In our example from above, we would do:
> > -
> > -	/* Note: in the case of the "old" kernel protocol, base_ptr must
> > -	   be == 0x90000 at this point; see the previous sample code */
> > -
> > -	seg = base_ptr >> 4;
> > -
> > -	cli();	/* Enter with interrupts disabled! */
> > -
> > -	/* Set up the real-mode kernel stack */
> > -	_SS = seg;
> > -	_SP = heap_end;
> > -
> > -	_DS = _ES = _FS = _GS = seg;
> > -	jmp_far(seg+0x20, 0);	/* Run the kernel */
> > -
> > -If your boot sector accesses a floppy drive, it is recommended to
> > -switch off the floppy motor before running the kernel, since the
> > -kernel boot leaves interrupts off and thus the motor will not be
> > -switched off, especially if the loaded kernel has the floppy driver as
> > -a demand-loaded module!
> > -
> > -
> > -**** ADVANCED BOOT LOADER HOOKS
> > -
> > -If the boot loader runs in a particularly hostile environment (such as
> > -LOADLIN, which runs under DOS) it may be impossible to follow the
> > -standard memory location requirements.  Such a boot loader may use the
> > -following hooks that, if set, are invoked by the kernel at the
> > -appropriate time.  The use of these hooks should probably be
> > -considered an absolutely last resort!
> > -
> > -IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and
> > -%edi across invocation.
> > -
> > -  realmode_swtch:
> > -	A 16-bit real mode far subroutine invoked immediately before
> > -	entering protected mode.  The default routine disables NMI, so
> > -	your routine should probably do so, too.
> > -
> > -  code32_start:
> > -	A 32-bit flat-mode routine *jumped* to immediately after the
> > -	transition to protected mode, but before the kernel is
> > -	uncompressed.  No segments, except CS, are guaranteed to be
> > -	set up (current kernels do, but older ones do not); you should
> > -	set them up to BOOT_DS (0x18) yourself.
> > -
> > -	After completing your hook, you should jump to the address
> > -	that was in this field before your boot loader overwrote it
> > -	(relocated, if appropriate.)
> > -
> > -
> > -**** 32-bit BOOT PROTOCOL
> > -
> > -For machine with some new BIOS other than legacy BIOS, such as EFI,
> > -LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel
> > -based on legacy BIOS can not be used, so a 32-bit boot protocol needs
> > -to be defined.
> > -
> > -In 32-bit boot protocol, the first step in loading a Linux kernel
> > -should be to setup the boot parameters (struct boot_params,
> > -traditionally known as "zero page"). The memory for struct boot_params
> > -should be allocated and initialized to all zero. Then the setup header
> > -from offset 0x01f1 of kernel image on should be loaded into struct
> > -boot_params and examined. The end of setup header can be calculated as
> > -follow:
> > -
> > -	0x0202 + byte value at offset 0x0201
> > -
> > -In addition to read/modify/write the setup header of the struct
> > -boot_params as that of 16-bit boot protocol, the boot loader should
> > -also fill the additional fields of the struct boot_params as that
> > -described in zero-page.txt.
> > -
> > -After setting up the struct boot_params, the boot loader can load the
> > -32/64-bit kernel in the same way as that of 16-bit boot protocol.
> > -
> > -In 32-bit boot protocol, the kernel is started by jumping to the
> > -32-bit kernel entry point, which is the start address of loaded
> > -32/64-bit kernel.
> > -
> > -At entry, the CPU must be in 32-bit protected mode with paging
> > -disabled; a GDT must be loaded with the descriptors for selectors
> > -__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
> > -segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
> > -must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
> > -must be __BOOT_DS; interrupt must be disabled; %esi must hold the base
> > -address of the struct boot_params; %ebp, %edi and %ebx must be zero.
> > -
> > -**** 64-bit BOOT PROTOCOL
> > -
> > -For machine with 64bit cpus and 64bit kernel, we could use 64bit bootloader
> > -and we need a 64-bit boot protocol.
> > -
> > -In 64-bit boot protocol, the first step in loading a Linux kernel
> > -should be to setup the boot parameters (struct boot_params,
> > -traditionally known as "zero page"). The memory for struct boot_params
> > -could be allocated anywhere (even above 4G) and initialized to all zero.
> > -Then, the setup header at offset 0x01f1 of kernel image on should be
> > -loaded into struct boot_params and examined. The end of setup header
> > -can be calculated as follows:
> > -
> > -	0x0202 + byte value at offset 0x0201
> > -
> > -In addition to read/modify/write the setup header of the struct
> > -boot_params as that of 16-bit boot protocol, the boot loader should
> > -also fill the additional fields of the struct boot_params as described
> > -in zero-page.txt.
> > -
> > -After setting up the struct boot_params, the boot loader can load
> > -64-bit kernel in the same way as that of 16-bit boot protocol, but
> > -kernel could be loaded above 4G.
> > -
> > -In 64-bit boot protocol, the kernel is started by jumping to the
> > -64-bit kernel entry point, which is the start address of loaded
> > -64-bit kernel plus 0x200.
> > -
> > -At entry, the CPU must be in 64-bit mode with paging enabled.
> > -The range with setup_header.init_size from start address of loaded
> > -kernel and zero page and command line buffer get ident mapping;
> > -a GDT must be loaded with the descriptors for selectors
> > -__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
> > -segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
> > -must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
> > -must be __BOOT_DS; interrupt must be disabled; %rsi must hold the base
> > -address of the struct boot_params.
> > -
> > -**** EFI HANDOVER PROTOCOL
> > -
> > -This protocol allows boot loaders to defer initialisation to the EFI
> > -boot stub. The boot loader is required to load the kernel/initrd(s)
> > -from the boot media and jump to the EFI handover protocol entry point
> > -which is hdr->handover_offset bytes from the beginning of
> > -startup_{32,64}.
> > -
> > -The function prototype for the handover entry point looks like this,
> > -
> > -    efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp)
> > -
> > -'handle' is the EFI image handle passed to the boot loader by the EFI
> > -firmware, 'table' is the EFI system table - these are the first two
> > -arguments of the "handoff state" as described in section 2.3 of the
> > -UEFI specification. 'bp' is the boot loader-allocated boot params.
> > -
> > -The boot loader *must* fill out the following fields in bp,
> > -
> > -    o hdr.code32_start
> > -    o hdr.cmd_line_ptr
> > -    o hdr.ramdisk_image (if applicable)
> > -    o hdr.ramdisk_size  (if applicable)
> > -
> > -All other fields should be zero.
> > diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
> > index 7612d3142b2a..8f08caf4fbbb 100644
> > --- a/Documentation/x86/index.rst
> > +++ b/Documentation/x86/index.rst
> > @@ -7,3 +7,5 @@ Linux x86 Support
> >  .. toctree::
> >     :maxdepth: 2
> >     :numbered:
> > +
> > +   boot
> 
> 
> 
> Thanks,
> Mauro

-- 
Cheers,
Changbin Du