openslx-ng/ipxe.git/src/arch/i386/prefix, branch openslx

[bios] Add bin-x86_64-pcbios build platform

2016-02-16T19:32:32+00:00

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

[prefix] Pad .text16 and .data16 segment sizes at build time

2016-02-12T14:04:51+00:00

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 Signed-off-by: Michael Brown

[romprefix] Report an optimistic runtime size estimate

2016-01-06T00:30:23+00:00

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

[prefix] Use correct register for KEEP_IT_REAL physical address conversion

2015-08-14T15:18:54+00:00

Signed-off-by: Daniel Pieczko Signed-off-by: Michael Brown

[mromprefix] Report a dummy size at offset 0x02 of .mrom payload

2015-06-25T09:33:46+00:00

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 Signed-off-by: Michael Brown

[int13con] Add basic ability to log to a local disk via INT 13

2015-05-19T11:58:03+00:00

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

[build] Work around binutils quirk on OpenBSD 5.7

2015-04-17T23:53:27+00:00

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 Tested-by: Jiri B Signed-off-by: Michael Brown

[build] Allow building PCI ROMs with device ID lists

2015-04-15T11:20:06+00:00

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

[romprefix] Allow autoboot device filter to be disabled

2015-04-13T13:49:02+00:00

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

[libprefix] Fix building on 64-bit FreeBSD 8.4

2015-03-23T13:28:59+00:00

Reported-by: Pavel Antonov Signed-off-by: Michael Brown