Fork of ipxe; additional commands and features https://git.openslx.org/openslx-ng/ipxe.git/atom/src/arch?h=v0.9.4 2008-09-26T00:36:22+00:00 2008-09-26T00:36:22+00:00 Michael Brown 2008-09-26T00:36:22+00:00 urn:sha1:9d72636da186ab22290967887c39a42f0bf17d22 2008-09-25T17:52:49+00:00 Michael Brown 2008-09-25T17:45:30+00:00 urn: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). 2008-09-25T02:34:26+00:00 Michael Brown 2008-09-25T02:34:26+00:00 urn: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. 2008-09-25T00:53:42+00:00 Michael Brown 2008-09-25T00:53:42+00:00 urn: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. 2008-09-24T20:23:50+00:00 Michael Brown 2008-09-24T20:23:50+00:00 urn:sha1:fed106b7fb62ed1a3db3ff690eae1c17a965cce8 Based on a patch provided by XenSource for Etherboot 5.4. 2008-09-24T17:33:31+00:00 Michael Brown 2008-09-24T17:33:31+00:00 urn:sha1:887d77c27ac6ccdb13892ab05e50281e63df6bbf Some really moronic BIOSes bring up the PXE stack via the UNDI loader entry point during POST, and then don't bother to unload it before overwriting the code and data segments. If this happens, we really don't want to leave INT 15 hooked, because that will cause any loaded OS to die horribly as soon as it attempts to fetch the system memory map. We use a heuristic to detect whether or not we are being loaded at the top of free base memory. If we determine that we are being loaded at some other arbitrary location in base memory, then we assume that it's not safe to hook INT 15. 2008-09-23T23:53:40+00:00 Michael Brown 2008-09-23T23:53:40+00:00 urn:sha1:9d44a061885cd81b58cc2d31edd16d60c5d8a3b2 On non-BBS systems we hook INT 19, since there is no other way we can guarantee gaining control of the flow of execution. If we end up doing this, prompt the user before attempting boot, since forcibly capturing INT 19 is rather antisocial. 2008-09-23T22:35:19+00:00 Michael Brown 2008-09-23T22:35:19+00:00 urn:sha1:8b20e5d2b766dd6165a34b62f33a6bd92a68ed63 Some systems seem to report insane memory maps (particularly at POST time). Detect and work around some of the common failure cases. 2008-09-23T00:13:28+00:00 Michael Brown 2008-09-23T00:13:28+00:00 urn:sha1:ca0b0f061673b27bb7bfa6f62e99385273c097da If the INT 15,e820 memory map reports a region [0,0), this confuses the "truncate to even megabytes" logic, which ends up rounding the region 'down' to [0,fff00000). Fix by ensuring that the region's end address is at least 1, before we subtract 1 to obtain the "last byte in region" address. 2008-09-22T23:58:12+00:00 Michael Brown 2008-09-22T23:58:12+00:00 urn:sha1:0fd1e54026d9c941fce041157bb00cb42fdef9dd INT 15,e801 is capable of returning a memory range that extends to 4GB, so allow for this in the debug message that shows the data returned by INT 15,e801.