aboutsummaryrefslogtreecommitdiffstats
path: root/src/Makefile.housekeeping
Commit message (Collapse)AuthorAgeFilesLines
* [build] Use separate code segment if supported by linkersepcodeMichael Brown2023-07-031-0/+7
| | | | | | | | | | | | | | | Some versions of ld will complain that the automatically created (and unused by our build process) ELF program headers include a "LOAD segment with RWX permissions". Silence this warning by adding "-z separate-code" to the linker options, where supported. For BIOS builds, where the prefix will generally require writable access to its own (tiny) code segment, simply inhibit the warning completely via "--no-warn-rwx-segments". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Simplify platform-specific client architecture definitionsMichael Brown2023-01-221-1/+0
| | | | | | | | | | | | | | | | Move the platform-specific DHCP client architecture definitions to header files of the form <ipxe/$(PLATFORM)/dhcparch.h>. This simplifies the directory structure and allows the otherwise unused arch/$(ARCH)/include/$(PLATFORM) to be removed from the include directory search path, which avoids the confusing situation in which a header file may potentially be accessed through more than one path. For Linux userspace binaries on any architecture, use the EFI values for that architecture by delegating to the EFI header file. This avoids the need to explicitly select values for Linux userspace binaries for each architecture. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Move -Ulinux to common MakefileMichael Brown2023-01-221-0/+4
| | | | | | | The requirement to undo the implicit "-Dlinux" is not specific to the x86 architecture. Move this out of the x86-specific Makefile. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Disable dangling pointer checking for GCCgcc12Michael Brown2022-12-141-2/+4
| | | | | | | | | | | | The dangling pointer warning introduced in GCC 12 reports false positives that result in build failures. In particular, storing the address of a local code label used to record the current state of a state machine (as done in crypto/deflate.c) is reported as an error. There seems to be no way to mark the pointer type as being permitted to hold such a value, so unconditionally disable the warning. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Disable array bounds checking for GCCMichael Brown2022-12-141-2/+2
| | | | | | | | | | | | The array bounds checker on GCC 12 and newer reports a very large number of false positives that result in build failures. In particular, accesses through pointers to zero-length arrays (such as those used by the linker table mechanism in include/ipxe/tables.h) are reported as errors, contrary to the GCC documentation. Work around this GCC issue by unconditionally disabling the warning. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Avoid invoking genkeymap.py via PerlMichael Brown2022-02-151-1/+1
| | | | | | | The build process currently invokes the Python genkeymap.py script via the Perl executable. Strangely, this appears to work. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Ensure version.%.o is always rebuilt as expectedMichael Brown2022-01-131-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Fix building on broken versions of GNU binutilsMichael Brown2021-06-171-1/+2
| | | | | | | | | | | Some versions of GNU objcopy (observed with binutils 2.23.52.0.1 on CentOS 7.0.1406) document the -D/--enable-deterministic-archives option but fail to recognise the short form of the option. Work around this problem by using the long form of the option. Reported-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Ensure build ID is deterministicBernhard M. Wiedemann2021-06-141-1/+1
| | | | | | | | | | | | Commit 040cdd0 ("[linux] Add a prefix to all symbols to avoid future name collisions") unintentionally reintroduced an element of non-determinism into the build ID, by omitting the -D option when manipulating the blib.a archive. Fix by adding the -D option to restore determinism. Reworded-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Add a prefix to all symbols to avoid future name collisionsMichael Brown2021-02-271-2/+5
| | | | | | | Allow for the possibility of linking to platform libraries for the Linux userspace build by adding an iPXE-specific symbol prefix. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Compress EFI ROM imagesMichael Brown2021-02-191-1/+1
| | | | | | | | | Use the reference implementation of the EFI compression algorithm (taken from the EDK2 codebase, with minor bugfixes to allow compilation with -Werror) to compress EFI ROM images. Inspired-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Remove support for building with the Intel C compilerMichael Brown2021-02-121-52/+5
| | | | | | | | | | | | | | | | | | | Support for building with the Intel C compiler (icc) was added in 2009 in the expectation that UEFI support would eventually involve compiling iPXE to EFI Byte Code. EFI Byte Code has never found any widespread use: no widely available compilers can emit it, Microsoft refuses to sign EFI Byte Code binaries for UEFI Secure Boot, and I have personally never encountered any examples of EFI Byte Code in the wild. The support for using the Intel C compiler has not been tested in over a decade, and would almost certainly require modification to work with current releases of the compiler. Simplify the build process by removing this old legacy code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Work around distros that use -fcf-protection=full by defaultMichael Brown2021-02-041-0/+10
| | | | | | | | | | | | | | | | | | | | | | Some patched versions of gcc (observed with gcc 9.3.0 on Ubuntu 20.04) enable -fcf-protection=full by default. This breaks code that is not explicitly written to expect the use of this flag. The breakage occurs only at runtime if the affected code (such as setjmp()) happens to execute, and is therefore a particularly pernicious class of bug to be introduced into working code by a broken compiler. Work around these broken patched versions of gcc by detecting support for -fcf-protection and explicitly setting -fcf-protection=none if found. If any Ubuntu maintainers are listening: PLEASE STOP DOING THIS. It's extremely unhelpful to have to keep working around breakages that you introduce by modifying the compiler's default behaviour. Do what Red Hat does instead: set your preferred CFLAGS within the package build system rather than by patching the compiler to behave in violation of its own documentation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Work around -fPIE patched versions of gcc on all architecturesMichael Brown2021-02-041-0/+27
| | | | | | | | | | | | | | | | | | | | | | | Several distributions include versions of gcc that are patched to create position-independent executables by default. These have caused multiple problems over the years: see e.g. commits fe61f6d ("[build] Fix compilation when gcc is patched to default to -fPIE -Wl,-pie"), 5de1346 ("[build] Apply the "-fno-PIE -nopie" workaround only to i386 builds"), 7c395b0 ("[build] Use -no-pie on newer versions of gcc"), and decee20 ("[build] Disable position-independent code for ARM64 EFI builds"). The build system currently attempts to work around these mildly broken patched versions of gcc for the i386 and arm64 architectures. This misses the relatively obscure bin-x86_64-pcbios build platform, which turns out to also require the same workaround. Attempt to preempt the next such required workaround by moving the existing i386 version to apply to all platforms and all architectures, unless -fpie has been requested explicitly by another Makefile (as is done by arch/x86_64/Makefile.efi). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Avoid spurious "make clean" when building for the first timeMichael Brown2021-02-041-29/+32
| | | | | | | | | | | | The function trace recorder build logic defaults to making "clean" a dependency of the first build in a clean checkout. This is redundant and causes problems if the build process spins up multiple make invocations to handle multiple build architectures. Fix by replacing with logic based on the known-working patterns used for the ASSERT and PROFILE build parameters. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Avoid using awk to format build ID as hexadecimalMichael Brown2021-01-311-1/+1
| | | | | | | | | | | | | | | | | | The version of awk used in FreeBSD seems to be incapable of formatting unsigned 32-bit integers above 0x80000000 and will silently render any such value as 0x80000000. For example: echo 3735928559 | awk '{printf "0x%08x", $1}' will produce 0x80000000 instead of the correct 0xdeadbeef. This results in an approximately 50% chance of a build ID collision when building on FreeBSD. Work around this problem by passing the decimal value directly in the ld --defsym argument value. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Avoid using sha1sum when calculating build IDMichael Brown2021-01-311-1/+1
| | | | | | | The sha1sum command may not be available on all systems. Use the POSIX-confirming cksum instead. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Check for broken elftoolchain version of objcopyMichael Brown2021-01-301-0/+7
| | | | | | | | | | | | | | | | The elftoolchain version of objcopy (as used in FreeBSD) seems to be unusable for generating a raw binary file, since it will apparently ignore the load memory addresses specified for each section in the input file. The binutils version of objcopy may be used on FreeBSD by specifying OBJCOPY=/usr/local/bin/objcopy Detect an attempt to use the unusable elftoolchain version of objcopy and report it as an error. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Replace random build ID with a deterministic oneManuel Mendez2021-01-301-1/+7
| | | | | | | | | | | Calculate the build ID as a checksum over the input files. Since the input files include $(BIN)/version.%.o which itself includes the build target name (from which TGT_LD_FLAGS is calculated), this should be sufficient to meet the requirement that the build ID be unique for each $(BIN)/%.tmp even within the same build run. Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use $(shell ...) to invoke BUILD_ID_CMDManuel Mendez2021-01-301-1/+1
| | | | | | | | | | When using $(shell), make will first invoke BUILD_ID_CMD and then have the value defined when calling $(LD). This means we get to see the _build_id when building with make V=1. Previously the build_id was figured out as a subshell command run during the recipe execution without being able to see the build_id itself. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use SOURCE_DATE_EPOCH if it existsManuel Mendez2021-01-301-0/+12
| | | | | | | | See https://reproducible-builds.org/docs/source-date-epoch/ for rationale. Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use recursive deletion for "make clean"Michael Brown2021-01-301-1/+1
| | | | | | | Directories may be left behind by failed filesystem image builds, and will not currently be successfully removed by a "make clean". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Avoid shell brace expansion in "make clean"Michael Brown2021-01-301-3/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Drop timestamps from .a fileBernhard M. Wiedemann2021-01-291-2/+2
| | | | | | | Make the contents of $(BLIB) deterministic to allow it to be subsequently used for calculating a build ID. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Provide a testable platform macro alongside -DPLATFORMMichael Brown2020-10-161-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Fix a GNUism that FreeBSD's sed(1) cannot deal withTobias Kortkamp2020-07-211-1/+1
| | | | | | | | | | | | At the moment '\s*' is silently interpreted as just 's*', but in the future it will be an error: sed: 1: "s/\.o\s*:/_DEPS +=/": RE error: trailing backslash (\) cf. https://bugs.freebsd.org/229925 Signed-off-by: Tobias Kortkamp <t@tobik.me> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Be explicit about -fcommon compiler directiveBruce Rogers2020-06-271-0/+1
| | | | | | | | | gcc10 switched default behavior from -fcommon to -fno-common. Since "__shared" relies on the legacy behavior, explicitly specify it. Signed-off-by: Bruce Rogers <brogers@suse.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Enable stack protection where possibleMichael Brown2020-06-241-11/+7
| | | | | | | | | | | | | | | | | | | Enable -fstack-protector for EFI builds, where binary size is less critical than for BIOS builds. The stack cookie must be constructed immediately on entry, which prohibits the use of any viable entropy source. Construct a cookie by XORing together various mildly random quantities to produce a value that will at least not be identical on each run. On detecting a stack corruption, attempt to call Exit() with an appropriate error. If that fails, then lock up the machine since there is no other safe action that can be taken. The old conditional check for support of -fno-stack-protector is omitted since this flag dates back to GCC 4.1. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Move predefined all-drivers build shortcut to MakefileMichael Brown2019-08-021-5/+0
| | | | | | | | | | | The (very approximate) split between Makefile.housekeeping and Makefile is that the former provides mechanism and the latter provides policy. Provide a section within Makefile as a home for predefined build shortcuts such as the existing all-drivers build. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Do not apply WORKAROUND_CFLAGS for host compilerMichael Brown2019-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | The WORKAROUND_CFLAGS list is constructed based on running tests on the target compiler, and the results may not be valid for the host compiler. The only relevant workaround required for the host compiler is -Wno-stringop-truncation, which is needed to avoid a spurious compiler warning for a totally correct usage of strncpy() in util/elf2efi.c. Duplicating the workaround tests for the host compiler is messy, as is conditionally applying __attribute__((nonstring)). Fix instead by disapplying WORKAROUND_CFLAGS for the host compiler, and using memcpy() with an explicitly calculated length instead of strncpy() in util/elf2efi.c. Reported-by: Ignat Korchagin <ignat@cloudflare.com> Reported-by: Christopher Clark <christopher.w.clark@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Workaround compilation error with gcc 9.1Valentine Barshak2019-07-221-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Compiling with gcc 9.1 generates lots of "taking address of packed member of ... may result in an unaligned pointer value" warnings. Some of these warnings are genuine, and indicate correctly that parts of iPXE currently require the CPU (or runtime environment) to support unaligned accesses. For example: the TCP/IP receive data path will attempt to access 32-bit fields that may not be aligned to a 32-bit boundary. Other warnings are either spurious (such as when the pointer is to a variable-length byte array, which can have no alignment requirement anyway) or unhelpful (such as when the pointer is used solely to provide a debug colour value for the DBGC() macro). There appears to be no easy way to silence the spurious warnings. Since the ability to perform unaligned accesses is already a requirement for iPXE, work around the problem by silencing this class of warnings. Signed-off-by: Valentine Barshak <gvaxon@gmail.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use positive-form tests when checking for supported warningsMichael Brown2018-07-081-2/+2
| | | | | | | | | | | | Some versions of gcc seem to silently accept an attempt to disable an unrecognised warning (e.g. via -Wno-stringop-truncation) but will then report the unrecognised warning if any other error occurs during the build, resulting in a potentially misleading error message. Avoid this potential confusion by using the positive-form tests in order to determine the workaround CFLAGS. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Disable gcc stringop-truncation warningsBruce Rogers2018-07-071-1/+9
| | | | | | | | | | | | | | | | | | | The gcc 8 compiler introduces a warning for certain string manipulation functions, flagging usages which _may_ not be intended. An audit of the iPXE sources indicates all usages of strncat and strncpy are as intended, so the warnings currently issued are not helpful, especially if warnings are considered errors. Fix by detecting gcc's support for -Wno-stringop-truncation and, if detected, using that option to avoid the warning. Signed-off-by: Bruce Rogers <brogers@suse.com> Modified-by: Michael Brown <mcb30@ipxe.org> Also-fixed-by: Christian Hesse <list@eworm.de> Also-fixed-by: Roman Kagan <rkagan@virtuozzo.com> Also-fixed-by: Bernhard M. Wiedemann <bwiedemann@suse.de> Also-fixed-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Exclude selected directories from Secure Boot buildsMichael Brown2017-09-181-10/+23
| | | | | | | | | | | | | | | | | | When submitting binaries for UEFI Secure Boot signing, certain known-dubious subsystems (such as 802.11 and NFS) must be excluded from the build. Mark the directories containing these subsystems as insecure, and allow the build target to include an explicit "security flag" (a literal "-sb" appended to the build platform) to exclude these source directories from the build process. For example: make bin-x86_64-efi-sb/ipxe.efi will build iPXE with all code from the 802.11 and NFS subsystems excluded from the build. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [profile] Allow profiling to be globally enabled or disabledMichael Brown2016-07-051-0/+27
| | | | | | | | | | As with assertions, profiling is enabled for objects built with any debug level (including an explicit debug level of zero). Allow profiling to be globally enabled or disabled by adding PROFILE=1 or PROFILE=0 respectively to the build command line. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Allow assertions to be globally enabled or disabledMichael Brown2016-07-051-0/+27
| | | | | | | | | | | | | | | | | | | | | | | Assertions are enabled for objects built with any debug level (including an explicit debug level of zero). It is sometimes useful to be able to enable assertions across all objects; this currently requires manually hacking include/assert.h. Allow assertions to be globally enabled by adding ASSERT=1 to the build command line. For example: make bin/8086100e.mrom ASSERT=1 Similarly, allow assertions to be globally disabled by adding ASSERT=0 to the build command line. If no ASSERT=... is specified on the build command line, then only objects mentioned in DEBUG=... will have assertions enabled (as is currently the case). Note than globally enabling assertions imposes a relatively heavy runtime penalty, primarily due to the various sanity checks performed by list_add(), list_for_each_entry(), etc. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [debug] Allow debug messages to be initially disabled at runtimeMichael Brown2016-07-051-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the DEBUG=... syntax to allow debug messages to be compiled in but disabled by default. For example: make bin/undionly.kpxe DEBUG=netdevice:3:1 would compile in the messages as for DEBUG=netdevice:3, but would set the debug level mask so that only the DEBUG=netdevice:1 messages would be displayed. This allows for external code to selectively enable the additional debug messages at runtime, without being overwhelmed by unwanted initial noise. For example, a developer of a new protocol may want to temporarily enable tracing of all packets received: this can be done by building with DEBUG=netdevice:3:1 and using // temporarily enable per-packet messages DBG_ENABLE_OBJECT ( netdevice, DBGLVL_EXTRA ); ... // disable per-packet messages DBG_DISABLE_OBJECT ( netdevice, DBGLVL_EXTRA ); Note that unlike the usual DBG_ENABLE() and DBG_DISABLE() macros, DBG_ENABLE_OBJECT() and DBG_DISABLE_OBJECT() will not be removed via dead code elimination if debugging is disabled in the specified object. In particular, this means that using either of these macros will always result in a symbol reference to the specified object. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Remove unnecessary dependency on zlibMichael Brown2016-05-021-6/+2
| | | | | | | | | | The dependency on zlib seems to have been introduced in commit 3dd7ce1 ("[efi] Allow building with non-system libbfd") as an indirect requirement of either libbfd or libiberty when building on Mac OS X. Since we no longer use either of these libraries, remove the unnecessary link against zlib. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Eliminate use of libbfdMichael Brown2016-05-021-6/+4
| | | | | | | | | Parse the intermediate ELF file directly instead of using libbfd, in order to allow for cross-compiled ELF objects. As a side bonus, this eliminates libbfd as a build requirement. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow assembler section type character to vary by architectureMichael Brown2016-03-131-1/+6
| | | | | | | | | | | | | | | On some architectures (such as ARM) the "@" character is used as a comment delimiter. A section type argument such as "@progbits" therefore becomes "%progbits". This is further complicated by the fact that the "%" character has special meaning for inline assembly when input or output operands are used, in which cases "@progbits" becomes "%%progbits". Allow the section type character(s) to be defined via Makefile variables. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [debug] Allow debug colourisation to be disabledMichael Brown2016-01-121-2/+2
| | | | | | | | | | Some BIOS console redirection capabilities do not work well with the colourised debug messages used by iPXE. We already allow the range of colours to be controlled via the DBGCOL=... build parameter. Extend this syntax to allow DBGCOL=0 to be used to mean "disable colours". Requested-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow extra objects to be included in an all-drivers buildMichael Brown2015-12-171-5/+5
| | | | | | | | | | | | | | | | | | | | | | The build system allows for additional drivers (or other objects) to be specified using build targets such as make bin/intel--realtek.usb make bin/8086100e--8086100f.mrom This currently fails if the base target is the "bin/ipxe.*" all-drivers target, e.g. make bin/ipxe--acm.usb Fix the build target parsing logic to allow additional drivers (or other objects) to be included on top of the base all-drivers target. This can be used to include USB network card drivers, which are not yet included by default in the all-drivers build. Reported-by: Andrew Sloma <asloma@lenovo.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Generalise CONSOLE_VESAFB to CONSOLE_FRAMEBUFFERMichael Brown2015-10-161-1/+1
| | | | | | | | | | | The name "vesafb" is intrinsically specific to a BIOS environment. Generalise the build configuration option CONSOLE_VESAFB to CONSOLE_FRAMEBUFFER, in preparation for adding EFI framebuffer support. Existing configurations using CONSOLE_VESAFB will continue to work. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Remove dependency on libibertyMichael Brown2015-09-141-1/+1
| | | | | | | | | | | | | | | | | Commit 7d36a1b ("[build] Explicitly link efilink against -liberty") introduced a dependency on libiberty to cope with old versions of libbfd. This commit dates from 2008 and seems to apply only to what are now extremely old versions of libbfd (prior to binutils 2.12). There are systems (such as current Debian) which do not include libiberty within the binutils packages. On such systems, our build dependency on libiberty represents a pointless hurdle. Remove the explicit dependency on libiberty, hoping that there are no modern systems where this will cause a problem. Suggested-by: Ben Hildred <42656e@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Fix .ids.o creation for drivers not in the all-drivers buildMichael Brown2015-06-011-2/+1
| | | | | | | | | | | | | | Commit dc19e63 ("[build] Construct all-drivers list based on driver class") accidentally excluded the USB bus drivers from the list of files parsed in order to create PCI 3.0 device ID lists. Fix by returning $(DRIVERS) to its previous definition as a list of all driver files, and use only $(DRIVERS_ipxe) to contain the filtered list containing only those drivers which we want to include in the "all-drivers" build. Reported-by: Mary-Ann Johnson <MaryAnn.Johnson@displaylink.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Construct all-drivers list based on driver classMichael Brown2015-04-221-1/+8
| | | | | | | | | | | | The USB bus drivers (ehci.c and xhci.c) have PCI device ID tables and hence PCI_ROM() lines, but should probably not be included in the all-drivers build on this basis, since they do nothing useful unless a USB network driver is also present. Fix by constructing the all-drivers list based on the driver class (i.e. the portion of the source path immediately after "drivers/"). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use a single call to parserom.pl to speed up buildingMichael Brown2015-04-181-21/+60
| | | | | | Inspired-by: Robin Smidsrød <robin@smidsrod.no> Tested-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow building PCI ROMs with device ID listsMichael Brown2015-04-151-4/+25
| | | | | | | | | | | | | | PCI v3.0 supports a "device list" which allows the ROM to claim support for multiple PCI device IDs (but only a single vendor ID). Add support for building such ROMs by scanning the build target element list and incorporating any device IDs into the ROM's device list header. For example: make bin/8086153a--8086153b.mrom would build a ROM claiming support for both 8086:153a and 8086:153b. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Remove obsolete and unused portions of config.cMichael Brown2015-03-041-25/+0
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [zbin] Use LZMA compressionMichael Brown2015-02-251-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | LZMA provides significantly better compression (by ~15%) than the current NRV2B algorithm. We use a raw LZMA stream (aka LZMA1) to avoid the need for code to parse the LZMA2 block headers. We use parameters {lc=2,lp=0,pb=0} to reduce the stack space required by the decompressor to acceptable levels (around 8kB). Using lc=3 or pb=2 would give marginally better compression, but at the cost of substantially increasing the required stack space. The build process now requires the liblzma headers to be present on the build system, since we do not include a copy of an LZMA compressor within the iPXE source tree. The decompressor is written from scratch (based on XZ Embedded) and is entirely self-contained within the iPXE source. The branch-call-jump (BCJ) filter used to improve the compressibility is specific to iPXE. We choose not to use liblzma's built-in BCJ filter since the algorithm is complex and undocumented. Our BCJ filter achieves approximately the same results (on typical iPXE binaries) with a substantially simpler algorithm. Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit (git 2.34.1) at 2025-02-23 15:11:38 +0000