summaryrefslogtreecommitdiffstats
path: root/src/arch
Commit message (Collapse)AuthorAgeFilesLines
...
* [build] Rename gPXE to iPXEMichael Brown2010-04-2088-291/+291
| | | | | | | | | | | Access to the gpxe.org and etherboot.org domains and associated resources has been revoked by the registrant of the domain. Work around this problem by renaming project from gPXE to iPXE, and updating URLs to match. Also update README, LOG and COPYRIGHTS to remove obsolete information. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Look for isolinux.bin in more placesPiotr Jaroszyński2010-04-161-1/+5
| | | | | Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com> Signed-off-by: Marty Connor <mdc@etherboot.org>
* [pxe] Remove pxe_set_cached_filename()Michael Brown2010-03-263-37/+0Star
| | | | | | | | | | | | | | | | | gPXE currently overwrites the filename stored in the cached DHCP packets when a call to PXENV_TFTP_READ_FILE or PXENV_RESTART_TFTP is made. This code has existed for many years as a workaround for RIS, which seemed to require that this be done. pxe_set_cached_filename() causes problems with the Bootix NBP, and a recent test demonstrates that RIS will complete successfully even with pxe_set_cached_filename() removed. There have been many changes to the DHCP and PXE logic since this code was first added, and it is quite plausible that it was masking a bug that no longer exists. Reported-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com> Debugged-by: Shao Miller <Shao.Miller@yrdsb.edu.on.ca> Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [pxe] Avoid potential interrupt storms when using shared interruptsMichael Brown2010-03-231-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | Current gPXE code always returns "OURS" in response to PXENV_UNDI_ISR:START. This is harmless for non-shared interrupt lines, and avoids the complexity of trying to determine whether or not we really did cause the interrupt. (This is a non-trivial determination; some drivers don't have interrupt support and hook the system timer interrupt instead, for example.) A problem occurs when we have a shared interrupt line, the other device asserts an interrupt, and the controlling ISR does not chain to the other device's ISR when we return "OURS". Under these circumstances, the other device's ISR never executes, and so the interrupt remains asserted, causing an interrupt storm. Work around this by returning "OURS" if and only if our net device's interrupt is currently recorded as being enabled. Since we always disable interrupts as a result of a call to PXENV_UNDI_ISR:START, this guarantees that we will eventually (on the second call) return "NOT OURS", allowing the other ISR to be called. Under normal operation, including a non-shared interrupt situation, this change will make no difference since PXENV_UNDI_ISR:START would be called only when interrupts were enabled anyway. Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [netdevice] Add netdev_is_open() wrapper functionMichael Brown2010-03-232-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [comboot] Match version strings to SYSLINUX styleDaniel Verkamp2010-03-011-2/+2
| | | | | | | | | In the actual SYSLINUX suite's comboot implementation, the version string is prefixed by CR LF, and the copyright string has a leading space. Some tools (specifically HDT) assume these padding characters exist, so we should probably return strings in a similar format. Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [undi] Ensure only one UNDI instance is loadedStefan Hajnoczi2010-02-241-0/+12
| | | | | | | | | | | | | | | | | | Loading multiple UNDI instances would be useful in systems that have several network cards with vendor PXE ROMs. However, we cannot rely on UNDI ROMs working correctly with multiple instances loaded simultaneously. The gPXE UNDI driver supports the following multi-NIC configurations: 1. Chainloading undionly.kpxe on a specific NIC. 2. Loading the UNDI driver for the first probed device and ignoring all other UNDI devices in the system. This patch refuses to probe additional UNDI devices so there can never be multiple instances of UNDI loaded. Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com> Signed-off-by: Marty Connor <mdc@etherboot.org>
* [prefix] Remove unsupported ELF preficesStefan Hajnoczi2010-02-015-514/+0Star
| | | | | | | | | The .elf, .elfd, .lmelf, and .lmelfd prefices were brought over from legacy Etherboot and they do not build in gPXE. This patch removes the ELF prefices. Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com> Signed-off-by: Marty Connor <mdc@etherboot.org>
* [prefix] Remove unsupported .exe prefixStefan Hajnoczi2010-02-012-42/+0Star
| | | | | | | | | The unfinished .exe prefix was brought over from legacy Etherboot. There has been no demand for .exe images so this patch removes the prefix. Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com> Signed-off-by: Marty Connor <mdc@etherboot.org>
* [prefix] Remove unsupported .com prefixStefan Hajnoczi2010-02-012-47/+0Star
| | | | | | | | | The DOS .com prefix was brought over from legacy Etherboot but does not build. There has been no demand for .com images so this patch removes the prefix. Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com> Signed-off-by: Marty Connor <mdc@etherboot.org>
* [prefix] Remove .bImage in favor of .lkrnStefan Hajnoczi2010-02-012-612/+0Star
| | | | | | | | | The .lkrn prefix allows gPXE to be loaded as a Linux bzImage. The bImage prefix was carried over from legacy Etherboot and does not build. This patch removes the .bImage prefix, use .lkrn instead. Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com> Signed-off-by: Marty Connor <mdc@etherboot.org>
* [pxe] Introduce PXE exit hook for NBP chainingShao Miller2010-01-245-1/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It might be the case that we wish to chain to an NBP without being "in the way". We now implement a hook in our exit path for gPXE *.*pxe build targets. The hook is a pointer to a SEG16:OFF16 which we try to jump to during exit. By default, this pointer results in the usual exit path. We also implement the "pxenv_file_exit_hook" PXE API routine to allow the user to specify an alternate SEG16:OFF16 to jump to during exit. Unfortunately, this additional PXE extension has a cost in code size. Fortunately, a look at the size difference for a gPXE .rom build target shows zero size difference after compression. The routine is documented in doc/pxe_extensions as follows: FILE EXIT HOOK Op-Code: PXENV_FILE_EXIT_HOOK (00e7h) Input: Far pointer to a t_PXENV_FILE_EXIT_HOOK parameter structure that has been initialized by the caller. Output: PXENV_EXIT_SUCCESS or PXENV_EXIT_FAILURE must be returned in AX. The Status field in the parameter structure must be set to one of the values represented by the PXENV_STATUS_xxx constants. Description:Modify the exit path to jump to the specified code. Only valid for pxeprefix-based builds. typedef struct s_PXENV_FILE_EXIT_HOOK { PXENV_STATUS_t Status; SEGOFF16_t Hook; } t_PXENV_FILE_EXIT_HOOK; Set before calling API service: Hook: The SEG16:OFF16 of the code to jump to. Returned from API service: Status: See PXENV_STATUS_xxx constants. Requested-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Shao Miller <shao.miller@yrdsb.edu.on.ca> Signed-off-by: Marty Connor <mdc@etherboot.org>
* [prefix] Add .xrom prefix for a ROM that loads itself by PCI accessesJoshua Oreman2010-01-204-10/+389
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The standard option ROM format provides a header indicating the size of the entire ROM, which the BIOS will reserve space for, load, and call as necessary. However, this space is strictly limited to 128k for all ROMs. gPXE ameliorates this somewhat by reserving space for itself in high memory and relocating the majority of its code there, but on systems prior to PCI3 enough space must still be present to load the ROM in the first place. Even on PCI3 systems, the BIOS often limits the size of ROM it will load to a bit over 64kB. These space problems can be solved by providing an artificially small size in the ROM header: just enough to let the prefix code (at the beginning of the ROM image) be loaded by the BIOS. To the BIOS, the gPXE ROM will appear to be only a few kilobytes; it can then load the rest of itself by accessing the ROM directly using the PCI interface reserved for that task. There are a few problems with this approach. First, gPXE needs to find an unmapped region in memory to map the ROM so it can read from it; this is done using the crude but effective approach of scanning high memory (over 0xF0000000) for a sufficiently large region of all-ones (0xFF) reads. (In x86 architecture, all-ones is returned for accesses to memory regions that no mapped device can satisfy.) This is not provably valid in all situations, but has worked well in practice. More importantly, this type of ROM access can only work if the PCI ROM BAR exists at all. NICs on physical add-in PCI cards generally must have the BAR in order for the BIOS to be able to load their ROM, but ISA cards and LAN-on-Motherboard cards will both fail to load gPXE using this scheme. Due to these uncertainties, it is recommended that .xrom only be used when a regular .rom image is infeasible due to crowded option ROM space. However, when it works it could allow loading gPXE images as large as a flash chip one could find - 128kB or even higher. Signed-off-by: Marty Connor <mdc@etherboot.org>
* [config] Make PXE stack a compile-time optionJoshua Oreman2010-01-205-46/+87
| | | | | | | | | | For extremely tight space requirements and specific applications, it is sometimes desirable to create gPXE images that cannot provide the PXE API functionality to client programs. Add a configuration header option, PXE_STACK, that can be removed to remove this stack. Also add PXE_MENU to control the PXE boot menu, which most uses of gPXE do not need. Signed-off-by: Marty Connor <mdc@etherboot.org>
* [pxe] Support cached DHCP packets in .kkpxe imagesJoshua Oreman2010-01-202-0/+72
| | | | | | | | | | | | If we don't unload the PXE stack before executing gPXE, automatically take advantage of the cached DHCPACK that the underlying/parent PXE stack can provide. If that cached DHCPACK contains option 175.178, or the user sets the use-cached setting before invoking DHCP, the real DHCP request will be skipped and the cached DHCPACK will be used for network configuration. Otherwise, the cached settings block is thrown away as soon as a fresh one is acquired. Signed-off-by: Marty Connor <mdc@etherboot.org>
* [pxe] Separate parent PXE API caller from UNDINET driverJoshua Oreman2010-01-206-216/+263
| | | | | | | | | Calling the parent PXE stack (the stack that loaded us, for undionly.kkpxe) can be useful for more than UNDI calls; for instance, it lets us get cached DHCP packets to avoid re-DHCP when working with embedded images. Signed-off-by: Marty Connor <mdc@etherboot.org>
* [tftp] Make TFTP size requests abort transfer with an errorThomas Horsten2010-01-181-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | pxenv_tftp_get_fsize is an API call that PXE clients can call to obtain the size of a remote file. It is implemented by starting a TFTP transfer with pxe_tftp_open, waiting for the response and then stopping the transfer with pxe_tftp_close(). This leaves the session hanging on the TFTP server and it will try to resend the packet repeatedly (verified with tftpd-hpa) until it times out. This patch adds a method "tftpsize" that will abort the transfer after the first packet is received from the server. This will terminate the session on the server and is the same behaviour as Intel's PXE ROM exhibits. Together with a qemu patch to handle the ERROR packet (submitted to qemu's mailing list), this resolves a specific issue where booting pxegrub with qemu's TFTP server would be slow or hang. I've tested this against qemu's tftp server and against my normal boot infrastructure (tftpd-hpa). Booting pxegrub and loading extra files now produces a trace similar to Intel's PXE client and there are no spurious retransmits from tftpd any more. Signed-off-by: Thomas Horsten <thomas@horsten.com> Signed-off-by: Milan Plzik <milan.plzik@gmail.com> Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com> Signed-off-by: Marty Connor <mdc@etherboot.org>
* [sanboot] Prevent leaking a stack reference for "keep-san" AoEStefan Hajnoczi2010-01-151-21/+33
| | | | | | | | | When the "keep-san" option is used, the function is exited without unregistering the stack allocated int13h drive. To prevent a dangling pointer to the stack, these structs should be heap allocated. Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com> Signed-off-by: Marty Connor <mdc@etherboot.org>
* [prefix] Add .hrom prefix for a ROM that loads high under PCI3 without PMMJoshua Oreman2010-01-143-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | gPXE currently takes advantage of the feature of PCI3.0 that allows option ROMs to relocate the bulk of their code to high memory and so take up only a small amount of space in the option ROM area. Currently, the relocation can only take place if the BIOS's implementation of PMM can be made to return blocks aligned to an even megabyte, because of the A20 gate. AMI BIOSes, in particular, will not return allocations that gPXE can use. Ameliorate the situation somewhat by adding a prefix, .hrom, that works identically to .rom except in the case that PMM allocation fails. Where .rom would give up and place itself entirely in option ROM space, .hrom moves to a block (assumed free) at HIGHMEM_LOADPOINT = 4MB. This allows for the use of larger gPXE ROMs than would otherwise be possible. Because there is no way to check that the area at HIGHMEM_LOADPOINT is really free, other devices using that memory during the boot process will cause failure for gPXE, the other device, or both. In practice such conflicts will likely not occur, but this prefix should still be considered EXPERIMENTAL. Signed-off-by: Marty Connor <mdc@etherboot.org>
* [build] Pad .hd image type to 32 KBStefan Hajnoczi2009-12-151-1/+1
| | | | | | | | | | | | The disk partition prefix code in hdprefix.S reads the gPXE image in tracks, not individual sectors. This means it will attempt to read beyond the end of the image if the .hd image type is not padded to 32 KB. This issue is affects virtualization software which may execute a .hd or .usb image file directly - effectively running a machine with a tiny disk containing just the gPXE image. Boot will fail when gPXE tries to read beyond the end of disk.
* [multiboot] Build memory map after shutting down and unhiding gPXEStefan Hajnoczi2009-12-141-2/+6
| | | | | | | | | | | The Multiboot memory map needs to be built after unhiding gPXE and downloaded images from memory. Solaris faults during boot when trying to access the ramdisk, which is hidden from the memory map while gPXE is executing. This issue is fixed by using the memory map from after gPXE unhides itself. Reported-by: Moinak Ghosh <moinakg@belenix.org> Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
* [e820mangler] Add missing CLC ins. for success pathShao Miller2009-11-211-0/+1
| | | | | | | The get_underlying_e820 function should return with CF unset on success. Reported-by: Timothy Stack <tstack@vmware.com> Signed-off-by: Marty Connor <mdc@etherboot.org>
* [linker] Expand and correct symbol requirement macrosJoshua Oreman2009-11-213-0/+3
| | | | | | | | | | | | | | | REQUIRE_SYMBOL() formerly used a formulation of symbol requirement that would allow a link to succeed despite lacking a required symbol, because it did not introduce any relocations. Fix by renaming it to REQUEST_SYMBOL() (since the soft-requirement behavior can be useful) and add a REQUIRE_SYMBOL() that truly requires. Add EXPORT_SYMBOL() and IMPORT_SYMBOL() for REQUEST_SYMBOL()-like behavior that allows one to make use of the symbol, by combining a weak external on the symbol itself with a REQUEST_SYMBOL() of a second symbol. Signed-off-by: Marty Connor <mdc@etherboot.org>
* [int13] Guard against BIOSes that "fix" the drive countMichael Brown2009-11-181-6/+48
| | | | | | | | | | | | | | | | Some BIOSes (observed with an AMI BIOS on a SunFire X2200) seem to reset the BIOS drive counter at 40:75 after a failed boot attempt. This causes problems when attempting a Windows direct-to-iSCSI installation: bootmgr.exe calls INT 13,0800 and gets told that there are no hard disks, so never bothers to read the MBR in order to obtain the boot disk signature. The Windows iSCSI initiator will detect the iBFT and connect to the target, and everything will appear to work except for the error message "This computer's hardware may not support booting to this disk. Ensure that the disk's controller is enabled in the computer's BIOS menu." Fix by checking the BIOS drive counter on every INT 13 call, and updating it whenever necessary.
* [int13] Fix number of sectors returned by INT 13,15Michael Brown2009-11-181-2/+6
| | | | | INT 13,15 should return the number of sectors, not the number of cylinders.
* [autoboot] Ensure that an error message is always printed for a boot failureMichael Brown2009-11-182-4/+0Star
| | | | | | | The case of an unsupported SAN protocol will currently not result in any error message. Fix by printing the error message at the top level using strerror(), rather than using hard-coded error messages in the error paths.
* [sanboot] Extend the "keep-san" option to non-iSCSI SAN protocolsMichael Brown2009-11-044-17/+35
| | | | This disgustingly ugly hack just keeps getting worse.
* [iscsi] Use the "Ethernet-compatible" MAC address in the iBFTMichael Brown2009-10-231-4/+8
|
* [iscsi] Fix printing of non-existent strings in iBFT debug messagesMichael Brown2009-10-231-1/+2
|
* [netdevice] Allow the hardware and link-layer addresses to differ in sizeMichael Brown2009-08-121-4/+6
| | | | | | | | | | IPoIB has a 20-byte link-layer address, of which only eight bytes represent anything relating to a "hardware address". The PXE and EFI SNP APIs expect the permanent address to be the same size as the link-layer address, so fill in the "permanent address" field with the initial link layer address (as generated by register_netdev() based upon the real hardware address).
* [netdevice] Separate out the concept of hardware and link-layer addressesMichael Brown2009-08-122-7/+3Star
| | | | | | | | | | | The hardware address is an intrinsic property of the hardware, while the link-layer address can be changed at runtime. This separation is exposed via APIs such as PXE and EFI, but is currently elided by gPXE. Expose the hardware and link-layer addresses as separate properties within a net device. Drivers should now fill in hw_addr, which will be used to initialise ll_addr at the time of calling register_netdev().
* [doc] Expand scope of doxygen-generated documentationMichael Brown2009-08-111-1/+1
|
* [zbin] Change fixup semantics to support ROMs over 128k uncompressedJoshua Oreman2009-08-116-25/+16Star
| | | | | | | | | | | | | | | | | | | | | | | | The option ROM header contains a one-byte field indicating the number of 512-byte sectors in the ROM image. Currently it is linked to contain the number of uncompressed sectors, with an instruction to the compressor to correct it. This causes link failure when the uncompressed size of the ROM image is over 128k. Fix by replacing the SUBx compressor fixup with an ADDx fixup that adds the total compressed output length, scaled as requested, to an addend stored in the field where the final length value will be placed. This is similar to the behavior of ELF relocations, and ensures that an overflow error will not be generated unless the compressed size is still too large for the field. This also allows us to do away with the _filesz_pgh and _filesz_sect calculations exported by the linker script. Output tested bitwise identical to the old SUBx mechanism on hd, dsk, lkrn, and rom prefixes, on both 32-bit and 64-bit processors. Modified-by: Michael Brown <mcb30@etherboot.org> Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [infiniband] Add support for the SRP Boot Firmware TableMichael Brown2009-08-103-0/+236
| | | | | | The SRP Boot Firmware Table serves a similar role to the iSCSI and AoE Boot Firmware Tables; it provides information required by the loaded OS in order to establish a connection back to the SRP boot device.
* [infiniband] Add support for SRP over InfinibandMichael Brown2009-08-101-0/+63
| | | | | | | | SRP is the SCSI RDMA Protocol. It allows for a method of SAN booting whereby the target is responsible for reading and writing data using Remote DMA directly to the initiator's memory. The software initiator merely sends and receives SCSI commands; it never has to touch the actual data.
* [romprefix] Cope with PnP BIOSes that fail to set %es:%di on entryMichael Brown2009-08-081-7/+20
| | | | | | | | | | | | Some BIOSes support the BIOS Boot Specification (BBS) but fail to set %es:%di correctly when calling the option ROM initialisation entry point. This causes gPXE to identify the BIOS as non-PnP (and so non-BBS), leaving the user unable to control the boot order. Fix by scanning for the $PnP signature ourselves, rather than relying on the BIOS having passed in %es:%di correctly. Tested-by: Helmut Adrigan <helmut.adrigan@chello.at>
* [pxe] Dual-license pxe_api.h under the MIT licenseH. Peter Anvin2009-08-031-0/+25
| | | | | | | | | pxe_api.h is just a description of API functions, it's actively undesirable to have more implementations than necessary. Allowing it under the MIT license lets the Syslinux libraries use it. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [pxe] Avoid printf format warning on some compilersMichael Brown2009-08-021-1/+1
| | | | Tested-by: Joshua Oreman <oremanj@xenon.get-linux.org>
* [build] Add syslinux floppy image type .sdskMarty Connor2009-08-021-0/+6
| | | | | | | | | | | | We add a syslinux floppy disk type using parts of the genliso script. This floppy image cat be dd'ed to a physical floppy or used in instances where a virtual floppy with an mountable DOS filesystem is useful. We also modify the genliso script to only generate .liso images rather than creating images depending on how it is called. Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [netdevice] Make ll_broadcast per-netdevice rather than per-ll_protocolMichael Brown2009-07-181-1/+1
| | | | | | | | | IPoIB has a link-layer broadcast address that varies according to the partition key. We currently go through several contortions to pretend that the link-layer address is a fixed constant; by making the broadcast address a property of the network device rather than the link-layer protocol it will be possible to simplify IPoIB's broadcast handling.
* [pxe] Add startpxe and stoppxe commandsMichael Brown2009-06-282-0/+34
| | | | | | | | | These commands can be used to activate or deactivate the PXE API (on a specifiable network interface). This is currently of limited use, since most image formats will call shutdown() before booting the image, meaning that the underlying net device gets shut down during remove_devices() anyway.
* [pxe] Check for unhookable interrupts in PXENV_STOP_UNDIMichael Brown2009-06-281-0/+9
| | | | | | PXENV_STOP_UNDI should return PXENV_STATUS_KEEP_UNDI if the UNDI cannot be safely unloaded (e.g. due to interrupt vectors that could not be unhooked).
* [pxe] Create pxe_[de]activate() wrapper functionsMichael Brown2009-06-284-40/+61
| | | | | Merge the pxe_set_netdev()+pxe_[un]hook_int1a() pattern into a single pxe_[de]activate() call.
* [pxe] Make pxe_init_structures() an initialisation functionMichael Brown2009-06-284-6/+7
| | | | | | | | | pxe_init_structures() fills in the fields of the !PXE and PXENV+ structures that aren't known until gPXE starts up. Once gPXE is started, these values will never change. Make pxe_init_structures() an initialisation function so that PXE users don't have to worry about calling it.
* [pxe] Update UNDI transmit count before transmitting packetMichael Brown2009-06-271-4/+8
| | | | | | | | | | | | | It is possible that the UNDI ISR may be triggered before netdev_tx() returns control to pxenv_undi_transmit(). This means that pxenv_undi_isr() may see a zero undi_tx_count, and so not check for TX completions. This is not a significant problem, since it will check for TX completions on the next call to pxenv_undi_isr() anyway; it just means that the NBP will see a spurious IRQ that was apparently caused by nothing. Fix by updating the undi_tx_count before calling netdev_tx(), so that pxenv_undi_isr() can decrement it and report the TX completion.
* [pxe] Implement PXENV_UNDI_{GET,SET}_MCAST_ADDRESSMichael Brown2009-06-271-15/+42
| | | | | | | | | | | | | | | Symantec Ghost requires working multicast support. gPXE configures all (sufficiently supported) network adapters into "receive all multicasts" mode, which means that PXENV_UNDI_SET_MCAST_ADDRESS is actually a no-op, but the current implementation returns PXENV_STATUS_UNSUPPORTED instead. Fix by making PXENV_UNDI_SET_MCAST_ADDRESS return success. For good measure, also implement PXENV_UNDI_GET_MCAST_ADDRESS, since the relevant functionality is now exposed by the net device core. Note that this will silently fail if the gPXE driver for the NIC being used fails to configure the NIC in "receive all multicasts" mode.
* [pxe] Improve pxe_undi debug messagesMichael Brown2009-06-271-32/+92
| | | | | | | | The PXE debugging messages have remained pretty much unaltered since Etherboot 5.4, and are now difficult to read in comparison to most of the rest of gPXE. Bring the pxe_undi debug messages up to normal gPXE standards.
* [comboot] Implement INT 22h AX=000Bh (Get Serial Console Configuration)Daniel Verkamp2009-06-241-1/+9
| | | | Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [pxe] Fix interoperability with the Symantec (undipd) DOS UNDI driverMichael Brown2009-06-231-1/+1
| | | | | | | | | | | The Symantec UNDI DOS driver fails when run on top of gPXE because we return our interface type as "gPXE" rather than one of the predefined NDIS interface type strings. Fix by returning the standard "DIX+802.3" string; this isn't necessarily always accurate, but it's highly unlikely that anything trying to use the UNDI API would understand our IPoIB link-layer pseudo-header anyway.
* [pxe] Fix interoperability with the Intel DOS UNDI driverMichael Brown2009-06-232-1/+23
| | | | | | | | The Intel DOS UNDI driver fails when run on top of gPXE because we do not fill in the ServiceFlags field in PXENV_UNDI_GET_IFACE_INFO. Fix by filling in the ServiceFlags field with reasonable values indicating our approximate feature capabilities.
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-01 16:37:45 +0100