power_supply: Sharp SL-6000 (tosa) batteries support

[pandora-kernel.git] / Documentation / i386 / boot.txt

diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt
index 2f75e75..95ad15c 100644 (file)
--- a/Documentation/i386/boot.txt
+++ b/Documentation/i386/boot.txt
@@ -40,8 +40,18 @@ 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
                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
+               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.

 
 **** MEMORY LAYOUT
 
 
 **** MEMORY LAYOUT
 


@@ -170,6 +180,10 @@ Offset     Proto   Name            Meaning
 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
 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

 
 (1) For backwards compatibility, if the setup_sects field contains 0, the
     real value is 4.
 
 (1) For backwards compatibility, if the setup_sects field contains 0, the
     real value is 4.


@@ -512,6 +526,32 @@ Protocol:  2.07+
 
   A pointer to data that is specific to hardware subarch
 
 
   A pointer to data that is specific to hardware subarch
 

+Field name:    payload_offset
+Type:          read
+Offset/size:   0x248/4
+Protocol:      2.08+
+
+  If non-zero then this field contains the offset from the end of the
+  real-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. Currently only gzip compressed ELF is used.
+  
+Field name:    payload_length
+Type:          read
+Offset/size:   0x24c/4
+Protocol:      2.08+
+
+  The length of the payload.
+
+**** 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
 


@@ -544,6 +584,28 @@ command line is entered using the following protocol:
        covered by setup_move_size, so you may need to adjust this
        field.
 
        covered by setup_move_size, so you may need to adjust this
        field.
 

+Field name:    setup_data
+Type:          write (obligatory)
+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.
+

 
 **** MEMORY LAYOUT OF THE REAL-MODE CODE
 
 
 **** MEMORY LAYOUT OF THE REAL-MODE CODE
 


@@ -785,3 +847,41 @@ IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and
        After completing your hook, you should jump to the address
        that was in this field before your boot loader overwrote it
        (relocated, if appropriate.)
        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 setupping 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; __BOOS_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.