This is an old revision of the document!
====== Stefan Hajnoczi: GDB Remote Debugging ====== ===== Week 6 ===== **Milestones:** * [b44] Tested and clean for mainline review. * [gpxelinux.0] Merge Award BIOS return-to-PXE workaround. ==== Mon Jul 14 ==== Git commit: [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=86d1342ffbb0dcfc6bb02da81af766f7a0e8f306|[init] Shutdown flags for fine-grained exit behavior]] Time is passing quickly. Today I worked on fine-grained ''shutdown()''. There are two scenarios under which ''shutdown()'' is called: - Booting an image that does not use gPXE interfaces (like BIOS int 13h or PXE). Here everything should be cleaned up and shut down. - Exiting gPXE to return control to firmware (usually to boot the next device if gPXE failed). Here we may wish to leave some resources, like the underlying PXE stack, running. There is currently no way to distinguish these two cases for ''shutdown()''. Therefore, we are not able to clean up or leave resources as appropriate. I have added a flag to ''shutdown()'' to indicate either ''SHUTDOWN_BOOT'' or ''SHUTDOWN_EXIT''. As part of ''undionly.kpxe'', we need to unload the PXE base code if ''shutdown(SHUTDOWN_BOOT)'' is performed. I still need to figure out how to do the unloading and freeing of base memory... ;-) ==== Tue Jul 15 ==== Git commit: * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=b370b8791c1b99a143a8b915170fac0b184f35b3|[prefix] kkpxe prefix for keep UNDI, return-to-PXE images]] Sent the ''e820mangler.S'' patch for full clipping into fragments for review today. **Created ''.kkpxe'' image type** for PXE images that keep PXE+UNDI loaded and return to PXE (instead of int 18h). [[http://etherboot.org/share/stefanha/gpxelinux.kkpxe|Here]] is a ''gpxelinux.0'' image built from ''undionly.kkpxe''. ==== Wed Jul 16 ==== **Sent gpxelinux merge patches for review**. I spent some time this week working on fine-grained ''shutdown()'' so that gPXE can free resources appropriately. However, I believe that this work is independent of the gpxelinux merge and our priority is to get gpxelinux merged. Therefore, I have submitted the gpxelinux patches now, without fine-grained ''shutdown()''. ==== Thur Jul 17 ==== Git commit: [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=0d15b1612bb1258c2cdccc7a106f94a5bb02bd88|[image] Multiple embedded images and no hardcoded DHCP]] Users who want a static IP address instead of DHCP find they need to edit the source to remove hardcoded DHCP. They can then use the ''EMBEDDED_IMAGE'' build option to include a gPXE script that configures their static network settings inside the gPXE binary. Since editing the source is inflexible, there is a discussion to change gPXE's behavior to something more general than hardcoded DHCP. The new policy would skip DHCP for embedded images since they likely want to set up network settings themselves. While this solves the problem for embedded gPXE scripts which do their own network configuration, it breaks when ''pxelinux.0'' is embedded inside gPXE. PXELINUX expects the network interface to be (auto-)configured. I think the most general way to solve this dilemma is by allowing multiple embedded images and making gPXE //always// boot from an embedded image. Even when you build without explicit ''EMBEDDED_IMAGE'' settings, a **default gPXE script** is built in. The default script simply boots from DHCP: <code> #!gpxe autoboot </code> **Static network configuration** works just like you'd expect: you build with ''EMBEDDED_IMAGE=mystatic.gpxe''. This replaces the default script with our custom script. Here is a sample script that works with QEMU's user network stack: <code> #!gpxe ifopen net0 set net0/ip 10.0.2.15 set net0/netmask 255.255.255.0 set net0/gateway 10.0.2.2 set net0/dns 10.0.2.3 kernel http://etherboot.org/gtest/gtest.gpxe boot </code> **Embedding PXELINUX** is also pretty easy, this time by using the multiple embedded image feature. We embed ''pxelinux.0'' //and// a little script to do DHCP. Once DHCP is complete, the little script boots ''pxelinux.0'': <code> #!gpxe dhcp net0 boot </code> Multiple embedded images theoretically allow embedding a ''vmlinuz'' and ''initrd'' inside gPXE. This isn't practical for space-constrained image types like floppy disk or ROM images. Anyway, I have created a ''multiembed'' branch with these features implemented. I think most of this solution has already been thought about by hpa, mcb30, and mdc. I just wanted to code something last night; hope this is a step in the right direction. **Limitations of my patch**: * The semantics of replacing ''autoboot()'' with embedded images are not 100% correct. The autoboot process will bring up each network interface in turn using DHCP and attempt to run the embedded image or fetch a file from the network. Now, embedded images run only once and without any network interface being up or configured. * The patch still needs polishing (error handling and ''mpopulate()'' to reclaim embedded image memory). * The Makefile does not check embedded images, so it is safest to do ''rm -f bin/embed.o'' before every ''make''. * Embedded images are limited to 15 character filenames. They must also be in the ''src/'' directory, not somewhere else in the file system. ==== Fri 18 2008 ==== **Back to the b44 driver**, I have removed uhmalloc and am using malloc's allocator instead. Once this reworking is complete, I can move up to the DMA mapping API to support DMA pools. Then I will send these patches for review and merge before sending the actual b44 driver. Next steps: * [multiembed] ''EMBEDDED_IMAGE='' Makefile integration. * [multiembed] Either get ''mpopulate'' working or make the embedded images already be struct image. * [multiembed] Error handling. * [uhmalloc] Kill this patch, use ''malloc'' allocator instead for DMA buffers. * [DMA] DMA pool API so drivers can reserve DMA buffers on ''open()''. * [b44] Cleanup, testing, performance. * [shutdown] Remove gPXE allocated memory and free up PXE+UNDI, if necessary. * [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.
