Fork of ipxe; additional commands and features https://git.openslx.org/openslx-ng/ipxe.git/atom/src/arch/i386?h=v0.9.5 2008-09-29T04:11:51+00:00 2008-09-29T04:11:51+00:00 Michael Brown 2008-09-29T04:11:51+00:00 urn:sha1:1dda75c9cdca7105733bfc21e8b4b6d46df19113 Although the E820 API allows for a caller to provide only a 20-byte buffer, there exists at least one combination (HP BIOS, 32-bit WinPE) that relies on information found only in the "extended attributes" field, which requires a 24-byte buffer. Allow for up to a 64-byte E820 buffer, in the hope of coping with future idiocies like this one. 2008-09-29T02:55:13+00:00 Michael Brown 2008-09-29T02:55:13+00:00 urn:sha1:040f7cdf3a99ed56a4487efc8e131c84984925bf The ACPI specification defines an additional 4-byte field at offset 20 for an E820 memory map entry. This field is presumably optional, since generally E820 gets given only a 20-byte buffer to fill. However, the bits of this optional field are defined as: bit 0 : region is enabled bit 1 : region is non-volatile memory rather than RAM so it seems as though callers that pass in only a 20-byte buffer may be missing out on some rather important information. 2008-09-29T00:00:14+00:00 Michael Brown 2008-09-29T00:00:14+00:00 urn:sha1:0015601f0b5c0d677450c1dc507a261d5ca3012d gcc should (I think) be warning about this anyway, but seems to do so only when assertions are enabled for this object. 2008-09-28T23:36:11+00:00 Michael Brown 2008-09-28T23:36:11+00:00 urn:sha1:50dc9344b7265915f5b9b1f795d024e775e3ae49 Our INT 15,e820 code was setting %es=%ss (as part of the "look ahead in the memory map" logic), but failing to restore %es afterwards. This is a serious bug, but wasn't affecting many platforms because almost all callers seem to set %es=%ss anyway. 2008-09-28T22:06:53+00:00 Michael Brown 2008-09-28T22:06:53+00:00 urn:sha1:e3c550717864cb60b982389eb845b825bb9574e8 Use as "call dump_regs" from any real-mode code within .text16. Should preserve all registers and flags. 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.