====== 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 05:36] 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 59: | Line 59: | ||
| Git commit: | Git commit: | ||
| * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=b658f32e59ca482e03b7caf978b6926589708f88|[prefix] Return-to-PXE when int 18h is broken]] | * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=b658f32e59ca482e03b7caf978b6926589708f88|[prefix] Return-to-PXE when int 18h is broken]] | ||
| + | * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=17fdb265ffb4685b496c7ca16d18da2620b9b8fb|[prefix] Stack overwrite check before return to PXE]] | ||
| **Ported gpxelinux.0 changes** to my new ''gpxelinux'' branch. SYSLINUX uses ''undionly.kpxe'' (keep UNDI loaded, no PCI support) with PXELINUX as an embedded image. HPA has added a workaround for buggy BIOSes that do not support int 18h from PXE NBPs. | **Ported gpxelinux.0 changes** to my new ''gpxelinux'' branch. SYSLINUX uses ''undionly.kpxe'' (keep UNDI loaded, no PCI support) with PXELINUX as an embedded image. HPA has added a workaround for buggy BIOSes that do not support int 18h from PXE NBPs. | ||
| Line 69: | Line 70: | ||
| - More control over ''shutdown()'' to distinguish between passing control to a successfully loaded image or asking for the next device to boot on failure. When passing control to an image that does not need gPXE services, we will unload everything. When asking for the next device to boot, we may keep the underlying PXE and UNDI. | - More control over ''shutdown()'' to distinguish between passing control to a successfully loaded image or asking for the next device to boot on failure. When passing control to an image that does not need gPXE services, we will unload everything. When asking for the next device to boot, we may keep the underlying PXE and UNDI. | ||
| - | Next steps: | + | **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. |
| - | * [b44] Performance testing. | + | |
| - | * [b44] Cleanup & testing. | + | **Testing images available here**: |
| - | * [bzImage] Expand the heap size to the full 64K segment when loading a bzImage kernel with version 2.02 or higher. | + | * [[http://etherboot.org/share/stefanha/gpxelinux.0|gpxelinux.0]] with buggy BIOS detection and return-to-PXE. |
| - | * [GDB] Real-mode remote debugging. | + | * [[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.) |
| + | |||
| + | 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]]. | ||
