Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
soc:2010:cooldavid:notes:expandheap [2010/06/04 00:50] cooldavid created |
soc:2010:cooldavid:notes:expandheap [2010/06/04 01:23] (current) cooldavid |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ==== Expand gPXE heap ==== | ==== Expand gPXE heap ==== | ||
| + | === Real-mode compatibility === | ||
| The gPXE's code can be executed on both real-mode and | The gPXE's code can be executed on both real-mode and | ||
| protected-mode because of the GDT's base address was filled with | protected-mode because of the GDT's base address was filled with | ||
| the starting point of the code. Which makes all the function, | the starting point of the code. Which makes all the function, | ||
| global variable's pointer valid between the transition. | global variable's pointer valid between the transition. | ||
| - | Also, the limit of GDT entry was set to 4G, so there is no need | + | |
| - | to concern if we are going to across the segment limit. | + | The original design already put the 16bit code and data to the |
| + | begining of the gPXE image. That reduced the posibility which | ||
| + | might occur when running 16 bit code hit the 1MB limit. | ||
| + | |||
| + | === How expand heap works === | ||
| + | The limit of GDT entry was set to 4G, so there is no need | ||
| + | to concern if we are going to across the segment limit in | ||
| + | 32 bits code. | ||
| Since the heap is not used by real-mode code, and is used at | Since the heap is not used by real-mode code, and is used at | ||
| Line 12: | Line 20: | ||
| heap out side of the .bss section, and put it at the very end of | heap out side of the .bss section, and put it at the very end of | ||
| the image. After we put the heap at the very end of the image, | the image. After we put the heap at the very end of the image, | ||
| - | we can make sure that no data might be needed for real-mode | + | we can make sure that no data accessed by 16 bits code would put |
| - | codes would put beyond 1MB limit. | + | higher than 1MB limit. |
| Currently I left 128KB for stack to grow, and put the heap right | Currently I left 128KB for stack to grow, and put the heap right | ||
| Line 20: | Line 28: | ||
| segment limit is way larger than image size. | segment limit is way larger than image size. | ||
| - | For the real-mode code, as long as the heap is not used. All the | + | The most important thing that makes it possiable is the modification |
| - | data needed should be within 1MB limit. | + | for relocate. 16 bits code do not access any memory that is not in |
| + | .*16 sections in general except when copying(relocation) the gPXE | ||
| + | image. After we ignore the copy of heap data, we can have virtually | ||
| + | unlimited heap which can be decide on compile time. | ||
| - | [[http://git.etherboot.org/?p=people/cooldavid/gpxe.git;a=commitdiff;h=09be316b2b1538860037233b41a43dfb3bb1f3d8|Commit-diff]] | + | [[http://bbs.cooldavid.org/git/?p=gpxe.git;a=shortlog;h=refs/heads/hugeheap|Heap modification branch]] |
| === Original heap location === | === Original heap location === | ||
| - | [[Original heap location|{{http://bbs.cooldavid.org/pic/origheap.png}}]] | + | {{:soc:2010:cooldavid:notes:origheap.png}} |
| === Modified heap location === | === Modified heap location === | ||
| - | [[Modified heap location|{{http://bbs.cooldavid.org/pic/hugeheap.png}}]] | + | {{:soc:2010:cooldavid:notes:hugeheap.png}} |
