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/mromprefix.S

536 lines
12 KiB
ArmAsm
Raw Normal View History

[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
/*
* Copyright (C) 2010 Michael Brown <mbrown@fensystems.co.uk>.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
[legal] Update FSF mailing address in GPL licence texts Suggested-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2012-07-20 20:55:45 +02:00
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
* 02110-1301, USA.
[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
*
[legal] Relicense files under GPL2_OR_LATER_OR_UBDL Relicense files for which I am the sole author (as identified by util/relicense.pl). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-03-02 12:54:40 +01:00
* You can also choose to distribute this program under the terms of
* the Unmodified Binary Distribution Licence (as given in the file
* COPYING.UBDL), provided that you have satisfied its requirements.
*
[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
*/
[legal] Relicense files under GPL2_OR_LATER_OR_UBDL Relicense files for which I am the sole author (as identified by util/relicense.pl). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-03-02 12:54:40 +01:00
FILE_LICENCE ( GPL2_OR_LATER_OR_UBDL )
[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
#define PCIBIOS_READ_CONFIG_WORD 0xb109
#define PCIBIOS_READ_CONFIG_DWORD 0xb10a
#define PCIBIOS_WRITE_CONFIG_WORD 0xb10c
#define PCIBIOS_WRITE_CONFIG_DWORD 0xb10d
#define PCI_COMMAND 0x04
#define PCI_COMMAND_MEM 0x02
#define PCI_BAR_0 0x10
#define PCI_BAR_5 0x24
#define PCI_BAR_EXPROM 0x30
[mromprefix] Use PCI length field to obtain length of individual images 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>
2014-08-26 13:29:54 +02:00
#define PCIR_SIGNATURE ( 'P' + ( 'C' << 8 ) + ( 'I' << 16 ) + ( 'R' << 24 ) )
[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
#define ROMPREFIX_EXCLUDE_PAYLOAD 1
[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
#define ROMPREFIX_MORE_IMAGES 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
#define _pcirom_start _mrom_start
#include "pciromprefix.S"
[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
.text
.arch i386
.code16
/* Obtain access to payload by exposing the expansion ROM BAR at the
* address currently used by a suitably large memory BAR on the same
* device. The memory BAR is temporarily disabled. Using a memory
* BAR on the same device means that we don't have to worry about the
* configuration of any intermediate PCI bridges.
*
* Parameters:
* %ds:0000 : Prefix
* %esi : Buffer for copy of image source (or zero if no buffer available)
[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
* %ecx : Expected offset within buffer of first payload block
[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
* Returns:
* %esi : Valid image source address (buffered or unbuffered)
[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
* %ecx : Actual offset within buffer of first payload block
[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
* CF set on error
*/
.section ".text16.early", "awx", @progbits
.globl open_payload
open_payload:
/* Preserve registers */
pushl %eax
pushw %bx
pushl %edx
pushl %edi
pushw %bp
[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
pushw %es
[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
pushw %ds
[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
/* Retrieve bus:dev.fn from .prefix */
[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
movw init_pci_busdevfn, %bx
/* Set up %ds for access to .text16.early */
pushw %cs
popw %ds
[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
/* Set up %es for access to flat address space */
xorw %ax, %ax
movw %ax, %es
/* Store bus:dev.fn to .text16.early */
[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
movw %bx, payload_pci_busdevfn
/* Get expansion ROM BAR current value */
movw $PCI_BAR_EXPROM, %di
call pci_read_bar
movl %eax, rom_bar_orig_value
/* Get expansion ROM BAR size */
call pci_size_mem_bar_low
movl %ecx, rom_bar_size
/* Find a suitable memory BAR to use */
movw $PCI_BAR_0, %di /* %di is PCI BAR register */
xorw %bp, %bp /* %bp is increment */
find_mem_bar:
/* Move to next BAR */
addw %bp, %di
cmpw $PCI_BAR_5, %di
jle 1f
stc
[romprefix] Report failure cause when unable to open payload 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>
2013-04-30 15:31:39 +02:00
movl $0xbabababa, %esi /* Report "No suitable BAR" */
[prefix] Report both %esi and %ecx when opening payload fails Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-26 15:53:46 +02:00
movl rom_bar_size, %ecx
[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
jmp 99f
1: movw $4, %bp
/* Get BAR current value */
call pci_read_bar
/* Skip non-existent BARs */
notl %eax
testl %eax, %eax
notl %eax
jz find_mem_bar
/* Skip I/O BARs */
testb $0x01, %al
jnz find_mem_bar
/* Set increment to 8 for 64-bit BARs */
testb $0x04, %al
jz 1f
movw $8, %bp
1:
/* Skip 64-bit BARs with high dword set; we couldn't use this
* address for the (32-bit) expansion ROM BAR anyway
*/
testl %edx, %edx
jnz find_mem_bar
/* Get low dword of BAR size */
call pci_size_mem_bar_low
/* Skip BARs smaller than the expansion ROM BAR */
cmpl %ecx, rom_bar_size
ja find_mem_bar
/* We have a memory BAR with a 32-bit address that is large
* enough to use. Store BAR number and original value.
*/
movw %di, stolen_bar_register
movl %eax, stolen_bar_orig_value
/* Remove flags from BAR address */
xorb %al, %al
/* Write zero to our stolen BAR. This doesn't technically
* disable it, but it's a pretty safe bet that the PCI bridge
* won't pass through accesses to this region anyway. Note
* that the high dword (if any) must already be zero.
*/
xorl %ecx, %ecx
call pci_write_config_dword
/* Enable expansion ROM BAR at stolen BAR's address */
movl %eax, %ecx
orb $0x1, %cl
movw $PCI_BAR_EXPROM, %di
call pci_write_config_dword
[romprefix] Allow .mrom image to be placed anywhere within the BAR 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 <mcb30@ipxe.org>
2012-06-10 20:01:20 +02:00
/* Locate our ROM image */
[mromprefix] Use PCI length field to obtain length of individual images 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>
2014-08-26 13:29:54 +02:00
1: movl $0xaa55, %ecx /* 55aa signature */
[prefix] Report both %esi and %ecx when opening payload fails Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-26 15:53:46 +02:00
addr32 es cmpw %cx, (%eax)
[mromprefix] Use PCI length field to obtain length of individual images 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>
2014-08-26 13:29:54 +02:00
jne 2f
movl $PCIR_SIGNATURE, %ecx /* PCIR signature */
addr32 es movzwl 0x18(%eax), %edx
addr32 es cmpl %ecx, (%eax,%edx)
jne 2f
addr32 es cmpl $_build_id, build_id(%eax) /* iPXE build ID */
[romprefix] Report failure cause when unable to open payload 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>
2013-04-30 15:31:39 +02:00
je 3f
[mromprefix] Use PCI length field to obtain length of individual images 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>
2014-08-26 13:29:54 +02:00
movl $0x80, %ecx /* Last image */
addr32 es testb %cl, 0x15(%eax,%edx)
jnz 2f
addr32 es movzwl 0x10(%eax,%edx), %ecx /* PCIR image length */
[romprefix] Allow .mrom image to be placed anywhere within the BAR 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 <mcb30@ipxe.org>
2012-06-10 20:01:20 +02:00
shll $9, %ecx
addl %ecx, %eax
jmp 1b
[mromprefix] Use PCI length field to obtain length of individual images 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>
2014-08-26 13:29:54 +02:00
2: /* Failure */
stc
movl %eax, %esi /* Report failure address */
jmp 99f
[romprefix] Report failure cause when unable to open payload 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>
2013-04-30 15:31:39 +02:00
3:
[romprefix] Allow .mrom image to be placed anywhere within the BAR 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 <mcb30@ipxe.org>
2012-06-10 20:01:20 +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
/* Copy payload to buffer, or set buffer address to BAR address */
testl %esi, %esi
jz 1f
[prefix] Use 16-bit protected mode for access to high memory Flat real mode works perfectly on real hardware, but seems to cause problems for some hypervisors. Revert to using 16-bit protected mode (and returning to real mode with 4GB limits, so as not to break PMM BIOSes). Allow the code specific to the .mrom format to continue to assume that flat real mode works, since this format is specific to real hardware. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-01-27 00:04:43 +01:00
/* We have a buffer; copy payload to it. Since .mrom is
* designed specifically for real hardware, we assume that
* flat real mode is working properly. (In the unlikely event
* that this code is run inside a hypervisor that doesn't
* properly support flat real mode, it will die horribly.)
*/
[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
pushl %esi
movl %esi, %edi
movl %eax, %esi
[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
addr32 es movzbl 2(%esi), %ecx
shll $7, %ecx
[mromprefix] Allow for .mrom images larger than 128kB 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>
2014-08-26 13:33:40 +02:00
addr32 es movzwl mpciheader_image_length(%esi,%ecx,4), %edx
[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, %edx
addl %edx, %ecx
[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
addr32 es rep movsl
popl %esi
jmp 2f
1: /* We have no buffer; set %esi to the BAR address */
movl %eax, %esi
2:
[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
/* Locate first payload block (after the dummy ROM header) */
addr32 es movzbl 2(%esi), %ecx
shll $9, %ecx
addl $_pprefix_skip, %ecx
[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
clc
/* Restore registers and return */
99: popw %ds
[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
popw %es
[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
popw %bp
popl %edi
popl %edx
popw %bx
popl %eax
lret
.size open_payload, . - open_payload
.section ".text16.early.data", "aw", @progbits
payload_pci_busdevfn:
.word 0
.size payload_pci_busdevfn, . - payload_pci_busdevfn
.section ".text16.early.data", "aw", @progbits
rom_bar_orig_value:
.long 0
.size rom_bar_orig_value, . - rom_bar_orig_value
.section ".text16.early.data", "aw", @progbits
rom_bar_size:
.long 0
.size rom_bar_size, . - rom_bar_size
.section ".text16.early.data", "aw", @progbits
stolen_bar_register:
.word 0
.size stolen_bar_register, . - stolen_bar_register
.section ".text16.early.data", "aw", @progbits
stolen_bar_orig_value:
.long 0
.size stolen_bar_orig_value, . - stolen_bar_orig_value
/* Restore original BAR values
*
* Parameters:
* none
* Returns:
* none
*/
.section ".text16.early", "awx", @progbits
.globl close_payload
close_payload:
/* Preserve registers */
pushw %bx
pushw %di
pushl %ecx
pushw %ds
/* Set up %ds for access to .text16.early */
pushw %cs
popw %ds
/* Retrieve stored bus:dev.fn */
movw payload_pci_busdevfn, %bx
/* Restore expansion ROM BAR original value */
movw $PCI_BAR_EXPROM, %di
movl rom_bar_orig_value, %ecx
call pci_write_config_dword
/* Restore stolen BAR original value */
movw stolen_bar_register, %di
movl stolen_bar_orig_value, %ecx
call pci_write_config_dword
/* Restore registers and return */
popw %ds
popl %ecx
popw %di
popw %bx
lret
.size close_payload, . - close_payload
/* Get PCI BAR value
*
* Parameters:
* %bx : PCI bus:dev.fn
* %di : PCI BAR register number
* Returns:
* %edx:%eax : PCI BAR value
*/
.section ".text16.early", "awx", @progbits
pci_read_bar:
/* Preserve registers */
pushl %ecx
pushw %di
/* Read low dword value */
call pci_read_config_dword
movl %ecx, %eax
/* Read high dword value, if applicable */
xorl %edx, %edx
andb $0x07, %cl
cmpb $0x04, %cl
jne 1f
addw $4, %di
call pci_read_config_dword
movl %ecx, %edx
1:
/* Restore registers and return */
popw %di
popl %ecx
ret
.size pci_read_bar, . - pci_read_bar
/* Get low dword of PCI memory BAR size
*
* Parameters:
* %bx : PCI bus:dev.fn
* %di : PCI BAR register number
* %eax : Low dword of current PCI BAR value
* Returns:
* %ecx : PCI BAR size
*/
.section ".text16.early", "awx", @progbits
pci_size_mem_bar_low:
/* Preserve registers */
pushw %dx
/* Disable memory accesses */
xorw %dx, %dx
call pci_set_mem_access
/* Write all ones to BAR */
xorl %ecx, %ecx
decl %ecx
call pci_write_config_dword
/* Read back BAR */
call pci_read_config_dword
/* Calculate size */
notl %ecx
orb $0x0f, %cl
incl %ecx
/* Restore original value */
pushl %ecx
movl %eax, %ecx
call pci_write_config_dword
popl %ecx
/* Enable memory accesses */
movw $PCI_COMMAND_MEM, %dx
call pci_set_mem_access
/* Restore registers and return */
popw %dx
ret
.size pci_size_mem_bar_low, . - pci_size_mem_bar_low
/* Read PCI config dword
*
* Parameters:
* %bx : PCI bus:dev.fn
* %di : PCI register number
* Returns:
* %ecx : Dword value
*/
.section ".text16.early", "awx", @progbits
pci_read_config_dword:
/* Preserve registers */
pushl %eax
pushl %ebx
pushl %edx
/* Issue INT 0x1a,b10a */
movw $PCIBIOS_READ_CONFIG_DWORD, %ax
int $0x1a
/* Restore registers and return */
popl %edx
popl %ebx
popl %eax
ret
.size pci_read_config_dword, . - pci_read_config_dword
/* Write PCI config dword
*
* Parameters:
* %bx : PCI bus:dev.fn
* %di : PCI register number
* %ecx : PCI BAR value
* Returns:
* none
*/
.section ".text16.early", "awx", @progbits
pci_write_config_dword:
/* Preserve registers */
pushal
/* Issue INT 0x1a,b10d */
movw $PCIBIOS_WRITE_CONFIG_DWORD, %ax
int $0x1a
/* Restore registers and return */
popal
ret
.size pci_write_config_dword, . - pci_write_config_dword
/* Enable/disable memory access response in PCI command word
*
* Parameters:
* %bx : PCI bus:dev.fn
* %dx : PCI_COMMAND_MEM, or zero
* Returns:
* none
*/
.section ".text16.early", "awx", @progbits
pci_set_mem_access:
/* Preserve registers */
pushal
/* Read current value of command register */
pushw %bx
pushw %dx
movw $PCI_COMMAND, %di
movw $PCIBIOS_READ_CONFIG_WORD, %ax
int $0x1a
popw %dx
popw %bx
/* Set memory access enable as appropriate */
andw $~PCI_COMMAND_MEM, %cx
orw %dx, %cx
/* Write new value of command register */
movw $PCIBIOS_WRITE_CONFIG_WORD, %ax
int $0x1a
/* Restore registers and return */
popal
ret
.size pci_set_mem_access, . - pci_set_mem_access
[romprefix] Avoid using PMM-allocated memory in UNDI loader entry point The UNDI loader entry point is very likely to be called after POST, when there is a high chance that the PMM-allocated image source area and decompression area have been reused by something else. In particular, using an iPXE .iso to test a separate iPXE ROM's UNDI loader entry point in a qemu VM is likely to crash. SeaBIOS allocates PMM blocks from close to the top of memory and so these blocks have a high chance of colliding with the runtime addresses subsequently chosen by the non-ROM iPXE by scanning the INT 15,e820 memory map. The standard romprefix.S has no choice about relying on the PMM-allocated image source area, since it has no other way to retrieve its compressed payload. In mromprefix.S, the image source area functions only as an optional buffer used to avoid repeated reads from the (potentially slow) expansion ROM BAR by the decompression code. We can therefore always set %esi=0 when calling install_prealloc from the UNDI loader entry point, and simply fall back to reading directly from the expansion ROM BAR. We can always set %edi=0 when calling install_prealloc from the UNDI loader entry point. This will behave as though the decompression area PMM allocation failed, and will therefore use INT 15,88 to find a temporary decompression area somewhere close to 64MB. This is by no means guaranteed to be safe from collisions, but it's probably safer on balance than the PMM-allocated address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-12-05 15:11:00 +01:00
/* Update image source address for UNDI loader
*
* Parameters:
* %esi : Image source address
* Returns:
* %esi : Image source address
*/
.section ".prefix", "ax", @progbits
.globl undiloader_source
undiloader_source:
/* Always use expansion ROM BAR directly when installing via
* the UNDI loader entry point, since the PMM-allocated block
* may collide with whatever is calling the UNDI loader entry
* point.
*/
xorl %esi, %esi
ret
[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
/* Payload prefix
[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
* We include a dummy ROM header to cover the "hidden" portion of the
* overall ROM image.
[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
.globl _payload_align
.equ _payload_align, 512
.section ".pprefix", "ax", @progbits
.org 0x00
mromheader:
.word 0xaa55 /* BIOS extension signature */
[mromprefix] Report a dummy size at offset 0x02 of .mrom payload 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>
2015-06-25 09:32:25 +02:00
.byte 0x01 /* Dummy size (BIOS bug workaround) */
[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
.org 0x18
.word mpciheader
.org 0x1a
.word 0
.size mromheader, . - mromheader
[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] 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
mpciheader:
.ascii "PCIR" /* Signature */
.word pci_vendor_id /* Vendor identification */
.word pci_device_id /* Device identification */
.word 0x0000 /* Device list pointer */
.word mpciheader_len /* PCI data structure length */
.byte 0x03 /* PCI data structure revision */
.byte 0x02, 0x00, 0x00 /* Class code */
mpciheader_image_length:
.word 0 /* Image length */
.word 0x0001 /* Revision level */
.byte 0xff /* Code type */
.byte 0x80 /* Last image indicator */
mpciheader_runtime_length:
.word 0 /* Maximum run-time image length */
.word 0x0000 /* Configuration utility code header */
.word 0x0000 /* DMTF CLP entry point */
.equ mpciheader_len, . - mpciheader
.size mpciheader, . - mpciheader
.section ".zinfo.fixup", "a", @progbits /* Compressor fixups */
.ascii "APPW"
.long mpciheader_image_length
.long 512
[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
.long 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
.ascii "APPW"
.long mpciheader_runtime_length
.long 512
.long 0
.previous
/* Fix up additional image source 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
.section ".zinfo.fixup", "a", @progbits /* Compressor fixups */
[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
.ascii "ADPW"
.long extra_size
.long 512
[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
.long 0
.previous