📄 spec.txt
字号:
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 + -