====== Differences ====== This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2008:stefanha:journal:week7 [2008/07/09 06:52] stefanha |
soc:2008:stefanha:journal:week7 [2008/07/22 12:26] (current) stefanha |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Stefan Hajnoczi: GDB Remote Debugging ====== | ====== Stefan Hajnoczi: GDB Remote Debugging ====== | ||
| - | ===== Week 6 ===== | + | ===== Week 7 ===== |
| **Milestones:** | **Milestones:** | ||
| Line 72: | Line 72: | ||
| **Detecting an overwritten stack** is a bit wierd. We want to return to PXE because int 18h is broken. In order to return, we need to make sure the stack has not been overwritten. If we determine the stack is unusable, then we are stuck - int 18h is broken and return to PXE is impossible! The policy I have coded for now is to reboot the machine. | **Detecting an overwritten stack** is a bit wierd. We want to return to PXE because int 18h is broken. In order to return, we need to make sure the stack has not been overwritten. If we determine the stack is unusable, then we are stuck - int 18h is broken and return to PXE is impossible! The policy I have coded for now is to reboot the machine. | ||
| - | Next steps: | + | **Testing images available here**: |
| - | * [b44] Performance testing. | + | * [[http://etherboot.org/share/stefanha/gpxelinux.0|gpxelinux.0]] with buggy BIOS detection and return-to-PXE. |
| - | * [b44] Cleanup & testing. | + | * [[http://etherboot.org/share/stefanha/gpxelinuxf.0|gpxelinuxf.0]] with forced return-to-PXE. (The above image should only return-to-PXE on a buggy Award BIOS. Use this image to try return-to-PXE or if the detection isn't working.) |
| - | * [bzImage] Expand the heap size to the full 64K segment when loading a bzImage kernel with version 2.02 or higher. | + | |
| - | * [GDB] Real-mode remote debugging. | + | Please give them a shot. You can tell that return-to-PXE is being used when there is no message about freeing UNDI memory. Let me know whether buggy BIOS detection works and whether return-to-PXE correctly tries to boot from the next device. |
| + | |||
| + | For some reason my test machine hangs instead of booting the next image. I tried a dummy NBP with an instruction to set the return type and an ''lret''. Perhaps my BIOS/PXE (Insyde + Intel BC + Broadcom UNDI) is buggy. | ||
| + | |||
| + | ==== Fri Jul 11 ==== | ||
| + | Git commit: | ||
| + | * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=3b375c3bfc0bf746bd43af55f63e2c69146b82d4|[prefix] Do int 18h if return stack is damaged]] | ||
| + | |||
| + | Just had a productive meeting with mdc and mcb30. I am still learning new things about gPXE and the world it lives in every week. | ||
| + | |||
| + | The b44 driver itself has been sitting still for a few weeks. The reason for this is that it requires changes to gPXE's memory management. Getting the driver working has turned into a journey through DMA mapping, gPXE's memory allocators (''malloc'' and ''umalloc''), hidden memory regions, and into the E820 memory map mangler. | ||
| + | |||
| + | Today's meeting has brought me one step closer to what our memory management needs to look like in order to support devices with addressing limitations, like the BCM4401 NIC. | ||
| + | |||
| + | ===== Next week ===== | ||
| + | On to [[.:week8|Week 8]]. | ||
