⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 spec.txt

📁 linux下从网卡远程启动
💻 TXT
📖 第 1 页 / 共 2 页
字号:
  Draft Net Boot Image Proposal 0.3  Jamie Honan and Gero Kuhlmann, gero AT minix PERIOD han  PERIOD de  June 15, 1997  This is the specification of the "tagged image" format  ______________________________________________________________________  Table of Contents  1. Note  2. Preamble - the why  3. The target  4. Net Boot Process Description.  5. Image Format with Initial Magic Number.  6. Boot prom entry points.  7. Example of a boot image.  8. Terms  9. References  ______________________________________________________________________  11..  NNoottee  In order to provide more functionality to the boot rom code Jamie's  draft has been changed a little bit. All of Gero Kuhmnann's changes  are preceded and followed by ((ggkk)). All of Ken Yap's changes are  preceded and followed by ((kkyy)).  Gero Kuhlmann  22..  PPrreeaammbbllee -- tthhee wwhhyy  Whilst researching what other boot proms do (at least those  implementing TCP/IP protocols) it is clear that each 'does their own  thing' in terms of what they expect in a boot image.  If we could all agree on working toward an open standard, O/S  suppliers and boot rom suppliers can build their products to this  norm, and be confident that they will work with each other.  This is a description of how I will implement the boot rom for Linux.  I  believe it to be flexible enough for any OS that will be loaded  when a PC boots from a network in the TCP/IP environment.  It would be good if this could be turned into some form of standard.  This is very much a first draft. I am inviting comment.  The ideas presented here should be independant of any implementation.  In the end, where there is a conflict between the final of this draft,  and an implementation, this description should prevail.  The terms I use are defined at the end.  ((ggkk))IMPORTANT NOTE: The scope of this document starts at the point  where the net boot process gains control from the BIOS, to where the  booted image reaches a state from which there is no return to the net  boot program possible.((ggkk))  33..  TThhee ttaarrggeett  The target is to have a PC retrieve a boot image from a network in the  TCP/IP environment.  ((ggkk))The boot may take place from a network adaptor rom, from a boot  floppy.((ggkk))  44..  NNeett BBoooott PPrroocceessss DDeessccrriippttiioonn..  ((ggkk))The net boot process is started as a result of the PC boot  process. The net boot program can reside on a rom, e.g. on an adaptor  card, or in ram as a result of reading off disk.((ggkk))  The boot process may execute in any mode (e.g. 8086, 80386) it  desires.  When it jumps to the start location in the boot image, it  must be in 8086 mode and be capable of going into any mode supported  by the underlying processor.  The image cannot be loaded into address spaces below 10000h((kkyy:: TThhiiss  rreessttrriiccttiioonn rreemmoovveedd iinn EEtthheerrbboooott)), or between A0000h through FFFFFh,  or between 98000h((kkyy:: CChhaannggeedd ttoo 9944000000hh iinn EEtthheerrbboooott 55..xx oonnwwaarrddss))  through 9FFFFh.  ((ggkk))Only when the image is not going to return to the  boot process, all the memory is available to it once it has been  started, so it can relocate parts of itself to these areas.((ggkk))  The boot process must be capable of loading the image into all other  memory locations. Specifically, where the machine supports this, this  means memory over 100000h.  The net boot process must execute the bootp protocol, followed by the  tftp protocol, as defined in the relevant rfc's.  The file name used in the tftp protocol must be that given by the  bootp record.  If less than 512 bytes are loaded, the net boot process attempts to  display on the screen any ascii data at the start of the image. The  net boot process then exits in the normal manner. For a boot prom,  this will allow normal disk booting. ((ggkk))Reference to DOS deleted.((ggkk))  When the first 512 bytes have been loaded, the boot process checks for  an initial magic number, which is defined later. If this number is  present, the net process continues loading under the control of the  image format. The image, which is described later, tells the net boot  process where to put this record and all subsequent data.  If no initial magic number is present the net boot process checks for  a second magic number at offset 510. If the magic number 510 = 55h,  511 = AAh, then the net process continues. If this second magic number  is not present, then the net boot process terminates the tftp  protocol, displays an error message and exits in the normal manner.  If no initial magic number is present and the second one is, the net  boot process relocates the 512 bytes to location 7c00h. The net boot  process continues to load any further image data to 10000h up. This  data can overwrite the first 512 boot bytes. If the image reaches  98000h, then any further data is continued to be loaded above 100000h.  When all the data has been loaded, the net boot process jumps to  location 0:7c00.((kkyy))NNoo lloonnggeerr ssuuppppoorrtteedd iinn EEtthheerrbboooott((kkyy))  ((ggkk))When the net boot program calls the image, it places 2 far  pointers onto the stack, in standard intel order (e.g.  segment:offset  representation).  The first far pointer which immediately follows the  return address on the stack, points to the loaded boot image header.  The second far pointer which is placed above the first one, shows to  the memory area where the net boot process saved the bootp reply.  If the boot image is flagged as being returnable to the boot process,  the boot program has to provide the boot image with interrupt vector  78h. It's an interface to services provided by the net boot program  (see below for further description).  If the boot image is not flagged as being returnable to the boot  process, before the boot image is called, the boot program has to set  the system into a state in which it was before the net boot process  has started.((ggkk))  55..  IImmaaggee FFoorrmmaatt wwiitthh IInniittiiaall MMaaggiicc NNuummbbeerr..  The first 512 bytes of the image file contain the image header, and  image loading information records. This contains all the information  needed by the net boot process as to where data is to be loaded.  The magic number (in time-honoured tradition (well why not?)) is:  ______________________________________________________________________          0 = 36h          1 = 13h          2 = 03h          3 = 1Bh  ______________________________________________________________________  Apart from the two magic numbers, all words and double words are in PC  native endian.  Including the initial magic number the header record is:  ______________________________________________________________________          +---------------------+          |                     |          | Initial Magic No.   |  4 bytes          +---------------------+          |                     |          | Flags and length    |  double word          +---------------------+          |                     |          | Location Address    |  double word in ds:bx format          +---------------------+          |                     |          | Execute Address     |  double word in cs:ip format          +---------------------+  ______________________________________________________________________  The Location address is where to place the 512 bytes. The net boot  process does this before loading the rest of the image. The location  address cannot be one of the reserved locations mentioned above, but  must be an address lower than 100000h.  The rest of the image must not overwrite these initial 512 bytes,  placed at the required location. The writing of data by the net boot  process into these 512 bytes is deprecated. These 512 bytes must be  available for the image to interogate once it is loaded and running.  The execute address is the location in cs:ip of the initial  instruction once the full image has been loaded. This must be lower  than 100000h, since the initial instructions will be executed in 8086  mode. When the jump (actually a far call) is made to the boot image,  the stack contains a far return address, with a far pointer parameter  above that, pointing to the location of this header.  ((kkyy)) If bit 31 in the flags is set, then the execute address is  interpreted as a linear 32-bit address, and a call is made to this  address. There is no restriction on the range of the execute address.  The arguments to the routine are: a pointer to an Etherboot specific  header, a pointer to the tagged image header, and a pointer to the  bootp reply.  The called routine may return to the boot loader.((kkyy))  The flags and length field is broken up in the following way:  Bits 0 to 3 (lowest 4 bits) define the length of the non-vendor header  in double words. Currently the value is 4.  Bits 4 to 7 define the length required by the vendor extra information  in double words. A value of zero indicates no extra vendor  information.  ((ggkk))Bit 8 is set if the boot image can return to the net boot process  after execution. If this bit is not set the boot image does never  return to the net boot process, and the net boot program has to set  the system into a clean state before calling the boot image.((ggkk))  ((kkyy))Bit 31 is set if the execute address of the boot image is a linear  32-bit address to be called. The boot image may return to the boot  loader.((kkyy))  ((ggkk++kkyy))Bits 9 to 30 are reserved for future use and must be set to  zero.((ggkk++kkyy))  After this header, and any vendor header, come the image loading  information records. These specify where data is to be loaded, how  long it is, and communicates to the loaded image what sort of data it  is.  The format of each image loading information record is :  ______________________________________________________________________

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -