summaryrefslogtreecommitdiffstats
path: root/src/arch/i386/prefix
Commit message (Collapse)AuthorAgeFilesLines
* [bios] Add bin-x86_64-pcbios build platformMichael Brown2016-02-1621-5656/+0Star
| | | | | | | | | | | | | | Move most arch/i386 files to arch/x86, and adjust the contents of the Makefiles and the include/bits/*.h headers to reflect the new locations. This patch makes no substantive code changes, as can be seen using a rename-aware diff (e.g. "git show -M5"). This patch does not make the pcbios platform functional for x86_64; it merely allows it to compile without errors. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [prefix] Pad .text16 and .data16 segment sizes at build timeMichael Brown2016-02-121-8/+5Star
| | | | | | | | | | | | | | | | | Commit c64747d ("[librm] Speed up real-to-protected mode transition under KVM") rounded down the .text16 segment address calculated in alloc_basemem() to a multiple of 64 bytes in order to speed up mode transitions under KVM. This creates a potential discrepancy between alloc_basemem() and free_basemem(), meaning that free_basemem() may free less memory than was allocated by alloc_basemem(). Fix by padding the calculated sizes of both .text16 and .data16 to a multiple of 64 bytes at build time. Debugged-by: Yossef Efraim <yossefe@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [romprefix] Report an optimistic runtime size estimateMichael Brown2016-01-061-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [prefix] Use correct register for KEEP_IT_REAL physical address conversionDaniel Pieczko2015-08-141-2/+2
| | | | | Signed-off-by: Daniel Pieczko <dpieczko@solarflare.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [mromprefix] Report a dummy size at offset 0x02 of .mrom payloadMichael Brown2015-06-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The size of the .mrom payload (the second PCI ROM image) is defined in its PCI header. The code type for the .mrom payload image is deliberately set to an invalid value (0xff) to ensure that no BIOS tries to parse anything in the image other than the PCI header. Since the code type is not set to 0x00 ("Intel x86, PC-AT compatible"), bytes 0x02-0x17 should not be interpreted by the BIOS as being in the standard ISA expansion ROM format. In particular, the byte at offset 0x02 does not represent the length of the ROM image (in 512-byte blocks). However, some Dell BIOSes seem to erroneously use the byte at offset 0x02 to determine the length of the .mrom payload when walking the list of PCI ROM images. Since this byte is currently set to zero, this can lead to the BIOS getting stuck in an infinite loop during POST. (This problem may not arise if the .mrom payload is the final image in the ROM, since the BIOS will then have no reason to attempt to locate the next image.) One possible workaround would be to put the real payload size in this byte, but doing so would constrain the .mrom payload size to 128kB (see commit 8049a52 ("[mromprefix] Allow for .mrom images larger than 128kB") for more details). Another possible workaround would be to put the real payload size as a word in bytes 0x02-0x03 (as is done for EFI ROMs). This would not constrain the .mrom payload size, but a payload size which happened to be exactly 128kB would result in a zero value in the byte at offset 0x02 and so could still result in infinite loops on BIOSes with this bug. We choose to place a fixed value of 0x01 in the byte at offset 0x02. This should at least prevent the BIOS from getting stuck in an infinite loop. (The BIOS may walk into the middle of the .mrom payload, where it will almost certainly not find a valid {0x55,0xaa} signature or a valid PCIR header, and will therefore hopefully abort processing.) Reported-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [int13con] Add basic ability to log to a local disk via INT 13Michael Brown2015-05-191-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | Several popular public cloud providers do not provide any sensible mechanism for obtaining debug output from an OS which is failing to boot. For example, Amazon EC2 provides the "Get System Log" facility, which occasionally deigns to report a random subset of the characters emitted via the VM's serial port, but usually returns only a blank screen. (Amazingly, this is still superior to the debugging facilities provided by Azure.) Work around these shortcomings by adding a console type which sends output to a magically detected raw disk partition, and including such a partition within any iPXE .usb-format image. To use this facility: - build an iPXE .usb image with CONSOLE_INT13 enabled - boot the cloud VM from this image - after the boot fails, attach the VM's boot disk to a second VM - from this second VM, use "less -f -R /dev/sdb3" (or similar) to view the iPXE output. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Work around binutils quirk on OpenBSD 5.7Michael Brown2015-04-181-0/+3
| | | | | | | | | | | | | The assembler on OpenBSD 5.7 seems not to correctly handle the combinations of .struct and .previous used in unlzma.S, and ends up complaining about an "attempt to allocate data in absolute section". Work around this problem by explicitly resetting the section after the data structure definitions. Reported-by: Jiri B <jirib@devio.us> Tested-by: Jiri B <jirib@devio.us> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow building PCI ROMs with device ID listsMichael Brown2015-04-151-1/+12
| | | | | | | | | | | | | | 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>
* [romprefix] Allow autoboot device filter to be disabledMichael Brown2015-04-131-0/+2
| | | | | | | | | | | | | | | | | 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>
* [libprefix] Fix building on 64-bit FreeBSD 8.4Michael Brown2015-03-231-1/+1
| | | | | Reported-by: Pavel Antonov <holly@istu.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Relicense files under GPL2_OR_LATER_OR_UBDLMichael Brown2015-03-117-3/+11
| | | | | | | | | Several of the assembly files in arch/i386/prefix were missed by the automated relicensing tool due to missing licence declarations, code dating back to the initial git revision, etc. Manual review shows that these files may be relicensed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Relicense files under GPL2_OR_LATER_OR_UBDLMichael Brown2015-03-051-1/+1
| | | | | | | | | | | Relicense files with kind permission from Stefan Hajnoczi <stefanha@redhat.com> alongside the contributors who have already granted such relicensing permission. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Fix the REQUIRE_SYMBOL mechanismMichael Brown2015-03-052-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [build] Use REQUIRE_OBJECT() to drag in per-object configurationMichael Brown2015-03-051-0/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Remove obsolete references to pxeparent_dhcpMichael Brown2015-03-032-6/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Relicense files under GPL2_OR_LATER_OR_UBDLMichael Brown2015-03-023-3/+7
| | | | | | | | | | 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>
* [legal] Relicense files under GPL2_OR_LATER_OR_UBDLMichael Brown2015-03-029-9/+29
| | | | | | | Relicense files for which I am the sole author (as identified by util/relicense.pl). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [zbin] Remove now-unused unnrv2b.S decompressorMichael Brown2015-02-262-193/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [zbin] Fix check for existence of most recent output byteMichael Brown2015-02-261-3/+1Star
| | | | | | | | | | | | | | | | | | | The code in lzma_literal() checks to see if we are at the start of the compressed input data in order to determine whether or not a most recent output byte exists. This check is incorrect, since initialisation of the decompressor will always consume the first five bytes of the compressed input data. Fix by instead checking whether or not we are at the start of the output data stream. This is, in any case, a more logical check. This issue was masked during development and testing since virtual machines tend to zero the initial contents of RAM; the spuriously-read "most recent output byte" is therefore likely to already be a zero when running in a virtual machine. Reported-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [zbin] Allow decompressor to generate debug output via BIOS consoleMichael Brown2015-02-261-19/+50
| | | | | | | | | | | | The 0xe9 debug port exists only on virtual machines. Provide an option to print debug output on the BIOS console, to allow for debugging on real hardware. Note that this option can be used only if the decompressor is called in flat real mode; the easiest way to achieve this is to build with DEBUG=libprefix. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [prefix] Call decompressor in flat real mode when DEBUG=libprefix is enabledMichael Brown2015-02-261-0/+16
| | | | | | | | Allow the decompressor the option of generating debugging output via the BIOS console by calling it in flat real mode (rather than 16-bit protected mode) when libprefix.S is built with debugging enabled. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [zbin] Perform extra normalisation after completing decompressionMichael Brown2015-02-261-0/+1
| | | | | | | | | | | LZMA performs an extra normalisation after decompression is complete, which does not affect the output but may consume an extra byte from the input (and so may affect which byte is identified as being the start of the next block). Reported-by: Robin Smidsrød <robin@smidsrod.no> Tested-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [zbin] Use LZMA compressionMichael Brown2015-02-252-0/+914
| | | | | | | | | | | | | | | | | | | | | | | | | | LZMA provides significantly better compression (by ~15%) than the current NRV2B algorithm. We use a raw LZMA stream (aka LZMA1) to avoid the need for code to parse the LZMA2 block headers. We use parameters {lc=2,lp=0,pb=0} to reduce the stack space required by the decompressor to acceptable levels (around 8kB). Using lc=3 or pb=2 would give marginally better compression, but at the cost of substantially increasing the required stack space. The build process now requires the liblzma headers to be present on the build system, since we do not include a copy of an LZMA compressor within the iPXE source tree. The decompressor is written from scratch (based on XZ Embedded) and is entirely self-contained within the iPXE source. The branch-call-jump (BCJ) filter used to improve the compressibility is specific to iPXE. We choose not to use liblzma's built-in BCJ filter since the algorithm is complex and undocumented. Our BCJ filter achieves approximately the same results (on typical iPXE binaries) with a substantially simpler algorithm. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [prefix] Use .bss16 as temporary stack space for calls to install_blockMichael Brown2015-02-241-11/+38
| | | | | | | | | | | | Some decompression algorithms (e.g. LZMA) require large amounts of temporary stack space, which may not be made available by all prefixes. Use .bss16 as a temporary stack for the duration of the calls to install_block (switching back to the external stack before we start making calls into code which might access variables in .bss16), and allow the decompressor to define a global symbol to force a minimum value on the size of .bss16. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow product URI to be customised via config/branding.hMichael Brown2015-02-111-1/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use PRODUCT_SHORT_NAME for end-user visible stringsMichael Brown2015-02-111-1/+2
| | | | | | | | | | | 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>
* [build] Move branding information to config/branding.hMichael Brown2015-02-111-1/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [mromprefix] Allow for .mrom images larger than 128kBMichael Brown2014-08-261-9/+1Star
| | | | | | | | | | The .mrom payload has a code type of 0xff and so the initialisation length field (single byte at offset 0x02) does not need to be present. Use only the PCI header's image length field, which allows the .mrom payload to be up to 32MB in size. Inspired-by: Swift Geek <swiftgeek@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [mromprefix] Use PCI length field to obtain length of individual imagesMichael Brown2014-08-261-7/+17
| | | | | | | | | | | | mromprefix.S currently uses the initialisation length field (single byte at offset 0x02) to determine the length of a ROM image within a multi-image ROM BAR. For PCI ROM images with a code type other than 0, the initialisation length field may not be present. Fix by using the PCI header's image length field instead. Inspired-by: Swift Geek <swiftgeek@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [prefix] Report both %esi and %ecx when opening payload failsMichael Brown2014-08-262-1/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [prefix] Halt system without burning CPU if we cannot access the payloadMichael Brown2014-08-261-1/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow ISA ROMs to be builtMichael Brown2014-08-225-27/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [romprefix] Do not preserve unused register %diMichael Brown2014-08-221-8/+1Star
| | | | | | | | | | Since some PnP BIOSes fail to set %es:di to point to the PnP signature on entry, we identify a PnP BIOS by scanning through the top 64kB of base memory looking for the PnP structure. We therefore don't actually use the values of %es:di provided to the initialisation entry point, and so there is no need to preserve them. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [lkrnprefix] Make real-mode setup code relocatableMichael Brown2014-05-151-3/+4
| | | | | | | | | | | | The bzImage boot protocol allows the real-mode code to be loaded at any segment within base memory. (The fact that both iPXE and recent versions of Syslinux will load the real-mode code at 1000:0000 is a coincidence; it is not guaranteed by the specification.) Fix by making the code relocatable. Reported-by: Andrew Stuart <andrew@shopcusa.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [lkrnprefix] Function as a bzImage kernelMichael Brown2014-05-131-132/+83Star
| | | | | | | | | | | | | | | | | | | | The .lkrn prefix currently provides a zImage kernel with unused setup sectors and the whole iPXE binary placed within the "protected mode kernel" portion of the zImage. The work carried out years ago to create the .mrom format provides a mechanism allowing the iPXE binary to be split into a small real-mode header and a larger payload. This neatly matches the way that a bzImage is loaded: the "setup sectors" can contain the header and the "protected mode kernel" can contain the payload. This removes the size restrictions on an iPXE .lkrn image (and hence on derived image formats such as .iso). Also remove obsolete copyright information, since none of the original code or functionality now remains. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Speed up real-to-protected mode transition under KVMMichael Brown2014-05-021-1/+4
| | | | | | | | | | | | | | | Ensure that all segment registers have zero in the low two bits before transitioning to protected mode. This allows the CPU state to immediately be deemed to be "valid", and eliminates the need for any further emulated instructions. Load the protected-mode interrupt descriptor table after switching to protected mode, since this avoids triggering an EXCEPTION_NMI and corresponding VM exit. This reduces the time taken by real_to_prot under KVM by around 50%. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Use genuine real mode to accelerate operation in virtual machinesMichael Brown2014-04-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [romprefix] Do not clobber stack segment when returning to BIOSMichael Brown2014-03-051-2/+2
| | | | | | | | | | | | | | | | | | 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>
* [romprefix] Store boot bus:dev.fn address as autoboot device locationAlex Williamson2014-03-031-1/+11
| | | | | | | | | | | | | | | | | 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>
* [romprefix] Allow ROM banner timeout to be configured independentlyAlex Williamson2014-03-031-7/+3Star
| | | | | | | | | | | | | | | | | 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>
* [lkrnprefix] Include iPXE version string in image headerMichael Brown2013-12-061-1/+4
| | | | | Originally-implemented-by: Christian Hesse <list@eworm.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Always retrieve cached DHCPACK and apply to relevant network deviceMichael Brown2013-10-251-3/+48
| | | | | | | | | | | | When chainloading, always retrieve the cached DHCPACK packet from the underlying PXE stack, and apply it as the original contents of the "net<X>.dhcp" settings block. This allows cached DHCP settings to be used for any chainloaded iPXE binary (not just undionly.kkpxe). This change eliminates the undocumented "use-cached" setting. Issuing the "dhcp" command will now always result in a fresh DHCP request. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [romprefix] Fix incorrect pointer offset in undiloader.SFrediano Ziglio2013-05-141-2/+2
| | | | | | | | | | | | | Commit 2422647 ("[prefix] Allow prefix to specify an arbitrary maximum address for relocation") introduced a regression into the UNDI ROM loader by preserving an extra register on the stack without modifying the %sp-relative addresses used in the routine. Fix by correcting the %sp-relative addresses to allow for the extra preserved variable. Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [romprefix] Report failure cause when unable to open payloadMichael Brown2013-04-301-4/+7
| | | | | | | | | | | | | | | | | Report the cause of the failure when we are unable to open the .mrom payload. There are two possible failure cases: - Unable to find a suitable memory BAR to borrow (e.g. if the NIC doesn't have a memory BAR that is at least as large as the expansion ROM BAR, or if the memory BAR has been assigned a 64-bit address which won't fit into the 32-bit expansion ROM BAR). This will be reported as "BABABABA". - Unable to find correct ROM image within the BAR. This will be reported as the address (within the borrowed BAR) at which we first fail to find a valid 55AA signature. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [lkrnprefix] Allow relocation when no initrd is presentMichael Brown2013-03-151-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Commit 2629b7e ("[pcbios] Inhibit all calls to INT 15,e820 and INT 15,e801 during POST") introduced a regression into .lkrn images when used with no corresponding initrd. Specifically, the semantics of the "maximum address for relocation" value passed to install_prealloc() in %ebp changed so that zero became a special value meaning "inhibit use of INT 15,e820 and INT 15,e801". The %ebp value meaing "no upper limit on relocation" was changed from zero to 0xffffffff, and all prefixes providing fixed values for %ebp were updated to match the new semantics. The .lkrn prefix provides the initrd base address as the maximum address for relocation. When no initrd is present, this address will be zero, and so will unintentionally trigger the "inhibit INT 15,e820 and INT 15,e801" behaviour. Fix by explicitly setting %ebp to 0xffffffff if no initrd is present before calling install_prealloc(). Reported-by: Ján ONDREJ (SAL) <ondrejj@salstar.sk> Tested-by: Ján ONDREJ (SAL) <ondrejj@salstar.sk> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [romprefix] Display only one "Ctrl-B" prompt per PCI device during POSTMichael Brown2013-03-111-3/+11
| | | | | | | | | | | | | 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>
* [pcbios] Inhibit all calls to INT 15,e820 and INT 15,e801 during POSTMichael Brown2013-03-114-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [prefix] Use %cs as implicit parameter to uninstall()Michael Brown2013-03-081-6/+6
| | | | | | | | | | | | | romprefix.S currently calls uninstall() with an invalid value in %ax. Consequently, base memory is not freed after a ROM boot attempt (or after entering iPXE during POST). The uninstall() function is physically present in .text16, and so can use %cs to determine the .text16 segment address. The .data16 segment address is not required, since uninstall() is called only by code paths which set up .data16 to immediately follow .text16. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [nbiprefix] Set up real-mode stack before jumping to .text16Michael Brown2013-03-081-0/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [romprefix] Round up PMM allocation sizes to nearest 4kBMichael Brown2012-07-251-1/+5
| | | | | | | | | | | | 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>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-02-27 17:56:32 +0100