mirror of
https://github.com/xcat2/xNBA.git
synced 2024-11-26 11:19:17 +00:00
xCAT Network Boot Agent
2629b7e2cd
Many BIOSes do not construct the full system memory map until after calling the option ROM initialisation entry points. For several years, we have added sanity checks and workarounds to accommodate charming quirks such as BIOSes which report the entire 32-bit address space (including all memory-mapped PCI BARs) as being usable RAM. The IBM x3650 takes quirky behaviour to a new extreme. Calling either INT 15,e820 or INT 15,e801 during POST doesn't just get you invalid data. We could cope with invalid data. Instead, these nominally read-only API calls manage to trash some internal BIOS state, with the result that the system memory map is _never_ constructed. This tends to confuse subsequent bootloaders and operating systems. [ GRUB 0.97 fails in a particularly amusing way. Someone thought it would be a good idea for memcpy() to check that the destination memory region is a valid part of the system memory map; if not, then memcpy() will sulk, fail, and return NULL. This breaks pretty much every use of memcpy() including, for example, those inserted implicitly by gcc to copy non-const initialisers. Debugging is _fun_ when a simple call to printf() manages to create an infinite recursion, exhaust the available stack space, and shut down the CPU. ] Fix by completely inhibiting calls to INT 15,e820 and INT 15,e801 during POST. We do now allow relocation during POST up to the maximum address returned by INT 15,88 (which seems so far to always be safe). This allows us to continue to have a reasonable size of external heap, even if the PMM allocation is close to the 1MB mark. The downside of allowing relocation during POST is that we may overwrite PMM-allocated memory in use by other option ROMs. However, the downside of inhibiting relocation, when combined with also inhibiting calls to INT 15,e820 and INT 15,e801, would be that we might have no external heap available: this would make booting an OS impossible and could prevent some devices from even completing initialisation. On balance, the lesser evil is probably to allow relocation during POST (up to the limit provided by INT 15,88). Entering iPXE during POST is a rare operation; on the even rarer systems where doing so happens to overwrite a PMM-allocated region, then there exists a fairly simple workaround: if the user enters iPXE during POST and wishes to exit iPXE, then the user must reboot. This is an acceptable cost, given the rarity of the situation and the simplicity of the workaround. Signed-off-by: Michael Brown <mcb30@ipxe.org> |
||
|---|---|---|
| contrib | ||
| src | ||
| COPYING | ||
| COPYRIGHTS | ||
| README | ||
iPXE README File Quick start guide: cd src make For any more detailed instructions, see http://ipxe.org