david/ipxe
david
/
ipxe
Archived
1
0
Fork 0
Code
This repository has been archived on 2020-12-06. You can view files and clone it, but cannot push or open issues or pull requests.
ipxe/src/arch/i386/prefix/romprefix.S

1080 lines
25 KiB
ArmAsm
Raw Normal View History

Initial revision
2005-03-08 19:53:11 +01:00
/* At entry, the processor is in 16 bit real mode and the code is being
* executed from an address it was not linked to. Code must be pic and
* 32 bit sensitive until things are fixed up.
*
* Also be very careful as the stack is at the rear end of the interrupt
* table so using a noticeable amount of stack space is a no-no.
*/
[legal] Add FILE_LICENCE declaration to romprefix.S
2009-05-18 10:33:36 +02:00
FILE_LICENCE ( GPL2_OR_LATER )
[romprefix] Allow BANNER_TIMEOUT to control banners in romprefix.S In particular, allow BANNER_TIMEOUT=0 to inhibit the prompt banners altogether. Ironically, this request comes from the same OEM that originally required the prompts to be present during POST.
2008-09-25 02:53:42 +02:00
#include <config/general.h>
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
#define PNP_SIGNATURE ( '$' + ( 'P' << 8 ) + ( 'n' << 16 ) + ( 'P' << 24 ) )
#define PMM_SIGNATURE ( '$' + ( 'P' << 8 ) + ( 'M' << 16 ) + ( 'M' << 24 ) )
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
#define PCI_SIGNATURE ( 'P' + ( 'C' << 8 ) + ( 'I' << 16 ) + ( ' ' << 24 ) )
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
#define STACK_MAGIC ( 'L' + ( 'R' << 8 ) + ( 'E' << 16 ) + ( 'T' << 24 ) )
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
#define PNP_GET_BBS_VERSION 0x60
[romprefix] Add more diagnostic messages to ROM prefix Include PMM allocation result in POST banner. Include full product string in "starting execution" message. Also mark ourselves as supporting DDIM in PnP header, for completeness.
2008-08-26 00:36:24 +02:00
#define PMM_ALLOCATE 0x0000
[romprefix] Use smaller PMM allocations if possible The only way that PMM allows us to request a block in a region with A20=0 is to ask for a block with an alignment of 2MB. Due to the PMM API design, the only way we can do this is to ask for a block with a size of 2MB. Unfortunately, some BIOSes will hit problems if we allocate a 2MB block. In particular, it may not be possible to enter the BIOS setup screen; the BIOS setup code attempts a PMM allocation, fails, and hangs the machine. We now try allocating only as much as we need via PMM. If the allocated block has A20=1, we free the allocated block, double the allocation size, and try again. Repeat until either we obtain a block with A20=0 or allocation fails. (This is guaranteed to terminate by the time we reach an allocation size of 2MB.)
2008-11-11 21:00:13 +01:00
#define PMM_DEALLOCATE 0x0002
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
[romprefix] Allow BANNER_TIMEOUT to control banners in romprefix.S In particular, allow BANNER_TIMEOUT=0 to inhibit the prompt banners altogether. Ironically, this request comes from the same OEM that originally required the prompts to be present during POST.
2008-09-25 02:53:42 +02:00
/* ROM banner timeout. Based on the configurable BANNER_TIMEOUT in
* config.h, but converted to a number of (18Hz) timer ticks, and
* doubled to allow for BIOSes that switch video modes immediately
* beforehand, so rendering the message almost invisible to the user.
*/
#define ROM_BANNER_TIMEOUT ( 2 * ( 18 * BANNER_TIMEOUT ) / 10 )
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
/* We can load a ROM in two ways: have the BIOS load all of it (.rom prefix)
* or have the BIOS load a stub that loads the rest using PCI (.xrom prefix).
* The latter is not as widely supported, but allows the use of large ROMs
* on some systems with crowded option ROM space.
*/
#ifdef LOAD_ROM_FROM_PCI
#define ROM_SIZE_VALUE _prefix_filesz_sect /* Amount to load in BIOS */
#else
#define ROM_SIZE_VALUE 0 /* Load amount (before compr. fixup) */
#endif
Initial revision
2005-03-08 19:53:11 +01:00
.text
.code16
.arch i386
.section ".prefix", "ax", @progbits
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
.org 0x00
romheader:
.word 0xAA55 /* BIOS extension signature */
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
romheader_size: .byte ROM_SIZE_VALUE /* Size in 512-byte blocks */
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
jmp init /* Initialisation vector */
checksum:
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
.byte 0, 0
real_size:
.word 0
Initial revision
2005-03-08 19:53:11 +01:00
.org 0x16
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
.word undiheader
Initial revision
2005-03-08 19:53:11 +01:00
.org 0x18
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
.word pciheader
.org 0x1a
.word pnpheader
.size romheader, . - romheader
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
[build] Fix building on Ubuntu 8.04 Not fully understood, but it seems that the LMA of bss sections matters for some newer binutils builds. Force all bss sections to have an LMA at the end of the file, so that they don't interfere with other sections. The symptom was that objcopy -O binary -j .zinfo would extract the .zinfo section from bin/xxx.tmp as a blob of the correct length, but with zero contents. This would then cause the [ZBIN] stage of the build to fail. Also explicitly state that .zinfo(.*) sections have @progbits, in case some future assembler or linker variant decides to omit them.
2008-10-17 02:39:48 +02:00
.section ".zinfo.fixup", "a", @progbits /* Compressor fixups */
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
#ifndef LOAD_ROM_FROM_PCI
[zbin] Change fixup semantics to support ROMs over 128k uncompressed 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>
2009-08-10 07:12:21 +02:00
.ascii "ADDB"
Update all prefixes currently referring to _load_size to include a compressor fixup section.
2007-07-16 18:17:26 +02:00
.long romheader_size
.long 512
.long 0
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
#endif
.ascii "ADDB"
.long real_size
.long 512
.long 0
Update all prefixes currently referring to _load_size to include a compressor fixup section.
2007-07-16 18:17:26 +02:00
.previous
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
pciheader:
.ascii "PCIR" /* Signature */
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
.word pci_vendor_id /* Vendor identification */
.word pci_device_id /* Device identification */
.word 0x0000 /* Device list pointer */
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
.word pciheader_len /* PCI data structure length */
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
.byte 0x03 /* PCI data structure revision */
.byte 0x02, 0x00, 0x00 /* Class code */
pciheader_image_length:
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
.word ROM_SIZE_VALUE /* Image length */
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
.word 0x0001 /* Revision level */
.byte 0x00 /* Code type */
.byte 0x80 /* Last image indicator */
pciheader_runtime_length:
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
.word ROM_SIZE_VALUE /* Maximum run-time image length */
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
.word 0x0000 /* Configuration utility code header */
.word 0x0000 /* DMTF CLP entry point */
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
.equ pciheader_len, . - pciheader
.size pciheader, . - pciheader
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
#ifndef LOAD_ROM_FROM_PCI
[build] Fix building on Ubuntu 8.04 Not fully understood, but it seems that the LMA of bss sections matters for some newer binutils builds. Force all bss sections to have an LMA at the end of the file, so that they don't interfere with other sections. The symptom was that objcopy -O binary -j .zinfo would extract the .zinfo section from bin/xxx.tmp as a blob of the correct length, but with zero contents. This would then cause the [ZBIN] stage of the build to fail. Also explicitly state that .zinfo(.*) sections have @progbits, in case some future assembler or linker variant decides to omit them.
2008-10-17 02:39:48 +02:00
.section ".zinfo.fixup", "a", @progbits /* Compressor fixups */
[zbin] Change fixup semantics to support ROMs over 128k uncompressed 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>
2009-08-10 07:12:21 +02:00
.ascii "ADDW"
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
.long pciheader_image_length
.long 512
.long 0
[zbin] Change fixup semantics to support ROMs over 128k uncompressed 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>
2009-08-10 07:12:21 +02:00
.ascii "ADDW"
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
.long pciheader_runtime_length
Update all prefixes currently referring to _load_size to include a compressor fixup section.
2007-07-16 18:17:26 +02:00
.long 512
.long 0
.previous
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
#endif
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
pnpheader:
.ascii "$PnP" /* Signature */
.byte 0x01 /* Structure revision */
.byte ( pnpheader_len / 16 ) /* Length (in 16 byte increments) */
.word 0x0000 /* Offset of next header */
.byte 0x00 /* Reserved */
.byte 0x00 /* Checksum */
.long 0x00000000 /* Device identifier */
.word mfgstr /* Manufacturer string */
.word prodstr /* Product name */
.byte 0x02 /* Device base type code */
.byte 0x00 /* Device sub-type code */
.byte 0x00 /* Device interface type code */
[romprefix] Add more diagnostic messages to ROM prefix Include PMM allocation result in POST banner. Include full product string in "starting execution" message. Also mark ourselves as supporting DDIM in PnP header, for completeness.
2008-08-26 00:36:24 +02:00
.byte 0xf4 /* Device indicator */
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
.word 0x0000 /* Boot connection vector */
.word 0x0000 /* Disconnect vector */
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
.word bev_entry /* Boot execution vector */
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
.word 0x0000 /* Reserved */
.word 0x0000 /* Static resource information vector*/
.equ pnpheader_len, . - pnpheader
.size pnpheader, . - pnpheader
Initial revision
2005-03-08 19:53:11 +01:00
[prefix] Add PCI bus:dev.fn to ROM product string This allows multiple gPXE ROMs in a system to be disambiguated at boot time; the PCI ID will show up in the boot menu for a BBS-compliant BIOS.
2008-05-21 19:43:58 +02:00
/* Manufacturer string */
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
mfgstr:
[build] Rename gPXE to iPXE 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>
2010-04-19 21:16:01 +02:00
.asciz "http://ipxe.org"
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
.size mfgstr, . - mfgstr
[prefix] Add PCI bus:dev.fn to ROM product string This allows multiple gPXE ROMs in a system to be disambiguated at boot time; the PCI ID will show up in the boot menu for a BBS-compliant BIOS.
2008-05-21 19:43:58 +02:00
/* Product string
*
[romprefix] Add vendor branding facilities and guidelines Some hardware vendors have been known to remove all gPXE-related branding from ROMs that they build. While this is not prohibited by the GPL, it is a little impolite. Add a facility for adding branding messages via two #defines (PRODUCT_NAME and PRODUCT_SHORT_NAME) in config/general.h. This should accommodate all known OEM-mandated branding requirements. Vendors with branding requirements that cannot be satisfied by using PRODUCT_NAME and/or PRODUCT_SHORT_NAME should contact us so that we can extended this facility as necessary.
2008-10-31 20:10:28 +01:00
* Defaults to PRODUCT_SHORT_NAME. If the ROM image is writable at
* initialisation time, it will be filled in to include the PCI
* bus:dev.fn number of the card as well.
[prefix] Add PCI bus:dev.fn to ROM product string This allows multiple gPXE ROMs in a system to be disambiguated at boot time; the PCI ID will show up in the boot menu for a BBS-compliant BIOS.
2008-05-21 19:43:58 +02:00
*/
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
prodstr:
[romprefix] Add vendor branding facilities and guidelines Some hardware vendors have been known to remove all gPXE-related branding from ROMs that they build. While this is not prohibited by the GPL, it is a little impolite. Add a facility for adding branding messages via two #defines (PRODUCT_NAME and PRODUCT_SHORT_NAME) in config/general.h. This should accommodate all known OEM-mandated branding requirements. Vendors with branding requirements that cannot be satisfied by using PRODUCT_NAME and/or PRODUCT_SHORT_NAME should contact us so that we can extended this facility as necessary.
2008-10-31 20:10:28 +01:00
.ascii PRODUCT_SHORT_NAME
[prefix] Add PCI bus:dev.fn to ROM product string This allows multiple gPXE ROMs in a system to be disambiguated at boot time; the PCI ID will show up in the boot menu for a BBS-compliant BIOS.
2008-05-21 19:43:58 +02:00
prodstr_separator:
.byte 0
.ascii "(PCI "
prodstr_pci_id:
.asciz "xx:xx.x)" /* Filled in by init code */
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
.size prodstr, . - prodstr
[pxe] Fill in UNDIROMID pointer in !PXE structure IBM's iSCSI Firmware Initiator checks the UNDIROMID pointer in the !PXE structure that gets created by the UNDI loader. We didn't previously fill this value in.
2008-08-28 00:45:59 +02:00
.globl undiheader
[config] Make PXE stack a compile-time option 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>
2009-10-07 01:15:06 +02:00
.weak undiloader
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
undiheader:
.ascii "UNDI" /* Signature */
.byte undiheader_len /* Length of structure */
Initial revision
2005-03-08 19:53:11 +01:00
.byte 0 /* Checksum */
.byte 0 /* Structure revision */
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
.byte 0,1,2 /* PXE version: 2.1.0 */
.word undiloader /* Offset to loader routine */
[i386] Simplify linker script and standardise linker-defined symbol names Reduce the number of sections within the linker script to match the number of practical sections within the output file. Define _section, _msection, _esection, _section_filesz, _section_memsz, and _section_lma for each section, replacing the mixture of symbols that previously existed. In particular, replace _text and _end with _textdata and _etextdata, to make it explicit within code that uses these symbols that the .text and .data sections are always treated as a single contiguous block.
2008-10-09 23:22:01 +02:00
.word _data16_memsz /* Stack segment size */
.word _data16_memsz /* Data segment size */
.word _text16_memsz /* Code segment size */
[romprefix] Add UNDI ROMID structure bus type field The IBM iSCSI Firmware Initiator complains that we don't have a bus type field in the UNDI ROMID structure, so include one.
2008-08-27 23:08:57 +02:00
.ascii "PCIR" /* Bus type */
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
.equ undiheader_len, . - undiheader
.size undiheader, . - undiheader
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* Initialisation (called once during POST)
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
*
* Determine whether or not this is a PnP system via a signature
* check. If it is PnP, return to the PnP BIOS indicating that we are
* a boot-capable device; the BIOS will call our boot execution vector
* if it wants to boot us. If it is not PnP, hook INT 19.
Initial revision
2005-03-08 19:53:11 +01:00
*/
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
init:
/* Preserve registers, clear direction flag, set %ds=%cs */
pushaw
Initial revision
2005-03-08 19:53:11 +01:00
pushw %ds
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
pushw %es
[prefix] Prompt for entering gPXE shell during POST The ROM prefix now prompts the user to enter the gPXE shell during POST; this allows for configuring gPXE without needing to attempt to boot from it. (It also slows down system boot by three seconds per gPXE ROM, but hey.) This is apparently a certain OEM's requirement for option ROMs.
2008-05-22 16:14:33 +02:00
pushw %fs
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
pushw %gs
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
cld
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
pushw %cs
popw %ds
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
/* Shuffle some registers around. We need %di available for
* the print_xxx functions, and in a register that's
* addressable from %es, so shuffle as follows:
*
* %di (pointer to PnP structure) => %bx
* %bx (runtime segment address, for PCI 3.0) => %gs
*/
movw %bx, %gs
[prefix] Add PCI bus:dev.fn to ROM product string This allows multiple gPXE ROMs in a system to be disambiguated at boot time; the PCI ID will show up in the boot menu for a BBS-compliant BIOS.
2008-05-21 19:43:58 +02:00
movw %di, %bx
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* Print message as early as possible */
movw $init_message, %si
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
xorw %di, %di
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
call print_message
[prefix] Add PCI bus:dev.fn to ROM product string This allows multiple gPXE ROMs in a system to be disambiguated at boot time; the PCI ID will show up in the boot menu for a BBS-compliant BIOS.
2008-05-21 19:43:58 +02:00
call print_pci_busdevfn
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
#ifdef LOAD_ROM_FROM_PCI
/* Save PCI bus:dev.fn for later use */
movw %ax, pci_busdevfn
#endif
[prefix] Add PCI bus:dev.fn to ROM product string This allows multiple gPXE ROMs in a system to be disambiguated at boot time; the PCI ID will show up in the boot menu for a BBS-compliant BIOS.
2008-05-21 19:43:58 +02:00
/* Fill in product name string, if possible */
movw $prodstr_pci_id, %di
call print_pci_busdevfn
[build] Cope with oddities in the Fedora 10 assembler The version of the GNU assembler shipped with Fedora 10 (2.18.50.0.9-8.fc10) complains about character literals in some of our assembly code. Changing $'x' to $( 'x' ) seems to fix the problem. Yes, the whitespace is required; using just $('x') does not work. Reported by Kevin O'Connor <kevin@koconnor.net>.
2009-02-16 04:53:25 +01:00
movb $( ' ' ), prodstr_separator
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
/* Print segment address */
[build] Cope with oddities in the Fedora 10 assembler The version of the GNU assembler shipped with Fedora 10 (2.18.50.0.9-8.fc10) complains about character literals in some of our assembly code. Changing $'x' to $( 'x' ) seems to fix the problem. Yes, the whitespace is required; using just $('x') does not work. Reported by Kevin O'Connor <kevin@koconnor.net>.
2009-02-16 04:53:25 +01:00
movb $( ' ' ), %al
[prefix] Add PCI bus:dev.fn to ROM product string This allows multiple gPXE ROMs in a system to be disambiguated at boot time; the PCI ID will show up in the boot menu for a BBS-compliant BIOS.
2008-05-21 19:43:58 +02:00
xorw %di, %di
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
call print_character
movw %cs, %ax
call print_hex_word
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
/* Check for PCI BIOS version */
pushl %ebx
pushl %edx
[romprefix] Preserve %edi when issuing INT 1A,B101 INT 1A,B101 (get PCI BIOS version) will overwrite %edi.
2008-08-26 06:03:19 +02:00
pushl %edi
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
stc
movw $0xb101, %ax
int $0x1a
[romprefix] Further sanity checks for the PCI 3 runtime segment address This extends the sanity checks on the runtime segment address provided in %bx, first implemented in commit 5600955. We now allow the ROM to be placed anywhere above a000:0000 (rather than c000:0000, as before), since this is the region allowed by the PCI 3 spec. If the BIOS asks us to place the runtime image such that it would overlap with the init-time image (which is explicitly prohibited by the PCI 3 spec), then we assume that the BIOS is faulty and ignore the provided runtime segment address. Testing on a SuperMicro BIOS providing overlapping segment addresses shows that ignoring the provided runtime segment address is safe to do in these circumstances.
2008-10-29 02:10:33 +01:00
jc no_pci3
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
cmpl $PCI_SIGNATURE, %edx
[romprefix] Further sanity checks for the PCI 3 runtime segment address This extends the sanity checks on the runtime segment address provided in %bx, first implemented in commit 5600955. We now allow the ROM to be placed anywhere above a000:0000 (rather than c000:0000, as before), since this is the region allowed by the PCI 3 spec. If the BIOS asks us to place the runtime image such that it would overlap with the init-time image (which is explicitly prohibited by the PCI 3 spec), then we assume that the BIOS is faulty and ignore the provided runtime segment address. Testing on a SuperMicro BIOS providing overlapping segment addresses shows that ignoring the provided runtime segment address is safe to do in these circumstances.
2008-10-29 02:10:33 +01:00
jne no_pci3
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
testb %ah, %ah
[romprefix] Further sanity checks for the PCI 3 runtime segment address This extends the sanity checks on the runtime segment address provided in %bx, first implemented in commit 5600955. We now allow the ROM to be placed anywhere above a000:0000 (rather than c000:0000, as before), since this is the region allowed by the PCI 3 spec. If the BIOS asks us to place the runtime image such that it would overlap with the init-time image (which is explicitly prohibited by the PCI 3 spec), then we assume that the BIOS is faulty and ignore the provided runtime segment address. Testing on a SuperMicro BIOS providing overlapping segment addresses shows that ignoring the provided runtime segment address is safe to do in these circumstances.
2008-10-29 02:10:33 +01:00
jnz no_pci3
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
#ifdef LOAD_ROM_FROM_PCI
incb pcibios_present
#endif
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
movw $init_message_pci, %si
xorw %di, %di
call print_message
movb %bh, %al
call print_hex_nibble
[build] Cope with oddities in the Fedora 10 assembler The version of the GNU assembler shipped with Fedora 10 (2.18.50.0.9-8.fc10) complains about character literals in some of our assembly code. Changing $'x' to $( 'x' ) seems to fix the problem. Yes, the whitespace is required; using just $('x') does not work. Reported by Kevin O'Connor <kevin@koconnor.net>.
2009-02-16 04:53:25 +01:00
movb $( '.' ), %al
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
call print_character
movb %bl, %al
call print_hex_byte
cmpb $3, %bh
[romprefix] Further sanity checks for the PCI 3 runtime segment address This extends the sanity checks on the runtime segment address provided in %bx, first implemented in commit 5600955. We now allow the ROM to be placed anywhere above a000:0000 (rather than c000:0000, as before), since this is the region allowed by the PCI 3 spec. If the BIOS asks us to place the runtime image such that it would overlap with the init-time image (which is explicitly prohibited by the PCI 3 spec), then we assume that the BIOS is faulty and ignore the provided runtime segment address. Testing on a SuperMicro BIOS providing overlapping segment addresses shows that ignoring the provided runtime segment address is safe to do in these circumstances.
2008-10-29 02:10:33 +01:00
jb no_pci3
[romprefix] Sanity-check the runtime segment address for PCI 3 Some PCI 3 BIOSes seem to provide a garbage value in %bx, which should contain the runtime segment address. Perform a basic sanity check: we reject the segment if it is below the start of option ROM space. If the sanity check fails, we assume that the BIOS was not expecting us to be a PCI 3 ROM, and we just leave our image in situ.
2008-10-17 19:12:24 +02:00
/* PCI >=3.0: leave %gs as-is if sane */
movw %gs, %ax
[romprefix] Further sanity checks for the PCI 3 runtime segment address This extends the sanity checks on the runtime segment address provided in %bx, first implemented in commit 5600955. We now allow the ROM to be placed anywhere above a000:0000 (rather than c000:0000, as before), since this is the region allowed by the PCI 3 spec. If the BIOS asks us to place the runtime image such that it would overlap with the init-time image (which is explicitly prohibited by the PCI 3 spec), then we assume that the BIOS is faulty and ignore the provided runtime segment address. Testing on a SuperMicro BIOS providing overlapping segment addresses shows that ignoring the provided runtime segment address is safe to do in these circumstances.
2008-10-29 02:10:33 +01:00
cmpw $0xa000, %ax /* Insane if %gs < 0xa000 */
jb pci3_insane
movw %cs, %bx /* Sane if %cs == %gs */
cmpw %bx, %ax
je 1f
movzbw romheader_size, %cx /* Sane if %cs+len <= %gs */
shlw $5, %cx
addw %cx, %bx
cmpw %bx, %ax
jae 1f
movw %cs, %bx /* Sane if %gs+len <= %cs */
addw %cx, %ax
cmpw %bx, %ax
jbe 1f
pci3_insane: /* PCI 3.0 with insane %gs value: print error and ignore %gs */
[build] Cope with oddities in the Fedora 10 assembler The version of the GNU assembler shipped with Fedora 10 (2.18.50.0.9-8.fc10) complains about character literals in some of our assembly code. Changing $'x' to $( 'x' ) seems to fix the problem. Yes, the whitespace is required; using just $('x') does not work. Reported by Kevin O'Connor <kevin@koconnor.net>.
2009-02-16 04:53:25 +01:00
movb $( '!' ), %al
[romprefix] Sanity-check the runtime segment address for PCI 3 Some PCI 3 BIOSes seem to provide a garbage value in %bx, which should contain the runtime segment address. Perform a basic sanity check: we reject the segment if it is below the start of option ROM space. If the sanity check fails, we assume that the BIOS was not expecting us to be a PCI 3 ROM, and we just leave our image in situ.
2008-10-17 19:12:24 +02:00
call print_character
movw %gs, %ax
call print_hex_word
[romprefix] Further sanity checks for the PCI 3 runtime segment address This extends the sanity checks on the runtime segment address provided in %bx, first implemented in commit 5600955. We now allow the ROM to be placed anywhere above a000:0000 (rather than c000:0000, as before), since this is the region allowed by the PCI 3 spec. If the BIOS asks us to place the runtime image such that it would overlap with the init-time image (which is explicitly prohibited by the PCI 3 spec), then we assume that the BIOS is faulty and ignore the provided runtime segment address. Testing on a SuperMicro BIOS providing overlapping segment addresses shows that ignoring the provided runtime segment address is safe to do in these circumstances.
2008-10-29 02:10:33 +01:00
no_pci3:
/* PCI <3.0: set %gs (runtime segment) = %cs (init-time segment) */
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
pushw %cs
popw %gs
[romprefix] Further sanity checks for the PCI 3 runtime segment address This extends the sanity checks on the runtime segment address provided in %bx, first implemented in commit 5600955. We now allow the ROM to be placed anywhere above a000:0000 (rather than c000:0000, as before), since this is the region allowed by the PCI 3 spec. If the BIOS asks us to place the runtime image such that it would overlap with the init-time image (which is explicitly prohibited by the PCI 3 spec), then we assume that the BIOS is faulty and ignore the provided runtime segment address. Testing on a SuperMicro BIOS providing overlapping segment addresses shows that ignoring the provided runtime segment address is safe to do in these circumstances.
2008-10-29 02:10:33 +01:00
1: popl %edi
[romprefix] Preserve %edi when issuing INT 1A,B101 INT 1A,B101 (get PCI BIOS version) will overwrite %edi.
2008-08-26 06:03:19 +02:00
popl %edx
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
popl %ebx
[romprefix] Cope with PnP BIOSes that fail to set %es:%di on entry 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>
2009-08-08 15:36:10 +02:00
/* Check for PnP BIOS. Although %es:di should point to the
* PnP BIOS signature on entry, some BIOSes fail to do this.
*/
movw $( 0xf000 - 1 ), %bx
pnp_scan:
incw %bx
jz no_pnp
movw %bx, %es
cmpl $PNP_SIGNATURE, %es:0
jne pnp_scan
xorw %dx, %dx
xorw %si, %si
movzbw %es:5, %cx
1: es lodsb
addb %al, %dl
loop 1b
jnz pnp_scan
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
/* Is PnP: print PnP message */
movw $init_message_pnp, %si
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
xorw %di, %di
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
call print_message
/* Check for BBS */
[romprefix] Cope with PnP BIOSes that fail to set %es:%di on entry 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>
2009-08-08 15:36:10 +02:00
pushw %es:0x1b /* Real-mode data segment */
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
pushw %ds /* &(bbs_version) */
pushw $bbs_version
pushw $PNP_GET_BBS_VERSION
[romprefix] Cope with PnP BIOSes that fail to set %es:%di on entry 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>
2009-08-08 15:36:10 +02:00
lcall *%es:0xd
[PXE] PMM now tested and working Minor bugfix: 4 x 2 = 8, not 16
2008-03-11 17:08:04 +01:00
addw $8, %sp
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
testw %ax, %ax
[romprefix] Add more diagnostic messages to ROM prefix Include PMM allocation result in POST banner. Include full product string in "starting execution" message. Also mark ourselves as supporting DDIM in PnP header, for completeness.
2008-08-26 00:36:24 +02:00
je got_bbs
[romprefix] Cope with PnP BIOSes that fail to set %es:%di on entry 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>
2009-08-08 15:36:10 +02:00
no_pnp: /* Not PnP-compliant - therefore cannot be BBS-compliant */
[romprefix] Add more diagnostic messages to ROM prefix Include PMM allocation result in POST banner. Include full product string in "starting execution" message. Also mark ourselves as supporting DDIM in PnP header, for completeness.
2008-08-26 00:36:24 +02:00
no_bbs: /* Not BBS-compliant - must hook INT 19 */
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
movw $init_message_int19, %si
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
xorw %di, %di
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
call print_message
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
xorw %ax, %ax
movw %ax, %es
[prefix] When we have to hook INT 19, chain to original handler if possible When the BIOS doesn't support BBS, hooking INT 19 is the only way to add ourselves as a boot device. If we have to do this, we should at least try to chain to the original INT 19 vector if our boot fails. Idea suggested by Andrew Schran <aschran@google.com>
2008-06-14 14:49:26 +02:00
pushl %es:( 0x19 * 4 )
popl orig_int19
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
pushw %gs /* %gs contains runtime %cs */
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
pushw $int19_entry
popl %es:( 0x19 * 4 )
[romprefix] Add more diagnostic messages to ROM prefix Include PMM allocation result in POST banner. Include full product string in "starting execution" message. Also mark ourselves as supporting DDIM in PnP header, for completeness.
2008-08-26 00:36:24 +02:00
jmp bbs_done
got_bbs: /* BBS compliant - no need to hook INT 19 */
movw $init_message_bbs, %si
xorw %di, %di
call print_message
bbs_done:
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* Check for PMM */
[romprefix] Fix PMM detection start address Commit fd0aef9 introduced a typo that caused PMM detection to start at paragraph 0xe00 rather than 0xe000. (Detection would still work, since it would scan until it ran out of base memory, but it would end up scanning an unnecessarily large portion of base memory.) Spotted by Sebastian Herbszt <herbszt@gmx.de>.
2008-06-29 00:18:11 +02:00
movw $( 0xe000 - 1 ), %bx
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
pmm_scan:
[prefix] Add PCI bus:dev.fn to ROM product string This allows multiple gPXE ROMs in a system to be disambiguated at boot time; the PCI ID will show up in the boot menu for a BBS-compliant BIOS.
2008-05-21 19:43:58 +02:00
incw %bx
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
jz no_pmm
[prefix] Add PCI bus:dev.fn to ROM product string This allows multiple gPXE ROMs in a system to be disambiguated at boot time; the PCI ID will show up in the boot menu for a BBS-compliant BIOS.
2008-05-21 19:43:58 +02:00
movw %bx, %es
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
cmpl $PMM_SIGNATURE, %es:0
jne pmm_scan
[prefix] Add PCI bus:dev.fn to ROM product string This allows multiple gPXE ROMs in a system to be disambiguated at boot time; the PCI ID will show up in the boot menu for a BBS-compliant BIOS.
2008-05-21 19:43:58 +02:00
xorw %dx, %dx
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
xorw %si, %si
movzbw %es:5, %cx
1: es lodsb
[prefix] Add PCI bus:dev.fn to ROM product string This allows multiple gPXE ROMs in a system to be disambiguated at boot time; the PCI ID will show up in the boot menu for a BBS-compliant BIOS.
2008-05-21 19:43:58 +02:00
addb %al, %dl
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
loop 1b
jnz pmm_scan
/* PMM found: print PMM message */
movw $init_message_pmm, %si
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
xorw %di, %di
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
call print_message
[romprefix] Use smaller PMM allocations if possible The only way that PMM allows us to request a block in a region with A20=0 is to ask for a block with an alignment of 2MB. Due to the PMM API design, the only way we can do this is to ask for a block with a size of 2MB. Unfortunately, some BIOSes will hit problems if we allocate a 2MB block. In particular, it may not be possible to enter the BIOS setup screen; the BIOS setup code attempts a PMM allocation, fails, and hangs the machine. We now try allocating only as much as we need via PMM. If the allocated block has A20=1, we free the allocated block, double the allocation size, and try again. Repeat until either we obtain a block with A20=0 or allocation fails. (This is guaranteed to terminate by the time we reach an allocation size of 2MB.)
2008-11-11 21:00:13 +01:00
/* We have PMM and so a 1kB stack: preserve upper register halves */
pushal
/* Calculate required allocation size in %esi */
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
movzwl real_size, %eax
[romprefix] Use smaller PMM allocations if possible The only way that PMM allows us to request a block in a region with A20=0 is to ask for a block with an alignment of 2MB. Due to the PMM API design, the only way we can do this is to ask for a block with a size of 2MB. Unfortunately, some BIOSes will hit problems if we allocate a 2MB block. In particular, it may not be possible to enter the BIOS setup screen; the BIOS setup code attempts a PMM allocation, fails, and hangs the machine. We now try allocating only as much as we need via PMM. If the allocated block has A20=1, we free the allocated block, double the allocation size, and try again. Repeat until either we obtain a block with A20=0 or allocation fails. (This is guaranteed to terminate by the time we reach an allocation size of 2MB.)
2008-11-11 21:00:13 +01:00
shll $9, %eax
addl $_textdata_memsz, %eax
orw $0xffff, %ax /* Ensure allocation size is at least 64kB */
bsrl %eax, %ecx
subw $15, %cx /* Round up and convert to 64kB count */
movw $1, %si
shlw %cl, %si
pmm_loop:
/* Try to allocate block via PMM */
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
pushw $0x0006 /* Aligned, extended memory */
pushl $0xffffffff /* No handle */
[romprefix] Use smaller PMM allocations if possible The only way that PMM allows us to request a block in a region with A20=0 is to ask for a block with an alignment of 2MB. Due to the PMM API design, the only way we can do this is to ask for a block with a size of 2MB. Unfortunately, some BIOSes will hit problems if we allocate a 2MB block. In particular, it may not be possible to enter the BIOS setup screen; the BIOS setup code attempts a PMM allocation, fails, and hangs the machine. We now try allocating only as much as we need via PMM. If the allocated block has A20=1, we free the allocated block, double the allocation size, and try again. Repeat until either we obtain a block with A20=0 or allocation fails. (This is guaranteed to terminate by the time we reach an allocation size of 2MB.)
2008-11-11 21:00:13 +01:00
movzwl %si, %eax
shll $12, %eax
pushl %eax /* Allocation size in paragraphs */
[romprefix] Add more diagnostic messages to ROM prefix Include PMM allocation result in POST banner. Include full product string in "starting execution" message. Also mark ourselves as supporting DDIM in PnP header, for completeness.
2008-08-26 00:36:24 +02:00
pushw $PMM_ALLOCATE
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
lcall *%es:7
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
addw $12, %sp
[romprefix] Use smaller PMM allocations if possible The only way that PMM allows us to request a block in a region with A20=0 is to ask for a block with an alignment of 2MB. Due to the PMM API design, the only way we can do this is to ask for a block with a size of 2MB. Unfortunately, some BIOSes will hit problems if we allocate a 2MB block. In particular, it may not be possible to enter the BIOS setup screen; the BIOS setup code attempts a PMM allocation, fails, and hangs the machine. We now try allocating only as much as we need via PMM. If the allocated block has A20=1, we free the allocated block, double the allocation size, and try again. Repeat until either we obtain a block with A20=0 or allocation fails. (This is guaranteed to terminate by the time we reach an allocation size of 2MB.)
2008-11-11 21:00:13 +01:00
/* Abort if allocation fails */
testw %dx, %dx /* %ax==0 even on success, since align>=64kB */
jz pmm_fail
/* If block has A20==1, free block and try again with twice
* the allocation size (and hence alignment).
*/
testw $0x0010, %dx
jz got_pmm
pushw %dx
pushw $0
pushw $PMM_DEALLOCATE
lcall *%es:7
addw $6, %sp
addw %si, %si
jmp pmm_loop
got_pmm: /* PMM allocation succeeded */
movw %dx, ( image_source + 2 )
[romprefix] Add more diagnostic messages to ROM prefix Include PMM allocation result in POST banner. Include full product string in "starting execution" message. Also mark ourselves as supporting DDIM in PnP header, for completeness.
2008-08-26 00:36:24 +02:00
movw %dx, %ax
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
xorw %di, %di
[romprefix] Add more diagnostic messages to ROM prefix Include PMM allocation result in POST banner. Include full product string in "starting execution" message. Also mark ourselves as supporting DDIM in PnP header, for completeness.
2008-08-26 00:36:24 +02:00
call print_hex_word
[build] Cope with oddities in the Fedora 10 assembler The version of the GNU assembler shipped with Fedora 10 (2.18.50.0.9-8.fc10) complains about character literals in some of our assembly code. Changing $'x' to $( 'x' ) seems to fix the problem. Yes, the whitespace is required; using just $('x') does not work. Reported by Kevin O'Connor <kevin@koconnor.net>.
2009-02-16 04:53:25 +01:00
movb $( '@' ), %al
[romprefix] Use smaller PMM allocations if possible The only way that PMM allows us to request a block in a region with A20=0 is to ask for a block with an alignment of 2MB. Due to the PMM API design, the only way we can do this is to ask for a block with a size of 2MB. Unfortunately, some BIOSes will hit problems if we allocate a 2MB block. In particular, it may not be possible to enter the BIOS setup screen; the BIOS setup code attempts a PMM allocation, fails, and hangs the machine. We now try allocating only as much as we need via PMM. If the allocated block has A20=1, we free the allocated block, double the allocation size, and try again. Repeat until either we obtain a block with A20=0 or allocation fails. (This is guaranteed to terminate by the time we reach an allocation size of 2MB.)
2008-11-11 21:00:13 +01:00
call print_character
movw %si, %ax
call print_hex_byte
[prefix] Add .hrom prefix for a ROM that loads high under PCI3 without PMM 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>
2009-10-06 22:12:22 +02:00
pmm_copy:
[romprefix] Use smaller PMM allocations if possible The only way that PMM allows us to request a block in a region with A20=0 is to ask for a block with an alignment of 2MB. Due to the PMM API design, the only way we can do this is to ask for a block with a size of 2MB. Unfortunately, some BIOSes will hit problems if we allocate a 2MB block. In particular, it may not be possible to enter the BIOS setup screen; the BIOS setup code attempts a PMM allocation, fails, and hangs the machine. We now try allocating only as much as we need via PMM. If the allocated block has A20=1, we free the allocated block, double the allocation size, and try again. Repeat until either we obtain a block with A20=0 or allocation fails. (This is guaranteed to terminate by the time we reach an allocation size of 2MB.)
2008-11-11 21:00:13 +01:00
/* Copy ROM to PMM block */
[romprefix] Add more diagnostic messages to ROM prefix Include PMM allocation result in POST banner. Include full product string in "starting execution" message. Also mark ourselves as supporting DDIM in PnP header, for completeness.
2008-08-26 00:36:24 +02:00
xorw %ax, %ax
movw %ax, %es
movl image_source, %edi
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
xorl %esi, %esi
movzbl romheader_size, %ecx
shll $9, %ecx
addr32 rep movsb /* PMM presence implies flat real mode */
movl %edi, decompress_to
[romprefix] Update ROM checksum even if PMM allocation fails There are code paths other than PMM allocation that can result in our changing the ROM checksum. For example, we attempt to update our product string to incorporate the PCI bus:dev.fn number. In a system that does not support PMM, we could therefore end up with an incorrect checksum. Fix by attempting to update the checksum unconditionally.
2009-02-15 12:42:15 +01:00
/* Shrink ROM */
movb $_prefix_memsz_sect, romheader_size
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
#if defined(SHRINK_WITHOUT_PMM) || defined(LOAD_ROM_FROM_PCI)
[prefix] Add .hrom prefix for a ROM that loads high under PCI3 without PMM 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>
2009-10-06 22:12:22 +02:00
jmp pmm_done
[romprefix] Update ROM checksum even if PMM allocation fails There are code paths other than PMM allocation that can result in our changing the ROM checksum. For example, we attempt to update our product string to incorporate the PCI bus:dev.fn number. In a system that does not support PMM, we could therefore end up with an incorrect checksum. Fix by attempting to update the checksum unconditionally.
2009-02-15 12:42:15 +01:00
pmm_fail:
[prefix] Add .hrom prefix for a ROM that loads high under PCI3 without PMM 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>
2009-10-06 22:12:22 +02:00
/* Print marker and copy ourselves to high memory */
movl $HIGHMEM_LOADPOINT, image_source
xorw %di, %di
movb $( '!' ), %al
call print_character
jmp pmm_copy
pmm_done:
#else
pmm_fail:
#endif
[romprefix] Update ROM checksum even if PMM allocation fails There are code paths other than PMM allocation that can result in our changing the ROM checksum. For example, we attempt to update our product string to incorporate the PCI bus:dev.fn number. In a system that does not support PMM, we could therefore end up with an incorrect checksum. Fix by attempting to update the checksum unconditionally.
2009-02-15 12:42:15 +01:00
/* Restore upper register halves */
popal
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
#if defined(LOAD_ROM_FROM_PCI)
call load_from_pci
jc load_err
jmp load_ok
[romprefix] Update ROM checksum even if PMM allocation fails There are code paths other than PMM allocation that can result in our changing the ROM checksum. For example, we attempt to update our product string to incorporate the PCI bus:dev.fn number. In a system that does not support PMM, we could therefore end up with an incorrect checksum. Fix by attempting to update the checksum unconditionally.
2009-02-15 12:42:15 +01:00
no_pmm:
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
/* Cannot continue without PMM - print error message */
xorw %di, %di
movw $init_message_no_pmm, %si
call print_message
load_err:
/* Wait for five seconds to let user see message */
movw $90, %cx
1: call wait_for_tick
loop 1b
/* Mark environment as invalid and return */
movl $0, decompress_to
jmp out
[romprefix] Update ROM checksum even if PMM allocation fails There are code paths other than PMM allocation that can result in our changing the ROM checksum. For example, we attempt to update our product string to incorporate the PCI bus:dev.fn number. In a system that does not support PMM, we could therefore end up with an incorrect checksum. Fix by attempting to update the checksum unconditionally.
2009-02-15 12:42:15 +01:00
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
load_ok:
#else
no_pmm:
#endif
[romprefix] Update ROM checksum even if PMM allocation fails There are code paths other than PMM allocation that can result in our changing the ROM checksum. For example, we attempt to update our product string to incorporate the PCI bus:dev.fn number. In a system that does not support PMM, we could therefore end up with an incorrect checksum. Fix by attempting to update the checksum unconditionally.
2009-02-15 12:42:15 +01:00
/* Update checksum */
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
xorw %bx, %bx
xorw %si, %si
[romprefix] Update ROM checksum even if PMM allocation fails There are code paths other than PMM allocation that can result in our changing the ROM checksum. For example, we attempt to update our product string to incorporate the PCI bus:dev.fn number. In a system that does not support PMM, we could therefore end up with an incorrect checksum. Fix by attempting to update the checksum unconditionally.
2009-02-15 12:42:15 +01:00
movzbw romheader_size, %cx
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
shlw $9, %cx
1: lodsb
addb %al, %bl
loop 1b
subb %bl, checksum
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
/* Copy self to option ROM space. Required for PCI3.0, which
* loads us to a temporary location in low memory. Will be a
* no-op for lower PCI versions.
*/
[build] Cope with oddities in the Fedora 10 assembler The version of the GNU assembler shipped with Fedora 10 (2.18.50.0.9-8.fc10) complains about character literals in some of our assembly code. Changing $'x' to $( 'x' ) seems to fix the problem. Yes, the whitespace is required; using just $('x') does not work. Reported by Kevin O'Connor <kevin@koconnor.net>.
2009-02-16 04:53:25 +01:00
movb $( ' ' ), %al
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
xorw %di, %di
call print_character
movw %gs, %ax
call print_hex_word
movzbw romheader_size, %cx
shlw $9, %cx
movw %ax, %es
[romprefix] Fix ROM image copy on PCI 3.0 BIOSes Add the missing instructions to the code path that I never tested due to not having a PCI 3.0 system available. (D'oh)
2008-08-06 00:18:07 +02:00
xorw %si, %si
xorw %di, %di
cs rep movsb
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
/* Prompt for POST-time shell */
[prefix] Prompt for entering gPXE shell during POST The ROM prefix now prompts the user to enter the gPXE shell during POST; this allows for configuring gPXE without needing to attempt to boot from it. (It also slows down system boot by three seconds per gPXE ROM, but hey.) This is apparently a certain OEM's requirement for option ROMs.
2008-05-22 16:14:33 +02:00
movw $init_message_prompt, %si
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
xorw %di, %di
[prefix] Prompt for entering gPXE shell during POST The ROM prefix now prompts the user to enter the gPXE shell during POST; this allows for configuring gPXE without needing to attempt to boot from it. (It also slows down system boot by three seconds per gPXE ROM, but hey.) This is apparently a certain OEM's requirement for option ROMs.
2008-05-22 16:14:33 +02:00
call print_message
[romprefix] Add vendor branding facilities and guidelines Some hardware vendors have been known to remove all gPXE-related branding from ROMs that they build. While this is not prohibited by the GPL, it is a little impolite. Add a facility for adding branding messages via two #defines (PRODUCT_NAME and PRODUCT_SHORT_NAME) in config/general.h. This should accommodate all known OEM-mandated branding requirements. Vendors with branding requirements that cannot be satisfied by using PRODUCT_NAME and/or PRODUCT_SHORT_NAME should contact us so that we can extended this facility as necessary.
2008-10-31 20:10:28 +01:00
movw $prodstr, %si
call print_message
movw $init_message_dots, %si
call print_message
[romprefix] If we hook INT 19, prompt before attempting boot On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial.
2008-09-24 01:53:40 +02:00
/* Wait for Ctrl-B */
movw $0xff02, %bx
call wait_for_key
[romprefix] Allow BANNER_TIMEOUT to control banners in romprefix.S In particular, allow BANNER_TIMEOUT=0 to inhibit the prompt banners altogether. Ironically, this request comes from the same OEM that originally required the prompts to be present during POST.
2008-09-25 02:53:42 +02:00
/* Clear prompt */
pushf
xorw %di, %di
[romprefix] Add vendor branding facilities and guidelines Some hardware vendors have been known to remove all gPXE-related branding from ROMs that they build. While this is not prohibited by the GPL, it is a little impolite. Add a facility for adding branding messages via two #defines (PRODUCT_NAME and PRODUCT_SHORT_NAME) in config/general.h. This should accommodate all known OEM-mandated branding requirements. Vendors with branding requirements that cannot be satisfied by using PRODUCT_NAME and/or PRODUCT_SHORT_NAME should contact us so that we can extended this facility as necessary.
2008-10-31 20:10:28 +01:00
call print_kill_line
movw $init_message_done, %si
[romprefix] Allow BANNER_TIMEOUT to control banners in romprefix.S In particular, allow BANNER_TIMEOUT=0 to inhibit the prompt banners altogether. Ironically, this request comes from the same OEM that originally required the prompts to be present during POST.
2008-09-25 02:53:42 +02:00
call print_message
popf
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
jnz out
[build] Rename gPXE to iPXE 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>
2010-04-19 21:16:01 +02:00
/* Ctrl-B was pressed: invoke iPXE. The keypress will be
[romprefix] If we hook INT 19, prompt before attempting boot On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial.
2008-09-24 01:53:40 +02:00
* picked up by the initial shell prompt, and we will drop
* into a shell.
[prefix] Prompt for entering gPXE shell during POST The ROM prefix now prompts the user to enter the gPXE shell during POST; this allows for configuring gPXE without needing to attempt to boot from it. (It also slows down system boot by three seconds per gPXE ROM, but hey.) This is apparently a certain OEM's requirement for option ROMs.
2008-05-22 16:14:33 +02:00
*/
pushw %cs
call exec
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
out:
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* Restore registers */
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
popw %gs
[prefix] Prompt for entering gPXE shell during POST The ROM prefix now prompts the user to enter the gPXE shell during POST; this allows for configuring gPXE without needing to attempt to boot from it. (It also slows down system boot by three seconds per gPXE ROM, but hey.) This is apparently a certain OEM's requirement for option ROMs.
2008-05-22 16:14:33 +02:00
popw %fs
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
popw %es
popw %ds
popaw
[romprefix] On a PCI3.0, non-BBS system, use the correct %cs for INT19 On a system that doesn't support BBS, we end up hooking INT19 to gain control of the boot process. If the system is PCI3.0, we must take care to use the runtime value for %cs, rather than the POST-time value, otherwise we end up pointing INT19 to the temporary option ROM POST scratch area.
2008-08-22 04:01:46 +02:00
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* Indicate boot capability to PnP BIOS, if present */
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
movw $0x20, %ax
Initial revision
2005-03-08 19:53:11 +01:00
lret
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
.size init, . - init
[romprefix] Add vendor branding facilities and guidelines Some hardware vendors have been known to remove all gPXE-related branding from ROMs that they build. While this is not prohibited by the GPL, it is a little impolite. Add a facility for adding branding messages via two #defines (PRODUCT_NAME and PRODUCT_SHORT_NAME) in config/general.h. This should accommodate all known OEM-mandated branding requirements. Vendors with branding requirements that cannot be satisfied by using PRODUCT_NAME and/or PRODUCT_SHORT_NAME should contact us so that we can extended this facility as necessary.
2008-10-31 20:10:28 +01:00
/*
* Note to hardware vendors:
*
* If you wish to brand this boot ROM, please do so by defining the
* strings PRODUCT_NAME and PRODUCT_SHORT_NAME in config/general.h.
*
* While nothing in the GPL prevents you from removing all references
[build] Rename gPXE to iPXE 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>
2010-04-19 21:16:01 +02:00
* to iPXE or http://ipxe.org, we prefer you not to do so.
[romprefix] Add vendor branding facilities and guidelines Some hardware vendors have been known to remove all gPXE-related branding from ROMs that they build. While this is not prohibited by the GPL, it is a little impolite. Add a facility for adding branding messages via two #defines (PRODUCT_NAME and PRODUCT_SHORT_NAME) in config/general.h. This should accommodate all known OEM-mandated branding requirements. Vendors with branding requirements that cannot be satisfied by using PRODUCT_NAME and/or PRODUCT_SHORT_NAME should contact us so that we can extended this facility as necessary.
2008-10-31 20:10:28 +01:00
*
* If you have an OEM-mandated branding requirement that cannot be
* satisfied simply by defining PRODUCT_NAME and PRODUCT_SHORT_NAME,
* please contact us.
*
* [ Including an ASCII NUL in PRODUCT_NAME is considered to be
* bypassing the spirit of this request! ]
*/
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
init_message:
[romprefix] Add vendor branding facilities and guidelines Some hardware vendors have been known to remove all gPXE-related branding from ROMs that they build. While this is not prohibited by the GPL, it is a little impolite. Add a facility for adding branding messages via two #defines (PRODUCT_NAME and PRODUCT_SHORT_NAME) in config/general.h. This should accommodate all known OEM-mandated branding requirements. Vendors with branding requirements that cannot be satisfied by using PRODUCT_NAME and/or PRODUCT_SHORT_NAME should contact us so that we can extended this facility as necessary.
2008-10-31 20:10:28 +01:00
.ascii "\n"
.ascii PRODUCT_NAME
.ascii "\n"
[build] Rename gPXE to iPXE 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>
2010-04-19 21:16:01 +02:00
.asciz "iPXE (http://ipxe.org) - "
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
.size init_message, . - init_message
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
init_message_pci:
.asciz " PCI"
.size init_message_pci, . - init_message_pci
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
init_message_pnp:
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
.asciz " PnP"
[prefix] Prompt for entering gPXE shell during POST The ROM prefix now prompts the user to enter the gPXE shell during POST; this allows for configuring gPXE without needing to attempt to boot from it. (It also slows down system boot by three seconds per gPXE ROM, but hey.) This is apparently a certain OEM's requirement for option ROMs.
2008-05-22 16:14:33 +02:00
.size init_message_pnp, . - init_message_pnp
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
init_message_bbs:
.asciz " BBS"
[prefix] Prompt for entering gPXE shell during POST The ROM prefix now prompts the user to enter the gPXE shell during POST; this allows for configuring gPXE without needing to attempt to boot from it. (It also slows down system boot by three seconds per gPXE ROM, but hey.) This is apparently a certain OEM's requirement for option ROMs.
2008-05-22 16:14:33 +02:00
.size init_message_bbs, . - init_message_bbs
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
init_message_pmm:
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
.asciz " PMM"
[prefix] Prompt for entering gPXE shell during POST The ROM prefix now prompts the user to enter the gPXE shell during POST; this allows for configuring gPXE without needing to attempt to boot from it. (It also slows down system boot by three seconds per gPXE ROM, but hey.) This is apparently a certain OEM's requirement for option ROMs.
2008-05-22 16:14:33 +02:00
.size init_message_pmm, . - init_message_pmm
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
#ifdef LOAD_ROM_FROM_PCI
init_message_no_pmm:
.asciz "\nPMM required but not present!\n"
.size init_message_no_pmm, . - init_message_no_pmm
#endif
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
init_message_int19:
.asciz " INT19"
[prefix] Prompt for entering gPXE shell during POST The ROM prefix now prompts the user to enter the gPXE shell during POST; this allows for configuring gPXE without needing to attempt to boot from it. (It also slows down system boot by three seconds per gPXE ROM, but hey.) This is apparently a certain OEM's requirement for option ROMs.
2008-05-22 16:14:33 +02:00
.size init_message_int19, . - init_message_int19
init_message_prompt:
[romprefix] Add vendor branding facilities and guidelines Some hardware vendors have been known to remove all gPXE-related branding from ROMs that they build. While this is not prohibited by the GPL, it is a little impolite. Add a facility for adding branding messages via two #defines (PRODUCT_NAME and PRODUCT_SHORT_NAME) in config/general.h. This should accommodate all known OEM-mandated branding requirements. Vendors with branding requirements that cannot be satisfied by using PRODUCT_NAME and/or PRODUCT_SHORT_NAME should contact us so that we can extended this facility as necessary.
2008-10-31 20:10:28 +01:00
.asciz "\nPress Ctrl-B to configure "
[prefix] Prompt for entering gPXE shell during POST The ROM prefix now prompts the user to enter the gPXE shell during POST; this allows for configuring gPXE without needing to attempt to boot from it. (It also slows down system boot by three seconds per gPXE ROM, but hey.) This is apparently a certain OEM's requirement for option ROMs.
2008-05-22 16:14:33 +02:00
.size init_message_prompt, . - init_message_prompt
[romprefix] Add vendor branding facilities and guidelines Some hardware vendors have been known to remove all gPXE-related branding from ROMs that they build. While this is not prohibited by the GPL, it is a little impolite. Add a facility for adding branding messages via two #defines (PRODUCT_NAME and PRODUCT_SHORT_NAME) in config/general.h. This should accommodate all known OEM-mandated branding requirements. Vendors with branding requirements that cannot be satisfied by using PRODUCT_NAME and/or PRODUCT_SHORT_NAME should contact us so that we can extended this facility as necessary.
2008-10-31 20:10:28 +01:00
init_message_dots:
.asciz "..."
.size init_message_dots, . - init_message_dots
init_message_done:
.asciz "\n\n"
.size init_message_done, . - init_message_done
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* ROM image location
*
* May be either within option ROM space, or within PMM-allocated block.
*/
[config] Make PXE stack a compile-time option 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>
2009-10-07 01:15:06 +02:00
.globl image_source
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
image_source:
.long 0
.size image_source, . - image_source
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* Temporary decompression area
*
* May be either at HIGHMEM_LOADPOINT, or within PMM-allocated block.
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
* If a PCI ROM load fails, this will be set to zero.
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
*/
[config] Make PXE stack a compile-time option 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>
2009-10-07 01:15:06 +02:00
.globl decompress_to
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
decompress_to:
.long HIGHMEM_LOADPOINT
.size decompress_to, . - decompress_to
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
#ifdef LOAD_ROM_FROM_PCI
/* Set if the PCI BIOS is present, even <3.0 */
pcibios_present:
.byte 0
.byte 0 /* for alignment */
.size pcibios_present, . - pcibios_present
/* PCI bus:device.function word
*
* Filled in by init in the .xrom case, so the remainder of the ROM
* can be located.
*/
pci_busdevfn:
.word 0
.size pci_busdevfn, . - pci_busdevfn
#endif
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
/* BBS version
*
* Filled in by BBS BIOS. We ignore the value.
*/
bbs_version:
.word 0
[romprefix] Add more diagnostic messages to ROM prefix Include PMM allocation result in POST banner. Include full product string in "starting execution" message. Also mark ourselves as supporting DDIM in PnP header, for completeness.
2008-08-26 00:36:24 +02:00
.size bbs_version, . - bbs_version
[PXE] Improve PnP/BBS detection Use BBS installation check to see if we need to hook INT19 even on a PnP BIOS. Verify that $PnP signature is paragraph-aligned; bochs/qemu BIOS provides a dummy $PnP signature with no valid entry point, and deliberately unaligns the signature to indicate that it is not properly valid. Print message if INT19 is hooked. Attempt to use PMM even if BBS check failed.
2008-03-11 13:02:12 +01:00
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* Boot Execution Vector entry point
*
* Called by the PnP BIOS when it wants to boot us.
*/
bev_entry:
pushw %cs
call exec
lret
.size bev_entry, . - bev_entry
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
#ifdef LOAD_ROM_FROM_PCI
#define PCI_ROM_ADDRESS 0x30 /* Bits 31:11 address, 10:1 reserved */
#define PCI_ROM_ADDRESS_ENABLE 0x00000001
#define PCI_ROM_ADDRESS_MASK 0xfffff800
#define PCIBIOS_READ_WORD 0xb109
#define PCIBIOS_READ_DWORD 0xb10a
#define PCIBIOS_WRITE_WORD 0xb10c
#define PCIBIOS_WRITE_DWORD 0xb10d
/* Determine size of PCI BAR
*
* %bx : PCI bus:dev.fn to probe
* %di : Address of BAR to find size of
* %edx : Mask of address bits within BAR
*
* %ecx : Size for a memory resource,
* 1 for an I/O resource (bit 0 set).
* CF : Set on error or nonexistent device (all-ones read)
*
* All other registers saved.
*/
pci_bar_size:
/* Save registers */
pushw %ax
pushl %esi
pushl %edx
/* Read current BAR value */
movw $PCIBIOS_READ_DWORD, %ax
int $0x1a
/* Check for device existence and save it */
testb $1, %cl /* I/O bit? */
jz 1f
andl $1, %ecx /* If so, exit with %ecx = 1 */
jmp 99f
1: notl %ecx
testl %ecx, %ecx /* Set ZF iff %ecx was all-ones */
notl %ecx
jnz 1f
stc /* All ones - exit with CF set */
jmp 99f
1: movl %ecx, %esi /* Save in %esi */
/* Write all ones to BAR */
movl %edx, %ecx
movw $PCIBIOS_WRITE_DWORD, %ax
int $0x1a
/* Read back BAR */
movw $PCIBIOS_READ_DWORD, %ax
int $0x1a
/* Find decode size from least set bit in mask BAR */
bsfl %ecx, %ecx /* Find least set bit, log2(decode size) */
jz 1f /* Mask BAR should not be zero */
xorl %edx, %edx
incl %edx
shll %cl, %edx /* %edx = decode size */
jmp 2f
1: xorl %edx, %edx /* Return zero size for mask BAR zero */
/* Restore old BAR value */
2: movl %esi, %ecx
movw $PCIBIOS_WRITE_DWORD, %ax
int $0x1a
movl %edx, %ecx /* Return size in %ecx */
/* Restore registers and return */
99: popl %edx
popl %esi
popw %ax
ret
.size pci_bar_size, . - pci_bar_size
/* PCI ROM loader
*
* Called from init in the .xrom case to load the non-prefix code
* using the PCI ROM BAR.
*
* Returns with carry flag set on error. All registers saved.
*/
load_from_pci:
/*
* Use PCI BIOS access to config space. The calls take
*
* %ah : 0xb1 %al : function
* %bx : bus/dev/fn
* %di : config space address
* %ecx : value to write (for writes)
*
* %ecx : value read (for reads)
* %ah : return code
* CF : error indication
*
* All registers not used for return are preserved.
*/
/* Save registers and set up %es for big real mode */
pushal
pushw %es
xorw %ax, %ax
movw %ax, %es
/* Check PCI BIOS presence */
cmpb $0, pcibios_present
jz err_pcibios
/* Load existing PCI ROM BAR */
movw $PCIBIOS_READ_DWORD, %ax
movw pci_busdevfn, %bx
movw $PCI_ROM_ADDRESS, %di
int $0x1a
/* Maybe it's already enabled? */
testb $PCI_ROM_ADDRESS_ENABLE, %cl
jz 1f
movb $1, %dl /* Flag indicating no deinit required */
movl %ecx, %ebp
jmp check_rom
/* Determine PCI BAR decode size */
1: movl $PCI_ROM_ADDRESS_MASK, %edx
call pci_bar_size /* Returns decode size in %ecx */
jc err_size_insane /* CF => no ROM BAR, %ecx == ffffffff */
/* Check sanity of decode size */
xorl %eax, %eax
movw real_size, %ax
shll $9, %eax /* %eax = ROM size */
cmpl %ecx, %eax
ja err_size_insane /* Insane if decode size < ROM size */
cmpl $0x100000, %ecx
jae err_size_insane /* Insane if decode size >= 1MB */
/* Find a place to map the BAR
* In theory we should examine e820 and all PCI BARs to find a
* free region. However, we run at POST when e820 may not be
* available, and memory reads of an unmapped location are
* de facto standardized to return all-ones. Thus, we can get
* away with searching high memory (0xf0000000 and up) on
* multiples of the ROM BAR decode size for a sufficiently
* large all-ones region.
*/
movl %ecx, %edx /* Save ROM BAR size in %edx */
movl $0xf0000000, %ebp
xorl %eax, %eax
notl %eax /* %eax = all ones */
bar_search:
movl %ebp, %edi
movl %edx, %ecx
shrl $2, %ecx
addr32 repe scasl /* Scan %es:edi for anything not all-ones */
jz bar_found
addl %edx, %ebp
testl $0x80000000, %ebp
jz err_no_bar
jmp bar_search
bar_found:
movl %edi, %ebp
/* Save current BAR value on stack to restore later */
movw $PCIBIOS_READ_DWORD, %ax
movw $PCI_ROM_ADDRESS, %di
int $0x1a
pushl %ecx
/* Map the ROM */
movw $PCIBIOS_WRITE_DWORD, %ax
movl %ebp, %ecx
orb $PCI_ROM_ADDRESS_ENABLE, %cl
int $0x1a
xorb %dl, %dl /* %dl = 0 : ROM was not already mapped */
check_rom:
/* Check and copy ROM - enter with %dl set to skip unmapping,
* %ebp set to mapped ROM BAR address.
* We check up to prodstr_separator for equality, since anything past
* that may have been modified. Since our check includes the checksum
* byte over the whole ROM stub, that should be sufficient.
*/
xorb %dh, %dh /* %dh = 0 : ROM did not fail integrity check */
/* Verify ROM integrity */
xorl %esi, %esi
movl %ebp, %edi
movl $prodstr_separator, %ecx
addr32 repe cmpsb
jz copy_rom
incb %dh /* ROM failed integrity check */
movl %ecx, %ebp /* Save number of bytes left */
jmp skip_load
copy_rom:
/* Print BAR address and indicate whether we mapped it ourselves */
movb $( ' ' ), %al
xorw %di, %di
call print_character
movl %ebp, %eax
call print_hex_dword
movb $( '-' ), %al /* '-' for self-mapped */
subb %dl, %al
subb %dl, %al /* '+' = '-' - 2 for BIOS-mapped */
call print_character
/* Copy ROM at %ebp to PMM or highmem block */
movl %ebp, %esi
movl image_source, %edi
movzwl real_size, %ecx
shll $9, %ecx
addr32 es rep movsb
movl %edi, decompress_to
skip_load:
testb %dl, %dl /* Was ROM already mapped? */
jnz skip_unmap
/* Unmap the ROM by restoring old ROM BAR */
movw $PCIBIOS_WRITE_DWORD, %ax
movw $PCI_ROM_ADDRESS, %di
popl %ecx
int $0x1a
skip_unmap:
/* Error handling */
testb %dh, %dh
jnz err_rom_invalid
clc
jmp 99f
err_pcibios: /* No PCI BIOS available */
movw $load_message_no_pcibios, %si
xorl %eax, %eax /* "error code" is zero */
jmp 1f
err_size_insane: /* BAR has size (%ecx) that is insane */
movw $load_message_size_insane, %si
movl %ecx, %eax
jmp 1f
err_no_bar: /* No space of sufficient size (%edx) found */
movw $load_message_no_bar, %si
movl %edx, %eax
jmp 1f
err_rom_invalid: /* Loaded ROM does not match (%ebp bytes left) */
movw $load_message_rom_invalid, %si
movzbl romheader_size, %eax
shll $9, %eax
subl %ebp, %eax
decl %eax /* %eax is now byte index of failure */
1: /* Error handler - print message at %si and dword in %eax */
xorw %di, %di
call print_message
call print_hex_dword
stc
99: popw %es
popal
ret
.size load_from_pci, . - load_from_pci
load_message_no_pcibios:
.asciz "\nNo PCI BIOS found! "
.size load_message_no_pcibios, . - load_message_no_pcibios
load_message_size_insane:
.asciz "\nROM resource has invalid size "
.size load_message_size_insane, . - load_message_size_insane
load_message_no_bar:
.asciz "\nNo memory hole of sufficient size "
.size load_message_no_bar, . - load_message_no_bar
load_message_rom_invalid:
.asciz "\nLoaded ROM is invalid at "
.size load_message_rom_invalid, . - load_message_rom_invalid
#endif /* LOAD_ROM_FROM_PCI */
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* INT19 entry point
*
[prefix] When we have to hook INT 19, chain to original handler if possible When the BIOS doesn't support BBS, hooking INT 19 is the only way to add ourselves as a boot device. If we have to do this, we should at least try to chain to the original INT 19 vector if our boot fails. Idea suggested by Andrew Schran <aschran@google.com>
2008-06-14 14:49:26 +02:00
* Called via the hooked INT 19 if we detected a non-PnP BIOS. We
[romprefix] If we hook INT 19, prompt before attempting boot On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial.
2008-09-24 01:53:40 +02:00
* attempt to return via the original INT 19 vector (if we were able
* to store it).
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
*/
int19_entry:
pushw %cs
[romprefix] If we hook INT 19, prompt before attempting boot On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial.
2008-09-24 01:53:40 +02:00
popw %ds
/* Prompt user to press B to boot */
movw $int19_message_prompt, %si
xorw %di, %di
call print_message
movw $prodstr, %si
call print_message
movw $int19_message_dots, %si
call print_message
[romprefix] Change from opt-in to opt-out when booting via INT19 On non-BBS systems, we have to hook INT 19 in order to be able to boot from the gPXE ROM at all. However, doing this unconditionally will prevent the user from booting via any other devices. Previously, the INT 19 entry point would prompt the user to press B in order to boot from gPXE, which makes it impossible to perform an unattended network boot. We now prompt the user to press N to skip booting from gPXE, which allows for unattended operation. This should be a better match for most real-world scenarios. Most modern systems support BBS and so are unaffected by this change. Very old (non-BBS) systems tend not to have PXE ROMs by default anyway; if the user has added a gPXE ROM then they probably do want to boot from the network. Newer non-BBS systems are essentially limited to IBM servers, which will recapture the INT 19 vector anyway and implement their own boot-ordering selection mechanism.
2008-12-04 17:46:16 +01:00
movw $0xdf4e, %bx
[romprefix] If we hook INT 19, prompt before attempting boot On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial.
2008-09-24 01:53:40 +02:00
call wait_for_key
[romprefix] Allow BANNER_TIMEOUT to control banners in romprefix.S In particular, allow BANNER_TIMEOUT=0 to inhibit the prompt banners altogether. Ironically, this request comes from the same OEM that originally required the prompts to be present during POST.
2008-09-25 02:53:42 +02:00
pushf
xorw %di, %di
[romprefix] Add vendor branding facilities and guidelines Some hardware vendors have been known to remove all gPXE-related branding from ROMs that they build. While this is not prohibited by the GPL, it is a little impolite. Add a facility for adding branding messages via two #defines (PRODUCT_NAME and PRODUCT_SHORT_NAME) in config/general.h. This should accommodate all known OEM-mandated branding requirements. Vendors with branding requirements that cannot be satisfied by using PRODUCT_NAME and/or PRODUCT_SHORT_NAME should contact us so that we can extended this facility as necessary.
2008-10-31 20:10:28 +01:00
call print_kill_line
movw $int19_message_done, %si
[romprefix] Allow BANNER_TIMEOUT to control banners in romprefix.S In particular, allow BANNER_TIMEOUT=0 to inhibit the prompt banners altogether. Ironically, this request comes from the same OEM that originally required the prompts to be present during POST.
2008-09-25 02:53:42 +02:00
call print_message
popf
[romprefix] Change from opt-in to opt-out when booting via INT19 On non-BBS systems, we have to hook INT 19 in order to be able to boot from the gPXE ROM at all. However, doing this unconditionally will prevent the user from booting via any other devices. Previously, the INT 19 entry point would prompt the user to press B in order to boot from gPXE, which makes it impossible to perform an unattended network boot. We now prompt the user to press N to skip booting from gPXE, which allows for unattended operation. This should be a better match for most real-world scenarios. Most modern systems support BBS and so are unaffected by this change. Very old (non-BBS) systems tend not to have PXE ROMs by default anyway; if the user has added a gPXE ROM then they probably do want to boot from the network. Newer non-BBS systems are essentially limited to IBM servers, which will recapture the INT 19 vector anyway and implement their own boot-ordering selection mechanism.
2008-12-04 17:46:16 +01:00
jz 1f
[build] Rename gPXE to iPXE 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>
2010-04-19 21:16:01 +02:00
/* Leave keypress in buffer and start iPXE. The keypress will
[romprefix] If we hook INT 19, prompt before attempting boot On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial.
2008-09-24 01:53:40 +02:00
* cause the usual initial Ctrl-B prompt to be skipped.
*/
pushw %cs
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
call exec
[romprefix] Allow BANNER_TIMEOUT to control banners in romprefix.S In particular, allow BANNER_TIMEOUT=0 to inhibit the prompt banners altogether. Ironically, this request comes from the same OEM that originally required the prompts to be present during POST.
2008-09-25 02:53:42 +02:00
1: /* Try to call original INT 19 vector */
[prefix] When we have to hook INT 19, chain to original handler if possible When the BIOS doesn't support BBS, hooking INT 19 is the only way to add ourselves as a boot device. If we have to do this, we should at least try to chain to the original INT 19 vector if our boot fails. Idea suggested by Andrew Schran <aschran@google.com>
2008-06-14 14:49:26 +02:00
movl %cs:orig_int19, %eax
testl %eax, %eax
[romprefix] If we hook INT 19, prompt before attempting boot On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial.
2008-09-24 01:53:40 +02:00
je 2f
[prefix] When we have to hook INT 19, chain to original handler if possible When the BIOS doesn't support BBS, hooking INT 19 is the only way to add ourselves as a boot device. If we have to do this, we should at least try to chain to the original INT 19 vector if our boot fails. Idea suggested by Andrew Schran <aschran@google.com>
2008-06-14 14:49:26 +02:00
ljmp *%cs:orig_int19
[romprefix] If we hook INT 19, prompt before attempting boot On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial.
2008-09-24 01:53:40 +02:00
2: /* No chained vector: issue INT 18 as a last resort */
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
int $0x18
.size int19_entry, . - int19_entry
[prefix] When we have to hook INT 19, chain to original handler if possible When the BIOS doesn't support BBS, hooking INT 19 is the only way to add ourselves as a boot device. If we have to do this, we should at least try to chain to the original INT 19 vector if our boot fails. Idea suggested by Andrew Schran <aschran@google.com>
2008-06-14 14:49:26 +02:00
orig_int19:
.long 0
.size orig_int19, . - orig_int19
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
[romprefix] If we hook INT 19, prompt before attempting boot On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial.
2008-09-24 01:53:40 +02:00
int19_message_prompt:
[romprefix] Change from opt-in to opt-out when booting via INT19 On non-BBS systems, we have to hook INT 19 in order to be able to boot from the gPXE ROM at all. However, doing this unconditionally will prevent the user from booting via any other devices. Previously, the INT 19 entry point would prompt the user to press B in order to boot from gPXE, which makes it impossible to perform an unattended network boot. We now prompt the user to press N to skip booting from gPXE, which allows for unattended operation. This should be a better match for most real-world scenarios. Most modern systems support BBS and so are unaffected by this change. Very old (non-BBS) systems tend not to have PXE ROMs by default anyway; if the user has added a gPXE ROM then they probably do want to boot from the network. Newer non-BBS systems are essentially limited to IBM servers, which will recapture the INT 19 vector anyway and implement their own boot-ordering selection mechanism.
2008-12-04 17:46:16 +01:00
.asciz "Press N to skip booting from "
[romprefix] If we hook INT 19, prompt before attempting boot On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial.
2008-09-24 01:53:40 +02:00
.size int19_message_prompt, . - int19_message_prompt
int19_message_dots:
.asciz "..."
.size int19_message_dots, . - int19_message_dots
[romprefix] Add vendor branding facilities and guidelines Some hardware vendors have been known to remove all gPXE-related branding from ROMs that they build. While this is not prohibited by the GPL, it is a little impolite. Add a facility for adding branding messages via two #defines (PRODUCT_NAME and PRODUCT_SHORT_NAME) in config/general.h. This should accommodate all known OEM-mandated branding requirements. Vendors with branding requirements that cannot be satisfied by using PRODUCT_NAME and/or PRODUCT_SHORT_NAME should contact us so that we can extended this facility as necessary.
2008-10-31 20:10:28 +01:00
int19_message_done:
.asciz "\n\n"
.size int19_message_done, . - int19_message_done
[romprefix] If we hook INT 19, prompt before attempting boot On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial.
2008-09-24 01:53:40 +02:00
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* Execute as a boot device
*
*/
exec: /* Set %ds = %cs */
pushw %cs
popw %ds
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses 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>
2009-10-18 22:12:51 +02:00
#ifdef LOAD_ROM_FROM_PCI
/* Don't execute if load was invalid */
cmpl $0, decompress_to
jne 1f
lret
1:
#endif
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* Print message as soon as possible */
[romprefix] Add more diagnostic messages to ROM prefix Include PMM allocation result in POST banner. Include full product string in "starting execution" message. Also mark ourselves as supporting DDIM in PnP header, for completeness.
2008-08-26 00:36:24 +02:00
movw $prodstr, %si
[prefix] Add PCI bus:dev.fn to ROM product string This allows multiple gPXE ROMs in a system to be disambiguated at boot time; the PCI ID will show up in the boot menu for a BBS-compliant BIOS.
2008-05-21 19:43:58 +02:00
xorw %di, %di
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
call print_message
[romprefix] Add more diagnostic messages to ROM prefix Include PMM allocation result in POST banner. Include full product string in "starting execution" message. Also mark ourselves as supporting DDIM in PnP header, for completeness.
2008-08-26 00:36:24 +02:00
movw $exec_message, %si
call print_message
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* Store magic word on BIOS stack and remember BIOS %ss:sp */
pushl $STACK_MAGIC
movw %ss, %dx
movw %sp, %bp
/* Obtain a reasonably-sized temporary stack */
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
xorw %ax, %ax
movw %ax, %ss
movw $0x7c00, %sp
Initial revision
2005-03-08 19:53:11 +01:00
[build] Rename gPXE to iPXE 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>
2010-04-19 21:16:01 +02:00
/* Install iPXE */
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
movl image_source, %esi
movl decompress_to, %edi
call alloc_basemem
call install_prealloc
Initial revision
2005-03-08 19:53:11 +01:00
Use internal real-mode stack from non-returnable prefixes
2007-06-28 22:56:14 +02:00
/* Set up real-mode stack */
movw %bx, %ss
movw $_estack16, %sp
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
/* Jump to .text16 segment */
Initial revision
2005-03-08 19:53:11 +01:00
pushw %ax
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
pushw $1f
lret
.section ".text16", "awx", @progbits
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
1: /* Call main() */
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
pushl $main
Initial revision
2005-03-08 19:53:11 +01:00
pushw %cs
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
call prot_call
[i386] Free allocated base memory on exit, if possible Code paths that automatically allocate memory from the FBMS at 40:13 should also free it, if possible. Freeing this memory will not be possible if either 1. The FBMS has been modified since our allocation, or 2. We have not been able to unhook one or more BIOS interrupt vectors.
2008-11-18 20:43:13 +01:00
popl %ecx /* discard */
[build] Rename gPXE to iPXE 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>
2010-04-19 21:16:01 +02:00
/* Uninstall iPXE */
[i386] Free allocated base memory on exit, if possible Code paths that automatically allocate memory from the FBMS at 40:13 should also free it, if possible. Freeing this memory will not be possible if either 1. The FBMS has been modified since our allocation, or 2. We have not been able to unhook one or more BIOS interrupt vectors.
2008-11-18 20:43:13 +01:00
call uninstall
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* Restore BIOS stack */
movw %dx, %ss
movw %bp, %sp
Initial revision
2005-03-08 19:53:11 +01:00
[PXE] Add PMM support to romprefix.S (untested) ROM initialisation vector now attempts to allocate a 2MB block using PMM. If successful, it copies the ROM image to this block, then shrinks the ROM image to allow for more option ROMs. If unsuccessful, it leaves the ROM as-is. ROM BEV now attempts to return to the BIOS, resorting to INT 18 only if the BIOS stack has been corrupted.
2008-03-09 23:13:07 +01:00
/* Check magic word on BIOS stack */
popl %eax
cmpl $STACK_MAGIC, %eax
jne 1f
/* BIOS stack OK: return to caller */
lret
1: /* BIOS stack corrupt: use INT 18 */
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
int $0x18
Initial revision
2005-03-08 19:53:11 +01:00
.previous
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
exec_message:
[romprefix] Add more diagnostic messages to ROM prefix Include PMM allocation result in POST banner. Include full product string in "starting execution" message. Also mark ourselves as supporting DDIM in PnP header, for completeness.
2008-08-26 00:36:24 +02:00
.asciz " starting execution\n"
Cut out almost all the optional code paths, drastically simplifying the flow of control through this code. We now always add PCI and PnP headers even for ISA ROMs; there's no harm in doing so. UNDI loader is still missing.
2006-06-06 17:33:39 +02:00
.size exec_message, . - exec_message
Initial revision
2005-03-08 19:53:11 +01:00
[romprefix] If we hook INT 19, prompt before attempting boot On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial.
2008-09-24 01:53:40 +02:00
/* Wait for key press specified by %bl (masked by %bh)
*
* Used by init and INT19 code when prompting user. If the specified
* key is pressed, it is left in the keyboard buffer.
*
* Returns with ZF set iff specified key is pressed.
*/
wait_for_key:
/* Preserve registers */
pushw %cx
pushw %ax
1: /* Empty the keyboard buffer before waiting for input */
movb $0x01, %ah
int $0x16
jz 2f
xorw %ax, %ax
int $0x16
jmp 1b
[romprefix] Allow BANNER_TIMEOUT to control banners in romprefix.S In particular, allow BANNER_TIMEOUT=0 to inhibit the prompt banners altogether. Ironically, this request comes from the same OEM that originally required the prompts to be present during POST.
2008-09-25 02:53:42 +02:00
2: /* Wait for a key press */
movw $ROM_BANNER_TIMEOUT, %cx
[romprefix] If we hook INT 19, prompt before attempting boot On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial.
2008-09-24 01:53:40 +02:00
3: decw %cx
js 99f /* Exit with ZF clear */
/* Wait for timer tick to be updated */
call wait_for_tick
/* Check to see if a key was pressed */
movb $0x01, %ah
int $0x16
jz 3b
/* Check to see if key was the specified key */
andb %bh, %al
cmpb %al, %bl
je 99f /* Exit with ZF set */
/* Not the specified key: remove from buffer and stop waiting */
pushfw
xorw %ax, %ax
int $0x16
popfw /* Exit with ZF clear */
99: /* Restore registers and return */
popw %ax
popw %cx
ret
.size wait_for_key, . - wait_for_key
/* Wait for timer tick
*
* Used by wait_for_key
*/
wait_for_tick:
pushl %eax
pushw %fs
movw $0x40, %ax
movw %ax, %fs
movl %fs:(0x6c), %eax
1: pushf
sti
hlt
popf
cmpl %fs:(0x6c), %eax
je 1b
popw %fs
popl %eax
ret
.size wait_for_tick, . - wait_for_tick