Include config/local/$file in config/$file where it makes sense and
create empty local configs during build if not present.
Modified-by: Michael Brown <mcb30@etherboot.org>
Signed-off-by: Michael Brown <mcb30@etherboot.org>
The function recorder is a crash and hang debugging tool. It logs each
function call into a memory buffer while gPXE runs. After the machine
is reset, and if the contents of memory have not been overwritten, gPXE
will detect the memory buffer and print out its contents.
This allows developers to see a trace of the last functions called
before a crash or hang. The util/fnrec.sh script can be used to convert
the function addresses back into symbol names.
To build with fnrec:
make FNREC=1
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>
Embedded image support uses .incbin in inline assembly to include binary
files. The file dependency is not spotted by ccache when deciding
whether or not to rebuild embedded.o. This results in builds that
contain an outdated version of the embedded image when ccache is used.
Reported-by: Tim 'Shaggy' Bielawa <tbielawa@jabber.org>
Reported-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>
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>
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 <mdc@etherboot.org>
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 <mdc@etherboot.org>
Debug builds for filenames with hyphens such as:
$ make bin/via-rhine.dsk DEBUG=via-rhine
fail with:
[BUILD] bin/via-rhine.dbg1.o
<command-line>: 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 <daniel@drv.nu>
Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Signed-off-by: Marty Connor <mdc@etherboot.org>
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 <daniel@drv.nu>
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).
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.
You can now type e.g.
make bin/rtl8139.rom.deps
to see a list of the source files included in the build of
bin/rtl8139.rom. This is intended to assist with copyright vetting.
Other new debugging targets include
make bin/rtl8139.rom.objs
to see a list of object files linked in to bin/rtl8139.rom, and
make bin/rtl8139.rom.nodeps
to see a list of the source files that are *not* required for the
build of bin/rtl8139.rom.
QEMU will silently round down a disk or ROM image file to the nearest
512 bytes. Fix by always padding .rom, .dsk and .hd images to the
nearest 512-byte boundary.
Originally-fixed-by: Stefan Hajnoczi <stefanha@gmail.com>
The "seq" command is GNU-specific; a BSD userland will not have it.
Use POSIX-conforming "awk" instead.
Reported-by: Joshua Oreman <oremanj@rwcr.net>
Suggested-by: Stefan Hajnoczi <stefanha@gmail.com>
On Mac OS X, it is necessary to build binutils manually; the system
does not provide bfd.h or the libbfd or libiberty libraries.
Originally-fixed-by: Joshua Oreman <oremanj@rwcr.net>
Some builds of the GNU assembler will treat a '/' character as a
comment delimiter. Adding "--divide" will cause it to be treated as a
division operator, as we expect. The "--divide" option is not
available in all gas versions, so apply it only conditionally.
Suggested-by: Joshua Oreman <oremanj@rwcr.net>
bin/embedded.o has a build dependency on bin/.embedded.list, which
gets generated automatically by the Makefile. However, if the
EMBEDDED_IMAGE list is empty, bin/.embedded.list will never be
created, and so bin/embedded.o will be rebuilt every time due to a
missing dependency.
Fix by forcing bin/.embedded.list to be created even if the list is
empty.
Having a default script containing
#!gpxe
autoboot
can cause problems when entering commands to load and start a kernel
manually; the default script image will still be present when the
kernel is started and so will be treated as an initrd. It is possible
to work around this by typing "imgfree" before any other commands, but
this is counter-intuitive.
Fix by allowing the embedded image list to be empty (in which case we
just call autoboot()), and making this the default.
Reported by alkisg@gmail.com.
This patch extends the embedded image feature to allow multiple
embedded images instead of just one.
gPXE now always boots the first embedded image on startup instead of
doing the hardcoded DHCP boot (aka autoboot).
Based heavily upon a patch by Stefan Hajnoczi <stefanha@gmail.com>.
elf2efi converts a suitable ELF executable (containing relocation
information, and with appropriate virtual addresses) into an EFI
executable. It is less tightly coupled with the gPXE build process
and, in particular, does not require the use of a hand-crafted PE
image header in efiprefix.S.
elf2efi correctly handles .bss sections, which significantly reduces
the size of the gPXE EFI executable.
FreeBSD requires the object format to be specified as elf_i386_fbsd,
rather than elf_i386.
Based on a patch from Eygene Ryabinkin <rea-fbsd@codelabs.ru>
We have EFI APIs for CPU I/O, PCI I/O, timers, console I/O, user
access and user memory allocation.
EFI executables are created using the vanilla GNU toolchain, with the
EXE header handcrafted in assembly and relocations generated by a
custom efilink utility.
-Wformat-nonliteral is not enabled by -Wall and needs to be explicitly
specified.
Modified the few files that use nonliteral format strings to work with
this new setting in place.
Inspired by a patch from Carl Karsten <carl@personnelware.com> and an
identical patch from Rorschach <r0rschach@lavabit.com>.
Allow for the build CPU architecture and platform to be specified as part
of the make command goals. For example:
make bin/rtl8139.rom # Standard i386 PC-BIOS build
make bin-efi/rtl8139.efi # i386 EFI build
The generic syntax is "bin[-[arch-]platform]", with the default
architecture being "i386" (regardless of the host architecture) and the
default platform being "pcbios".
Non-path targets such as "srcs" can be specified using e.g.
make bin-efi srcs
Note that this changeset is merely Makefile restructuring to allow the
build architecture and platform to be determined by the make command
goals, and to export these to compiled code via the ARCH and PLATFORM
defines. It doesn't actually introduce any new build platforms.
Some older versions of gcc don't complain about unknown compiler flags
unless you ask them to actually compile; asking them to merely
preprocess won't trigger the error.
Fix the -fno-stack-protector test by making it attempt to compile an
empty file, rather than preprocess an empty file.
?= in a Makefile means that that variable can be overridden by the
environment. This is confusing to users, especially with a generic
name like "ARCH".
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Use "-include" rather than "include" for the generated Makefile
fragments, in order to suppress the long list of warnings that
otherwise appears at the start of a clean build.
Contributed by Edward Waugh <ewaugh@netxen.com>
Revert "Use .SECONDARY instead of .PRECIOUS for bin/%.tmp targets."
This reverts commit de29e5a39c.
.SECONDARY doesn't seem to work properly with the target patterns of
implicit rules. In particular, a "make clean ; make bin/rtl8139.dsk"
will correctly leave the bin/rtl8139.dsk.tmp file present when .PRECIOUS
is used, but not when .SECONDARY is used.
This is slightly irritating since we don't want the
"do-not-delete-if-interrupted" semantics of .PRECIOUS, but it seems to be
the best compromise.
During development it is often handy to change the config.h options from
their defaults, for example to enable debugging features.
To prevent accidental commits of debugging config.h changes, mdc
suggested having a config-local.h that is excluded from source control.
This file acts as a temporary config.h and can override any of the
defaults.
This commit is an attempt to implement the config-local.h feature.
The config.h file now has the following as its last line:
/* @TRYSOURCE config-local.h */
The @TRYSOURCE directive causes config-local.h to be included at that
point in the file. If config-local.h does not exist, no error will be
printed and parsing will continue as normal. Therefore, mkconfig.pl is
"trying" to "source" config-local.h.
ROMs will refuse to build unless pci_vendor_id and pci_device_id are
defined. We probably ought to fix up the Makefile (and the ROM prefix) so
that they're required only for PCI ROMs, but this will do for now.
Piotr Jaroszyński