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/x86/prefix/romprefix.S

912 lines
21 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] Relicense files under GPL2_OR_LATER_OR_UBDL These files cannot be automatically relicensed by util/relicense.pl since they either contain unusual but trivial contributions (such as the addition of __nonnull function attributes), or contain lines dating back to the initial git revision (and so require manual knowledge of the code's origin). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-03-02 14:29:46 +01:00
FILE_LICENCE ( GPL2_OR_LATER_OR_UBDL )
[legal] Add FILE_LICENCE declaration to romprefix.S
2009-05-18 10:33:36 +02:00
[librm] Provide an abstraction wrapper for prot_call Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-02-19 00:23:38 +01:00
#include <librm.h>
[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>
[build] Move branding information to config/branding.h Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-02-11 13:51:58 +01:00
#include <config/branding.h>
[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
[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 ) )
[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] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
#define PMM_FIND 0x0001
#define PMM_HANDLE_BASE ( ( ( 'F' - 'A' + 1 ) << 26 ) + \
( ( 'E' - 'A' + 1 ) << 21 ) + \
( ( 'N' - 'A' + 1 ) << 16 ) )
#define PMM_HANDLE_BASE_IMAGE_SOURCE \
( PMM_HANDLE_BASE | 0x00001000 )
#define PMM_HANDLE_BASE_DECOMPRESS_TO \
( PMM_HANDLE_BASE | 0x00002000 )
[romprefix] Display only one "Ctrl-B" prompt per PCI device during POST If a multifunction PCI device exposes an iPXE ROM via each function, then each function will display a "Press Ctrl-B to configure iPXE" prompt, and delay for two seconds. Since a single instance of iPXE can drive all functions on the multifunction device, this simply adds unnecessary delay to the boot process. Fix by inhibiting the "Press Ctrl-B" prompt for all except the first function on a PCI device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-03-11 02:43:12 +01:00
#define PCI_FUNC_MASK 0x07
[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 ROM banner timeout to be configured independently iPXE currently prints a "Press Ctrl-B" banner twice: once when the ROM is first called for initialisation and again if we attempt to boot from the ROM. This slows boot, especially when the NIC is not the primary boot device. Tools such as libguestfs make use of QEMU VMs for performing maintenance on disk images and may make use of NICs in the VM for network support. If iPXE introduces a static init-time delay, that directly translates to increased runtime for the tools. Fix by allowing the ROM banner timeout to be configured independently of the main banner timeout. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-02-26 00:33:08 +01:00
/* ROM banner timeout, converted to a number of (18Hz) timer ticks. */
#define ROM_BANNER_TIMEOUT_TICKS ( ( 18 * ROM_BANNER_TIMEOUT ) / 10 )
[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
[romprefix] Add .mrom format, allowing loading of large ROMs Add an infrastructure allowing the prefix to provide an open_payload() method for obtaining out-of-band access to the whole iPXE image. Add a mechanism within this infrastructure that allows raw access to the expansion ROM BAR by temporarily borrowing an address from a suitable memory BAR on the same PCI card. For cards that have a memory BAR that is at least as large as their expansion ROM BAR, this allows large iPXE ROMs to be supported even on systems where PMM fails, or where option ROM space pressure makes it impossible to use PMM shrinking. The BIOS sees only a stub ROM of approximately 3kB in size; the remainder (which can be well over 64kB) is loaded only at the time iPXE is invoked. As a nice side-effect, an iPXE .mrom image will continue to work even if its PMM-allocated areas are overwritten between initialisation and invocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-25 16:57:00 +02:00
/* Allow payload to be excluded from ROM size
*/
#if ROMPREFIX_EXCLUDE_PAYLOAD
#define ZINFO_TYPE_ADxB "ADHB"
#define ZINFO_TYPE_ADxW "ADHW"
#else
#define ZINFO_TYPE_ADxB "ADDB"
#define ZINFO_TYPE_ADxW "ADDW"
[romprefix] Add a dummy ROM header to cover the .mrom payload The header of a .mrom image declares its length to be only a few kilobytes; the remainder is accessed via a sideband mechanism. This makes it difficult to append an additional ROM image, such as an EFI ROM. Add a second, dummy ROM header covering the payload portion of the .mrom image, allowing consumers to locate any appended ROM images in the usual way. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-06-10 19:25:26 +02:00
#endif
/* Allow ROM to be marked as containing multiple images
*/
#if ROMPREFIX_MORE_IMAGES
#define INDICATOR 0x00
#else
#define INDICATOR 0x80
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
#endif
/* Default to building a PCI ROM if no bus type is specified
*/
#ifndef BUSTYPE
#define BUSTYPE "PCIR"
[romprefix] Add .mrom format, allowing loading of large ROMs Add an infrastructure allowing the prefix to provide an open_payload() method for obtaining out-of-band access to the whole iPXE image. Add a mechanism within this infrastructure that allows raw access to the expansion ROM BAR by temporarily borrowing an address from a suitable memory BAR on the same PCI card. For cards that have a memory BAR that is at least as large as their expansion ROM BAR, this allows large iPXE ROMs to be supported even on systems where PMM fails, or where option ROM space pressure makes it impossible to use PMM shrinking. The BIOS sees only a stub ROM of approximately 3kB in size; the remainder (which can be well over 64kB) is loaded only at the time iPXE is invoked. As a nice side-effect, an iPXE .mrom image will continue to work even if its PMM-allocated areas are overwritten between initialisation and invocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-25 16:57:00 +02:00
#endif
Initial revision
2005-03-08 19:53:11 +01:00
.text
.code16
.arch i386
.section ".prefix", "ax", @progbits
[build] Use unique entry symbols for each prefix Some binutils versions will drag in an object to satisfy the entry symbol; some won't. Try to cope with this exciting variety of behaviour by ensuring that all entry symbols are unique. Remove the explicit inclusion of the prefix object on the linker command line, since the entry symbol now provides all the information needed to identify the prefix. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-02-23 22:12:56 +01:00
.globl _rom_start
_rom_start:
Initial revision
2005-03-08 19:53:11 +01: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
.org 0x00
romheader:
.word 0xAA55 /* BIOS extension signature */
[romprefix] Remove .xrom prefix The .xrom prefix provides an experimental mechanism for loading ROM images greater than 64kB in size by mapping the expansion ROM BAR in at a hopefully-unused address. This is unreliable, and potentially dangerous. In particular, there is no guarantee that any PCI bridges between the CPU and the device will respond to accesses for the "unused" memory region that is chosen, and it is possible that the process of scanning for the "unused" memory region may end up issuing reads to other PCI devices. If this ends up trampling on a register with read side-effects belonging to an unrelated PCI device, this may cause undefined behaviour. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-19 21:32:25 +02:00
romheader_size: .byte 0 /* 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:
[romprefix] Remove .xrom prefix The .xrom prefix provides an experimental mechanism for loading ROM images greater than 64kB in size by mapping the expansion ROM BAR in at a hopefully-unused address. This is unreliable, and potentially dangerous. In particular, there is no guarantee that any PCI bridges between the CPU and the device will respond to accesses for the "unused" memory region that is chosen, and it is possible that the process of scanning for the "unused" memory region may end up issuing reads to other PCI devices. If this ends up trampling on a register with read side-effects belonging to an unrelated PCI device, this may cause undefined behaviour. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-19 21:32:25 +02:00
.byte 0
[romprefix] Report a pessimistic runtime size estimate PCI3.0 allows us to report a "runtime size" which can be smaller than the actual ROM size. On systems that support PMM our runtime size will be small (~2.5kB), which helps to conserve the limited option ROM space. However, there is no guarantee that the PMM allocation will succeed, and so we need to report the worst-case runtime size in the PCI header. Move the "shrunk ROM size" field from the PCI header to a new "iPXE ROM header", allowing it to be accessed by ROM-manipulation utilities such as disrom.pl. Reported-by: Anton D. Kachalov <mouse@yandex-team.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-07-23 18:41:38 +02:00
.org 0x10
.word ipxeheader
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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.ifeqs BUSTYPE, "PCIR"
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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +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
.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 */
[romprefix] Add .mrom format, allowing loading of large ROMs Add an infrastructure allowing the prefix to provide an open_payload() method for obtaining out-of-band access to the whole iPXE image. Add a mechanism within this infrastructure that allows raw access to the expansion ROM BAR by temporarily borrowing an address from a suitable memory BAR on the same PCI card. For cards that have a memory BAR that is at least as large as their expansion ROM BAR, this allows large iPXE ROMs to be supported even on systems where PMM fails, or where option ROM space pressure makes it impossible to use PMM shrinking. The BIOS sees only a stub ROM of approximately 3kB in size; the remainder (which can be well over 64kB) is loaded only at the time iPXE is invoked. As a nice side-effect, an iPXE .mrom image will continue to work even if its PMM-allocated areas are overwritten between initialisation and invocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-25 16:57:00 +02:00
.ascii ZINFO_TYPE_ADxB
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
.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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.ifeqs BUSTYPE, "PCIR"
[romprefix] Avoid unaligned accesses within ROM headers Ensure that all headers (PCI, UNDI, PnP, iPXE) are aligned to at least four bytes, so that all accesses to header fields will be correctly aligned even when reading directly from the expansion ROM BAR. Reported-by: Peter von Konigsmark <peter@exablaze.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2017-08-30 11:15:25 +02:00
.align 4
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 */
[build] Allow building PCI ROMs with device ID lists PCI v3.0 supports a "device list" which allows the ROM to claim support for multiple PCI device IDs (but only a single vendor ID). Add support for building such ROMs by scanning the build target element list and incorporating any device IDs into the ROM's device list header. For example: make bin/8086153a--8086153b.mrom would build a ROM claiming support for both 8086:153a and 8086:153b. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-04-14 10:59:59 +02:00
.word ( pci_devlist - pciheader ) /* 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:
[romprefix] Remove .xrom prefix The .xrom prefix provides an experimental mechanism for loading ROM images greater than 64kB in size by mapping the expansion ROM BAR in at a hopefully-unused address. This is unreliable, and potentially dangerous. In particular, there is no guarantee that any PCI bridges between the CPU and the device will respond to accesses for the "unused" memory region that is chosen, and it is possible that the process of scanning for the "unused" memory region may end up issuing reads to other PCI devices. If this ends up trampling on a register with read side-effects belonging to an unrelated PCI device, this may cause undefined behaviour. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-19 21:32:25 +02:00
.word 0 /* 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 */
[romprefix] Add a dummy ROM header to cover the .mrom payload The header of a .mrom image declares its length to be only a few kilobytes; the remainder is accessed via a sideband mechanism. This makes it difficult to append an additional ROM image, such as an EFI ROM. Add a second, dummy ROM header covering the payload portion of the .mrom image, allowing consumers to locate any appended ROM images in the usual way. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-06-10 19:25:26 +02:00
.byte INDICATOR /* Last image indicator */
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
pciheader_runtime_length:
[romprefix] Remove .xrom prefix The .xrom prefix provides an experimental mechanism for loading ROM images greater than 64kB in size by mapping the expansion ROM BAR in at a hopefully-unused address. This is unreliable, and potentially dangerous. In particular, there is no guarantee that any PCI bridges between the CPU and the device will respond to accesses for the "unused" memory region that is chosen, and it is possible that the process of scanning for the "unused" memory region may end up issuing reads to other PCI devices. If this ends up trampling on a register with read side-effects belonging to an unrelated PCI device, this may cause undefined behaviour. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-19 21:32:25 +02:00
.word 0 /* 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
[build] Allow building PCI ROMs with device ID lists PCI v3.0 supports a "device list" which allows the ROM to claim support for multiple PCI device IDs (but only a single vendor ID). Add support for building such ROMs by scanning the build target element list and incorporating any device IDs into the ROM's device list header. For example: make bin/8086153a--8086153b.mrom would build a ROM claiming support for both 8086:153a and 8086:153b. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-04-14 10:59:59 +02:00
/* PCI additional device list (filled in by linker) */
.section ".pci_devlist.00000000", "a", @progbits
pci_devlist:
.previous
.section ".pci_devlist.ffffffff", "a", @progbits
pci_devlist_end:
.short 0x0000 /* List terminator */
.previous
/* Ensure that terminator is always present */
.reloc pciheader, RELOC_TYPE_NONE, pci_devlist_end
[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 */
[romprefix] Add .mrom format, allowing loading of large ROMs Add an infrastructure allowing the prefix to provide an open_payload() method for obtaining out-of-band access to the whole iPXE image. Add a mechanism within this infrastructure that allows raw access to the expansion ROM BAR by temporarily borrowing an address from a suitable memory BAR on the same PCI card. For cards that have a memory BAR that is at least as large as their expansion ROM BAR, this allows large iPXE ROMs to be supported even on systems where PMM fails, or where option ROM space pressure makes it impossible to use PMM shrinking. The BIOS sees only a stub ROM of approximately 3kB in size; the remainder (which can be well over 64kB) is loaded only at the time iPXE is invoked. As a nice side-effect, an iPXE .mrom image will continue to work even if its PMM-allocated areas are overwritten between initialisation and invocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-25 16:57:00 +02:00
.ascii ZINFO_TYPE_ADxW
[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
[romprefix] Report an optimistic runtime size estimate Commit 5de45cd ("[romprefix] Report a pessimistic runtime size estimate") set the PCI3.0 "runtime size" field equal to the worst-case runtime size, on the basis that there is no guarantee that PMM allocation will succeed and hence no guarantee that we will be able to shrink the ROM image. On a PCI3.0 system where PMM allocation would succeed, this can cause the BIOS to unnecessarily refuse to initialise the iPXE ROM due to a perceived shortage of option ROM space. Fix by reporting the best-case runtime size via the PCI header, and checking that we have sufficient runtime space (if applicable). This allows iPXE ROMs to initialise on PCI3.0 systems that might otherwise fail due to a shortage of option ROM space. This may cause iPXE ROMs to fail to initialise on PCI3.0 systems where PMM is broken. (Pre-PCI3.0 systems are unaffected since there must already have been sufficient option ROM space available for the initialisation entry point to be called.) On balance, it seems preferable to avoid breaking "good" systems (PCI3.0 with working PMM) at the cost of potentially breaking "bad" systems (PCI3.0 with broken PMM). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-01-06 00:40:18 +01:00
.ascii "ADHW"
[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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.endif /* PCIR */
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
[romprefix] Force PnP header to a 16-byte boundary for IBM BIOSes IBM BIOSes ignore the PnP header offset stored at address 0x1a and instead scan for the $PnP signature on a 16-byte boundary. (This alignment is not mandated by the PnP specification.) Force PnP header to a 16-byte boundary to work around these BIOSes. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-05-17 23:48:52 +02:00
/* PnP doesn't require any particular alignment, but IBM
* BIOSes will scan on 16-byte boundaries rather than using
* the offset stored at 0x1a
*/
.align 16
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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.ifeqs BUSTYPE, "PCIR"
[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:
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.ascii "xx:xx.x)" /* Filled in by init code */
.endif /* PCIR */
.byte 0
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
[romprefix] Avoid unaligned accesses within ROM headers Ensure that all headers (PCI, UNDI, PnP, iPXE) are aligned to at least four bytes, so that all accesses to header fields will be correctly aligned even when reading directly from the expansion ROM BAR. Reported-by: Peter von Konigsmark <peter@exablaze.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2017-08-30 11:15:25 +02:00
.align 4
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 */
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.ascii BUSTYPE /* 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
[romprefix] Avoid unaligned accesses within ROM headers Ensure that all headers (PCI, UNDI, PnP, iPXE) are aligned to at least four bytes, so that all accesses to header fields will be correctly aligned even when reading directly from the expansion ROM BAR. Reported-by: Peter von Konigsmark <peter@exablaze.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2017-08-30 11:15:25 +02:00
.align 4
[romprefix] Report a pessimistic runtime size estimate PCI3.0 allows us to report a "runtime size" which can be smaller than the actual ROM size. On systems that support PMM our runtime size will be small (~2.5kB), which helps to conserve the limited option ROM space. However, there is no guarantee that the PMM allocation will succeed, and so we need to report the worst-case runtime size in the PCI header. Move the "shrunk ROM size" field from the PCI header to a new "iPXE ROM header", allowing it to be accessed by ROM-manipulation utilities such as disrom.pl. Reported-by: Anton D. Kachalov <mouse@yandex-team.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-07-23 18:41:38 +02:00
ipxeheader:
.ascii "iPXE" /* Signature */
.byte ipxeheader_len /* Length of structure */
.byte 0 /* Checksum */
shrunk_rom_size:
.byte 0 /* Shrunk size (in 512-byte blocks) */
.byte 0 /* Reserved */
build_id:
.long _build_id /* Randomly-generated build ID */
.equ ipxeheader_len, . - ipxeheader
.size ipxeheader, . - ipxeheader
.section ".zinfo.fixup", "a", @progbits /* Compressor fixups */
.ascii "ADHB"
.long shrunk_rom_size
.long 512
.long 0
.previous
[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
[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
[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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
/* Store PCI 3.0 runtime segment address for later use, if
* applicable.
*/
.ifeqs BUSTYPE, "PCIR"
movw %bx, %gs
.endif
/* Store PCI bus:dev.fn address, print PCI bus:dev.fn, and add
* PCI bus:dev.fn to product name string, if applicable.
*/
.ifeqs BUSTYPE, "PCIR"
xorw %di, %di
call print_space
movw %ax, init_pci_busdevfn
call print_pci_busdevfn
[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 $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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.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
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
/* Print segment address */
[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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
call print_space
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
/* Check for PCI BIOS version, if applicable */
.ifeqs BUSTYPE, "PCIR"
[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
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
[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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.endif /* PCIR */
[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] Remove special treatment for IBM BIOSes Revert commit 38cd351 ("[romprefix] Attempt to gracefully handle semi-PnP IBM BIOSes"), since the test for the "IBM " signature in %edi is not sufficient to identify an IBM BIOS. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-05-17 16:27:47 +02:00
/* Check for PnP BIOS. Although %es:di should point to the
[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
* 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
[romprefix] Do not check for BBS compatibility The existence and usage of the BEV entry point is covered by the PnP spec, not the BBS spec; the BBS spec merely describes a policy for selecting the boot device order. iPXE should therefore check only for a PnP BIOS in order to decide whether or not to hook INT19. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-06-24 20:03:04 +02:00
jmp pnp_done
no_pnp: /* Not PnP-compliant - hook INT 19 */
[romprefix] Do not fall back to hooking INT19 by default Several BIOSes (including most IBM BIOSes and many virtual machine BIOSes) do not provide detectable PnP support, but will use the BEV entry point for a PnP option ROM. On these semi-PnP BIOSes, iPXE will respond to the absence of detectable PnP support by hooking INT19, which disrupts the boot order. BIOSes that genuinely require hooking INT19 seem to be very rare nowadays. It may therefore be preferable to assume that the absence of detectable PnP support indicates a semi-PnP BIOS rather than a non-PnP BIOS. Change the default behaviour so that INT19 will never be hooked unless the compile-time option NONPNP_HOOK_INT19 is enabled. Leave the redundant PnP detection routine in-place to allow for debugging via the ROM banner line. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-05-17 16:35:23 +02:00
#ifdef NONPNP_HOOK_INT19
[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] Do not fall back to hooking INT19 by default Several BIOSes (including most IBM BIOSes and many virtual machine BIOSes) do not provide detectable PnP support, but will use the BEV entry point for a PnP option ROM. On these semi-PnP BIOSes, iPXE will respond to the absence of detectable PnP support by hooking INT19, which disrupts the boot order. BIOSes that genuinely require hooking INT19 seem to be very rare nowadays. It may therefore be preferable to assume that the absence of detectable PnP support indicates a semi-PnP BIOS rather than a non-PnP BIOS. Change the default behaviour so that INT19 will never be hooked unless the compile-time option NONPNP_HOOK_INT19 is enabled. Leave the redundant PnP detection routine in-place to allow for debugging via the ROM banner line. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-05-17 16:35:23 +02:00
#endif /* NONPNP_HOOK_INT19 */
[romprefix] Do not check for BBS compatibility The existence and usage of the BEV entry point is covered by the PnP spec, not the BBS spec; the BBS spec merely describes a policy for selecting the boot device order. iPXE should therefore check only for a PnP BIOS in order to decide whether or not to hook INT19. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-06-24 20:03:04 +02:00
pnp_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] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
/* We have PMM and so a 1kB stack: preserve whole registers */
[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
pushal
[romprefix] Round up PMM allocation sizes to nearest 4kB Some AMI BIOSes apparently break in exciting ways when asked for PMM allocations for sizes that are not multiples of 4kB. Fix by rounding up the image source area to the nearest 4kB. (The temporary decompression area is already rounded up to the nearest 128kB, to facilitate sharing between multiple iPXE ROMs.) Reported-by: Itay Gazit <itayg@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-07-25 15:32:37 +02:00
/* Allocate image source PMM block. Round up the size to the
* nearest 4kB (8 512-byte sectors) to work around AMI BIOS bugs.
*/
[romprefix] Add a dummy ROM header to cover the .mrom payload The header of a .mrom image declares its length to be only a few kilobytes; the remainder is accessed via a sideband mechanism. This makes it difficult to append an additional ROM image, such as an EFI ROM. Add a second, dummy ROM header covering the payload portion of the .mrom image, allowing consumers to locate any appended ROM images in the usual way. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-06-10 19:25:26 +02:00
movzbl romheader_size, %ecx
addw extra_size, %cx
[romprefix] Round up PMM allocation sizes to nearest 4kB Some AMI BIOSes apparently break in exciting ways when asked for PMM allocations for sizes that are not multiples of 4kB. Fix by rounding up the image source area to the nearest 4kB. (The temporary decompression area is already rounded up to the nearest 128kB, to facilitate sharing between multiple iPXE ROMs.) Reported-by: Itay Gazit <itayg@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-07-25 15:32:37 +02:00
addw $0x0007, %cx /* Round up to multiple of 8 512-byte sectors */
andw $0xfff8, %cx
[romprefix] Use correct size for PMM allocation of image source block iPXE allocates its first PMM block using the image source length, which is rounded up to the nearest 16-byte paragraph. It then copies in data of a length calculated from the ROM size, which is theoretically less than or equal to the image source length, but is rounded up to the nearest 512-byte sector. This can result in copying beyond the end of the allocated PMM block, which can corrupt the PMM data structures (and other essentially arbitrary areas of memory). Fix by rounding up the image source length to the nearest 512-byte sector before using it as the PMM allocation length. Reported-by: Alex Williamson <alex.williamson@redhat.com> Reported-by: Jarrod Johnson <jarrod.b.johnson@gmail.com> Reported-by: Itay Gazit <itayg@mellanox.co.il> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-03-15 02:52:58 +01:00
shll $5, %ecx
[romprefix] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
movl $PMM_HANDLE_BASE_IMAGE_SOURCE, %ebx
movw $get_pmm_image_source, %bp
call get_pmm
movl %esi, image_source
[romprefix] Treat 0xffffffff as an error return from PMM PMM defines the return code 0xffffffff as meaning "unsupported function". It's hard to imagine a PMM BIOS that doesn't support pmmAllocate(), but apparently such things do exist. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-06-19 19:54:22 +02:00
jz 1f
[romprefix] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
/* Copy ROM to image source PMM block */
pushw %es
[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
[romprefix] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
movl %esi, %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
[romprefix] Add a dummy ROM header to cover the .mrom payload The header of a .mrom image declares its length to be only a few kilobytes; the remainder is accessed via a sideband mechanism. This makes it difficult to append an additional ROM image, such as an EFI ROM. Add a second, dummy ROM header covering the payload portion of the .mrom image, allowing consumers to locate any appended ROM images in the usual way. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-06-10 19:25:26 +02:00
shll $7, %ecx
addr32 rep movsl /* PMM presence implies flat real mode */
[romprefix] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
popw %es
[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 */
[romprefix] Report a pessimistic runtime size estimate PCI3.0 allows us to report a "runtime size" which can be smaller than the actual ROM size. On systems that support PMM our runtime size will be small (~2.5kB), which helps to conserve the limited option ROM space. However, there is no guarantee that the PMM allocation will succeed, and so we need to report the worst-case runtime size in the PCI header. Move the "shrunk ROM size" field from the PCI header to a new "iPXE ROM header", allowing it to be accessed by ROM-manipulation utilities such as disrom.pl. Reported-by: Anton D. Kachalov <mouse@yandex-team.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-07-23 18:41:38 +02:00
movb shrunk_rom_size, %al
[prefix] Add .text16.early section Add a section .text16.early which is always kept inline with the prefix. This will allow for some code sharing between the .prefix and .text16 sections. Note that the simple solution of just prepending the .prefix section to the .text16 section will not work, because a bug in Wyse Streaming Manager server (WLDRM13.BIN) requires us to place a dummy PXENV+ entry point at the start of .text16. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-20 12:05:53 +02:00
movb %al, romheader_size
[romprefix] Align PMM temporary decompression area to a page boundary Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-02-18 03:58:03 +01:00
1: /* Allocate decompression PMM block. Allow 4kB for page
* alignment and round up the size to the nearest 128kB, then
* use the size within the PMM handle; this allows the same
* decompression area to be shared between multiple iPXE ROMs
* even with differing build IDs
[romprefix] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
*/
movl $_textdata_memsz_pgh, %ecx
[romprefix] Align PMM temporary decompression area to a page boundary Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-02-18 03:58:03 +01:00
addl $( 0x00000100 /* 4kB */ + 0x00001fff /* 128kB - 1 */ ), %ecx
andl $( 0xffffe000 /* ~( 128kB - 1 ) */ ), %ecx
[romprefix] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
movl %ecx, %ebx
shrw $12, %bx
orl $PMM_HANDLE_BASE_DECOMPRESS_TO, %ebx
movw $get_pmm_decompress_to, %bp
call get_pmm
[romprefix] Align PMM temporary decompression area to a page boundary Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-02-18 03:58:03 +01:00
addl $( 0x00000fff /* 4kB - 1 */ ), %esi
andl $( 0xfffff000 /* ~( 4kB - 1 ) */ ), %esi
[romprefix] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
movl %esi, decompress_to
/* Restore registers */
[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
popal
no_pmm:
/* 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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
/* Copy self to option ROM space, if applicable. Required for
* PCI3.0, which loads us to a temporary location in low
* memory. Will be a no-op for lower PCI versions.
[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
*/
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.ifeqs BUSTYPE, "PCIR"
[romprefix] Report an optimistic runtime size estimate Commit 5de45cd ("[romprefix] Report a pessimistic runtime size estimate") set the PCI3.0 "runtime size" field equal to the worst-case runtime size, on the basis that there is no guarantee that PMM allocation will succeed and hence no guarantee that we will be able to shrink the ROM image. On a PCI3.0 system where PMM allocation would succeed, this can cause the BIOS to unnecessarily refuse to initialise the iPXE ROM due to a perceived shortage of option ROM space. Fix by reporting the best-case runtime size via the PCI header, and checking that we have sufficient runtime space (if applicable). This allows iPXE ROMs to initialise on PCI3.0 systems that might otherwise fail due to a shortage of option ROM space. This may cause iPXE ROMs to fail to initialise on PCI3.0 systems where PMM is broken. (Pre-PCI3.0 systems are unaffected since there must already have been sufficient option ROM space available for the initialisation entry point to be called.) On balance, it seems preferable to avoid breaking "good" systems (PCI3.0 with working PMM) at the cost of potentially breaking "bad" systems (PCI3.0 with broken PMM). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-01-06 00:40:18 +01:00
/* Get runtime segment address and length */
movw %gs, %ax
movw %ax, %es
movzbw romheader_size, %cx
/* Print runtime segment address */
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
xorw %di, %di
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
call print_space
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
call print_hex_word
[romprefix] Report an optimistic runtime size estimate Commit 5de45cd ("[romprefix] Report a pessimistic runtime size estimate") set the PCI3.0 "runtime size" field equal to the worst-case runtime size, on the basis that there is no guarantee that PMM allocation will succeed and hence no guarantee that we will be able to shrink the ROM image. On a PCI3.0 system where PMM allocation would succeed, this can cause the BIOS to unnecessarily refuse to initialise the iPXE ROM due to a perceived shortage of option ROM space. Fix by reporting the best-case runtime size via the PCI header, and checking that we have sufficient runtime space (if applicable). This allows iPXE ROMs to initialise on PCI3.0 systems that might otherwise fail due to a shortage of option ROM space. This may cause iPXE ROMs to fail to initialise on PCI3.0 systems where PMM is broken. (Pre-PCI3.0 systems are unaffected since there must already have been sufficient option ROM space available for the initialisation entry point to be called.) On balance, it seems preferable to avoid breaking "good" systems (PCI3.0 with working PMM) at the cost of potentially breaking "bad" systems (PCI3.0 with broken PMM). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-01-06 00:40:18 +01:00
/* Fail if we have insufficient space in final location */
movw %cs, %si
cmpw %si, %ax
je 1f
cmpw pciheader_runtime_length, %cx
jbe 1f
movb $( '!' ), %al
call print_character
xorw %cx, %cx
1: /* Copy to final location */
[romprefix] Update PCI ROM structure to PCI 3.0
2008-07-30 20:57:46 +02:00
shlw $9, %cx
[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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
/* Skip prompt if this is not the first PCI function, if applicable */
.ifeqs BUSTYPE, "PCIR"
[romprefix] Display only one "Ctrl-B" prompt per PCI device during POST If a multifunction PCI device exposes an iPXE ROM via each function, then each function will display a "Press Ctrl-B to configure iPXE" prompt, and delay for two seconds. Since a single instance of iPXE can drive all functions on the multifunction device, this simply adds unnecessary delay to the boot process. Fix by inhibiting the "Press Ctrl-B" prompt for all except the first function on a PCI device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-03-11 02:43:12 +01:00
testb $PCI_FUNC_MASK, init_pci_busdevfn
jnz no_shell
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.endif
[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
[romprefix] Display only one "Ctrl-B" prompt per PCI device during POST If a multifunction PCI device exposes an iPXE ROM via each function, then each function will display a "Press Ctrl-B to configure iPXE" prompt, and delay for two seconds. Since a single instance of iPXE can drive all functions on the multifunction device, this simply adds unnecessary delay to the boot process. Fix by inhibiting the "Press Ctrl-B" prompt for all except the first function on a PCI device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-03-11 02:43:12 +01:00
jnz no_shell
[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
*/
[pcbios] Inhibit all calls to INT 15,e820 and INT 15,e801 during POST Many BIOSes do not construct the full system memory map until after calling the option ROM initialisation entry points. For several years, we have added sanity checks and workarounds to accommodate charming quirks such as BIOSes which report the entire 32-bit address space (including all memory-mapped PCI BARs) as being usable RAM. The IBM x3650 takes quirky behaviour to a new extreme. Calling either INT 15,e820 or INT 15,e801 during POST doesn't just get you invalid data. We could cope with invalid data. Instead, these nominally read-only API calls manage to trash some internal BIOS state, with the result that the system memory map is _never_ constructed. This tends to confuse subsequent bootloaders and operating systems. [ GRUB 0.97 fails in a particularly amusing way. Someone thought it would be a good idea for memcpy() to check that the destination memory region is a valid part of the system memory map; if not, then memcpy() will sulk, fail, and return NULL. This breaks pretty much every use of memcpy() including, for example, those inserted implicitly by gcc to copy non-const initialisers. Debugging is _fun_ when a simple call to printf() manages to create an infinite recursion, exhaust the available stack space, and shut down the CPU. ] Fix by completely inhibiting calls to INT 15,e820 and INT 15,e801 during POST. We do now allow relocation during POST up to the maximum address returned by INT 15,88 (which seems so far to always be safe). This allows us to continue to have a reasonable size of external heap, even if the PMM allocation is close to the 1MB mark. The downside of allowing relocation during POST is that we may overwrite PMM-allocated memory in use by other option ROMs. However, the downside of inhibiting relocation, when combined with also inhibiting calls to INT 15,e820 and INT 15,e801, would be that we might have no external heap available: this would make booting an OS impossible and could prevent some devices from even completing initialisation. On balance, the lesser evil is probably to allow relocation during POST (up to the limit provided by INT 15,88). Entering iPXE during POST is a rare operation; on the even rarer systems where doing so happens to overwrite a PMM-allocated region, then there exists a fairly simple workaround: if the user enters iPXE during POST and wishes to exit iPXE, then the user must reboot. This is an acceptable cost, given the rarity of the situation and the simplicity of the workaround. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-03-11 01:50:52 +01:00
xorl %ebp, %ebp /* Inhibit use of INT 15,e820 and INT 15,e801 */
[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
[romprefix] Display only one "Ctrl-B" prompt per PCI device during POST If a multifunction PCI device exposes an iPXE ROM via each function, then each function will display a "Press Ctrl-B to configure iPXE" prompt, and delay for two seconds. Since a single instance of iPXE can drive all functions on the multifunction device, this simply adds unnecessary delay to the boot process. Fix by inhibiting the "Press Ctrl-B" prompt for all except the first function on a PCI device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-03-11 02:43:12 +01:00
no_shell:
movb $( '\n' ), %al
xorw %di, %di
call print_character
[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] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
/* Attempt to find or allocate PMM block
*
* Parameters:
* %ecx : size of block to allocate, in paragraphs
* %ebx : PMM handle base
* %bp : routine to check acceptability of found blocks
* %es:0000 : PMM structure
* Returns:
* %ebx : PMM handle
[romprefix] Treat 0xffffffff as an error return from PMM PMM defines the return code 0xffffffff as meaning "unsupported function". It's hard to imagine a PMM BIOS that doesn't support pmmAllocate(), but apparently such things do exist. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-06-19 19:54:22 +02:00
* %esi : allocated block address, or zero (with ZF set) if allocation failed
[romprefix] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
*/
get_pmm:
/* Preserve registers */
pushl %eax
pushw %di
[romprefix] Fix romprefix build with certain versions of binutils Signed-off-by: Valentine Barshak <gvaxon@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-08-06 21:40:04 +02:00
movw $( ' ' ), %di
[romprefix] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
get_pmm_find:
/* Try to find existing block */
pushl %ebx /* PMM handle */
pushw $PMM_FIND
lcall *%es:7
addw $6, %sp
pushw %dx
pushw %ax
popl %esi
[romprefix] Treat 0xffffffff as an error return from PMM PMM defines the return code 0xffffffff as meaning "unsupported function". It's hard to imagine a PMM BIOS that doesn't support pmmAllocate(), but apparently such things do exist. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-06-19 19:54:22 +02:00
/* Treat 0xffffffff (not supported) as 0x00000000 (not found) */
incl %esi
jz get_pmm_allocate
decl %esi
[romprefix] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
jz get_pmm_allocate
/* Block found - check acceptability */
call *%bp
jnc get_pmm_done
/* Block not acceptable - increment handle and retry */
incl %ebx
jmp get_pmm_find
get_pmm_allocate:
/* Block not found - try to allocate new block */
pushw $0x0002 /* Extended memory */
pushl %ebx /* PMM handle */
pushl %ecx /* Length */
pushw $PMM_ALLOCATE
lcall *%es:7
addw $12, %sp
pushw %dx
pushw %ax
popl %esi
[romprefix] Fix romprefix build with certain versions of binutils Signed-off-by: Valentine Barshak <gvaxon@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-08-06 21:40:04 +02:00
movw $( '+' ), %di /* Indicate allocation attempt */
[romprefix] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
get_pmm_done:
/* Print block address */
movw %di, %ax
xorw %di, %di
call print_character
movl %esi, %eax
call print_hex_dword
[romprefix] Treat 0xffffffff as an error return from PMM PMM defines the return code 0xffffffff as meaning "unsupported function". It's hard to imagine a PMM BIOS that doesn't support pmmAllocate(), but apparently such things do exist. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-06-19 19:54:22 +02:00
/* Treat 0xffffffff (not supported) as 0x00000000 (allocation
* failed), and set ZF to indicate a zero result.
*/
incl %esi
jz 1f
decl %esi
1: /* Restore registers and return */
[romprefix] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
popw %di
popl %eax
ret
.size get_pmm, . - get_pmm
/* Check acceptability of image source block */
get_pmm_image_source:
pushw %es
xorw %ax, %ax
movw %ax, %es
movl build_id, %eax
[romprefix] Add missing addr32 prefix Reported-by: Jedrzej Kalinowski <kalinoj1@iem.pw.edu.pl> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-10-29 02:45:21 +02:00
addr32 cmpl %es:build_id(%esi), %eax
[romprefix] Split PMM allocations for image source and decompression area Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a single area large enough to hold both the iPXE image source and the temporary decompression area, despite promising a largest available PMM memory block of several megabytes. This causes ROM image shrinking to fail on these BIOSes, with undesirable consequences: other option ROMs may be disabled due to shortage of option ROM space, and the iPXE ROM may itself be corrupted by a further BIOS bug (again, observed on an AMI BIOS) which causes large ROMs to end up overlapping reserved areas of memory. This can potentially render a system unbootable via any means. Increase the chances of a successful PMM allocation by dropping the alignment requirement (which is redundant now that we can enable A20 from within the prefix); this allows us to reduce the allocation size from 2MB down to only the required size. Increase the chances still further by using two separate allocations: one to hold the image source (i.e. the copy of the ROM before being shrunk) and the other to act as the decompression area. This allows ROM image shrinking to take place even on systems that fail to allocate enough memory for the temporary decompression area. Improve the behaviour of iPXE in systems with multiple iPXE ROMs by sharing PMM allocations where possible. Image source areas can be shared with any iPXE ROMs with a matching build identifier, and the temporary decompression area can be shared with any iPXE ROMs with the same uncompressed size (rounded up to the nearest 128kB). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:34:28 +02:00
je 1f
stc
1: popw %es
ret
.size get_pmm_image_source, . - get_pmm_image_source
/* Check acceptability of decompression block */
get_pmm_decompress_to:
clc
ret
.size get_pmm_decompress_to, . - get_pmm_decompress_to
[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
[build] Move branding information to config/branding.h Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-02-11 13:51:58 +01:00
* strings PRODUCT_NAME and PRODUCT_SHORT_NAME in config/branding.h.
[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
*
* 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] Use PRODUCT_SHORT_NAME for end-user visible strings Use PRODUCT_SHORT_NAME instead of a hardcoded "iPXE" for strings which are typically shown in the user interface. Note that this only allows for customisation of the user interface. Where the "iPXE" string serves a technical purpose (such as in the HTTP User-Agent), the string cannot be customised. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-02-11 14:02:52 +01:00
.ascii PRODUCT_SHORT_NAME
[build] Allow product URI to be customised via config/branding.h Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-02-11 14:08:36 +01:00
.ascii " ("
.ascii PRODUCT_URI
.asciz ")"
[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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.ifeqs BUSTYPE, "PCIR"
[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
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.endif /* PCIR */
[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] 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
[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
[romprefix] Add .mrom format, allowing loading of large ROMs Add an infrastructure allowing the prefix to provide an open_payload() method for obtaining out-of-band access to the whole iPXE image. Add a mechanism within this infrastructure that allows raw access to the expansion ROM BAR by temporarily borrowing an address from a suitable memory BAR on the same PCI card. For cards that have a memory BAR that is at least as large as their expansion ROM BAR, this allows large iPXE ROMs to be supported even on systems where PMM fails, or where option ROM space pressure makes it impossible to use PMM shrinking. The BIOS sees only a stub ROM of approximately 3kB in size; the remainder (which can be well over 64kB) is loaded only at the time iPXE is invoked. As a nice side-effect, an iPXE .mrom image will continue to work even if its PMM-allocated areas are overwritten between initialisation and invocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-25 16:57:00 +02:00
/* PCI bus:dev.fn
*
*/
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.ifeqs BUSTYPE, "PCIR"
[romprefix] Add .mrom format, allowing loading of large ROMs Add an infrastructure allowing the prefix to provide an open_payload() method for obtaining out-of-band access to the whole iPXE image. Add a mechanism within this infrastructure that allows raw access to the expansion ROM BAR by temporarily borrowing an address from a suitable memory BAR on the same PCI card. For cards that have a memory BAR that is at least as large as their expansion ROM BAR, this allows large iPXE ROMs to be supported even on systems where PMM fails, or where option ROM space pressure makes it impossible to use PMM shrinking. The BIOS sees only a stub ROM of approximately 3kB in size; the remainder (which can be well over 64kB) is loaded only at the time iPXE is invoked. As a nice side-effect, an iPXE .mrom image will continue to work even if its PMM-allocated areas are overwritten between initialisation and invocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-25 16:57:00 +02:00
init_pci_busdevfn:
[romprefix] Display only one "Ctrl-B" prompt per PCI device during POST If a multifunction PCI device exposes an iPXE ROM via each function, then each function will display a "Press Ctrl-B to configure iPXE" prompt, and delay for two seconds. Since a single instance of iPXE can drive all functions on the multifunction device, this simply adds unnecessary delay to the boot process. Fix by inhibiting the "Press Ctrl-B" prompt for all except the first function on a PCI device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-03-11 02:43:12 +01:00
.word 0
[romprefix] Add .mrom format, allowing loading of large ROMs Add an infrastructure allowing the prefix to provide an open_payload() method for obtaining out-of-band access to the whole iPXE image. Add a mechanism within this infrastructure that allows raw access to the expansion ROM BAR by temporarily borrowing an address from a suitable memory BAR on the same PCI card. For cards that have a memory BAR that is at least as large as their expansion ROM BAR, this allows large iPXE ROMs to be supported even on systems where PMM fails, or where option ROM space pressure makes it impossible to use PMM shrinking. The BIOS sees only a stub ROM of approximately 3kB in size; the remainder (which can be well over 64kB) is loaded only at the time iPXE is invoked. As a nice side-effect, an iPXE .mrom image will continue to work even if its PMM-allocated areas are overwritten between initialisation and invocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-25 16:57:00 +02:00
.size init_pci_busdevfn, . - init_pci_busdevfn
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.endif /* PCIR */
[romprefix] Add .mrom format, allowing loading of large ROMs Add an infrastructure allowing the prefix to provide an open_payload() method for obtaining out-of-band access to the whole iPXE image. Add a mechanism within this infrastructure that allows raw access to the expansion ROM BAR by temporarily borrowing an address from a suitable memory BAR on the same PCI card. For cards that have a memory BAR that is at least as large as their expansion ROM BAR, this allows large iPXE ROMs to be supported even on systems where PMM fails, or where option ROM space pressure makes it impossible to use PMM shrinking. The BIOS sees only a stub ROM of approximately 3kB in size; the remainder (which can be well over 64kB) is loaded only at the time iPXE is invoked. As a nice side-effect, an iPXE .mrom image will continue to work even if its PMM-allocated areas are overwritten between initialisation and invocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-25 16:57:00 +02:00
[prefix] Use area at top of INT 15,88 memory map for temporary decompression Use INT 15,88 to find a suitable temporary decompression area, rather than a fixed address. This hopefully gives us a better chance of not treading on any PMM-allocated areas, in BIOSes where PMM support exists but tends not to give us the large blocks that we ask for. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:22:54 +02:00
/* Image source area
[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
*
[prefix] Use area at top of INT 15,88 memory map for temporary decompression Use INT 15,88 to find a suitable temporary decompression area, rather than a fixed address. This hopefully gives us a better chance of not treading on any PMM-allocated areas, in BIOSes where PMM support exists but tends not to give us the large blocks that we ask for. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:22:54 +02:00
* May be either zero (indicating to use option ROM space as source),
* or within a PMM-allocated block.
[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 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
[romprefix] Add a dummy ROM header to cover the .mrom payload The header of a .mrom image declares its length to be only a few kilobytes; the remainder is accessed via a sideband mechanism. This makes it difficult to append an additional ROM image, such as an EFI ROM. Add a second, dummy ROM header covering the payload portion of the .mrom image, allowing consumers to locate any appended ROM images in the usual way. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-06-10 19:25:26 +02:00
/* Additional image source size (in 512-byte sectors)
[romprefix] Add .mrom format, allowing loading of large ROMs Add an infrastructure allowing the prefix to provide an open_payload() method for obtaining out-of-band access to the whole iPXE image. Add a mechanism within this infrastructure that allows raw access to the expansion ROM BAR by temporarily borrowing an address from a suitable memory BAR on the same PCI card. For cards that have a memory BAR that is at least as large as their expansion ROM BAR, this allows large iPXE ROMs to be supported even on systems where PMM fails, or where option ROM space pressure makes it impossible to use PMM shrinking. The BIOS sees only a stub ROM of approximately 3kB in size; the remainder (which can be well over 64kB) is loaded only at the time iPXE is invoked. As a nice side-effect, an iPXE .mrom image will continue to work even if its PMM-allocated areas are overwritten between initialisation and invocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-25 16:57:00 +02:00
*
*/
[romprefix] Add a dummy ROM header to cover the .mrom payload The header of a .mrom image declares its length to be only a few kilobytes; the remainder is accessed via a sideband mechanism. This makes it difficult to append an additional ROM image, such as an EFI ROM. Add a second, dummy ROM header covering the payload portion of the .mrom image, allowing consumers to locate any appended ROM images in the usual way. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-06-10 19:25:26 +02:00
extra_size:
[romprefix] Add .mrom format, allowing loading of large ROMs Add an infrastructure allowing the prefix to provide an open_payload() method for obtaining out-of-band access to the whole iPXE image. Add a mechanism within this infrastructure that allows raw access to the expansion ROM BAR by temporarily borrowing an address from a suitable memory BAR on the same PCI card. For cards that have a memory BAR that is at least as large as their expansion ROM BAR, this allows large iPXE ROMs to be supported even on systems where PMM fails, or where option ROM space pressure makes it impossible to use PMM shrinking. The BIOS sees only a stub ROM of approximately 3kB in size; the remainder (which can be well over 64kB) is loaded only at the time iPXE is invoked. As a nice side-effect, an iPXE .mrom image will continue to work even if its PMM-allocated areas are overwritten between initialisation and invocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-25 16:57:00 +02:00
.word 0
[romprefix] Add a dummy ROM header to cover the .mrom payload The header of a .mrom image declares its length to be only a few kilobytes; the remainder is accessed via a sideband mechanism. This makes it difficult to append an additional ROM image, such as an EFI ROM. Add a second, dummy ROM header covering the payload portion of the .mrom image, allowing consumers to locate any appended ROM images in the usual way. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-06-10 19:25:26 +02:00
.size extra_size, . - extra_size
[prefix] Add .text16.early section Add a section .text16.early which is always kept inline with the prefix. This will allow for some code sharing between the .prefix and .text16 sections. Note that the simple solution of just prepending the .prefix section to the .text16 section will not work, because a bug in Wyse Streaming Manager server (WLDRM13.BIN) requires us to place a dummy PXENV+ entry point at the start of .text16. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-20 12:05:53 +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
/* Temporary decompression area
*
[prefix] Use area at top of INT 15,88 memory map for temporary decompression Use INT 15,88 to find a suitable temporary decompression area, rather than a fixed address. This hopefully gives us a better chance of not treading on any PMM-allocated areas, in BIOSes where PMM support exists but tends not to give us the large blocks that we ask for. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:22:54 +02:00
* May be either zero (indicating to use default decompression area in
* high memory), or within a PMM-allocated block.
[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:
[prefix] Use area at top of INT 15,88 memory map for temporary decompression Use INT 15,88 to find a suitable temporary decompression area, rather than a fixed address. This hopefully gives us a better chance of not treading on any PMM-allocated areas, in BIOSes where PMM support exists but tends not to give us the large blocks that we ask for. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-24 23:22:54 +02:00
.long 0
[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 decompress_to, . - decompress_to
/* Boot Execution Vector entry point
*
* Called by the PnP BIOS when it wants to boot us.
*/
bev_entry:
[pcbios] Inhibit all calls to INT 15,e820 and INT 15,e801 during POST Many BIOSes do not construct the full system memory map until after calling the option ROM initialisation entry points. For several years, we have added sanity checks and workarounds to accommodate charming quirks such as BIOSes which report the entire 32-bit address space (including all memory-mapped PCI BARs) as being usable RAM. The IBM x3650 takes quirky behaviour to a new extreme. Calling either INT 15,e820 or INT 15,e801 during POST doesn't just get you invalid data. We could cope with invalid data. Instead, these nominally read-only API calls manage to trash some internal BIOS state, with the result that the system memory map is _never_ constructed. This tends to confuse subsequent bootloaders and operating systems. [ GRUB 0.97 fails in a particularly amusing way. Someone thought it would be a good idea for memcpy() to check that the destination memory region is a valid part of the system memory map; if not, then memcpy() will sulk, fail, and return NULL. This breaks pretty much every use of memcpy() including, for example, those inserted implicitly by gcc to copy non-const initialisers. Debugging is _fun_ when a simple call to printf() manages to create an infinite recursion, exhaust the available stack space, and shut down the CPU. ] Fix by completely inhibiting calls to INT 15,e820 and INT 15,e801 during POST. We do now allow relocation during POST up to the maximum address returned by INT 15,88 (which seems so far to always be safe). This allows us to continue to have a reasonable size of external heap, even if the PMM allocation is close to the 1MB mark. The downside of allowing relocation during POST is that we may overwrite PMM-allocated memory in use by other option ROMs. However, the downside of inhibiting relocation, when combined with also inhibiting calls to INT 15,e820 and INT 15,e801, would be that we might have no external heap available: this would make booting an OS impossible and could prevent some devices from even completing initialisation. On balance, the lesser evil is probably to allow relocation during POST (up to the limit provided by INT 15,88). Entering iPXE during POST is a rare operation; on the even rarer systems where doing so happens to overwrite a PMM-allocated region, then there exists a fairly simple workaround: if the user enters iPXE during POST and wishes to exit iPXE, then the user must reboot. This is an acceptable cost, given the rarity of the situation and the simplicity of the workaround. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-03-11 01:50:52 +01:00
orl $0xffffffff, %ebp /* Allow arbitrary relocation */
[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 %cs
call exec
lret
.size bev_entry, . - bev_entry
/* 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.
*/
[pcbios] Inhibit all calls to INT 15,e820 and INT 15,e801 during POST Many BIOSes do not construct the full system memory map until after calling the option ROM initialisation entry points. For several years, we have added sanity checks and workarounds to accommodate charming quirks such as BIOSes which report the entire 32-bit address space (including all memory-mapped PCI BARs) as being usable RAM. The IBM x3650 takes quirky behaviour to a new extreme. Calling either INT 15,e820 or INT 15,e801 during POST doesn't just get you invalid data. We could cope with invalid data. Instead, these nominally read-only API calls manage to trash some internal BIOS state, with the result that the system memory map is _never_ constructed. This tends to confuse subsequent bootloaders and operating systems. [ GRUB 0.97 fails in a particularly amusing way. Someone thought it would be a good idea for memcpy() to check that the destination memory region is a valid part of the system memory map; if not, then memcpy() will sulk, fail, and return NULL. This breaks pretty much every use of memcpy() including, for example, those inserted implicitly by gcc to copy non-const initialisers. Debugging is _fun_ when a simple call to printf() manages to create an infinite recursion, exhaust the available stack space, and shut down the CPU. ] Fix by completely inhibiting calls to INT 15,e820 and INT 15,e801 during POST. We do now allow relocation during POST up to the maximum address returned by INT 15,88 (which seems so far to always be safe). This allows us to continue to have a reasonable size of external heap, even if the PMM allocation is close to the 1MB mark. The downside of allowing relocation during POST is that we may overwrite PMM-allocated memory in use by other option ROMs. However, the downside of inhibiting relocation, when combined with also inhibiting calls to INT 15,e820 and INT 15,e801, would be that we might have no external heap available: this would make booting an OS impossible and could prevent some devices from even completing initialisation. On balance, the lesser evil is probably to allow relocation during POST (up to the limit provided by INT 15,88). Entering iPXE during POST is a rare operation; on the even rarer systems where doing so happens to overwrite a PMM-allocated region, then there exists a fairly simple workaround: if the user enters iPXE during POST and wishes to exit iPXE, then the user must reboot. This is an acceptable cost, given the rarity of the situation and the simplicity of the workaround. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-03-11 01:50:52 +01:00
orl $0xffffffff, %ebp /* Allow arbitrary relocation */
[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
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
/* 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] Provide indication of successful call to install_prealloc The existing "iPXE starting execution" message indicates that the BEV (or INT19) was invoked, but gives no indication on whether or not the iPXE source was successfully retrieved (e.g. from PMM). Split the "starting execution message" into "starting execution...ok"; the "ok" indicates that the main iPXE body was successfully decompressed and relocated. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-21 14:35:31 +02:00
movw $exec_message_pre_install, %si
[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_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
[prefix] Allow prefix to specify an arbitrary maximum address for relocation Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-11-12 00:20:28 +01:00
movw %ss, %cx
movw %sp, %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
/* Obtain a reasonably-sized temporary stack */
[romprefix] Inhibit the use of relocation during POST It is common for system memory maps to be grotesquely unreliable during POST. Many sanity checks have been added to the memory map reading code, but these do not catch all problems. Skip relocation entirely if called during POST. This should avoid the problems typically encountered, at the cost of slightly disrupting the memory map of an operating system booted via iPXE when iPXE was entered during POST. Since this is a very rare special case (used, for example, when reflashing an experimental ROM that would otherwise prevent the system from completing POST), this is an acceptable cost. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-25 02:37:25 +02:00
xorw %bx, %bx
movw %bx, %ss
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 $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 */
[romprefix] Inhibit the use of relocation during POST It is common for system memory maps to be grotesquely unreliable during POST. Many sanity checks have been added to the memory map reading code, but these do not catch all problems. Skip relocation entirely if called during POST. This should avoid the problems typically encountered, at the cost of slightly disrupting the memory map of an operating system booted via iPXE when iPXE was entered during POST. Since this is a very rare special case (used, for example, when reflashing an experimental ROM that would otherwise prevent the system from completing POST), this is an acceptable cost. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-25 02:37:25 +02:00
call alloc_basemem
[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 install_prealloc
Initial revision
2005-03-08 19:53:11 +01:00
[romprefix] Provide indication of successful call to install_prealloc The existing "iPXE starting execution" message indicates that the BEV (or INT19) was invoked, but gives no indication on whether or not the iPXE source was successfully retrieved (e.g. from PMM). Split the "starting execution message" into "starting execution...ok"; the "ok" indicates that the main iPXE body was successfully decompressed and relocated. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-21 14:35:31 +02:00
/* Print message indicating successful installation */
movw $exec_message_post_install, %si
xorw %di, %di
call print_message
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
[romprefix] Store boot bus:dev.fn address as autoboot device location Per the BIOS Boot Specification, the initialization phase of the ROM is called with the PFA (PCI Function Address) in the %ax register. The intention is that the ROM code will store that device address somewhere and use it for booting from that device when the Boot Entry Vector (BEV) is called. iPXE does store the PFA, but doesn't use it to select the boot network device. This renders BIOS IPL lists fairly ineffective. Fix by using the BBS-specified bus:dev.fn address as the autoboot device location. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-02-26 00:00:44 +01:00
1:
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
/* Retrieve PCI bus:dev.fn, if applicable */
.ifeqs BUSTYPE, "PCIR"
[romprefix] Do not clobber stack segment when returning to BIOS Commit c429bf0 ("[romprefix] Store boot bus:dev.fn address as autoboot device location") introduced a regression by using register %cx to temporarily hold the PCI bus:dev.fn address, despite the fact that %cx was already being used to hold the stored BIOS stack segment. Consequently, when returning to the BIOS after a failed or cancelled boot attempt, iPXE would end up calling INT 18 with the stack segment set equal to the PCI bus:dev.fn address. Writing to essentially random areas of memory tends to upset even the more robust BIOSes. Fix by using register %ax to temporarily hold the PCI bus:dev.fn address. Reported-by: Anton D. Kachalov <mouse@yandex-team.ru> Tested-by: Anton D. Kachalov <mouse@yandex-team.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-03-05 13:25:21 +01:00
movw init_pci_busdevfn, %ax
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.endif
[romprefix] Store boot bus:dev.fn address as autoboot device location Per the BIOS Boot Specification, the initialization phase of the ROM is called with the PFA (PCI Function Address) in the %ax register. The intention is that the ROM code will store that device address somewhere and use it for booting from that device when the Boot Entry Vector (BEV) is called. iPXE does store the PFA, but doesn't use it to select the boot network device. This renders BIOS IPL lists fairly ineffective. Fix by using the BBS-specified bus:dev.fn address as the autoboot device location. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-02-26 00:00:44 +01:00
/* Set up %ds for access to .data16 */
movw %bx, %ds
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
/* Store PCI bus:dev.fn, if applicable */
.ifeqs BUSTYPE, "PCIR"
[romprefix] Allow autoboot device filter to be disabled Our current behaviour when booting as a ROM is to autoboot only from devices which are attached via the PCI bus:dev.fn address passed to the ROM's initialisation vector. Add a build configuration option AUTOBOOT_ROM_FILTER (enabled by default) to control this behaviour. This allows for ROMs to be built which will attempt to boot from any detected device, even if not attached via the original PCI bus:dev.fn address. (This is particularly useful when building combined EHCI/xHCI ROMs for USB network boot, since the BIOS may request a boot via the EHCI controller but the xHCI driver will reroute the root hub ports to the xHCI controller.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-04-13 15:49:02 +02:00
#ifdef AUTOBOOT_ROM_FILTER
[romprefix] Do not clobber stack segment when returning to BIOS Commit c429bf0 ("[romprefix] Store boot bus:dev.fn address as autoboot device location") introduced a regression by using register %cx to temporarily hold the PCI bus:dev.fn address, despite the fact that %cx was already being used to hold the stored BIOS stack segment. Consequently, when returning to the BIOS after a failed or cancelled boot attempt, iPXE would end up calling INT 18 with the stack segment set equal to the PCI bus:dev.fn address. Writing to essentially random areas of memory tends to upset even the more robust BIOSes. Fix by using register %ax to temporarily hold the PCI bus:dev.fn address. Reported-by: Anton D. Kachalov <mouse@yandex-team.ru> Tested-by: Anton D. Kachalov <mouse@yandex-team.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-03-05 13:25:21 +01:00
movw %ax, autoboot_busdevfn
[romprefix] Allow autoboot device filter to be disabled Our current behaviour when booting as a ROM is to autoboot only from devices which are attached via the PCI bus:dev.fn address passed to the ROM's initialisation vector. Add a build configuration option AUTOBOOT_ROM_FILTER (enabled by default) to control this behaviour. This allows for ROMs to be built which will attempt to boot from any detected device, even if not attached via the original PCI bus:dev.fn address. (This is particularly useful when building combined EHCI/xHCI ROMs for USB network boot, since the BIOS may request a boot via the EHCI controller but the xHCI driver will reroute the root hub ports to the xHCI controller.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-04-13 15:49:02 +02:00
#endif /* AUTOBOOT_ROM_FILTER */
[build] Allow ISA ROMs to be built The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-21 17:34:26 +02:00
.endif
[romprefix] Store boot bus:dev.fn address as autoboot device location Per the BIOS Boot Specification, the initialization phase of the ROM is called with the PFA (PCI Function Address) in the %ax register. The intention is that the ROM code will store that device address somewhere and use it for booting from that device when the Boot Entry Vector (BEV) is called. iPXE does store the PFA, but doesn't use it to select the boot network device. This renders BIOS IPL lists fairly ineffective. Fix by using the BBS-specified bus:dev.fn address as the autoboot device location. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-02-26 00:00:44 +01:00
[librm] Provide an abstraction wrapper for prot_call Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-02-19 00:23:38 +01:00
/* Run iPXE */
virtcall main
[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
[librm] Use genuine real mode to accelerate operation in virtual machines We currently use flat real mode wherever real mode is required. This guarantees that we will not surprise some unsuspecting external caller which has carefully set up flat real mode by suddenly reducing the segment limits to 64kB. However, operating in flat real mode imposes a severe performance penalty in some virtualisation environments, since some CPUs cannot fully virtualise flat real mode and so the hypervisor must fall back to emulation. In particular, operating under KVM on a pre-Westmere Intel CPU will be at least an order of magnitude slower, to the point that there is a visible teletype effect when printing anything to the BIOS console. (Older versions of KVM used to cheat and ignore the "flat" part of flat real mode, which masked the problem.) Switch (back) to using genuine real mode with 64kB segment limits instead of flat real mode. Hopefully this won't break anything. Add an explicit switch to flat real mode before returning to the BIOS from the ROM prefix, since we know that a PMM BIOS will call the ROM initialisation point (and potentially the BEV) in flat real mode. As noted in previous commit messages, it is not possible to restore the real-mode segment limits after a transition to protected mode, since there is no way to know which protected-mode segment descriptor was originally used to initialise the limit portion of the segment register. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-04-28 02:21:08 +02:00
/* Set up flat real mode for return to BIOS */
call flatten_real_mode
[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 */
[prefix] Allow prefix to specify an arbitrary maximum address for relocation Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-11-12 00:20:28 +01:00
movw %cx, %ss
movw %dx, %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
[romprefix] Provide indication of successful call to install_prealloc The existing "iPXE starting execution" message indicates that the BEV (or INT19) was invoked, but gives no indication on whether or not the iPXE source was successfully retrieved (e.g. from PMM). Split the "starting execution message" into "starting execution...ok"; the "ok" indicates that the main iPXE body was successfully decompressed and relocated. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-21 14:35:31 +02:00
exec_message_pre_install:
.asciz " starting execution..."
.size exec_message_pre_install, . - exec_message_pre_install
exec_message_post_install:
.asciz "ok\n"
.size exec_message_post_install, . - exec_message_post_install
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 */
[romprefix] Allow ROM banner timeout to be configured independently iPXE currently prints a "Press Ctrl-B" banner twice: once when the ROM is first called for initialisation and again if we attempt to boot from the ROM. This slows boot, especially when the NIC is not the primary boot device. Tools such as libguestfs make use of QEMU VMs for performing maintenance on disk images and may make use of NICs in the VM for network support. If iPXE introduces a static init-time delay, that directly translates to increased runtime for the tools. Fix by allowing the ROM banner timeout to be configured independently of the main banner timeout. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-02-26 00:33:08 +01:00
movw $ROM_BANNER_TIMEOUT_TICKS, %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
[build] Use REQUIRE_OBJECT() to drag in per-object configuration Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-03-04 18:22:07 +01:00
[build] Fix the REQUIRE_SYMBOL mechanism At some point in the past few years, binutils became more aggressive at removing unused symbols. To function as a symbol requirement, a relocation record must now be in a section marked with @progbits and must not be in a section which gets discarded during the link (either via --gc-sections or via /DISCARD/). Update REQUIRE_SYMBOL() to generate relocation records meeting these criteria. To minimise the impact upon the final binary size, we use existing symbols (specified via the REQUIRING_SYMBOL() macro) as the relocation targets where possible. We use R_386_NONE or R_X86_64_NONE relocation types to prevent any actual unwanted relocation taking place. Where no suitable symbol exists for REQUIRING_SYMBOL() (such as in config.c), the macro PROVIDE_REQUIRING_SYMBOL() can be used to generate a one-byte-long symbol to act as the relocation target. If there are versions of binutils for which this approach fails, then the fallback will probably involve killing off REQUEST_SYMBOL(), redefining REQUIRE_SYMBOL() to use the current definition of REQUEST_SYMBOL(), and postprocessing the linked ELF file with something along the lines of "nm -u | wc -l" to check that there are no undefined symbols remaining. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-03-04 19:48:19 +01:00
/* Drag in objects via _rom_start */
REQUIRING_SYMBOL ( _rom_start )
[build] Use REQUIRE_OBJECT() to drag in per-object configuration Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-03-04 18:22:07 +01:00
/* Drag in ROM configuration */
REQUIRE_OBJECT ( config_romprefix )