I am writing this page to present info about network boot, and
my primary topic is booting DOS-like systems from IPX/NetWare
network (from Nowell or mars_nwe server). I myself wrote a Boot-ROM
code which is dedicated to be freely copyable (w/ GNU copyleft).

Other net boot packages or info I found on net:

Newest versions I have seen: Etherboot-4.2.10 Comboot-1.2 Netboot-0.8.1

netboot - recommended in NFS-Root-HOWTO; comboot; (.pl)
netboot (home?)

Etherboot: Etherboot home page

Other info which may be helpful for booting.

1. What acts on the begin: the Boot-ROM.

1.1. General rules for boot from NetWare.

   What the server provides to aid workstation boot?

   There is a directory LOGIN on SYS volume. Files which are there
  are accessible for not-logged-in workstations. This means they
  can be accessed after: 1. sending ATTACH request to the server
  (in reply W/S gets connection id which must be used in every
  subsequent request), 2. sending LOGOUT request (this maps the
  SYS:LOGIN directory to default network drive), and of course
  3. sending OPEN request which specifies the file to be accessed
  (a directory search is also possible, and will be in example),
  which can be followed by 4. READing contents of these files.

1.2. Boot start - how BootROM gets control.

   On boot BIOS does ROM scan: it check for 55 AA sequence on
  address where it expects ROM may begin, and if found takes next
  byte as the ROM size in pages (1 page=512=200h bytes), and
  computes checksum of the ROM adding all bytes. Low byte of the
  sum must be 0 - otherwise the ROM is ignored. BIOS calls ROM
  init code, which is assumed to be at offset 3 (i.e. it starts
  on next byte after the ROM size byte), by far call. But it is
  NOT good time to boot - should return from the call, otherwise
  BIOS may fail to find other ROMs. The BootROM sets interrupt
  vector 19h to point to some code in it, and returns.
   When BIOS finishes its initialization, it invokes INT 19h.
  Normally, it points to disk boot, but BootROM has changes it,
  so it gets control. And it should boot if possible - a return
  would most likely invoke ROM Basic, if it is on the computer.

1.3. IPX packet structures.

   The IPX header is 30-byte structure:
    WORD checkSum (send -1 - this means "no checksum"),
         length (Hi-Lo, includes IPX header itself);
    BYTE transportControl (0 when sent),
         packetType (usually 11h);
    IPX_Address destination, source;
   The IPX_Address is structure:
    BYTE network[4], node[6], socket[2];
   Note all values are in Hi-Lo order. The node is same as net
  adapter's Ethernet address, FFFFFFFFFFFF means broadcast,
  network 0 means local net - use such a values in first packet.

   SAP query consists of IPX header followed by:
    WORD query_type, WORD service_type;
  query 3 is nearest, query 1 is general, service 4 is fileserver;
  note on net byte order is Hi-Lo - the data sent is 00 03 00 04.
   SAP reply consists of IPX header followed by: WORD response_type;
  and  WORD server_type; char server_name[48];
       IPX_Addresss server_address; WORD distance;
  repeated if many servers reported (on nearest service query with
  server type = 4 the response has always one entry); Novell's doc
  says the distance is in Lo-Hi order (unlike other WORDs!).

   NCP request: IPX header is followed by WORD type; BYTE sequence,
    connection, 0, 0, code; and optional data as the request needs;
    type is usually 2222h (1111h for ATTACH, 5555h for DETACH).
   NCP reply: IPX header is followed by WORD type; BYTE sequence,
    connection, ?, ?, status, ?; and optional data; the type is
    3333h for normal replies (type of 9999h means sth. special);
    the sequence in NCP reply is same as in corresponding request,
    generally requests should advance the sequence on every one,
    but seems Novell serwer accepts using same sequence again, and
    it ignores requests with other sequence number; the status of
    non-zero means an error occured during request processing;
    on receipt usual checks are: matching sequence, status=0.

   NCP ATTACH request: type=1111h, connection=0FFh, code=11h
   NCP DETACH request: type=5555h, code=0
   NCP LOGOUT request: code=19h
   NCP OPEN request: code=41h, data 1,6 name_length name; the reply
    contains 36 bytes of data, first 6 of them are file handle
   NCP READ request: code=48h, data 0 handle start[4] length[2],
    note start and length in Hi-Lo order; the reply contains data:
    WORD read_length, the_data_read

