openslx-ng/ipxe.git/src/Makefile.housekeeping, 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

[makefile] Allow .sizes target to work with funny-named objects

2010-01-14T16:28:52+00:00

The bin/xxx.sizes targets examine the list of obj_ symbols in bin/xxx.tmp to determine which objects to measure the size of. These symbols have been normalized to C identifiers, so the result is an error message from `size' when examining a target that includes objects that were originally named with hyphens. Fix by turning obj_foo_bar into $(wildcard bin/foo?bar.o) instead of bin/foo_bar.o. Signed-off-by: Marty Connor

[prefix] Add .hrom prefix for a ROM that loads high under PCI3 without PMM

2010-01-14T15:56:08+00:00

gPXE currently takes advantage of the feature of PCI3.0 that allows option ROMs to relocate the bulk of their code to high memory and so take up only a small amount of space in the option ROM area. Currently, the relocation can only take place if the BIOS's implementation of PMM can be made to return blocks aligned to an even megabyte, because of the A20 gate. AMI BIOSes, in particular, will not return allocations that gPXE can use. Ameliorate the situation somewhat by adding a prefix, .hrom, that works identically to .rom except in the case that PMM allocation fails. Where .rom would give up and place itself entirely in option ROM space, .hrom moves to a block (assumed free) at HIGHMEM_LOADPOINT = 4MB. This allows for the use of larger gPXE ROMs than would otherwise be possible. Because there is no way to check that the area at HIGHMEM_LOADPOINT is really free, other devices using that memory during the boot process will cause failure for gPXE, the other device, or both. In practice such conflicts will likely not occur, but this prefix should still be considered EXPERIMENTAL. Signed-off-by: Marty Connor

[build] Fix DEBUG builds for filenames with hyphens

2009-10-15T18:07:20+00:00

Debug builds for filenames with hyphens such as: $ make bin/via-rhine.dsk DEBUG=via-rhine fail with: [BUILD] bin/via-rhine.dbg1.o : error: missing whitespace after the macro name make: *** [bin/via-rhine.dbg1.o] Error 1 This is because "-" is not a legal character in C identifiers, and gcc rejects "-Ddebug_via-rhine=1" as an argument. Signed-off-by: Daniel Verkamp Signed-off-by: Joshua Oreman Signed-off-by: Marty Connor

[doc] Expand scope of doxygen-generated documentation

2009-08-11T14:14:36+00:00

[build] Add -fno-dwarf2-cfi-asm to CFLAGS if supported by the gcc in use

2009-05-27T01:30:46+00:00

gcc 4.4 defaults to using .cfi assembler directives for debugging information, which causes unneeded .eh_frame sections to be generated. These sections are already stripped out by our linker script, so don't affect the final build, but do distort the output of "size" when run on individual .o files; the .eh_frame size is included within the size reported for .text. This makes it difficult to accurately judge the effects of source code changes upon object code size. Fix by adding -fno-dwarf2-cfi-asm to CFLAGS if we detect that this option is supported by the gcc that we are compiling with. Tested-by: Daniel Verkamp

[legal] Add licence.pl and %.licence make target

2009-05-18T07:29:24+00:00

It is now possible to run e.g. make bin/rtl8139.dsk.licence in order to see a licensing assessment for any given gPXE build. The assessment will either produce a single overall licence for the build (based on combining all the licences used within the source files for that build), or will exit with an error stating why a licence assessment is not possible (for example, if there are files involved that do not yet contain an explicit FILE_LICENCE() declaration).

[build] Automatically sort the list of constituent object sizes

2009-04-18T15:20:03+00:00

[build] Provide mechanism for listing constituent object sizes

2009-04-18T14:56:29+00:00

You can now type e.g. make bin/rtl8139.rom.sizes in order to see the (uncompressed) sizes of all of the object files linked in to bin/rtl8139.rom. This should make it easier to identify relevant code bloat.

[build] Kill off the multiple-object-per-source-file mechanism

2009-04-17T12:43:35+00:00

Now that there are no remaining multiple-object source files, kill off the mechanism in order to simplify the Makefile.