gPXE currently takes advantage of the feature of PCI3.0 that allows option ROMs to relocate the bulk of their code to high memory and so take up only a small amount of space in the option ROM area. Currently, the relocation can only take place if the BIOS's implementation of PMM can be made to return blocks aligned to an even megabyte, because of the A20 gate. AMI BIOSes, in particular, will not return allocations that gPXE can use. Ameliorate the situation somewhat by adding a prefix, .hrom, that works identically to .rom except in the case that PMM allocation fails. Where .rom would give up and place itself entirely in option ROM space, .hrom moves to a block (assumed free) at HIGHMEM_LOADPOINT = 4MB. This allows for the use of larger gPXE ROMs than would otherwise be possible. Because there is no way to check that the area at HIGHMEM_LOADPOINT is really free, other devices using that memory during the boot process will cause failure for gPXE, the other device, or both. In practice such conflicts will likely not occur, but this prefix should still be considered EXPERIMENTAL. Signed-off-by: Marty Connor <mdc@etherboot.org>tags/v1.0.0-rc1
|
||
830 | 830 |
|
831 | 831 |
|
832 | 832 |
|
833 |
|
|
833 | 834 |
|
834 | 835 |
|
835 | 836 |
|
|
||
11 | 11 |
|
12 | 12 |
|
13 | 13 |
|
14 |
|
|
14 | 15 |
|
15 | 16 |
|
16 | 17 |
|
|
||
30 | 31 |
|
31 | 32 |
|
32 | 33 |
|
34 |
|
|
33 | 35 |
|
34 | 36 |
|
35 | 37 |
|
|
||
1 |
|
|
2 |
|
|
3 |
|
|
4 |
|
|
5 |
|
|
6 |
|
|
7 |
|
|
8 |
|
|
9 |
|
|
10 |
|
|
11 |
|
|
12 |
|
|
||
351 | 351 |
|
352 | 352 |
|
353 | 353 |
|
354 |
|
|
354 | 355 |
|
355 | 356 |
|
356 | 357 |
|
|
||
362 | 363 |
|
363 | 364 |
|
364 | 365 |
|
366 |
|
|
367 |
|
|
365 | 368 |
|
369 |
|
|
370 |
|
|
371 |
|
|
372 |
|
|
373 |
|
|
374 |
|
|
375 |
|
|
376 |
|
|
377 |
|
|
378 |
|
|
366 | 379 |
|
367 | 380 |
|
368 | 381 |
|