Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2010:cooldavid:journal:week2 [2010/06/04 00:46] cooldavid |
soc:2010:cooldavid:journal:week2 [2010/06/04 05:47] (current) cooldavid |
||
|---|---|---|---|
| Line 38: | Line 38: | ||
| (unsigned long)iob->data, mapping, len); | (unsigned long)iob->data, mapping, len); | ||
| </code> | </code> | ||
| - | * This will behave poorly when memory runs out. Better is to have a refill routine that runs after the poll(), and always attempts to refill up to a specified level. <code C> | + | * This will behave poorly when memory runs out. Better is to have a refill routine that runs after the poll(), and always attempts to refill up to a specified level. <code C> |
| rxdesc += idx; | rxdesc += idx; | ||
| if (jme_make_new_rx_buf(rxring->bufinf + idx)) { | if (jme_make_new_rx_buf(rxring->bufinf + idx)) { | ||
| Line 45: | Line 45: | ||
| } else { | } else { | ||
| </code> | </code> | ||
| + | |||
| + | * From me: | ||
| + | * The refill function did not work correctly. Because of the error packet was reused instead of making a hole. [[http://bbs.cooldavid.org/git/?p=gpxe.git;a=commitdiff;h=aa105ed1c6d99588dceeec3ead4e434b40b59644|This patch fixed it]] | ||
| ==== Trace memory related codes ==== | ==== Trace memory related codes ==== | ||
| Line 68: | Line 71: | ||
| === Expand heap === | === Expand heap === | ||
| - | The gPXE's code can be executed on both real-mode and | + | * [[soc:2010:cooldavid:notes:expandheap|Expand gPXE heap]] |
| - | protected-mode because of the GDT's base address was filled with | + | |
| - | the starting point of the code. Which makes all the function, | + | |
| - | 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. | + | |
| - | + | ||
| - | Since the heap is not used by real-mode code, and is used at | + | |
| - | late stages of gPXE. I think it might be possible to put the | + | |
| - | 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, | + | |
| - | we can make sure that no data might be needed for real-mode | + | |
| - | codes would put beyond 1MB limit. | + | |
| - | + | ||
| - | Currently I left 128KB for stack to grow, and put the heap right | + | |
| - | behind it. The C code which runs in protected-mode would work | + | |
| - | fine, since it's already using 32 bit addressing, and the | + | |
| - | segment limit is way larger than image size. | + | |
| - | + | ||
| - | For the real-mode code, as long as the heap is not used. All the | + | |
| - | data needed should be within 1MB limit. | + | |
| - | + | ||
| - | [[http://git.etherboot.org/?p=people/cooldavid/gpxe.git;a=commitdiff;h=09be316b2b1538860037233b41a43dfb3bb1f3d8|Commit-diff]] | + | |
| - | + | ||
| - | === Original heap location === | + | |
| - | [[Original heap location|{{http://bbs.cooldavid.org/pic/origheap.png}}]] | + | |
| - | + | ||
| - | === Modified heap location === | + | |
| - | [[Modified heap location|{{http://bbs.cooldavid.org/pic/hugeheap.png}}]] | + | |
