spec.txt

linux下从网卡远程启动

            +---------------------+
            | Flags, tags and     |  double word
            | lengths             |
            +---------------------+
            |                     |
            | Load Address        |  double word
            +---------------------+
            |                     |
            | Image Length        |  double word
            +---------------------+
            |                     |
            | Memory Length       |  double word
            +---------------------+
  ______________________________________________________________________



  Each image loading information record follows the previous, or the
  header.



  The memory length, image length and load address fields are unsigned
  32 numbers. They do not have the segment:offset format used by the
  8086.



  The flags, tags and lengths field is broken up as follows:



  Bits 0 to 3 (lowest 4 bits) are the length of the non vendor part of
  this header in double words. Currently this value is 4.



  Bits 4 to 7 indicate the length of any vendor information, in double
  words.



  Bits 8 to 15 are for vendor's tags. The vendor tag is a private number
  that the loaded image can use to determine what sort of image is at
  this particular location.



  Bits 16 to 23 are for future expansion and should be set to zero.



  Bits 24 to 31 are for flags, which are defined later.



  Vendors may place further information after this information record,
  and before the next. Each information record may have a different
  vendor length.



  There are two restrictions on vendor information.


  One is that the header and all information records that the net boot
  process is to use fall within the first 512 bytes.



  The second restriction is that the net boot process must ignore all
  vendor additions. The net boot process may not overwrite vendor
  supplied information, or other undefined data in the initial 512
  bytes.



  The flags are used to modify the load address field, and to indicate
  that this is the last information record that the net boot process
  should use.



  Bit 24 works in conjunction with bit 25 to specify the meaning of the
  load address.


  ______________________________________________________________________
            B24    B25

             0     0    load address is an absolute 32 number

             1     0    add the load address to the location one past the last byte
                        of the memory area required by the last image loaded.
                        If the first image, then add to 512 plus the location
                        where the 512 bytes were placed

             0     1    subtract the load address from the one past the
                        last writeable location in memory. Thus 1 would
                        be the last location one could write in memory.

             1     1    load address is subtracted from the start of
                        the last image loaded. If the first image, then
                        subtract from the start of where the 512 bytes were
                        placed
  ______________________________________________________________________



  (For convenience bit 24 is byte 0 of the flag field)



  Bit 26 is the end marker for the net boot process. It is set when this
  is the last information record the net boot process should look at.
  More records may be present, but the net boot process will not look at
  them. (Vendors can continue information records out past the 512
  boundary for private use in this manner).



  The image length tells the net boot process how many bytes are to be
  loaded.  Zero is a valid value. This can be used to mark memory areas
  such as shared memory for interprocessor communication, flash eproms,
  data in eproms.



  The image length can also be different from the memory length. This
  allows decompression programs to fluff up the kernel image. It also
  allows a file system to be larger then the loaded file system image.
  Bits 27 through 31 are not defined as yet and must be set to zero
  until they are.


  66..  BBoooott pprroomm eennttrryy ppooiinnttss..


  ((ggkk))As mentioned above the net boot process has to provide interrupt
  78h as an entry point in case, the returnable flag (bit 9 of the flags
  field in the image header) of the boot image has been set.  When
  calling this interface interrupt, the caller has to load the AH
  register with a value indicating the type of operation requested:


  ______________________________________________________________________
         00h  -  Installation check
                 Input:  none
                 Output: AX  -  returns the value 474Bh
                         BX  -  flags indicating what further services are
                                provided by the net boot program:
                                 Bit 0 - packet driver interface (see below)
                                 Bits 1 to 15 are unused and have to be zero

         01h  -  Cleanup and terminate the boot process services. This will
                 also remove the services provided by interrupt 87h.
                 Input:  none
                 Output: none
  ______________________________________________________________________





  Further functions are not yet defined. These functions are only
  available to boot images which have the first magic number at the
  beginning of the image header, and have the returnable flag set in the
  flags field.



  In order to provide compatibility with net boot programs written to
  match an earlier version of this document, the loaded image should
  check for the existence of interrupt 78h by looking at it's vector. If
  that's 0:0, or if it does not return a proper magic ID after calling
  the installation check function, the boot image has to assume that the
  net boot program does not support this services interrupt.



  If the bit 0 of register BX of function 00h is set, the boot program
  has to provide a packet driver <http://www.crynwr.com> interface at
  interrupt 79h as described in the packet driver interface standard,
  version 1.09, published by FTP Software, Inc., which is not repeated
  here. It serves as an interface to the system's network card. It is
  important to note that the net boot process has to provide a clean
  packet driver interface without any handles being defined when the
  boot image gets started. It is expected that the boot image sets up
  it's own TCP/IP or other network's stack on top of this packet driver
  interface.  When the boot image returns to the net boot process, it
  has to return a clean packet driver interface as well, without any
  handles being defined.((ggkk))





  77..  EExxaammppllee ooff aa bboooott iimmaaggee..


  Here is an example of how the boot image would look for Linux:


  ______________________________________________________________________
            0x1B031336,  /* magic number */
            0x4,         /* length of header is 16 bytes, no vendor info */
            0x90000000,  /* location in ds:bx format */
            0x90000200,  /* execute address in cs:ip format */

                         /* 2048 setup.S bytes */
            0x4,         /* flags, not end, absolute address, 16 bytes this
                            record, no vendor info */
            0x90200,     /* load address - note format */
            0x800,       /* 4 8 512 byte blocks for linux */
            0x800,

                         /* kernel image */
            0x4,         /* flags, not end, absolute address, 16 bytes this
                            record, no vendor info */
            0x10000,     /* load address - note format */
            0x80000,     /* 512K (this could be shorter */
            0x80000,

                         /* ramdisk for root file system */
            0x04000004,  /* flags = last, absolute address, 16 bytes this
                            record, no vendor info *//
            0x100000,    /* load address - in extended memory */
            0x80000,     /* 512K for instance */
            0x80000,

                         /* Then follows linux specific information */
  ______________________________________________________________________




  88..  TTeerrmmss


  When I say 'the net boot process', I mean the act of loading the image
  into memory, setting up any tables, up until the jump to the required
  location in the image.



  The net booting program executes the net boot process. The net boot
  program may be a rom, but not neccassarily. It is a set of
  instructions and data residing on the booting machine.



  The image, or boot image,  consists of the data loaded by the net boot
  process.



  When I say 'the PC boot process', I mean the general PC rom bios boot
  process, the setting up of hardware, the scanning for adaptor roms,
  the execution of adaptor roms, the loading in of the initial boot
  track. The PC boot process will include the net boot process, if one
  is present.


  When I say client, I mean the PC booting up.



  When I say 'image host', I mean the host where the boot image is
  comming from.  This may not have the same architecture as the client.



  The bootp protocol is defined in RFC951 and RFC1084. The tftp protocol
  is defined in RFC783. These are available on many sites.  See Comer
  1991 for details on how to obtain them.



  A bootp server is the machine that answers the bootp request. It is
  not neccessarily the image host.



  "Can" and "may" means doesn't have to, but is allowed to and might.
  "Must" means just that. "Cannot" means must not.


  99..  RReeffeerreenncceess


  Comer, D.E. 1991, Internetworking with TCP/IP Vol I: Principles,
  Protocols, and Architecture Second Edition, Prentice Hall, Englewood
  Cliffs, N.J., 1991



  Stevens, W.R 1990, Unix Network Programming, Prentice Hall, Englewood
  Cliffs, N.J., 1990