Etherboot User Manual Ken Yap and Markus Gutschke, , v5.0.7, 31 July 2002 This User Manual explains how to install, configure and use the Ether- boot package. The instructions here apply to version 5.0 of Ether- boot. ______________________________________________________________________ Table of Contents 1. About this User Manual 1.1 Purpose / Scope of this User Manual 1.2 Obtaining the most recent version of this document 1.3 Document history 1.4 Feedback 1.5 Copyrights and Trademarks 1.6 Acknowledgements and Thanks 2. Introduction to Etherboot 2.1 What is Etherboot? 2.2 Legal status of the code 2.3 What hardware is supported? 2.4 Getting help 3. Unpacking, compiling and testing the package 3.1 A short cut to getting ROM images 3.2 Unpacking the distribution 3.3 Compiling the ROM images 3.4 Adjusting the PCI IDs 3.5 Testing the ROM images 4. Setting up a diskless boot 4.1 Making a tagged image 4.2 Compiling a custom kernel 4.3 Setting up a DHCP daemon 4.3.1 REQUIRE_VCI_ETHERBOOT 4.4 Setting up a bootp daemon 4.5 Setting up a tftp daemon 5. Testing the network booting 5.1 Setting up an initrd filesystem 5.2 Setting up a NFS root filesystem 5.3 Other filesystem setups 5.4 Swap over NFS 6. Booting DOS 7. Making an Etherboot EPROM or EEPROM 7.1 Choosing the EPROM 7.2 Enabling the EPROM 7.3 Size and speed of the EPROM 8. Troubleshooting tips 9. Frequently Answered Questions 9.1 Building Etherboot 9.2 Testing Etherboot 9.3 Hardware capabilities 9.4 Booting Linux 9.5 Running X 9.6 Other client applications 9.7 Booting FreeBSD 9.8 Booting other operating systems (DOS, Windows) 9.9 Hardware issues 9.10 Drivers 9.11 Miscellaneous 10. Acknowledgements 11. Source copyrights ______________________________________________________________________ 11.. AAbboouutt tthhiiss UUsseerr MMaannuuaall 11..11.. PPuurrppoossee // SSccooppee ooff tthhiiss UUsseerr MMaannuuaall This User Manual explains how to install, configure and use the Etherboot package. The instructions here apply to version 5.0 of Etherboot. 11..22.. OObbttaaiinniinngg tthhee mmoosstt rreecceenntt vveerrssiioonn ooff tthhiiss ddooccuummeenntt This document and related documents are also kept online at the Etherboot Home Page . This will in general have the latest source distributions and documentation. 11..33.. DDooccuummeenntt hhiissttoorryy 55..00..77 22000022--0077--3311 Released as Etherboot-doc 5.0.7. 55..00..66 22000022--0033--3311 Released as Etherboot-doc 5.0.6. 55..00..55 22000011--1122--3311 Released as Etherboot-doc 5.0.5. 55..00..44 22000011--0099--1166 Released as Etherboot-doc 5.0.4. 55..00..33 22000011--0088--0055 Released as Etherboot-doc 5.0.3. 55..00..22 22000011--0066--2233 Released as Etherboot-doc 5.0.2. 55..00..11 22000011--0055--0044 Released as Etherboot-doc 5.0.1. 55..00..00 22000011--0044--2266 Released with Etherboot 5.0.0. 11..44.. FFeeeeddbbaacckk Comments on and corrections for this User Manual may be directed to the primary author . 11..55.. CCooppyyrriigghhttss aanndd TTrraaddeemmaarrkkss (C) 2001,2002 Ken Yap and Markus Gutschke. This manual may be reproduced in whole or in part, without fee, subject to the following restrictions: +o The copyright notice above and this permission notice must be preserved complete on all complete or partial copies. +o Any translation or derived work must be approved by the author in writing before distribution. +o If you distribute this work in part, instructions for obtaining the complete version of this manual must be included, and a means for obtaining a complete version provided. +o Small portions may be reproduced as illustrations for reviews or quotes in other works without this permission notice if proper citation is given. Exceptions to these rules may be granted for academic purposes: Write to the author and ask. These restrictions are here to protect us as authors, not to restrict you as learners and educators. All trademarks mentioned in this document belong to their respective owners. 11..66.. AAcckknnoowwlleeddggeemmeennttss aanndd TThhaannkkss Thanks to Markus Gutschke who wrote the first version of this document, and to all the people who have contributed information and corrections to this document. For a list of people who have contributed substantially to the code, please see the ``Acknowledgements'' section. 22.. IInnttrroodduuccttiioonn ttoo EEtthheerrbboooott 22..11.. WWhhaatt iiss EEtthheerrbboooott?? Etherboot is a software package for creating ROM images that can download code over an Ethernet network to be executed on an x86 computer. Many network adapters have a socket where a ROM chip can be installed. Etherboot is code that can be put in such a ROM. Etherboot can also be booted from floppies (mainly for testing purposes but some people have been known to use this all the time) and hard disk, as a LILO/SYSLINUX compatible image, or from a hard disk partition. Etherboot requires the PC architecture, it does not work for other Linux platforms such as Alphas or Suns. Typically the computer is diskless and the code is Linux or FreeBSD, but these are not the only possibilities. The code uses the bootp, tftp and NFS Internet Protocols, among others. For a somewhat out of date talk/tutorial type introduction to what Etherboot does and how to set it up, see my SLUG talk . You may wish to review this before reading further. 22..22.. LLeeggaall ssttaattuuss ooff tthhee ccooddee Etherboot is Open Source under the GNU General Public License Version 2 (GPL2). The license conditions can be obtained from the file COPYING in the top directory of the distribution or viewed at www.gnu.org . In particular note that if you are distributing binaries generated from Etherboot, such as ROMs or ROM images, you must provide or promise to provide the user with the source. If you have not made private changes to the code, you can do this by pointing the user to the Etherboot home page , noting the release version of course. If you have made private changes to the code, then you must distribute those changes too with binary distributions. The GPL applies to the whole package but portions may be used under other licenses. See the section on ``source copyrights'' for details, file by file. Please support Open Source by joining the community and sharing. See the Etherboot home page for some ways you can help Etherboot. _N_o _W_a_r_r_a_n_t_y _o_r _S_u_p_p_o_r_t_: _E_t_h_e_r_b_o_o_t _c_o_m_e_s _w_i_t_h _N_O _w_a_r_r_a_n_t_i_e_s _o_f _a_n_y _k_i_n_d_. _I_t _i_s _h_o_p_e_d _t_h_a_t _i_t _w_i_l_l _b_e _u_s_e_f_u_l _t_o _y_o_u_, _b_u_t _N_O _r_e_s_p_o_n_s_i_b_i_l_i_t_y _i_s _a_c_c_e_p_t_e_d _f_o_r _a_n_y _o_u_t_c_o_m_e _o_f _u_s_i_n_g _i_t_. _E_t_h_e_r_b_o_o_t _a_l_s_o _c_o_m_e_s _w_i_t_h _N_O _s_u_p_p_o_r_t_, _a_l_t_h_o_u_g_h _y_o_u _m_a_y _g_e_t _h_e_l_p_f_u_l _a_d_v_i_c_e _f_r_o_m _t_h_e _m_a_i_l_i_n_g _l_i_s_t_s _l_i_s_t_e_d _o_n _t_h_e _E_t_h_e_r_b_o_o_t _h_o_m_e _p_a_g_e_. 22..33.. WWhhaatt hhaarrddwwaarree iiss ssuuppppoorrtteedd?? The following is the current NIC configuration file as of 2002-07-29. Even if your NIC does not appear in the list, it may still be supported if the chip is one of those supported. Many OEMs use chips from foundries. An exhaustive list of brand names is impossible. The best strategy is to read the number on the LAN controller chip on the board. ______________________________________________________________________ # This is the config file for creating Makefile rules for Etherboot ROMs # # To make a ROM for a supported NIC locate the appropriate family # and add a line of the form # # ROM PCI-IDs Comment # # ROM is the desired output name for both .rom and .lzrom images. # PCI IDs are the PCI vendor and device IDs of the PCI NIC # For ISA NICs put - # Comment will be copied into config.c for display when detected # # All PCI ROMs that share a single driver are only built once (because they # only have different PCI-IDs, but identical code). ISA ROMS are built for # each ROM type, because different vendors used a different logic around the # basic chip. The most popular example is the NS8390, which some cards use # in PIO mode, some in DMA mode. Two chips currently don't fit into this nice # black-and-white scheme (the Lance and the NS8390). Their driver deals # with both PCI and ISA cards. These drivers will be treated similarly to # ISA only drivers by genrules.pl and are compiled for each ROM type that is # ISA, and additionally compiled for the PCI card type. # # Then do: make clean, make Roms and make # # Please send additions to this file to # Start of configuration family 3c595 # 3c59x cards (Vortex) and 3c900 cards # If your 3c900 NIC detects but fails to work, e.g. no link light, with # the 3c90x driver, try using the 3c595 driver. I have one report that the # 3c595 driver handles these NICs properly. (The 595 driver uses the # programmed I/O mode of operation, whereas the 90x driver uses the bus # mastering mode. These NICs are capable of either mode.) When it comes to # making a ROM, as usual, you must choose the correct image, the one that # contains the same PCI IDs as your NIC. 3c590 0x10b7,0x5900 3c595 0x10b7,0x5950 3c595-1 0x10b7,0x5951 3c595-2 0x10b7,0x5952 3c900-tpo 0x10b7,0x9000 3c900-t4 0x10b7,0x9001 3c900b-tpo 0x10b7,0x9004 3c900b-combo 0x10b7,0x9005 3c900b-tpb2 0x10b7,0x9006 3c900b-fl 0x10b7,0x900a family 3c90x # Original 90x revisions: 3c905-tpo 0x10b7,0x9000 10 Base TPO 3c905-t4 0x10b7,0x9001 10/100 T4 3c905-tpo100 0x10b7,0x9050 10/100 TPO 3c905-combo 0x10b7,0x9051 10 Base Combo # Newer 90xB revisions: 3c905b-tpo 0x10b7,0x9004 10 Base TPO 3c905b-combo 0x10b7,0x9005 10 Base Combo 3c905b-tpb2 0x10b7,0x9006 10 Base TP and Base2 3c905b-fl 0x10b7,0x900a 10 Base FL 3c905b-tpo100 0x10b7,0x9055 10/100 TPO 3c905b-t4 0x10b7,0x9056 10/100 T4 3c905b-9058 0x10b7,0x9058 0x9058 3c905b-fx 0x10b7,0x905a 10 Base FX # Newer 90xC revision: 3c905c-tpo 0x10b7,0x9200 10/100 TPO (3C905C-TXM) 3c980 0x10b7,0x9800 3c9805 0x10b7,0x9805 3csoho100-tx 0x10b7,0x7646 family eepro100 # Intel Etherexpress Pro/100 eepro100 0x8086,0x1229 82559er 0x8086,0x1209 id1029 0x8086,0x1029 id1030 0x8086,0x1030 id1038 0x8086,0x1038 82562et 0x8086,0x1039 82562em 0x8086,0x2449 family e1000 #Intel Etherexpress Pro/1000 e1000 0x8086,0x1000 e1000-fib 0x8086,0x1001 e1000-cop 0x8086,0x1004 e1000-ecop 0x8086,0x1008 e1000-creb 0x8086,0x100d family lance # Lance PCI PCNet/32 lancepci 0x1022,0x2000 pcnetfastiii 0x1022,0x2625 amdhomepna 0x1022,0x2001 AMD HomePNA ne2100 - Novell NE2100, NE1500 ni6510 - Racal-Interlan NI6510 family tulip dc21040 0x1011,0x0002 dc21041 0x1011,0x0014 Tulip+ ds21140 0x1011,0x0009 ds21140a 0x1011,0x0009 ds21142 0x1011,0x0019 Tulip 21142 ds21143 0x1011,0x0019 Tulip 21143 # Netgear FA310TX and similar Tulip clones 82c168 0x11ad,0x0002 kne110tx 0x11ad,0x0002 lc82c115 0x11ad,0xc115 LNE100TX # Macronix 987x5 Tulip clones mx98713 0x10d9,0x0512 mx98715 0x10d9,0x0531 mx98725 0x10d9,0x0531 # Another Macronix clone? mxic-98715 0x1113,0x1217 an981 0x1317,0x0981 ADMTek Centaur-P (stmicro) an983 0x1113,0x1216 ADMTek Comet 983 centaur-p 0x1317,0x0985 ADMtek Centaur-P centaur-c 0x1317,0x1985 ax88140 0x125b,0x1400 ASIX AX88140 ax88141 0x125b,0x1400 # Davicom, but using the Tulip driver dm9100 0x1282,0x9100 dm9102 0x1282,0x9102 intel21145 0x8086,0x0039 Intel Tulip rl100tx 0x11f6,0x9881 Compex RL100-TX xircomtulip 0x115d,0x0003 family davicom davicom9102 0x1282,0x9102 Davicom DM9102 davicom9009 0x1282,0x9009 family rtl8139 rtl8129 0x10ec,0x8129 Realtek 8129 rtl8139 0x10ec,0x8139 Realtek 8139 smc1211 0x1112,0x1211 SMC1211 dfe538 0x1186,0x1300 D-Link DFE538TX family via-rhine dlink-530tx-old 0x1106,0x3043 Rhine-I dlink-530tx 0x1106,0x3065 # Rhine-II via-rhine-old 0x1106,0x6100 via-rhine 0x1106,0x3065 family w89c840 winbond840 0x1050,0x0840 Winbond W89c840 compexrl100atx 0x11f6,0x2011 Compex RL100-ATX family sis900 sis900 0x1039,0x0900 SIS 900 sis7016 0x1039,0x7016 SIS 7016 family natsemi fa311 0x100B,0x0020 Netgear FA311/312 fa312 0x100B,0x0020 Netgear FA311/312 dp83815 0x100B,0x0020 DP83815 family fa311 fa311too 0x100B,0x0020 DP83815 also family tlan #olicom2326 0x108d,0x0014 TI Thunderlan family prism2_plx ma301 0x1385,0x4100 Netgear MA301 family prism2_pci # Various Prism2.5 (PCI) devices that manifest themselves as Harris Semiconductor devices # (with the actual vendor appearing as the vendor of the first subsystem) prism2_pci 0x1260,0x3873 Generic Prism2.5 PCI device hwp01170 0x1260,0x3873 ActionTec HWP01170 dwl520 0x1260,0x3873 DLink DWL-520 family ns8390 # A few NE2000 PCI clones, list not exhaustive rtl8029 0x10ec,0x8029 RealTek 8029 dlink-528 0x1186,0x0300 D-Link DE528 winbond940 0x1050,0x0940 Winbond 86C940 compexrl2000 0x11f6,0x1401 Compex RL2000 ktiet32p2 0x8e2e,0x3000 KTI ET32P2 nv5000sc 0x4a14,0x5000 NetVin 5000SC holtek80232 0x12c3,0x0058 Holtek 80232 wd - WD8003/8013, SMC8216/8416, SMC 83c790 (EtherEZ) ne - NE1000/2000 and clones 3c503 - 3Com503, Etherlink II[/16] family epic100 epic100 0x10b8,0x0005 SMC 83c170 EPIC/100 family 3c509 3c509 - 3c509, ISA/EISA 3c529 - 3c529 == MCA 3c509 family 3c515 3c515 - 3c515, Fast EtherLink ISA family eepro eepro - Intel Etherexpress Pro/10 family cs89x0 cs89x0 - Crystal Semiconductor CS89x0 family depca depca - Digital DE100 and DE200 family i82586 3c507 - 3Com507 ni5210 - Racal-Interlan NI5210 exos205 - Exos 205 family ni5010 ni5010 - Racal-Interlan NI5010 family sk_g16 sk_g16 - Schneider and Koch G16 family smc9000 smc9000 - SMC9000 family tiara tiara - Tiara, Fujitsu Lancard The following drivers have notes in the src directory, please read them: 3c515.txt 3c90x.txt cs89x0.txt sis900.txt tulip.txt ______________________________________________________________________ All Etherboot drivers are autoprobing, which means they attempt to detect the hardware addresses at which the card is installed. It's fairly easy to write a driver if you know C and are familiar with Ethernet hardware interfacing. Please read the developer manual if you wish to do so. 22..44.. GGeettttiinngg hheellpp Please join the Etherboot mailing lists . These are listed on the Etherboot home page. There is a users mailing list and a developers mailing list. The users list is for issues with building and running the software, while the developers list is for issues with features and coding. Please post questions to the Etherboot mailing lists instead of mailing me because: you get the benefit of a lot of experts seeing your question (no, I don't know everything, if only because there are many configurations I have never used); a lot of people see the question and answer and this helps them too. You will usually not get any reply from me if you email questions to me directly. I want to make the best use of my time and that is by making sure that as many people as possible see the questions and answers. Note that I will post my replies to the mailing lists so to see the answers you should subscribe, or be willing to check the archives later. Other lists you can join are the Netboot mailing list (joining details on Etherboot home page), and the Linux Terminal Server Project mailing lists at LTSP . The Etherboot and Netboot lists are for general netbooting issues, while LTSP is focused more on the LTSP packages. However there is a fair amount of overlap between the lists and many key people are on all lists. Note that the Netboot mailing list is spam protected. If your ISP has been slack security-wise and had a machine of theirs get onto one of the Open Relay Blacklists, then you will not be allowed to post. The only things I can suggest are to change your ISP to a more responsible one, or to get a Web based mailbox. I cannot help you with problems here as I do not administer the Netboot mailing list. 33.. UUnnppaacckkiinngg,, ccoommppiilliinngg aanndd tteessttiinngg tthhee ppaacckkaaggee 33..11.. AA sshhoorrtt ccuutt ttoo ggeettttiinngg RROOMM iimmaaggeess Marty Connor has set up a web form for creating a ROM image on the fly and returning it as the output of the form. If all you want is a ROM image, this could save you time building the distribution. 33..22.. UUnnppaacckkiinngg tthhee ddiissttrriibbuuttiioonn Unpack the distribution using gunzip and tar, using one of the following commands, where you replace x by the patchlevel number: ______________________________________________________________________ tar zxvf etherboot-5.0.x.tar.gz tar jxvf etherboot-5.0.x.tar.bz2 gunzip < etherboot-5.0.x.tar.gz | tar xvf - bunzip2 < etherboot-5.0.x.tar.bz2 | tar xvf - ______________________________________________________________________ If the documentation tarball was provided separately, then in addition do this: ______________________________________________________________________ cd etherboot-5.0.x ______________________________________________________________________ followed by one of the following: ______________________________________________________________________ tar zxvf ../etherboot-doc-5.0.x.tar.gz tar jxvf ../etherboot-doc-5.0.x.tar.bz2 gunzip < ../etherboot-doc-5.0.x.tar.gz | tar xvf - bunzip2 < ../etherboot-doc-5.0.x.tar.bz2 | tar xvf - ______________________________________________________________________ which will extract the documentation in a subdirectory of the Etherboot top directory. 33..33.. CCoommppiilliinngg tthhee RROOMM iimmaaggeess To build the ROM images you need a recent release of gcc and the binutils tools. This package has been compiled with the tools from a SuSE 7.1 distribution but it should work with any recent Linux or FreeBSD distribution. gas 2.9.1 is too old to handle the 16-bit code in loader.S. Use gas 2.9.5 at least. Also the "gcc 2.96" used in RedHat 7.0 (and later versions maybe) generates faulty machine code compiling Etherboot. Use kgcc from those distributions instead. You only have to go to src/, edit the options in Config and say make. We suggest you accept the default options if you are not sure what to select. This will create all the ROM images available in bin32. The .lzrom images are the same as the .rom images. Since the .lzrom images are smaller and work exactly the same, there is no real reason to use .rom images any more, unless you are nervous about compression algorithm patents. We believe the algorithm used does not infringe patents, having been in public use for some time, but we do not know all the legal ramifications. See here for more details. Here is a description of the options available: ______________________________________________________________________ User interaction options: -DASK_BOOT=n Ask "Boot from Network or from Local? " at startup, timeout after n seconds (0 = no timeout); this can be done in a more generic way by using the IMAGE_MENU, but it requires that the "bootp" server is accessible, even when booting locally. If unset, boot immediately using the default. -DANS_DEFAULT=ANS_NETWORK Assume Network to previous question (alternative: ANS_LOCAL) on timeout or Return key See etherboot.h for prompt and answer strings. -DBAR_PROGRESS Use rotating bar instead of sequential dots to indicate an IP packet transmitted. -DMOTD Display message of the day; read vendortags.html for further information. (Deprecated) -DIMAGE_MENU Allow to interactively chose between different bootimages; read vendortags.html for further information. (Deprecated) -DPASSWD Enable password protection for boot images; this requires -DIMAGE_MENU. (Deprecated) -DUSRPARMS Allow the user to interactively edit parameters that are passed to the booted kernel; you should probably enable -DPASSWD as well; this feature requires -DIMAGE_MENU. (Deprecated) -DANSIESC Evaluate a subset of common ANSI escape sequences when displaying the message of the day; this probably does not make sense unless you also define -DMOTD or at least -DIMAGE_MENU. It is possible to combine this option with -DCONSOLE_DUAL, but you have to be aware that the boot menu will no longer use ANSI escapes to be compatible with the serial console. Also be careful with your banners, as they may confuse your serial console. Generally you lose most of the ANSIESC functionality. (Deprecated) -DGFX Support extensions to the ANSI escape sequences for displaying graphics (icons or logos); this requires -DANSIESC. It probably does not make sense to use -DGFX if you have -DCONSOLE_DUAL, as the serial console normally cannot handle the GFX stuff. (Deprecated) -DSHOW_NUMERIC Display menu item labels as numbers. -DDELIMITERLINES Print a line of = characters at the start and also just before starting an image. -DSIZEINDICATOR Update a running total of the amount of code loaded so far, in kilobytes. Boot autoconfiguration protocol options: -DNO_DHCP_SUPPORT Use BOOTP instead of DHCP. -DRARP_NOT_BOOTP Use RARP instead of BOOTP/DHCP. -DREQUIRE_VCI_ETHERBOOT Require an encapsulated Vendor Class Identifier of "Etherboot" in the DHCP reply Requires DHCP support. -DALLOW_ONLY_ENCAPSULATED Ignore Etherboot-specific options that are not within the Etherboot encapsulated options field. This option should be enabled unless you have a legacy DHCP server configuration from the bad old days before the use of encapsulated Etherboot options. Boot tuning parameters: -DCONGESTED Turns on packet retransmission. Use it on a congested network, where the normal operation can't boot the image. -DBACKOFF_LIMIT Sets the maximum RFC951 backoff exponent to n. Do not set this unreasonably low, because on networks with many machines they can saturate the link (the delay corresponding to the exponent is a random time in the range 0..3.5*2^n seconds). Use 5 for a VERY small network (max. 2 minutes delay), 7 for a medium sized network (max. 7.5 minutes delay) or 10 for a really huge network with many clients, frequent congestions (max. 1 hour delay). On average the delay time will be half the maximum value. If in doubt about the consequences, use a larger value. Also keep in mind that the number of retransmissions is not changed by this setting, so the default of 20 may no longer be appropriate. You might need to set MAX_ARP_RETRIES, MAX_BOOTP_RETRIES, MAX_TFTP_RETRIES and MAX_RPC_RETRIES to a larger value. Boot device options: -DCAN_BOOT_DISK Can boot from floppy/hd if bootimage matches the pattern "/dev/[fhs]d*". -DTRY_FLOPPY_FIRST If > 0, tries that many times to read the boot sector from a floppy drive before booting from ROM. If successful, does a local boot. It assumes the floppy is bootable. Requires -DCAN_BOOT_DISK. -DEMERGENCYDISKBOOT If no BOOTP server can be found, then boot from local disk. The accessibility of the TFTP server has no effect, though! So configure your BOOTP server properly. You should probably reduce MAX_BOOTP_RETRIES to a small number like 3. Boot image options: -DTAGGED_IMAGE Add tagged image kernel boot support (Recommended). -DAOUT_IMAGE Add a.out kernel boot support (generic). -DELF_IMAGE Add generic ELF kernel boot support (Recommended). -DIMAGE_MULTIBOOT Add Multiboot image support (currently only for ELF images). Without this, generic ELF support is selected. -DIMAGE_FREEBSD Add FreeBSD image loading support (requires at least -DAOUT_IMAGE and/or -DELF_IMAGE). -DFREEBSD_KERNEL_ENV Pass in FreeBSD kernel environment -DAOUT_LYNX_KDI Add Lynx a.out KDI support -DDOWNLOAD_PROTO_TFTP If defined, boots by TFTP (Recommended). -DDOWNLOAD_PROTO_NFS If defined, boots from a NFS mount and disables TFTP loading. Default is DOWNLOAD_PROTO_TFTP if neither is defined. Console options: -DCONSOLE_CRT Set for CRT console (default if nothing else is set). -DCONSOLE_SERIAL Set for serial console. -DCONSOLE_DUAL Set for CRT and serial console, see comment at -DANSIESC and -DGFX. -DCOMCONSOLE Set port, e.g. 0x3F8. -DCONSPEED Set speed, e.g. 57600. -DCOMPARM Set Line Control Register value for data bits, stop bits and parity. See a National Semiconditor 8250/ 16450/16550 data sheet for bit meanings. If undefined, defaults to 0x03 = 8N1. -DCOMPRESERVE Ignore COMSPEED and COMPARAM and instead preserve the com port parameters from the previous user of the com port. Examples of previous user are a BIOS that implements console redirection, lilo and LinuxBIOS. This makes it trivial to keep the serial port speed setting in sync between multiple users. You set the speed in the first user and the rest follow along. BIOS interface options: -DPCBIOS Compile in support for the normal pcbios -DLINUXBIOS Compile in support for LinuxBIOS -DBBS_BUT_NOT_PNP_COMPLIANT Some BIOSes claim to be PNP but they don't conform to the BBS spec which specifies that ES:DI must point to the string $PnP on entry. This option works around those. This option must be added to LCONFIG. -DNO_DELAYED_INT Take control as soon as BIOS detects the ROM. Normally hooks onto INT18H or INT19H. Use only if you have a very non-conformant BIOS as it bypasses BIOS initialisation of devices. This only works for legacy ROMs, i.e. PCI_PNP_HEADER not defined. This option was formerly called NOINT19H. -DBOOT_INT18H Etherboot normally hooks onto INT19H for legacy ROMs. You can choose to hook onto INT18H (BASIC interpreter entry point) instead. This entry point is used when all boot devices have been exhausted. This option must be added to LCONFIG. -DCONFIG_PCI_DIRECT Define this for PCI BIOSes that do not implement BIOS32 or not correctly. Normally not needed. Only works for BIOSes of a certain era. -DCONFIG_TSC_CURRTICKS Uses the processor time stamp counter instead of reading the BIOS time counter. This allows Etherboot to work even without a BIOS. This only works on late model 486s and above. -DPXELOADER_KEEP_UNDI For implementation later with UNDI. -DIBM_L40 This option uses the 0x92 method of controlling A20 instead of the traditional method of using the keyboard controller. An explanation of A20 is here: http://www.win.tue.nl/~aeb/linux/kbd/A20.html This occurs on MCA, EISA and some embedded boards, and sometimes with the Fast Gate A20 option on some BIOSes. Enable this only if you are sure of what you are doing. Obscure options you probably don't need to touch: -DPOWERSAVE Halt the processor when waiting for keyboard input which saves power while waiting for user interaction. Good for compute clusters and VMware emulation. But may not work for all CPUs. -DT503_AUI Use AUI by default on 3c503 cards. -DMOVEROM If your motherboard does not cache adapter memory space, then this option can speed up loading of compressed BOOT-Prom images. It has no effect on uncompressed images. Unless you are very tight on free space, you will usually want to define this option. This option must be added to LCONFIG! (Recommended). -DUSE_LOWMEM_BUFFER Define to put some buffers below 0x10000 which may interfere with other programs (Deprecated). ______________________________________________________________________ 33..44.. AAddjjuussttiinngg tthhee PPCCII IIDDss You may have to set the PCI vendor and device IDs correctly for PCI NICs. Look at the file NIC. Locate the line that has the correct PCI IDs for your NIC. This will give you the name of the ROM image you should use. The PCI IDs are usually displayed by the BIOS on booting up. They can also be read out from a running Linux system using the Linux PCI Utilities . If you do not use the ROM with the correct IDs, the floppy version will work, but the ROM will not since the BIOS will check for a match. 33..55.. TTeessttiinngg tthhee RROOMM iimmaaggeess You can test the image with a floppy before programming an EPROM. On Linux just put a blank floppy in fd0 and say make bin32/card.fd0 where card is the name of your network card and it will copy a bootable image onto the floppy. If you wish to do this by hand, it's easy, just make bin/boot1a.bin and prepend this to card.rom (or card.lzrom) and write this combined binary to the floppy raw, i.e. starting at the boot block. Like this, after you have done a make to create all the images: ______________________________________________________________________ cat bin/boot1a.bin bin32/3c509.lzrom > /dev/fd0 ______________________________________________________________________ Make sure the floppy has no bad blocks. It is best if it has been formatted just before use. You do not need to put any kind of filesystem on it. If you wish, you could substitute /dev/fd0 with the actual device suitable for the floppy size you are using, for example /dev/fd0H1440 for 1.44 MB floppies. This may be more reliable than using the autodetecting device /dev/fd0. This will also work on a hard disk partition, but as this is a riskier operation, you should read the instructions in boot1a.s. If you don't understand how to do it, please ask the mailing list for help, don't just try it and destroy your disk data. When you boot with this floppy it will load the Etherboot ROM image from floppy and execute it. If you chose the correct ROM image, it should be able to detect your card. To get the bootrom to acquire an IP address and load the intended code, you need to set up bootp or DHCP, tftp and NFS services, which we will discuss next. We suggest you continue to use floppy booting until you have completed the setup of the server and are satisfied that diskless booting works. In addition, you can generate images with the suffixes .com, .lilo, .lzlilo and .pxe. Where you would normally say: ______________________________________________________________________ make bin32/3c509.rom ______________________________________________________________________ you would say ______________________________________________________________________ make bin32/3c509.com ______________________________________________________________________ and similarly for .lilo, .lzlilo and .pxe. These are alternate boot image formats. The ones ending in .com are DOS format executables, suitable for starting from DOS. It requires a real DOS environment, not a virtual DOS environment such as that provided by the DOS prompt window under Windows. Also it requires that there be no XMS drivers or other memory handlers loaded. It is not guaranteed to work if the environment is not clean, and sometimes not even if it is. The best chance of this format working is when DOS is booted with no device drivers whatsoever. If you can, use raw floppy or SYSLINUX booting instead. The ones ending in .lilo and .lzlilo look sufficiently like Linux kernel images to be accepted by LILO and SYSLINUX for installation. Unfortunately loadlin uses a slightly different method of booting for Linux kernels from LILO and SYSLINUX and will not work with these images. The difference between .lilo and .lzlilo is compression, analogous to the difference between .rom and .lzrom. The fact that .(lz)lilo images look like a Linux kernel to LILO and SYSLINUX allows some interesting booting possibilities. For example, you could use LILO to select between DOS/Windows and Etherboot images from a disk that contains no Linux partitions, only FAT based partitions. This HOWTO shows you how this can be arranged. The ones ending in .pxe can be booted by a PXE booter. This is useful to chain to Etherboot from PXE. Here are some notes on how to combine PXE and Etherboot. In addition you can generate .dsk and .lzdsk images. These are just the .rom or .lzrom with the disk loader already prepended, and the size padded out to 18 kB, for reasons of filling out a floppy track. The make command is similar to those above. 44.. SSeettttiinngg uupp aa ddiisskklleessss bboooott In this section I assume you want to boot a Linux kernel. Booting a FreeBSD kernel is documented elsewhere and does not require a tagged image. Booting a DOS kernel is similar, the main differences being in the way you set up the tagged image. 44..11.. MMaakkiinngg aa ttaaggggeedd iimmaaggee Etherboot expects to download a tagged image containing the code to be executed. Briefly explained, a tagged image is a wrapper around the pieces of code or data that need to be put in various places in the computer's memory. It contains a directory telling how large the pieces are and where they go in memory. It also says where to start execution. A tagged image is created using a utility program. The utility program is specific to the kernel you want to load. The version for Linux is called mknbi-linux or mkelf-linux and that for DOS is mknbi-dos. These utilities are distributed separately and can be obtained from Etherboot web site . 44..22.. CCoommppiilliinngg aa ccuussttoomm kkeerrnneell You will almost certainly have to compile a custom kernel because the kernel needs to have the "Root file system on NFS" option compiled in. (You need to select "NFS filesystem support" as built-in, not a module, and possibly also "Kernel level autoconfiguration" before this option will appear.) You should also select "BOOTP support" and/or "DHCP support". "RARP support" is not needed. In 2.2 kernels you have to enable the "Kernel level autoconfiguration" option under IP networking to access the BOOTP support question. And unless you are using an initrd (initial ramdisk) you will have to compile in the driver for your network card too. For details, see the file /usr/src/linux/Documentation/nfsroot.txt in a Linux kernel source distribution. After you have compiled the custom kernel, make the tagged image, typically like this: ______________________________________________________________________ mknbi-linux --output=/tftpdir/vmlinuz.xterm zImage ______________________________________________________________________ (See an important note regarding IP autoconfig in kernels in the 2.2 series 2.2.18 and after under the section --ip= in the mknbi-linux documentation .) Then put the tagged image in where the tftp daemon expects to find it, in this example /tftpdir. Make sure it is world-readable because typically the tftp daemon runs as an unprivileged user. It is recommended that you set a path explicitly for tftpd instead of relying on any defaults. For example: ______________________________________________________________________ tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpdir ______________________________________________________________________ 44..33.. SSeettttiinngg uupp aa DDHHCCPP ddaaeemmoonn You need to set up a DHCP server to hand out an IP address and other configuration information to the client. The main requirement of the DHCP server is that it needs to send out suitable configuration information. Prior to version 5.0.7, Etherboot accepted any DHCP offer (but see REQUIRE_VCI_ETHERBOOT below for an exception). In version 5.0.7 and above, Etherboot will not accept any DHCP offer where the server IP is empty (all zero) or the filename is empty. These offers are useless to Etherboot anyway so ignoring these offers will give it a better chance of picking the right DHCP server. If you already have a DHCP server on your network for providing Windows clients with IP addresses, chances are that it is not a suitable DHCP server because it's only tailored to the single purpose of handing out client addresses. Suitable DHCP servers include the ISC DHCPD, available for most Unix/Linux systems. You can run such a DHCP server in parallel with the Windows one, provided you do not attempt to give Windows clients leases, in which case there would be a clash. You can exclude Windows clients in two ways. One is to register the only the MAC addresses of the diskless clients in /etc/dhcpd.conf, and to make sure that the server is declared "not authoritative". The second is to look for the Vendor Class Identifier of "Etherboot-5.x" in the DHCP discover packet. If you already have a DHCP server on your network that does provide the server IP and the filename, then you have to either use that DHCP server by editing its configuration file. This may require the cooperation of the system admin if you are not the admin. If you are not able to configure the DHCP server, then proceed to the section on REQUIRE_VCI_ETHERBOOT. The minimum information you need to put in /etc/dhcpd.conf is: 1. The domain name of the machine. 2. The Ethernet (MAC) address of the network card, which you generally obtain from a sticker on the card, a configuration program for the card, or in the last resort, from watching the output of Etherboot or from the packets sent from the card when trying to boot, using the debug option of DHCPD. 3. The name of the tagged image file, relative to the tftpdir directory. 4. The IP address you intend to give it. 5. The TFTP server defaults to the DHCP server if not specified with next-server. Here is a sample DHCP configuration for ISC dhcpd: ______________________________________________________________________ option domain-name "ken.net.au"; option domain-name-servers 192.168.0.1; option broadcast-address 192.168.0.255; use-host-decl-names on; subnet 192.168.0.0 netmask 255.255.255.0 { filename "/tftpdir/vmlinuz.xterm"; host xterm { hardware ethernet 08:00:2B:B7:F3:80; fixed-address xterm.ken.net.au; filename "/tftpdir/vmlinuz.xterm"; } } ______________________________________________________________________ The declaration "use-host-decl-names on" tells dhcpd to include the name xterm in the reply so that it can be used as part of pathname to mount by NFS, etc. If your tftp server is not the same as the DHCP server, use the next- server declaration to specify a tftp server. You don't have to use fixed addresses, of course, but if you use dynamic addresses, then you have to deal with the resulting issues of NFS mounting. Recent kernels in the 2.2 series can autoconfigure using DHCP thanks to code by Chip Salzenberg. It also can use DHCP in 2.4 kernels starting from 2.4.4 thanks to Eric Biederman. Otherwise the kernel will do a bootp request to find the IP address for mounting the NFS filesystem. You may also wish to investigate the --rootdir=rom option in mknbi- linux which tells the kernel to take the address from the initial DHCP reply, or to use initrds in conjunction with a userland DHCP client program to configure the netbooted machine. 44..33..11.. RREEQQUUIIRREE__VVCCII__EETTHHEERRBBOOOOTT You may need to Etherboot in an environment where you have to install your own DHCP server, and it may interfere with the existing DHCP server. Etherboot has a feature designed to overcome this problem. It consists of two parts: The first part is Etherboot contains code that when it sends out a DHCPDISCOVER request, a tag containing a Vendor Class Identifier of "Etherboot-x.y" is sent out, where x.y is the version number, currently 5.0. The 5 and the 0 are printable digits, not binary values, i.e. byte values 53 and 48 respectively. This allows the server to identify Etherboot clients and ignore all others. The second part is Etherboot can be conditionally compiled to require a Vendor Encapsulated Option containing a VCI of "Etherboot", otherwise it will ignore the DHCPOFFER. The option is not compiled in by default because it would cause Etherboot to not boot in plain setups. The server we want to respond will include this tag in DHCPOFFERs and while other servers (e.g. Windows servers) may respond, they will be ignored. Vendor Encapsulated Option is supported in ISC DHCPD 2 or 3. (It's not documented in DHCPD 2, but it works.) Other DHCP servers may support VEO. (It's a RFC2132 option.) In ISC DHCPD 3, follow the documentation for declaring a VEO scope. In ISC DHCPD 2 the magic line required is: ______________________________________________________________________ option vendor-encapsulated-options 3c:09:45:74:68:65:72:62:6f:6f:74:ff; ______________________________________________________________________ Put this in the appropriate scope. Translation: Vendor Encapsulation Options (Option 43) encloses: Vendor Class Identifier (Option 60 = 0x3c), length 9, value "Etherboot"; End of Options (Option 255 = 0xff). If you have a DHCP server already running for the subnet, you probably should specify that your additional ISC DHCPD server is not authoritative for the the subnet, or it will veto (NAK) existing client IP address allocations, upsetting the status quo. See the ISC DHCPD options documentation. Here is a practical document < http://www.geocrawler.com/archives/3/5299/2001/7/100/6129709/> describing how it is done. More information about DHCP can be found at the DHCP FAQ Web Page . If you are on a local network that is not directly connected to the Internet, you can use the "private" IP addresses 192.168.x.y (or in the other ranges mentioned in RFC1918 ). Otherwise please ask either your network administrator or your Internet service provider for your own IP address(es). 44..44.. SSeettttiinngg uupp aa bboooottpp ddaaeemmoonn You could use a bootp daemon instead of a DHCP daemon. This means installing the bootp package, sometimes it's not supplied or installed by default in some distributions. Then you need to make sure that the bootps service is active in /etc/inetd.conf; it should look something like this: ______________________________________________________________________ bootps dgram udp wait root /usr/sbin/tcpd bootpd ______________________________________________________________________ Then you need to edit /etc/bootptab. The essential pieces of information you need to put in bootptab are similar to /etc/dhcpd.conf. Here is an example of a /etc/bootptab for the bootpd supplied with many Linux distributions and probably many versions of Unix: ______________________________________________________________________ .default:\ :ht=ethernet:\ :hd=/tftpdir:bf=null:\ :ds=nameserver:\ :hn:to=36000: xterm.ken.net.au:tc=.default:ha=08002BB7F380:ip=192.168.0.100:bf=vmlinuz.xterm ______________________________________________________________________ The first entry sets up some common defaults which applies to all succeeding entries which can be "included" using the tc=.default attribute. The first field is the domain name of the machine. The ha attribute is the Ethernet address. The ip attribute is self- explanatory. The bf field specifies the tagged image filename. For more details, consult the bootptab man page. There is a bug in some old versions of bootpd where unnecessarily large reply packets are sent, causing packet fragmentation at the UDP level, and dropping of the packets by Etherboot. Either get a recent bootpd or use DHCPD. DHCPD can emulate bootpd if that's what you really want. But for various reasons, DHCPD is prefered to bootpd. Please note that if you use the ef (extension file) attribute to be able to send more configuration data to the diskless machine, you must run bootpef everytime bootptab is modified. 44..55.. SSeettttiinngg uupp aa ttffttpp ddaaeemmoonn Now set up a tftp daemon. This means installing the tftp package and making sure that the tftp service is active in /etc/inetd.conf. If you want to be very careful you may wish to use the secure (-s) option of tftpd, this chroots to the specified directory, but then your pathnames in bootptab or dhcpd.conf must be relative to the new root directory. If you are booting many clients you should be aware of the limitations of running tftpd from inetd. Typically inetd has limits on how often a daemon can be spawned, to detect runaway daemons. If many clients request the tftp service within a short period, inetd may shutdown that service. If you have a setup where there are many clients, it may be better to use an improved replacement for inetd, such as xinetd. Another solution is to run a dedicated tftpd that is not spawned from inetd. One such tftpd can be found here at: ftp://nilo.on.openprojects.net/pub/nilo/snapshots Another possible contender is in the directory atftp at the Etherboot web site. This one is started from inetd, but thereafter multithreads internally. 55.. TTeessttiinngg tthhee nneettwwoorrkk bboooottiinngg Now when you start up Etherboot, it should obtain an IP address and print out what it received. If you do not get this to work, turn on debugging in bootpd and see if any query was received. You may also wish to use the tcpdump or ethereal utilities to watch the network for bootp packets (port bootps). If not, check your network hardware (cables, etc). If a query was received, check if bootpd/dhcpd was able to give an answer. If not, then the Ethernet address was not found in /etc/bootptab or /etc/dhcp.conf. If a reply was sent, then only faulty hardware or a bug in Etherboot would prevent it being received by Etherboot. Assuming an IP address was received, the next thing Etherboot tries to do is load a file using tftp. Check your system logs to see if a tftp daemon was started up and a file requested. Generally if you run tftpd under tcpwrapper security, a log entry will be generated. If not, it could be a path problem or file permission problem (the file needs to be readable by tftpd). Another problem could be that tftpd needs to reverse map the IP address to a name for security checking, and you don't have the client's details in /etc/hosts or in DNS, or your tcpwrapper config files (/etc/hosts.deny, /etc/hosts/allow) do not allow the access. Fix the problem. After the tagged image is loaded, Etherboot will jump to it. If it crashes here, check that the image is a tagged image. If it executes and stops at the point where it's trying to mount the NFS root, and you intend to use kernel space NFS root (see next two sections), then you need to check that you have the "root on NFS" option compiled in and that you have compiled in the network card driver. 55..11.. SSeettttiinngg uupp aann iinniittrrdd ffiilleessyysstteemm Recent advances in the Linux kernel (2.4 and above) have made the use of an initrd that does user space autoconfiguration and mounting of a NFS root filesystem, followed by a pivot_root, a more flexible alternative to kernel autoconfiguration and mounting of a NFS root filesystem. Postings on the kernel mailing lists indicate that at some point in the future, kernel level autoconfiguration (BOOTP/DHCP from the kernel) may be removed from the Linux kernel and initrds will be the recommended way to start up a diskless system. Until I have time to write detailed instructions on how to construct the initrd, I refer you to the LTSP distribution which uses this technique. Mknbi supports initrds, see the ramdisk argument of mknbi-linux . The Linux kernel documentation describes the extra arguments should be passed to the kernel to make it use an initrd, and how to arrange the initrd so that the startup script within it is called when it's mounted. If the initrd mounts a NFS root filesystem then it should still have all the needed structure as explained in the next section. Initrds can also be used for mounting other network filesystems instead of NFS root. Some applications could even run totally out of initrd, e.g. Floppy Firewall , provided you have the memory, of course. 55..22.. SSeettttiinngg uupp aa NNFFSS rroooott ffiilleessyysstteemm The NFS root filesystem for the diskless computer is typically placed under /tftpboot/, provided your DHCP server sends the hostname in the reply, otherwise it may be under /tftpboot/. This NFS root needs to contain a complete root filesystem that will make the kernel boot happily. This means, for most kernels, it should contain /dev, /proc, /etc, /sbin, /bin, /tmp and /var. The details vary from distribution to distribution. Once you have got the initial filesystem mounted, you can mount additional network filesystems such as /usr or /opt to give you a full execution environment. See the FAQ section for various methods of constructing a NFS root filesystem. There is no one true method. In the method I use I was lazy so I just made a copy of the necessary files from an existing Linux filesystem on the server and modify some key files appropriately. You can find a rather dated description in my tutorial and some shell scripts to copy the files. Since distributions have moved on since I wrote the scripts, you will have to adapt it to your needs. Since the amount of disk space needed is relatively small in these days of large disks, I don't bother to throw out things that may not be needed. One thing to be aware of is that when you host the root filesystem on a NFS server that is not Linux, the major and minor numbers of device files will be different from what Linux is expecting, so the init process will probably break just after it mounts the root NFS, maybe when it tries to open the console device. You must create the root filesystem so that it is Linux compatible, even though it is hosted on a different Unix. One way might be to use cpio to capture a Linux root FS and then to unpack on the target Unix system. Warning: Do not attempt to reuse the root filesystem of your server, whether by exporting it directly or by making hard links (symbolic links will not work). First of all, the configuration files will contain information pertaining to the server, not the client, so your client will get the wrong information. Secondly, this is a security risk. NFS is already not totally safe, but this way you are directly exposing your server root to clients. Even if you make hard links, the clients could (maliciously or accidentally) overwrite key binaries, making the server unusable. Don't try to save a few megabytes of disk space this way. You can however share some directories between clients, typically /sbin, /bin and /lib. The sample scripts in the tutorial show you how. The root filesystem should be exported rw and no_root_squash because the various processes need to be root and need to write to log files in the root partition. You may wish to export /usr and /home filesystems to the diskless computer also. These do not need no_root_squash permission, and in the case of /usr probably only needs to be ro. Otherwise you will be opening up a security hole for hacking the server from the client. Be aware that practically all Linux distributions have a few "bugs" relating to symlinks and so forth for diskless booting. These are mentioned in the tutorial. 55..33.. OOtthheerr ffiilleessyysstteemm sseettuuppss This tutorial does not cover all possible ways of setting up a diskless client's initial filesystem. The initrd method and the NFS root method described above are two ways. You could even mount a conventional hard disk. Why would you want to boot "diskless" if you have a hard disk? Reasons might be: you do not wish to adminster the local disk; you want the assurance that a system is running a kernel from a central server; or you like the speed of network booting. Network booting is one technique in a toolbox. Techniques can be combined to do what you want. If you are interested in running the diskless client as an X-terminal, a very common use, you may wish to investigate the Linux Terminal Server Project . 55..44.. SSwwaapp oovveerr NNFFSS Swap over NFS can be arranged but you have to patch the kernel source. See here . Be aware that opinions are divided on NFS swap. Some people think it's a bad thing because it just kills the network if you have lots of diskless computers and that you shouldn't be running into a swap regime on a diskless computer anyway. Some other people like having a bit of insurance. Also have a look at the NBD Network Block Device web page for swapping over that. This requires a 2.1 or 2.2 kernel. There is also the follow-on project ENBD , the Enhanced Network Block Driver. I have no experience with this for swapping. Comments welcome. 66.. BBoooottiinngg DDOOSS What about DOS? The deal with DOS is that one is loading a virtual floppy called A: into extended memory and then booting from this floppy. So you have to capture an image of a bootable DOS floppy first. Some more details can be found in the mknbi-dos utility. I have booted DOS (both M$ versions up to 5.0 and DR versions up to 7.03) diskless this way. A mknbi-fdos is available for building tagged images for booting FreeDOS, the procedure differs slightly from booting M$ or DR DOS. If you were thinking of booting a Windows machine via the network, it seems (I'm not masochistic enough to do this) the problem is not the network booting but the mounting of a file system over NetBIOS (Windows does not do remote mounts of root filesystems over NetBIOS on TCP). So that rules out a Samba server. It appears to be possible over a Netware server, for which Linux or FreeBSD has workalikes. Also it is said that only certain versions of Windows will allow diskless booting. You will also have problems with pathnames and the usual Windows hassles. Do you really want to do this? You do know that you can run lots of desktop applications like Netscape, StarOffice, etc. on Linux, FreeBSD, etc. now? Why pay good money when you can use equally good free replacements? Anyway if you are still determined, in the Etherboot home page , there are links to external Web pages, one explaining how this was done with a commercial TCP/IP boot ROM, another explaining how to do it using Etherboot and Netbios over IPX. A recent user experience is here . Good luck and send us your experiences or better still a URL to a page explaining how you did it. 77.. MMaakkiinngg aann EEtthheerrbboooott EEPPRROOMM oorr EEEEPPRROOMM Assuming you have satisfactorily set up your server environment, you may now wish to put the Etherboot onto an EPROM or EEPROM. Naturally this assumes access to hardware to program (and possibly erase) EPROMs. Access to a friendly electronics engineer and/or lab is one way to program and erase EPROMs. Otherwise you can look at the commercial links page for places you can buy programmed EPROMs from. If you are familiar with electronics construction, an alternative is to use an EEPROM card. There is a schematic and PCB artwork for such a card at the web site where you got the Etherboot distribution. This EEPROM card plugs onto the ISA bus and can be reprogrammed with software. Some high-end network cards, for example the 3Com 905B, have a socket for an EEPROM which can be programmed in situ with the right utilities. See any release notes accompanying Etherboot for more information. 77..11.. CChhoooossiinngg tthhee EEPPRROOMM Most network cards come with a blank (E)EPROM socket even though it is seldom used. When it is used, it is typically filled with a proprietary EPROM from the network card manufacturer. You can put an Etherboot EPROM there instead. 77..22.. EEnnaabblliinngg tthhee EEPPRROOMM First you must discover how to enable the EPROM socket on your card. Typically the EPROM is not enabled from the factory and a jumper or a software configuration program is used to enable it. 77..33.. SSiizzee aanndd ssppeeeedd ooff tthhee EEPPRROOMM Secondly, you must discover what size and speed of EPROM is needed. This can be difficult as network card manufacturers often neglect to provide this information. The smallest EPROM that is accepted by network cards is an 8k EPROM (2764). 16kB (27128) or 32kB (27256) are the norm. Some cards will even go up to 64kB EPROMs (27512). (You will often see a C after the 27, e.g. 27C256. This indicates a CMOS EPROM, which is equivalent to the non-C version and is a good thing because of lower power consumption.) You want to use the smallest EPROM you can so that you don't take up more of the upper memory area than needed as other extensions BIOSes may need the space. However you also want to get a good price for the EPROM. Currently the 32kB and 64kB EPROMs (27256 and 27512) seem to be the cheapest per unit. Smaller EPROMs appear to be more expensive because they are out of mainstream production. If you cannot find out from the documentation what capacity of EPROM your card takes, for ISA NICs only, you could do it by trial and error. (PCI NICs do not enable the EPROM until the BIOS tells the NIC to.) Take a ROM with some data on it (say a character generator ROM) and plug it into the socket. Be careful not to use an extension BIOS for this test because it may be detected and activated and prevent you from booting your computer. Using the debug program under DOS, dump various regions of the memory space. Say you discover that you can see the data in a memory window from CC00:0 to CC00:3FFF (= 4000 hex = 16384 decimal locations). This indicates that a 16kB EPROM is needed. However if you see an alias in parts of the memory space, say the region from CC00:0 to CC00:1FFF is duplicated in CC00:2000 to CC00:3FFF, then you have put an 8kB EPROM into a 16kB slot and you need to try a larger EPROM. Note that because pinouts for 28 pin EPROMs are upward compatible after a fashion, you can probably use a larger capacity EPROM in a slot intended for a smaller one. The higher address lines will probably be held high so you will need to program the image in the upper half or upper quarter of the larger EPROM, as the case may be. However you should double check the voltages on the pins armed with data sheet and a meter because CMOS EPROMs don't like floating pins. If the ROM is larger than the size of the image, for example, a 32 kB ROM containing a 16 kB image, then you can put the image in either half of the ROM. You will sometimes see advice to put two copies of the image in the ROM. This will work but is not recommended because the ROM will be activated twice if it's a legacy ROM and may not work at all if it's a PCI/PnP ROM. It is tolerated by Etherboot because the code checks to see if it's been activated already and the second activation will do nothing. The recommended method is to fill the unused half with blank data. All ones data is recommended because it is the natural state of the EPROM and involves less work for the PROM programmer. Here is a Unix command line that will generate 16384 bytes of 0xFF and combine it with a 16 kB ROM into a 32 kB image for your PROM programmer. ______________________________________________________________________ (perl -e 'print "\xFF" x 16384'; cat bin32/3c509.lzrom) > 32kbimage ______________________________________________________________________ The speed of the EPROM needed depends on how it is connected to the computer bus. If the EPROM is directly connected to the computer bus, as in the case of many cheap NE2000 clones, then you will probably have to get an EPROM that is at least as fast as the ROMs used for the main BIOS. This is typically 120-150 ns. Some network cards mediate access to the EPROM via circuitry and this may insert wait states so that slower EPROMs can be used. Incidentally the slowness of the EPROM doesn't affect Etherboot execution speed much because Etherboot copies itself to RAM before executing. I'm told Netboot does the same thing. If you have your own EPROM programming hardware, there is a nice collection of EPROM file format conversion utilities here . The files produced by the Etherboot build process are plain binary. A simple binary to Intel hex format converter can be found at the Etherboot web site here . Etherboot is believed to make PnP compliant ROMs for PCI NICs. A long- standing bug in the headers has been tracked down. However some faulty old BIOSes are out there so I have written a Perl script swapdevids.pl to switch the header around if necessary. You'll have to experiment with it both ways to find out which works. Or you could dump a ROM image that works (e.g. RPL, PXE ROM) using the Perl script disrom.pl. The fields to look at are Device (base, sub, interface) Type. It should be 02 00 00, but some BIOSes want 00 00 02 due to ambiguity in the original specification. 88.. TTrroouubblleesshhoooottiinngg ttiippss +o Floppy boot doesn't work. Is the floppy error-free? Have you copied the ROM image (with the disk loader prepended) to the floppy raw? Is that size of floppy bootable by your computer? Are you trying to run Etherboot on a 16 bit machine (286, 086/088)? Have you selected too many compile time options? The real limit on Etherboot is not the size of the EPROM but the fact that it executes in the 48kB region between 0x94000 and 0xA0000. If the sum of code, stack and bss is greater than 48kB, then Etherboot might crash at unexpected places. +o Floppy version works but EPROM version doesn't work. There is a program called rom-scan (Linux, FreeBSD and DOS versions) in the directory contrib/rom-scan which will help detect problems. Rom- scan will only work on ISA ROMs though. +o If the EPROM is not detected at all then the contents of the EPROM are not visible to the BIOS. Check that you have enabled the EPROM with any jumpers or soft configuration settings. Check that you do not have any conflicts in the memory address of the EPROM and any other hardware. Perhaps you have to prevent it from being mapped out by your BIOS settings. Or perhaps you have to shadow it with RAM. Maybe you put the code in the wrong half or wrong quarter of the EPROM. Maybe the access time of the EPROM is not low enough. You can also use the debug program under BIOS to examine the memory area in question. +o If rom-scan says the EPROM is present but not active, then something prevented the BIOS from seeing it as a valid extension BIOS. This could be truncation of the EPROM window, maybe you have a larger EPROM in a slot meant for a smaller one. Maybe there is a checksum error in the EPROM due to some bits not properly programmed or the EPROM not being fast enough. In one case that we know of, the 3c503 network card, the ASIC actually returns 2 bytes of 80 80 in the end locations of the EPROM space. This apparently is a kind of signature. The makerom program in Etherboot compensates for this, but if the pattern is not 80 80, then the code needs to be modified. +o If rom-scan says the EPROM is present and active, but BIOS does not see it, then perhaps the EPROM is located in an area that the BIOS does not scan. The range scanned is supposed to be 0xC0000 to 0xEF800 in increments of 2kB but I have seen some BIOSes that continue the scan into the 0xF0000 page. Note that rom-scan will also detect other extension BIOSes mounted on your computer, for example VGA BIOSes and SCSI adapter BIOSes. This is normal. For PCI NICs there may be a different reason why the ROM does not work. The PCI IDs of the ROM must match those of the NIC controller chip or the BIOS will ignore the ROM. The floppy version does not undergo this check since it isn't directly called from the BIOS. As mentioned before in the ``configuration instructions'', you must use the ROM image with the correct PCI IDs for your NIC. +o Etherboot does not detect card. Are you using the right ROM image? Is the card properly seated in the computer? Can you see the card with other software? Are there any address conflicts with other hardware? Is the PCI id of the card one that is not known to Etherboot yet? In this case and where you think there is a bug in Etherboot, please submit a report to the Etherboot-users mailing list. +o Etherboot detects card but hangs computer after detection. Some cards are booby traps while they are enabled. The typical offenders are NE2000s which will hang the bus if any access is made to the reset addresses while interrupts are active. You may need to do a hard reset of the computer, i.e. power down and up again before running Etherboot. +o Etherboot detects card but does nothing after saying Searching for server. Check your network hardware. Did you select the right hardware interface (AUI, BNC, RJ45)? Is the cabling ok? If you have a Unix computer on the network and have root privileges, you could run tcpdump or ethereal looking for broadcast packets on the bootps port. If the requests are getting sent out but no replies are getting back, check your bootpd setup. Also check if the server has a route to the client. +o Etherboot obtains IP address but fails to load file. Check the tftp server. Is the tagged image file installed? Is the file world readable? Is the path to the file allowed by the configuration of tftpd? Is the client denied by tcpwrapper rules? Did you put the right home directory and boot filename in bootptab? If you are booting lots of clients, is inetd shutting down tftpd for being spawned too often? If so, you need to get a better inetd or a a dedicated tftpd that runs as an independent daemon. +o Etherboot loads file but hangs halfway through the transfer. We have one report that this happens if the Fast A20 Gate option is selected in the BIOS setup. The A20 issue is explained here . In effect this causes the loaded kernel to overwrite Etherboot and kill it. Etherboot (as of writing, version 5.0.5) does not yet have the smarts to detect when Fast A20 Gate is in effect and do the right thing. So don't select the option. You don't need it for Linux anyway. +o Etherboot loads file via tftp but Linux fails to boot. This is a large category. Here are some suggestions: +o You do not have a private copy of the /, /etc, /var, ... directories +o Your /dev directory is missing entries for /dev/zero and/or /dev/null or is sharing device entries from a server that uses different major and minor numbers (i.e. a server that is not running Linux). +o Your /lib directory is missing libraries (most notably libc* and/or libm*) or does not have the loader files ld*.so* +o You neglected to run ldconfig to update /etc/ldconfig.cache or you do not have a configuration file for ldconfig. +o Your /etc/inittab and/or /etc/rc.d/* files have not been customised for the clients. For example if you set the wrong IP address in your client's init files you could interfere with the server. +o Your kernel is missing some crucial compile-time feature (such as NFS filesystem support, booting from the net, transname (optional), ELF file support, networking support, driver for your ethernet card). +o Missing init executable (in one of the directories known by the kernel: /etc, /sbin, ?). Remember /sbin/init must be a real file, not a symlink. +o Missing /etc/inittab +o Missing /dev/tty? +o Missing /bin/sh +o System programs that insist on creating/writing to files outside of /var (mount and /etc/mtab* is the canonical example) The essence is that you must provide whatever is needed in the NFS root filesystem that your kernel needs to boot. This is somewhat distribution dependent. In the discussion mentioned above I solved the problem by making a copy of an existing root filesystem and modifying a few bits. Be aware that some, if not all, distributions contain bugs in their layout that hinder diskless mounting so you will have to fix any problems that arise. An example was a directory in /usr/X11R6/lib that needed to be writable, however /usr was mounted read-only. Another common problem is the assumption in init scripts that /usr is available before NFS mounts are done and invoking programs under /usr/sbin. +o Etherboot works fine and kernel starts but network interface doesn't work. Check your network configuration in the OS. Etherboot uses polled I/O and not interrupt I/O to fetch the images. So the IRQ line doesn't get exercised. This manifested itself in one case with a NIC that could netboot but network programs run afterwards couldn't receive any packets. It seemed to be a combination of a weak NIC IRQ line and a fussy motherboard. But the same thing could happen if say the IRQ is not set to where the software is expecting it. The image will load fine with the wrong IRQ but the software will not run properly. This is more of an issue with say DOS packet drivers, where the user has to specify the IRQ line than with Linux, which autoprobes. 99.. FFrreeqquueennttllyy AAnnsswweerreedd QQuueessttiioonnss Please check this section if you have a problem before asking on the mailing lists. 99..11.. BBuuiillddiinngg EEtthheerrbboooott 1. What do I need to build Etherboot? You need gcc, gas and objcopy, as well as any accompanying libraries and include files. Generally speaking on a package based system using RPM or DEB, you will need the C compiler package, the include file package, the C library package, the assembler package and the binutils package (this may include the assembler). You will also need perl if you modify the file NIC or use a different RELOCADDR value in the Makefile than the default, and m4 if you modify this file userman.xsgml. 2. I get an error from as saying data32 is an unknown directive or it has errors assembling loader.S or boot1a.s. Your gas is too old, upgrade to 2.9.5. 3. I get warnings about ljmp *. They are harmless, you can ignore these. They are due to changes in the assembler syntax between gas versions. We could get rid of the warnings if we could easily detect which patches are installed in the version of gas you are using (it's not just a matter of detecting the gas version) but we'd rather just wait for the old gas versions to disappear since they are just warnings. 4. The documentation talks about mknbi-linux and mknbi-dos. Where are they? These are distributed from the Etherboot web site . 5. Why don't you provide prebuilt ROM images? Etherboot is constantly updated, and binary images would get out of date soon. Binaries can lose any external indication of what release they were from. Old binaries might float around and create problems for users who are not aware that bugs have been fixed in newer versions. Also there are some user configurable options you might want to change. For this reason, Etherboot is provided in source form for you to build. However you might wish to check out rom-o-matic.net , which is a site that makes ROM images for you on demand from specifications given to a web form and returns the image as the result of the form. 99..22.. TTeessttiinngg EEtthheerrbboooott 1. I put the ROM image on floppy like you wrote (cat bin/boot1a.bin bin32/foo.rom > /dev/fd0, or make bin32/foo.fd0) but the loader prints out an error. The floppy you use should be an error-free, preferably a recently formatted floppy. Do not trust new floppies; they have been known to lose their manufacturer formatting in storage. You don't need to put a filesystem of any sort on it, FAT or ext2 or otherwise. Another possible cause is that there are alignment differences between the drive used to write the floppy and that used on the target machine. Another possible reason is you are not using a 1.44 MB floppy. The boot sector boot1a.s may not work on other floppy sizes. If you find this is the case, then try substituting floppyload.S for boot1a.s as the value of DISKLOADER in the Makefile. This boot sector should work on all floppy sizes (1.44M, 720k, and even 1.2M and 360k if you can still find these), but beware of differences between drives, e.g. writing a 360k floppy in a 1.2M drive creates narrow tracks which may not overwrite previous contents. 2. My network adapter is detected but I get no reply to the BOOTP/DHCP request. Do you have a BOOTP or DHCP server running on the same Ethernet segment? On many operating systems the server is not enabled by default. Review the instructions in the Troubleshooting section. Another thing to note is that the BOOTP (or DHCP in fixed address mode) server will not reply if it does not know the network adapter's Ethernet address. Since the address may be hard to determine if it is not printed on the card or you do not have the adapter's setup program, you can copy it from Etherboot's startup message. Remember to restart the server if you have edited the config file and the server does not automatically reread when it discovers an updated config file. Another thing to check is that the BOOTP or DHCP server is allowed to receive the query. You may have some protection mechanism such as tcpwrappers or a firewall in front of it. As the booting computer does not have an IP address, the request will come from 0.0.0.0 so your rules must allow through packets from this address. If the BOOTP or DHCP server is on another Ethernet segment, things get more complicated. You need to run a BOOTP or DHCP relay. You will probably also need to set the gateway field in the reply so that TFTP will work across the gateway. You should read a good explanation of how these work, in say, W. Richard Steven's book TCP/IP Illustrated. 3. Etherboot gets the BOOTP/DHCP parameters but cannot find a TFTP server. Do you have a TFTP server installed and running and is it allowed to serve the client in question? For example the tcpwrapper rules may not allow TFTPD to respond to the IP address the booting computer is at. You should look at the log files on the server for any clues. 4. The TFTP server is found but it replies Access violation. Access violation is a blanket reply for many different problems but essentially the TFTP server cannot give Etherboot the file requested. Did you put the file where TFTPD expects to find it, e.g. on a directory that is on its path? Did you make the file world readable? Case of the filename is important too. Check the log files on the TFTP server to see what the actual filename it tried to open was, sometimes directory prefixes are prepended to the name due to the program options specified. 5. I made this kernel and put it in /tftpdir like you wrote but Etherboot says Unable to load file. Is the file a tagged image? You cannot use a ordinary kernel image, you must process it with mknbi-linux first. 6. I have this proprietary boot ROM (e.g. LanWorks, PXE, etc) and I used mknbi-linux to make a tagged image, (or I got this tagged image from the LTSP project), but the boot ROM doesn't load it, or it fails to run. Tagged image format is specific to Etherboot and Netboot. It will not work with proprietary boot ROMs. You have to find out from the supplier what boot procedures you should use. For example, if you are using a LanWorks boot ROM, the information you need is here . 7. Why don't you use some standard format instead of tagged image format? First of all, tagged image format actually precedes many of the proprietary formats in use today. So we were there first. Secondly there is no acknowledged standard for the boot image format, although there are some contenders now. Perhaps some day there will be an open, widely-accepted format. Until then you have to aware that there are different ones out there. 99..33.. HHaarrddwwaarree ccaappaabbiilliittiieess 1. What network cards are supported? See an earlier section in this manual. 2. I have a machine with the X processor and Y megabytes of memory. What can I expect to run on it? Please note that these estimates are approximate: +o On a 386 with at least 4MB of memory you can boot Linux. With 4MB perhaps only a few telnet sessions are possible. With 8MB you might be able to run a text based web browser like Lynx or W3M. You can also run firewalls such as floppyfw . +o On a 486 with 16MB of memory you can run X to make an X-terminal. +o On a Pentium with 32MB of memory you can run an X-terminal and some applications locally, say perhaps printing, daemons to control devices, etc. +o On anything faster and with more memory you could perhaps do distributed computation, e.g. a Beowulf cluster. 99..44.. BBoooottiinngg LLiinnuuxx 1. The kernel loads but it cannot configure the network device. Did you compile the network adaptor driver into the kernel? Is the network adaptor at an address that is probed by the driver? If not, perhaps you need to provide some kernel parameters to help it find the hardware. 2. The kernel loads but it cannot mount a root filesystem, then it asks me to insert a floppy. Did you build the kernel with the root on NFS option? You cannot use a stock kernel from a distribution. Another reason might be you are running a recent kernel (2.2.18 and higher in the 2.2 series, not known from what release number in the 2.4 series) where IP Autoconfiguration is not enabled by default. You need to add ip=dhcp or ip=bootp to the kernel parameters (this requires mknbi-1.1 and above). Or you can use the append= option in mknbi-1.0 to add this option. 3. The kernel loads but it cannot find a NFS server for the root filesystem. Do you have a NFS server running and is it allowed to serve this client? NFS is actually several services. On Linux at least you need: nfsd (either kernel or userland version), rpc.mountd and portmapper. Check if the tcpwrappers config file is allowing portmapper to receive the request. Look at the log files for clues. Did we already mention that log files are your friends? 4. The root filesystem mounts but it says something about not being able to open an initial console. Or alternatively, various services complain about not being able to write to the filesystem. A common mistake in Linux NFS servers is to put extra spaces in /etc/exports. Please see the NFS FAQ for frequently answered questions about Linux NFS services. Please review the Troubleshooting section for what is required on this root filesystem. The situation is complicated by the fact that there are many possible ways of setting this up, including using a root filesystem that is on ramdisk. If you wish to avoid many of the troubles, try using a packaged solution such as LTSP . 5. What is the recommended way of setting up the NFS root? There is no one true way, but several approaches. Network booting is a tool and a very flexible one. Here are just a few suggestions: a. You can make a separate NFS root for each client, but share the sharable files between clients using hard links to minimise disk space requirements. This is the approach I took in my tutorial . I used this because I was lazy, I have only a couple of diskless clients and I could copy the files from an existing distribution. Note that these scripts may need changing for your distribution, I used it on a RedHat 5.2 system long ago. If you don't feel up to understanding what needs to be fixed, see the next item. b. You could use the packaged solution from LTSP , which creates a shareable NFS root for multiple clients. c. August Hoerandl describes his approach which uses a ramdisk for the initial startup, and then merges in a readonly NFS filesystem. d. It is rumoured that the Debian distribution has a package called diskless that contains Perl scripts to create such a filesystem. If you have an approach which you think the world should know about, please send the URL of a web page that describes it to me . 99..55.. RRuunnnniinngg XX 1. I tried to run X on the client but it aborted. Remember that the config files used by the X server should pertain to the client's video adapter and display hardware. If you used a LTSP package, please review the configuration directions. If you used the copy files from server solution, then you need to customise the X server configuration. Another thing that may cause the server to abort is lack of a mouse device. 2. X -query server runs but all I get is a gray stippled screen. Either you don't have an XDM server running on the server machine or it is not allowed to serve this client. In the latter case check XDM's Xaccess file, because for security reasons, the ability for clients to connect is usually disabled. 3. When I am logged in using an X-terminal, I find that the floppy drive, sound card and name of the computer are those of the server!? This is to be expected! This is exactly how an X-terminal works. You are indeed logged onto the server and the client just provides display (screen) and input device (keyboard and mouse) services to the application. This is one of the beauties of the X Windowing system model, it's _n_e_t_w_o_r_k _t_r_a_n_s_p_a_r_e_n_t. 4. So how do I run applications on the client? I have this (smartcard reader, printer, sound card, etc) program that must execute locally. The client can be configured to allow you to run programs locally. What you have to do is either start the application from the init scripts run during bootup, as would be the case for the printer and sound daemons mentioned later; or to start a shell interpreter on the client, either through an interactive login to the client or a remote execution of a command from the server to the client. Common methods are rsh (insecure) and ssh (better). 5. X applications cannot find (some) fonts. Do you have an X font server (XFS) running on the server machine, is it allowed to serve this client, and has the client been told to use the font server? The last point is usually configured in the XF86Config file, or by a xset command to modify the font path after logging in. Also note that RedHat (and possibly other distributions) has made XFS by default serve only the local machine using a Unix socket. You need to modify the startup script to tell XFS to use a TCP/IP socket. 6. How much CPU power and memory do I need on the client? On the server? It depends on the configuration. There are two major cases: where the client is an X-terminal, and not much more; and where the client is configured to run applications locally. An X server will fit in 16MB of memory, and 32MB is quite adequate. Performance depends on the CPU, video card and your expectations. An old Pentium 200 with a PCI video card does very well, but if you are not fussy, a high-end 486 with a VLB video card can be satisfying too. If you want to run apps locally, well how long is a piece of string? Netscape will need say another 16MB. It all depends. Whatever you do, it's worth trimming down on the services you run on the client. Don't run more virtual consoles than you need and don't run unneeded daemons. As for the server, in the X-terminal case this has all the applications running on it, so it should be adequate for the multiuser aspect. A high-end Pentium, with 64 MB of memory to start with, and between 8 and 16MB for each extra client is a good starting point. It will also depend on your mix of client access, statistically perhaps not everybody will be running at the same time. Remember that you don't have to have one big server for all your clients, you can and you should distribute the load across servers. 99..66.. OOtthheerr cclliieenntt aapppplliiccaattiioonnss 1. How can I print to a printer attached to a diskless client? There is a server program called p910nd at the Etherboot web site (and modified versions of it at LTSP ) that funnels data from a TCP/IP connection to the printer port. You can instruct lpd or CUPS on the server to send jobs across the network to p910nd. 2. How can I output sound on the client? There is a package called virtualfs that proxies the sound devices across the network. It can also proxy the floppy drive. Another solution is EsounD You may wish to check the LTSP site and mailing lists for other proposed solutions. 3. How can I access the floppy on the client? Besides virtualfs mentioned above, recent distributions of mtools have a floppyd. This only works with the mtools utilities though. 99..77.. BBoooottiinngg FFrreeeeBBSSDD 1. Where are the instructions for booting FreeBSD? For now, there is just a short document in the doc directory. Better versions of this document depend on contributions from the FreeBSD community, I am unable to test FreeBSD because I don't run it. 99..88.. BBoooottiinngg ootthheerr ooppeerraattiinngg ssyysstteemmss ((DDOOSS,, WWiinnddoowwss)) 1. I want to boot FreeDOS. The new mknbi utility supports creating tagged images from FreeDOS kernels now. See the man page for details. FreeDOS is a moving target and the layout of the kernel image or other things may have changed so you would need to be well acquainted with FreeDOS. Please send any corrections to me. 2. I cannot boot DR-DOS 7.03. There is some difference between the DR-DOS 7.03 and 7.02 bootblock that causes it not to boot. But a 7.02 bootblock works just as well with the DR-DOS 7.03 kernel, so you can substitute that. There are instructions to extract the bootblock in the AT netbooting document . 3. DOS dies when I load HIMEM.SYS. Use the /testmem:off option to prevent HIMEM from scribbling over the ramdisk which is the floppy A:. 4. How do I make A: my real floppy again after booting is complete? Use the rmrd.com program supplied with mknbi . 5. I want to use the real floppy at the same time I am using the ramdisk image of the boot floppy. The --harddisk option of mknbi is intended for this. It causes your boot drive to be C:, so you can use A: for the real floppy. See the man page for more details 6. I want to boot Windows. I pass on this one, as I do not have (by choice) any Windows systems running on my computers. Perhaps others can contribute to this section. However I gather that it is only possible on Windows95A, as other versions don't have the necessary support for diskless booting. 99..99.. HHaarrddwwaarree iissssuueess 1. Where can I get an EPROM made? Depending on where you live, you might find a supplier listed on the Commercial Links page. Another possibility is to seek the help of someone working in a university or industrial lab who has an EPROM programmer. If you are handy with hardware, you could buy a kit or build your own. There are links to kit suppliers in the Commercial Links part of the home page. Some high end adapters, for example the 3Com and Intel ones, accept an EEPROM in the socket. This can be programmed in-situ using utility programs, some of which or information about are under the contrib directory in the Etherboot distribution. Finally some recent motherboard have flash BIOSes which contain space where an extension BIOS such as Etherboot can be inserted. The Phoenix Award BIOSes can be modified using a program called cbrom.exe possibly here . It is also reputed to live here . Or do a Web search for it. No success has been reported for AMI BIOSes. Dirk von Suchodoletz maintains a list of successes and failures here . Here is some text contributed by Dirk von Suchodoletz. He hopes to put it on a web site someday: ___________________________________________________________________ 6.4 Using your mainboard's BIOS to integrate etherboot-code Newer mainboards that have an AWARD-BIOS can use etherboot without separate EPROMS and therefore without the necessity of having a EPROM-programmer[?]. (Heinrich Rebehn wishes to add: Flashing the BIOS is always a (small) risk. Flashing with unsupported, hacked BIOS image is *dangerous* and may render your PC unbootable. If you don't have access to a PROM burner you should stay away from experimenting.) In order to do this, you need 2 software tools: awdflash.exe, which should be included in your mainboard package, and cbrom.exe, which is an OEM-tool that allows modifications of the BIOS. awdflash.exe reads and writes the flashrom content, whereas cbrom.exe is used to analyse the content of the AWARD BIOS image. cbrom.exe can also add code to the BIOS image or remove components. This way you can easily integrate etherboot into your mainboards without even opening the PC's case. After the BIOS image has been saved (e.g. as bios.bin), or in case the current version of the BIOS has been copied from the board manufacturer's website, 'cbrom bios.bin /d' shows how much space is left on the image for your code. As the flashrom holds the compressed BIOS, cbrom will also compress the code when adding it to the BIOS. Therefore, 8 to 20 kbyte of free memory is needed, depending on the network adapter's driver. In case not enough memory is left, unneeded BIOS components can be removed from the BIOS image to regain space: the manufacturer's logo or the Symbios/NCR SCSI-code are note needed for diskless systems. 'cbrom bios.bin /[pci|ncr|logo|isa] release' will remove those unnecessary components. The command line "cbrom bios.bin /[pci|isa] bootimg.rom [D000:0]" adds the compiled etherboot code to the bios. bootimg.rom is the code we would use to burn onto EEPROMs in other cases. Depending on your network card, either the pci or isa options have to be used. With isa cards you have to tell cbrom to which RAM location the code will be extracted at boot time. Attention: Compile the etherboot with the -DASK_BOOT or -DEMERGENCYDISKBOOT option to be able to access a disk. The code added by cbrom will be executed before the computer seeks for a boot disk or floppy. 6.5 Booting with a DOS executable (COM) file If the computer has to be used with more than one operating systems, for example using the computer as an X-Terminal in addition to the already installed NT on the harddrive, etherboot has to be used with the compile-time option -DASK_BOOT. In case hardware-conflicts between Windows NT and the installed EPROM exist, creating DOS Executables (e.g. using 'make rtl8139.com') can provide a useful remedy. Those DOS Executables are comparable in their functionality to .rom images and can be used as substitutes. In case an existing DOS-bootsector, stored in BOOTSECT.DOS, cannot be used, creating one has to be done by formatting and installing a harddrive using DOS before installing NT (see Win-NT Multiboot-HOWTO). In addition the DOS system files are needed (IO.SYS, MSDOS.SYS, or KERNEL.SYS when using Freedos) and have to be copied into the directory of the NT loader. If using Autoexec.bat to start the .COM file is desired, either the particular COMMAND.COM has to be provided or the etherboot file needs to be renamed as COMMAND.COM. This file will then be started instead of the DOS-Shell which is useful for avoiding unwanted user interaction. Afterwards a line has to be added to BOOT.INI as if DOS was to be booted: [boot loader] timeout=20 default=C:\bootsect.dos #add this line if dhcp/tftp should be default action [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows NT Workstation, Version 4.0" [VGA-Modus]" /basevideo /sos C:\bootsect.dos="DHCP/TFTP (Linux diskless via etherboot)" #our boot option ___________________________________________________________________ And here are some comments by Rapp Informatik Systeme GmbH about cbrom.exe versions: ______________________________________________________________________ Some more remarks for cbrom.. There are several version numbers of cbrom.exe p.e. 1.x and 2.x. and there is a cbrom called cbrom6.exe. First cbrom.exe with Version 1.x (newest 1.32) is for Award Bios Version 4.5x and cbrom6.exe is for Award Bios Version 6.xx. So because it seems a lot people become confused and use cbrom 1.x for the new 6.x Bios Award merged this together to a cbrom.exe with Version number 2.x ( newest know 2.04) witch now runs on Award 4.5x and 6.xx Bioses. Now how to find cbrom.exe. Different 1.x Versions of cbrom.exe could be found on the net, cbrom6.exe seems to be gone. It seems that Award/Phoenix do all that cbrom is deleted from servers of board manufactures. So cbrom.exe Vers 2.04 is not available on the net. If somebody need this please try to send a demand question to the list - I hope somebody will mail it to you. ______________________________________________________________________ 2. How do I enable the ROM socket on my network adapter? There are no jumpers on the card. These jumperless cards need a card-specific utility program to enable the ROM. Normally the manufacturer supplies it on a diskette or CDROM. You lost the diskette? If you know the manufacturer, you might be able to get the program from their website. You have a mystery card? Well the first thing to do is to identify the card. If it is an ISA card and made in Taiwan or China it's almost certainly a NE2000 clone. For some information, try here . If it's a PCI card, then either the BIOS or the Linux PCI Utilities should be able to tell you the manufacturer and device IDs, which you can then look up to convert to names. 3. I would like to boot my laptop diskless from a floppy containing Etherboot. The problem is that laptops these days use PCMCIA network adapter cards. These in turn connect to the PCMCIA controller when docked. To be able to communicate with the PCMCIA card, Etherboot would first have to talk to the PCMCIA controller. Until somebody writes the code to do this... Booting from disk is different because the kernel will load the PCMCIA controller code from disk first. You could always put a Linux kernel on the boot floppy. 99..1100.. DDrriivveerrss 1. There is no Etherboot driver for my network adapter. Can you write me one? If I were independently wealthy and had nothing else to do in life, sure! But unfortunately I have a day job and Etherboot is a hobby. A couple of the drivers were written for pay and the others were written by volunteers. Perhaps you might like to volunteer? If you have a good grasp of C, and understand basic hardware concepts, it is quite doable, and not nearly as difficult as writing a Linux device driver. See the developer manual . You will have the reward of understanding hardware intimately and seeing your work benefit users worldwide. If you are a commercial entity, you might consider assigning staff or hiring a volunteer to write the driver. You get the benefit of the rest of the Etherboot code infrastructure and users worldwide get to appreciate your contribution. Bear in mind the ``GPL'' license conditions, of course. NIC manufacturers note, this may be one way to attract users to your hardware products. NIC users note, petition your NIC manufacturer to support Etherboot. 2. I see that my network adapter is supported in Linux but not in Etherboot. Can I use the Linux driver in Etherboot? Or maybe you can adapt the Linux source for me. I can send you the Linux driver source if you just say the word. No, the structure of Linux and Etherboot drivers are quite different. There are several reasons: Linux drivers are more complicated and written to give good performance, whereas Etherboot drivers are written to be simple. Linux drivers are interrupt driven, whereas Etherboot drivers are polling. Linux drivers have an elaborate support structure, whereas Etherboot drivers are fairly self-standing. Finally Etherboot drivers have a difficult constraint on the amount of memory available to it, about 48kB near the top of 640kB. But... you can use Linux drivers as a source of reverse-engineering information. Several of the drivers in Etherboot were adapted from Linux drivers. But don't send me the driver source; see previous FAQ about volunteering. And I have the latest Linux source anyway, doesn't everyone? 99..1111.. MMiisscceellllaanneeoouuss 1. I don't understand something, or I have a question not covered by this list. Please see the section on ``getting help'' earlier in this document. 1100.. AAcckknnoowwlleeddggeemmeennttss The following people have contributed substantially to Etherboot. If you feel your name has been left out, just let me know and I will fix it up. MMaarrkkuuss GGuuttsscchhkkee Co-author of Etherboot. He was the person who ported the Netboot suite from FreeBSD. He has enhanced Etherboot with many features, one new driver and has contributed various utilities and addons. GGeerroo KKuuhhllmmaannnn The original mknbi utilities used by Etherboot are from Netboot. He has also clarified the original specification by Jamie Honan. JJaammiiee HHoonnaann Jamie started Netboot off by writing the first version that used code from a packet driver. MMaarrttiinn RReenntteerrss eett.. aall The original authors of Netboot on FreeBSD. BBrruuccee EEvvaannss Created bcc compiler used by Etherboot/16 (16 bit ROMs are no longer supported). RRoobb ddee BBaatthh Current maintainer of bcc and associated tools like as86, used in older versions of Etherboot to assemble the x86 assembly language files. GGeerrdd KKnnoorrrr Contributed MASQ for making a boot floppy without DOS. AAddaamm RRiicchhtteerr Contributed comboot for making a boot floppy without DOS. CCllaauuss--JJuussttuuss HHeeiinnee Contributed patch for serial console and NFS swapping. See the contrib/nfs-swap directory for his Web page. DDiicckkoonn RReeeedd Contributed display of loading status and a hack for the 3c509 card. DDaavviidd MMuunnrroo Contributed PCI detection code originally from Linux sources. CChhaarrlliiee BBrraaddyy Donated NE2100 card so that a driver could be written, and helped test the LancePCI driver. Spotted bug with 4.1 header code. RRooggiieerr WWoollffff Created Intel EtherExpressPro 100 driver and binary to hex converter. VVllaagg LLuunngguu Contributed patches to work with DHCP. Also contributed a fix to match the received XID against the transmitted one, important in a network with many requesters. WWiilllliiaamm AArrbbaauugghh Patches for eepro to work with 3.2. JJeeaann MMaarrcc LLaaccrrooiixx Contributed an improved bin2intelhex. JJiimm HHaagguuee Contributed fixes to 3c503 driver for PIO mode, fix to makerom for presetting EPROM bytes, and various endian fixes. AAnnddrreeww CCoouulltthhuurrsstt Contributed patch for making Intel eepro work in 4.0. DDoouugg AAmmbbrriisskkoo Contributed patches to start32.S from FreeBSD version to make it boot Windoze after answering N to Boot from Network question. Contributed FreeBSD support and improved serial console support which is now merged into distribution since version 4.2.8. Minor patches to 4.7.21 to make compilation under FreeBSD easier. AAlleexx HHaarriinn Contributed patches for prepended loaders and makerom to make bootrom PnP and PCI compatible. PPeetteerr DDoobbccssaannyyii Contributed vendor and device IDs for the Netvin NE2000/PCI clone. aaddaamm AATT mmuuddlliisstt PPEERRIIOODD eeoorrbbiitt PPEERRIIOODD nneett Contributed RARP code as alternative to BOOTP/DHCP. Activated by RARP_NOT_BOOTP define. DDaanniieell EEnnggssttrroomm Contributed a SMC9000 driver. DDiiddiieerr PPooiirroott Contributed an Etherpower II (EPIC 100) driver. MMaarrttiinn AAttkkiinnss Contributed mntnbi for mounting DOS NBIs. AAttttiillaa BBooggaarr Contributed a bug fix to the bootmenu code and a patch to main.c to remove looping menus on failure. Also code for ARP replies and TFTP retransmit (#ifdef CONGESTED). Cleanup of tftp and tftpd. NNaatthhaann RR.. NNeeuulliinnggeerr Found bug due to tu_block being declared signed short in arpa/tftp.h on many platforms when it should be unsigned short. DDaavviidd SShhaarrpp Contributed a FreeBSD driver for Tulip based cards. Ken Yap ported it to Etherboot. Not tested because code needs to be written for all the variants of the Tulip and also because no hardware available to me. GGrreegg BBeeeelleeyy Contributed a 3c905b driver. Be sure to read the release notes in 3c905b.txt before using. AAlleexx NNeemmiirroovvsskkyy Contributed patches to use BIOS call to size memory otherwise Etherboot was trampling on top of 640kB area, which is used by some extended BIOSes. Also contributed patches to pci.c to implement PCI bus support on BIOSes that do not implement BIOS32, or incorrectly. GGuueenntteerr KKnnaauuff Suggested making the ASK_BOOT prompts more generic and clearer. Also contributed a DOS utility for extracting the identifier string and PCI IDs, if any, out of the boot ROM. Contributed a wake on LAN CGI script. KKllaauuss EEssppeennllaauubb Contributed various cleanup patches to the code especially in the bootmenu area, fixes for the NE2000 driver, as well as a completely revamped start32.S. Also introduced Rainer Bawidamann's code, see next paragraph. Contributed further improvements in Realtek 8139 driver. Did a major rewrite from 4.4.5 to 4.5.5, see doc/maint/LOG. RRaaiinneerr BBaawwiiddaammaannnn Contributed a Realtek 8139 driver. GGeeoorrgg BBaauumm contributed a Schneider & Koch G16 driver. jjlluukkee AATT ddeeaakkiinn PPEERRIIOODD eedduu PPEERRIIOODD aauu sent in a fix for the WD/SMC8013 which I finally verified. MMaarrkk BBuurraazziinn contributed a fix for Compex RL2000 NICs. MMaatttthhiiaass MMeeiixxnneerr found a receive status bug in the RTL8139 driver. JJiimm MMccQQuuiillllaann provided changes to support the SMC1211 which uses the RTL8139 chip. SStteevvee SSmmiitthh Extended the 3c905b driver for other members of the 90x family. Be sure to read the release notes in 3c90x.txt before using. Modified loader.S for some BIOSes that don't behave correctly with INT19H. JJoohhnn FFiinnllaayy Wrote a utility for programming EEPROMs on 3c90x in situ. NNiicckk LLooppeezz Contributed change to tulip.c to handle Macronix 98715 (Tulip clone). MMaatttt HHoorrttmmaann Contributed fix to eepro100 driver that fixes incorrect latency setting. Also Makefile rule for .lzfd0. MMaarrttyy CCoonnnnoorr Contributed new Tulip driver ntulip.c. Reduced RTL8139 footprint. Added support for Netgear FA310TX (Tulip clone, LC82C168 chip). Support for 3Com905C. Romutil for 905C, which have block erase EEPROMs. Contributed the development of liloprefix.S through thinguin.org. Finally made the ROM images conformant PnP boot ROM images. Wrote the SiS900 driver. Made Tulip driver work for many more variants. Wrote the National Semiconductor DP83815 driver, under funding from Sicom System . AAnnddeerrss LLaarrsseenn contributed mkQNXnbi, for generating tagged images from QNX kernels. BBeerrnndd WWiieebbeelltt contributed code to request vendor tags in DHCP. PPaaoolloo MMaarriinnii contributed the Via-Rhine driver. AAddaamm FFrriittzzlleerr contributed 3c529 (MCA version of 3c509) support in driver. SShhuussuukkee NNiissiiyyaammaa contributed a 3c595 (may work for 3c590) driver. IIggoorr VV.. KKoovvaalleennkkoo contributed a Winbind W89C840 driver. GGaarryy BByyeerrss of thinguin.org wrote the LILO prefix program liloprefix.S. DDoonnaalldd CChhrriisstteennsseenn converted all the as86/nasm .S files to gas format, thus allowing Etherboot to be built without requiring as86/nasm. LLuuiiggii RRiizzzzoo contributed a bootloader from FreeBSD that works for both floppy and hard disk partitions. This obsoletes floppyload.S. Patch to do adaptive timeout in NFS booting. MMiicchhaaeell SSiinnzz contributed patches for loading debug symbols when booting FreeBSD. JJeeaann--JJaaccqquueess MMiicchheell contributed patches to the via-rhine.c driver to make it work for the VT6102 model as used on some DFE530-TX Rev.A3 NICs. PPeetteerr KKooeeggeell contributed patches to the SiS900 driver to make it work for the SiS630e/SiS730s. EErriicc BBiieeddeerrmmaann improved the recovery logic of main.c and lots of other changes. Contributed E820H memory sizing logic. Reworked PCI logic. Made more compatible with LinuxBIOS. Lots of small fixes. PPeetteerr LLiisstteerr aanndd VVaassiill VVaassiilleevv contributed changes to generate .pxe image that can be booted using a PXE booter. FFrreedd GGrraayy contributed changes in tulip.c to check for a duplex connection and to modify the controller register if so. MMaarrkk GG of Inprimis Technologies contributed another FA311 (National Semiconductor DP83815) driver, also based on the Donald Becker Linux driver. AArrmmiinn SScchhiinnddlleerr contributed a patch to allow booting LynxOS KDI images. CChhrriissttoopphheerr LLii contributed an Intel E1000 gigabit Ethernet driver. RRoohhiitt JJaallaann contributed a patch for FreeBSD style PXE booting. AAnnddrreeww BBeettttiissoonn sent in a patch to run the SMC EtherEZ in PIO mode, required for some motherboards. MMiicchhaaeell BBrroowwnn contributed the first wireless NIC drivers for the Prism chipset. TTiimmootthhyy LLeeggggee contributed a 3c515 driver. 1111.. SSoouurrccee ccooppyyrriigghhttss The boot code from FreeBSD is under the BSD license. The code taken from the Linux PCI subsystem and Linux NIC drivers are under GPL. Some source files have been put under GPL by their authors. Hence the Etherboot distribution is in general under the GPL, but you may use parts of it derived from FreeBSD under FreeBSD rules. Simply speaking, the GPL says that if you distribute a binary derived from Etherboot code (this includes boot ROMs) you have to provide, or promise to provide on demand, the source code. The full conditions of the GPL are specified in the file COPYING. Here are the copyright details of the source, file by file: ______________________________________________________________________ Files marked GPL may be used under the GPL. Files marked BSD may be used under the GPL or BSD license. For other licenses see the respective source for details. The BSD files are those inherited from FreeBSD netboot. The GPL files are in general either from Linux or have been explicitly put under GPL by the authors. File Copyright status 3c509.c BSD 3c509.h BSD 3c515.c GPL 3c515_isapnp.h GPL 3c595.c BSD 3c595.h BSD 3c90x.c Open Source ansiesc.c GPL boot1a.s BSD bootmenu.c BSD cards.h GPL comprefix.S GPL config.c GPL cs89x0.c GPL cs89x0.h GPL davicom.c GPL depca.c GPL disrom.pl GPL e1000.c GPL e1000.h GPL e1000_fxhw.c GPL e1000_fxhw.h GPL e1000_phy.c GPL e1000_phy.h GPL eepro.c GPL eepro100.c GPL epic100.c None epic100.h None etherboot.h GPL fa311.c GPL floppy.c GPL floppyload.S GPL genrules.pl GPL hfa384x.h GPL i82586.c GPL lance.c GPL liloprefix.S GPL linux-asm-io.h GPL linux-asm-string.h None linuxbios.c GPL linuxbios_tables.h GPL loader.S BSD/GPL? lzhuf.c Open Source main.c BSD makerom.c BSD makerom.pl/modrom.pl GPL md5.c GPL memsizes.c None misc.c BSD natsemi.c GPL nfs.c GPL ni5010.c GPL nic.h GPL ns8390.c BSD ns8390.h BSD osdep.h BSD osloader.c GPL otulip.c BSD otulip.h BSD p80211hdr.h GPL pcbios.S GPL pci.c GPL pci.h GPL prism2.c GPL prism2_pci.c GPL prism2_plx.c GPL rtl8139.c GPL serial.S Mach sis900.c GPL sis900.h GPL sk_g16.c GPL sk_g16.h GPL skel.c GPL smc9000.c GPL smc9000.h GPL start32.S BSD swapdevids.pl GPL tiara.c GPL timer.c GPL timer.h GPL tulip.c BSD via-rhine.c GPL w89c840.c GPL wlan_compat.h GPL This lengthy notice is required for serial.S: /* * Mach Operating System * Copyright (c) 1992, 1991 Carnegie Mellon University * All Rights Reserved. * * Permission to use, copy, modify and distribute this software and its * documentation is hereby granted, provided that both the copyright * notice and this permission notice appear in all copies of the * software, derivative works or modified versions, and any portions * thereof, and that both notices appear in supporting documentation. * * CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS IS" * CONDITION. CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF ANY KIND FOR * ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS SOFTWARE. * * Carnegie Mellon requests users of this software to return to * * Software Distribution Coordinator or Software.Distribution@CS.CMU.EDU * School of Computer Science * Carnegie Mellon University * Pittsburgh PA 15213-3890 * * any improvements or extensions that they make and grant Carnegie Mellon * the rights to redistribute these changes. * * from: Mach, Revision 2.2 92/04/04 11:34:26 rpd * $Id: userman.txt,v 1.2 2004/03/09 06:48:46 stick Exp $ */ /* Copyright 1988, 1989, 1990, 1991, 1992 by Intel Corporation, Santa Clara, California. All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appears in all copies and that both the copyright notice and this permission notice appear in supporting documentation, and that the name of Intel not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. INTEL DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL INTEL BE LIABLE FOR ANY SPECIAL, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN ACTION OF CONTRACT, NEGLIGENCE, OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ /* * Serial bootblock interface routines * Copyright (c) 1994, J"org Wunsch * * Permission to use, copy, modify and distribute this software and its * documentation is hereby granted, provided that both the copyright * notice and this permission notice appear in all copies of the * software, derivative works or modified versions, and any portions * thereof, and that both notices appear in supporting documentation. * * THE AUTHOR ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS IS" * CONDITION. THE AUTHOR DISCLAIMS ANY LIABILITY OF ANY KIND FOR * ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS SOFTWARE. */ ______________________________________________________________________