summaryrefslogtreecommitdiffstats
path: root/src/Makefile.housekeeping
diff options
context:
space:
mode:
authorJoshua Oreman2009-10-18 22:12:51 +0200
committerMarty Connor2010-01-20 23:46:48 +0100
commit06a8398422efb613b7ee4f9d8f1abcc813bb3f3b (patch)
tree81dc06685687ee84b6b168e1218852e3f6c175bf /src/Makefile.housekeeping
parent[config] Make PXE stack a compile-time option (diff)
downloadipxe-06a8398422efb613b7ee4f9d8f1abcc813bb3f3b.tar.gz
ipxe-06a8398422efb613b7ee4f9d8f1abcc813bb3f3b.tar.xz
ipxe-06a8398422efb613b7ee4f9d8f1abcc813bb3f3b.zip
[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses
The standard option ROM format provides a header indicating the size of the entire ROM, which the BIOS will reserve space for, load, and call as necessary. However, this space is strictly limited to 128k for all ROMs. gPXE ameliorates this somewhat by reserving space for itself in high memory and relocating the majority of its code there, but on systems prior to PCI3 enough space must still be present to load the ROM in the first place. Even on PCI3 systems, the BIOS often limits the size of ROM it will load to a bit over 64kB. These space problems can be solved by providing an artificially small size in the ROM header: just enough to let the prefix code (at the beginning of the ROM image) be loaded by the BIOS. To the BIOS, the gPXE ROM will appear to be only a few kilobytes; it can then load the rest of itself by accessing the ROM directly using the PCI interface reserved for that task. There are a few problems with this approach. First, gPXE needs to find an unmapped region in memory to map the ROM so it can read from it; this is done using the crude but effective approach of scanning high memory (over 0xF0000000) for a sufficiently large region of all-ones (0xFF) reads. (In x86 architecture, all-ones is returned for accesses to memory regions that no mapped device can satisfy.) This is not provably valid in all situations, but has worked well in practice. More importantly, this type of ROM access can only work if the PCI ROM BAR exists at all. NICs on physical add-in PCI cards generally must have the BAR in order for the BIOS to be able to load their ROM, but ISA cards and LAN-on-Motherboard cards will both fail to load gPXE using this scheme. Due to these uncertainties, it is recommended that .xrom only be used when a regular .rom image is infeasible due to crowded option ROM space. However, when it works it could allow loading gPXE images as large as a flash chip one could find - 128kB or even higher. Signed-off-by: Marty Connor <mdc@etherboot.org>
Diffstat (limited to 'src/Makefile.housekeeping')
-rw-r--r--src/Makefile.housekeeping2
1 files changed, 2 insertions, 0 deletions
diff --git a/src/Makefile.housekeeping b/src/Makefile.housekeeping
index 1642374c..1f5e115f 100644
--- a/src/Makefile.housekeeping
+++ b/src/Makefile.housekeeping
@@ -831,6 +831,8 @@ endif # defined(BIN)
FINALISE_rom = $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
-i$(IDENT) -s 0 $@
FINALISE_hrom = $(FINALISE_rom)
+FINALISE_xrom = $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
+ -i$(IDENT) -n -s 0 $@
# Some ROMs require specific flags to be passed to makerom.pl
#