File: spec.txt

package info (click to toggle)
mknbi 1.2.7-1
  • links: PTS
  • area: main
  • in suites: woody
  • size: 628 kB
  • ctags: 1,489
  • sloc: asm: 3,907; ansic: 1,980; perl: 1,147; makefile: 217; sh: 47; pascal: 37
file content (660 lines) | stat: -rw-r--r-- 20,228 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
  Draft Net Boot Image Proposal 0.3
  Jamie Honan and Gero Kuhlmann, gero@minix.han.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, or
  between A0000h through FFFFFh, or between 98000h 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.



  ((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 :


















  ______________________________________________________________________
            +---------------------+
            | 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