1.4. How Novell's BootROM works.

   It uses technique described above, saving original vector at
  0:300h, and setting word at 0:304h to 6a6eh, which is
  flag telling that the vectors were changed. Then returns.
   When invoked by INT 19h it first attempts to read boot sector
  from floppy A: - if succeed, it (A) restores original INT 19h
  vector and invokes it for BIOS to boot the computer as usually.
   Next it check for presence of harddisk, and if present it does
  the following: 1. some video processing - moves cursor to home
  position, asks for video mode, if 7 assumes mono else sets mode
  3 (=CO80) and sets cursor shape according to the mode, finally
  clears screen (assuming address 0B0000h for mono, 0B8000h for
  color mode, and usual size); 2. displays a question
  "Boot from Network (Y or N) ? ", and gets answer (if invalid it
  repeats the question), on N it displays CRLF and goes to A.

   Then the code is moved to segment MemTop-900h, stack is set to
  0:0c000h and jump is done to the moved code.

   After the jump it initializes video as already described and
  displays "Novell Netware Remote Program Loader", driver info,
  and Novell's copyright, then enters boot loop. In the loop it:

  - calls driver initialization code (2 procedures, the second
   may return error - ZF=0 means AX=offset of error message, in
   such a case it shows the message, displays "Error initializing
   network interface board" and waits 3 second, then retries)

  - sends packet from socket 4A58 to broadcast address with socket
   0452 (SAP=Service Advertisement Protocol socket) containing SAP
   query for nearest fileserver, and reads the reply; an immediate
   address of replying node will be used to route all requests,
   destination address net part will be used as net part of own
   address, and the FS address will be used to access the server

  - sends NCP ATTACH request from socket 4A57 (note socket change:
   it prevents receiving replies to SAP query), and gets from the
   reply connection id (ATTACH only uses connection id 0FFh)

  - sends LOGOUT request, error if no reply or invalid

  - sends OPEN requests on the following files: BOOTCONF.SYS (on
   success it is scanned, using READ requests to get data from it,
   for line for this W/S, and file specified in it is tried first),
   then NET$DOS.SYS, IBM$DOS.SYS, first successfull open on image
   file causes boot to be done from it, error if all opens fail.

  - on error a message is displayed, and after 3 second pause the
   loop is started from begin.

   The BOOTCONF.SYS is scanned for 0x,=filename, any of
  these values can be 0 to match everything, preceding 0-s can be
  omitted, scanning countinues until first match or read error.
   The boot is processed as follows: vectors 0F1h-0F4h are set
  to 5774:654E ("Netw"), copy of vector 13h, new vector 13h (it
  is changed to point to code which reads boot image), and "boot
  terminate" vector, then a "bootsector" is read from boot image
  (the most recently opened file), sectors per track and number
  of heads are took from it, and jump to it is done; then read
  from floppy is serviced by reading the boot image file

   Boot terminate sends DETACH request, and closes the socket
  used by the boot (see below why).
   The boot image is still accessible when IPX driver is loaded
  by booted system. How? The BootROM contains own "mini-IPX"
  which on every request checks if real IPX was loaded, and in
  such a case opens socket (to be able to receive packets), and
  forwards all requests to the real IPX. This of course works
  well providing that network adapter will not be accessed until
  IPX is loaded - true is using IPX.COM containing driver, and
  usually true if NDIS driver is used - note some NDIS drivers,
  in spite specification demands they must not do it, initialize
  adapter when loaded, and cause the boot to fail.

   How the Novell's BootROM is made? There is some code from
  Novell, and there is driver code from the network adapter
  manufacturer, probably they are two .OBJ-s and usual LINK
  can be used to produce .EXE, then DCONFIG/ECONFIG can be
  used to configure it (on image w/o .EXE header offsets would
  not match), and finally EXE2BIN to produce BootROM image.

1.5. My ideas about making Boot-ROMs. my bootrom code
(it was fixed Jan 25,2000 - there was extra 0 byte in "open"
 request causing the request to fail on Windows NT; fixed again
 Mar 31,2000 - allow repeating initial SAP until any reply)
You also need some program to make the rom: here it is.

   First of all, I decided to make it as simple as possible:
  the Boot-ROM is to allow some file to be read into W/S memory
  and executed; everything else can be in the file. IMHO this
  will give maximum flexibility of the boot. Later I decided to
  make it in a way simple program in e.g. Turbo C to be able to
  run without starting the system - and it required adding some
  DOS function simulation (not many, almost all were required
  to start Packet Driver, as described below).

   I wrote code which can interface standard Packet Driver - it
  supports INT 21h interface and few DOS calls for the driver
  to be able to start, and Crynwr drivers work well with it.
  I decided for it to get best flexibility - the only need to
  boot from network is to have Packet Driver for net adapter.
  In practice, not as well as expected - some drivers differ
  from "normal" so they cannot work. E.g. for OvisLink 8029R
  (RealTec 8029 - PCI "NE2000") I use NE2000 driver with PCI
  initialization code rather then driver from OvisLink.
  Also, some new network adapters have no packet drivers...

   My code moves Boot-ROM contents to RAM, prepares PSP, and
  jumps to start of the driver as it were a .COM loaded by DOS.
  After the driver ends by "Terminate and Stay Resident", it is
  used to send and receive packets. The sequence is basically
  the same as in Novell's Boot-ROM: SAP Query, Attach, Logout,
  Open... and here is a difference: I open file which name is
  specified in the Boot-ROM (it can be set, including but not
  necessarily required, the fileserver name so it boots from the
  server even if other server responds first to the SAP), and it
  is loaded into memory (address 4000h:0), and control is passed
  to the address (I wrote some code which, if put before .EXE,
  allows it to be used there, so one may use e.g. Turbo C or
  Turbo Pascal to write program, which will be executed this way
  - nice? ;-), then the program can read files from SYS:LOGIN
  directory and decide how to continue the boot.
   I have separate file which contains list of workstations, and
  for every W/S there can be specified a boot image file and
  CONFIG.SYS file (external to the boot image - one can make
  configuration with one boot image, and different CONFIG.SYS
  for each W/S, to save some disk space on copies of programs).

   I know someone had a problem w/ Novell's Boot-ROM on his net
  - it received SAP reply first from a server connected via slow
  line. Result: it booted horribly slooooooooowly. Novell's boot
  has no standard way to fix it (I made some code which can help:
  instead boot image one can put small program, which gets "good"
  server address, and then boots from it, but I already forgot
  where I have it, and it was not tested)...
   Using my Boot-ROM one can put server name in the file with
  workstations list and the program can process boot from really
  nearest server (the program only comes through the slow line).

   Some other Boot-ROM-s (Etherboot, Netboot packages) allow
  "boot image" which specifies what data is to be put at what
  memory address (there can be many parts to go to different
  addresses). Netboot also can boot simply image of boot disk.

1.6. Boot-ROM test aids: put its image on disk, and try it!
   My Boot-ROM, and Etherboot have this ability. (download)

2. What does the DOS during the network boot?

2.1. Standard DOS boot processing.

   First of all, a bootsector is read - like on normal boot from
  a disk, and the bootsector reads file named IO.SYS in MS-DOS,
  The bootsector code usually can read contiguous files only - it
  computes where the file starts on the disk, and reads as many
  consecutive sectors as necessary (or even worse is possible -
  it assumes the file starts from cluster 2 on the disk), but the
  IO.SYS can start if, I guess, 3 or 4 sectors were read - it can
  reread remaining data if necessary (MS-DOS), DRDOS simply has
  bootsector which can read non-contiguous files. Seems the file
  contains boot initialization code only, and the "DOS kernel" is
  in another one, it is MSDOS.SYS in MS-DOS, IBMDOS.COM in PC-DOS, 
  DRBDOS.SYS in DR-DOS; all DOS-es I knew used just two files.

   Another important file is CONFIG.SYS - it contains directives
  which are processed during DOS kernel configuring, they can load
  device drivers (sometimes network driver is loaded in it). These
  directives decide what will be done later - usually DOS loads
  its shell COMMAND.COM, and starts processing AUTOEXEC.BAT by it,
  but the default can be redefined in the CONFIG.SYS. A problem:
  where is the code which controls the boot? I tested it for MSDOS
  and found it is near top of "classic" RAM (the 640kB below video
  RAM area at 0A0000h); Novell's Boot-ROM used the same area for
  its boot processing, and they needed to write RPLFIX program to
  patch boot images for they protect the area from overwriting.

   The CONFIG.SYS can contain several directives, like:
  SHELL=. From MS-DOS 6.22 multiconfiguration feature was added,
  by directives like [block], MENUITEM=, MENUDEFAULT=, SUBMENU=,
  it shows menu (initially [MENU] block, can be changed if SUBMENU
  is selected) during boot, and processes selected block, setting
  CONFIG environment variable to name of last block selected, note
  can use SET CONFIG=value to get other value if needed. Example:

      MENUITEM=NET,my favorite network configuration
      SUBMENU=CHOOSE,choose other network adapter
      REM will wait 1 second to allow choosing other
      MENUITEM=SMC8000,use SMC8000 adapter
      MENUITEM=NONET,boot without network
      REM for later processing same as with NE2000 adapter
      REM reserved name, MS docs say it is processed first

2.2. Memory - how to prevent boot code overwriting? (DOS 5+ only)

    Problem: the code from Boot-ROM, data used by it, and some
   code loaded to support the boot are in area which DOS would
   overwrite if not told to avoid it. How can this be done?
   By setting INT 2Fh vector, and putting a code there which for
   AX=???? returns first paragraph it uses in ?? - MS-DOS-es 5.0+
   checks the vector, and if it is set asks and builds MCB with
   name "RPL", belonging to "SYSTEM PSP" (usually 8).

my boot program uses this during boot.
Do not forget some cleanup must be done to release the memory.

2.3. Programs to aid configuring during the boot. (here) 

    When DOS starts, and sets INT 21h, the Boot-ROM DOS-simulation
   becomes unavailable (in fact, it is turned off earlier - IRQ of
   network adapter is usually masked). There is a program, which
   can be used to copy files from SYS:LOGIN directory still until
   network adapter is initialized by a driver loaded during boot.
   It was initially NWBCOPY.EXE, and could be invoked by AUTOEXEC,
   later I wrote NWBCOPY.SYS, which can be loaded by DEVICE= in
   CONFIG.SYS. Idea: make RAMDRIVE, copy necessary files to it.
   The .SYS version has several enhancements, e.g. it can select
   RAMDRIVE as current drive (for a case it for same reason was
   other then usual C: - e.g. when the computer has harddrive).
   (the NWBCOPY.SYS is replacement for COPYFILE.SYS I wrote long
   ago, a program which could copy file accessible via DOS calls)

2.4. Necessary cleanups during boot and when it finishes.
   - disable INT 13h servicing - restore original INT 13h
   - disable network driver
   - free memory used by Boot-ROM code

Other info which may be helpful for booting.
Homepage GKM - Eprom/Flash-Service - Eprom/Flash-Programmierun
(the page offers EPROM programming in Germany, 32kB EPROM + programming 25DM)
bin2intelhex converter (C source) if eprom writer needs IntelHex
Linux boot: hints about using initrd tu run isapnp before driver init
NILO - Etherboot successor NILO home page NILO mirror
Linux Terminal Server Project
More about NILO and similar projects:
Boot: Remote Boot Howto
Boot: Grub - attempt to produce bootloader
Boot: OsKit - OS Development Kit (for creating OS-es)
Intel wfm specs (PXE pointer), local copy the PXE is here

P.K. Wong's HOWTO for booting Windows 95 diskless
Linux Remote-Boot mini-HOWTO: Configuring Remote-Boot Workstations with Red-Hat Linux, DOS, Windows 3.1 and Windows 95

A collection of jumper settings for old network cards
Ken Yap's Links (e.g. what to do with old PC)