openslx-ng/ipxe.git/src/arch/i386/prefix/mromprefix.S, 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

[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

[legal] Relicense files under GPL2_OR_LATER_OR_UBDL

2015-03-02T14:17:31+00:00

Relicense files for which I am the sole author (as identified by util/relicense.pl). Signed-off-by: Michael Brown

[mromprefix] Allow for .mrom images larger than 128kB

2014-08-26T14:17:56+00:00

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

[mromprefix] Use PCI length field to obtain length of individual images

2014-08-26T14:17:56+00:00

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

[prefix] Report both %esi and %ecx when opening payload fails

2014-08-26T14:17:34+00:00

Signed-off-by: Michael Brown

[build] Allow ISA ROMs to be built

2014-08-22T16:34:07+00:00

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

[romprefix] Report failure cause when unable to open payload

2013-04-30T13:56:19+00:00

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

[legal] Update FSF mailing address in GPL licence texts

2012-07-20T18:55:45+00:00

Suggested-by: Daniel P. Berrange Signed-off-by: Michael Brown

[romprefix] Allow .mrom image to be placed anywhere within the BAR

2012-06-12T14:15:06+00:00

A .mrom image currently assumes that it is the first image within the expansion ROM BAR, which may not be correct when multiple images are present. Fix by scanning through the BAR until we locate an image matching our build ID. Signed-off-by: Michael Brown