soc:2008:stefanha:journal:week7 - Etherboot/gPXE Wiki

====== Differences ====== This shows you the differences between two versions of the page.

--- soc:2008:stefanha:journal:week7 [2008/07/08 07:10]
stefanha
+++ soc:2008:stefanha:journal:week7 [2008/07/22 12:26] (current)
stefanha
@@ Line 1: / Line 1: @@
 ====== Stefan Hajnoczi: GDB Remote Debugging ======
-===== Week 6 =====
+===== Week 7 =====
 **Milestones:**
@@ Line 8: / Line 8: @@
 ==== Tue Jul 8 ====
-Git commit:
+Git commits:
   * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=9a4daaf7d1d3cbe8302aace77854ee99b2696b25|[e820] Full clipping of regions into fragments]]
+  * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=2e9dc72974b5ee0183e6268c3d1a747552c0c964|[e820] Clean up new e820 memory mangler]]
 **Progress on e820 memory map mangler**.  I finally made the push for an e820 memory map mangler that can clip regions into fragments.  The existing e820 memory map mangler works well when gPXE hides the beginning and/or end of a memory region.  The new mangler supports hidden memory regions anywhere, and any number of them.  In the worst case, this means splitting a memory region into two or more fragments.
@@ Line 45: / Line 46: @@
 </code>
-For every e820 region, the algorithm steps through each hidden region.  Actually, it clips using the "current" hidden region and the "next" hidden region.
+For every e820 region, the algorithm steps through each hidden region.  Actually, it clips using the "current" hidden region and the "next" hidden region.  The concept of ordered current and next hidden regions requires that hidden regions are sorted by start address.
 The e820 region is clipped to the end of the current region and the start of the next region.  If there was an overlap and a fragment was clipped, then it is returned.
@@ Line 55: / Line 56: @@
 The pseudocode above is written with a continuous thread of control.  However, the actual int 15h, e820 handler needs to be called for each fragment, so the full assembly code needs to manually manage iteration state and do continuation.
-Next steps:
+==== Wed Jul 9 ====
-  * [b44] Performance testing.
+Git commit:
-  * [b44] Cleanup & testing.
+  * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=b658f32e59ca482e03b7caf978b6926589708f88|[prefix] Return-to-PXE when int 18h is broken]]
-  * [gpxelinux] Work with hpa and mcb30 to cleanly merge gpxelinux.0 modifications into gPXE.
+  * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=17fdb265ffb4685b496c7ca16d18da2620b9b8fb|[prefix] Stack overwrite check before return to PXE]]
-  * [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.
+**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.
+We want to merge the workaround into mainline.  On Monday, mcb30 and I discussed fingerprinting the buggy BIOS so gPXE can decide whether to exit via int 18h or by returning to PXE.  A flag gets set when a buggy BIOS is detected.  On exit, we check this flag and return via PXE if necessary.
+Overall, the steps to get ''gpxelinux.0'' cleanly merged are:
+  - Merge return-to-PXE code from ''gpxelinux.0'', add buggy BIOS fingerprinting.
+  - Detecting an overwritten stack.  We cannot return to PXE if the stack has been corrupted (say, in the attempt to boot an image).
+  - 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.
+**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.
+**Testing images available here**:
+  * [[http://etherboot.org/share/stefanha/gpxelinux.0|gpxelinux.0]] with buggy BIOS detection and return-to-PXE.
+  * [[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]].

Trace:

Navigation

Search

Toolbox

QR Code