openslx-ng/ipxe.git, branch v0.9.4Fork of ipxe; additional commands and featureshttps://git.openslx.org/openslx-ng/ipxe.git/atom/?h=v0.9.42008-09-26T19:14:34+00:00[release] Update version information for 0.9.4 release2008-09-26T19:14:34+00:00Marty Connor2008-09-26T19:14:34+00:00urn:sha1:601d244a8e6dc742780060a9e0c48b91fa6c4524[settings] Allow for setting fetchers to fail in fetchf_hex()2008-09-26T02:39:35+00:00Michael Brown2008-09-26T02:39:35+00:00urn:sha1:6936c40fef84ab61fa57b7a5ec3f84e9c26f9829[settings] Expose MAC address setting for general use2008-09-26T02:39:17+00:00Michael Brown2008-09-26T02:39:17+00:00urn:sha1:e2d5788716684889a4ea5548942e206414c06bbd[romprefix] Fully clear the "Press B to boot..." message when INT19 is used2008-09-26T00:36:22+00:00Michael Brown2008-09-26T00:36:22+00:00urn:sha1:9d72636da186ab22290967887c39a42f0bf17d22[pcbios] Fetch INT 15,e820 entry directly into our e820 cache2008-09-25T17:52:49+00:00Michael Brown2008-09-25T17:45:30+00:00urn:sha1:3392cfa7df58a5662417f25226cf75dedabeb750
Some BIOSes require us to pass in not only the continuation value (in
%ebx) as returned by the previous call to INT 15,e820 but also the
unmodified buffer (at %es:%di) as returned by the previous call to INT
15,e820. Apparently, someone thought it would be a worthwhile
optimisation to fill in only the low dword of the "length" field and
the low byte of the "type field", assuming that the buffer would
remain unaltered from the previous call.
This problem was being triggered by the "peek ahead" logic in
get_mangled_e820(), which would read the next entry into a temporary
buffer in order to be able to guarantee terminating the map with
%ebx=0 rather than CF=1. (Terminating with CF=1 upsets some Windows
flavours, despite being documented legal behaviour.)
Work around this problem by always fetching directly into our e820
cache; that way we can guarantee that the underlying call always sees
the previous buffer contents (and the same buffer address).
[arbel] Allocate sufficient space for firmware buffer2008-09-25T06:23:34+00:00Michael Brown2008-09-25T06:23:34+00:00urn:sha1:fa880ec70a07f45048c7e3beec225634e8623de9
We were accidentally allocating only half the required amount of
memory (given the alignment method) for the firmware buffer, leading
to conflicts between the firmware buffer and gPXE code/data segments.
[hermon] Allocate sufficient space for firmware buffer2008-09-25T06:22:06+00:00Michael Brown2008-09-25T06:22:06+00:00urn:sha1:b45b39260ceb65aa020acfe5a3e961a19ed8489a
We were accidentally allocating only half the required amount of
memory (given the alignment method) for the firmware buffer, leading
to conflicts between the firmware buffer and gPXE code/data segments.
[pcbios] Add facility for testing arbitrary E820 memory maps2008-09-25T02:34:26+00:00Michael Brown2008-09-25T02:34:26+00:00urn:sha1:c24bc349ead939d90b5784dbff3cd9fdb9d83ba8
We seem to be having issues with various E820 memory maps. These
problems are often difficult to reproduce, requiring access to the
specific system exhibiting the problem.
Add a facility for hooking in a fake E820 map generator, using an
arbitrary map defined in a C array, solely in order to be able to test
the map-mangling code against arbitrary E820 maps.
[crypto] Remove spurious #include "config.h"2008-09-25T00:55:48+00:00Michael Brown2008-09-16T01:38:29+00:00urn:sha1:9c71949d1fd59701664a71d52f6fa841c1661b89[romprefix] Allow BANNER_TIMEOUT to control banners in romprefix.S2008-09-25T00:53:42+00:00Michael Brown2008-09-25T00:53:42+00:00urn:sha1:539f94b9805ec4ccb7e526f7043161068727ad41
In particular, allow BANNER_TIMEOUT=0 to inhibit the prompt banners
altogether.
Ironically, this request comes from the same OEM that originally
required the prompts to be present during POST.