openslx-ng/ipxe.git/src/util, branch v1.0.0

[prefix] Add .xrom prefix for a ROM that loads itself by PCI accesses

2010-01-20T22:46:48+00:00

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

[util] Add diffsize.pl utility for generating diffs of object sizes

2010-01-14T16:30:30+00:00

This is useful when comparing size optimizations. Signed-off-by: Marty Connor

[zbin] Fix 64-bit compilation warnings for util/zbin.c

2009-10-20T20:57:54+00:00

Recent gcc versions generate more warnings when compiling util/zbin.c on a 64-bit system: util/zbin.c: In function `read_file': util/zbin.c:85: warning: format `%d' expects type `int', but argument 3 has type `size_t' util/zbin.c:91: warning: format `%d' expects type `int', but argument 3 has type `size_t' util/zbin.c: In function `read_zinfo_file': util/zbin.c:119: warning: format `%d' expects type `int', but argument 4 has type `size_t' util/zbin.c: In function `alloc_output_file': util/zbin.c:134: warning: format `%d' expects type `int', but argument 3 has type `size_t' util/zbin.c: In function `process_zinfo_add': util/zbin.c:244: warning: format `%d' expects type `int', but argument 3 has type `size_t' util/zbin.c:266: warning: format `%d' expects type `int', but argument 7 has type `size_t' util/zbin.c:286: warning: format `%#x' expects type `unsigned int', but argument 7 has type `size_t' util/zbin.c: In function `write_output_file': util/zbin.c:348: warning: format `%d' expects type `int', but argument 3 has type `size_t' This patch eliminates these warnings. Signed-off-by: Marty Connor

[util] Change gensdsk file permissions to include execute

2009-10-20T14:07:50+00:00

src/util/gensdsk is a shell script and should have execute permission. Reported-by: sobtwmxt sobtwmxt@sdf.lonestar.org

[zbin] Fix compilation warnings for util/zbin.c

2009-10-17T17:56:03+00:00

Recent gcc versions generate warnings when compiling util/zbin.c ( tested with gcc-4.3.3 ): util/zbin.c: In function ‘process_zinfo_pack’: util/zbin.c:200: warning: format ‘%#zx’ expects type ‘size_t’, but argument 6 has type ‘long unsigned int’ util/zbin.c: In function ‘process_zinfo_add’: util/zbin.c:257: warning: format ‘%#lx’ expects type ‘long unsigned int’, but argument 4 has type ‘int’ util/zbin.c:266: warning: format ‘%#lx’ expects type ‘long unsigned int’, but argument 4 has type ‘int’ util/zbin.c:266: warning: format ‘%d’ expects type ‘int’, but argument 8 has type ‘long unsigned int’ util/zbin.c:286: warning: format ‘%#lx’ expects type ‘long unsigned int’, but argument 6 has type ‘int’ util/zbin.c:286: warning: format ‘%#lx’ expects type ‘long unsigned int’, but argument 7 has type ‘size_t’ This patch eliminates these warnings. Tested with gcc-4.3.3 on Ubuntu 9.04 and gcc-4.1.2 on Debian Etch. Signed-off-by: Marty Connor

[util] Make mtools check detect new versions

2009-10-15T18:54:30+00:00

The mtools version check does not handle GNU mtools 4.0.10. This commit makes the pattern more general so it matches older mtools as well as the newer "mtools (GNU mtools) 4.0.10" string. Signed-off-by: Stefan Hajnoczi Signed-off-by: Marty Connor

[modrom] Avoid clobbering near jump with checksum

2009-10-15T18:47:54+00:00

A jump instruction starts at the third byte of an option ROM image, and it is required that the bytes in the whole image add up to zero. To achieve this, a checksum byte is usually placed after the jump. The jump can be either a short jump (2 bytes, EB xx) or a near jump (3 bytes, E9 xx xx). gPXE's romprefix.S uses a near jump, but modrom.pl assumed a short jump, and clobbered the high byte of the offset. This caused modrom-modified gPXE ROM images to crash the system during POST. Fix by making modrom.pl place the checksum at byte 6, like makerom.pl does. Signed-off-by: Marty Connor

[zbin] Change fixup semantics to support ROMs over 128k uncompressed

2009-08-11T11:59:26+00:00

The option ROM header contains a one-byte field indicating the number of 512-byte sectors in the ROM image. Currently it is linked to contain the number of uncompressed sectors, with an instruction to the compressor to correct it. This causes link failure when the uncompressed size of the ROM image is over 128k. Fix by replacing the SUBx compressor fixup with an ADDx fixup that adds the total compressed output length, scaled as requested, to an addend stored in the field where the final length value will be placed. This is similar to the behavior of ELF relocations, and ensures that an overflow error will not be generated unless the compressed size is still too large for the field. This also allows us to do away with the _filesz_pgh and _filesz_sect calculations exported by the linker script. Output tested bitwise identical to the old SUBx mechanism on hd, dsk, lkrn, and rom prefixes, on both 32-bit and 64-bit processors. Modified-by: Michael Brown Signed-off-by: Michael Brown

[geniso] Emit proper error message for incorrect location of ISOLINUX_BIN

2009-08-08T23:05:49+00:00

If isolinux.bin is not installed in the expected location the error message shown is slightly misleading. Signed-off-by: Vibi Sreenivasan Signed-off-by: Michael Brown

[legal] Add the MIT and ISC licenses to licence.pl

2009-08-02T22:30:38+00:00

The MIT and ISC licenses are legally equivalent to the bsd2 license, but with slightly different verbiage. Signed-off-by: H. Peter Anvin Signed-off-by: Michael Brown