✎ soc:2008:stefanha:journal:week6

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Stefan Hajnoczi: GDB Remote Debugging ======

===== Week 6 =====

**Milestones:**
  * [b44] Tested and clean for mainline review.
  * [r-o-m] Fix known ROM-o-matic bugs.

==== Mon Jun 30 ====
Git commits:
  * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=7e7df3fbed400348887fa5bf845546f1bac18caf|[DMA] Add test for bounce buffers.]]
  * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=1cd064010d816dfb3c0dd24ae4c83baf153325aa|[b44] Begin driver clean up work]]
  * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=f895b2b214f8492ecbee58ea9baa1355b4b83a5d|[b44] Auto-negotiate link]]

**Posted DMA mapping patches to the mailing list**.  I am hoping to get feedback on whether this approach looks good.

**Cleaning up b44 driver**.  I am trying to get rid of unused functionality from the driver.  The aim is to simplify the code for humans and reduce code size.  I noticed that loading a 6 MB initrd via HTTP hangs on my hardware, this is probably an issue in the b44 driver or DMA mapping code.  Debugging this is my next task.

==== Tue Jul 1 ====
**Fixed known ROM-o-matic bugs**.  Soon ROM-o-matic will be added to gPXE ''contrib/''.  This will allow anyone to run their own or contribute to mainline development.  There were a few known bugs that I tracked down and fixed today.

**E820 memory map splitting support**.  Yesterday's hang while loading an initrd turned out to be caused by me misunderstanding 
''e820mangler.S''.  gPXE can mark memory regions as hidden.  When gPXE or an image use the E280 BIOS memory map function, ''e820mangler.S'' will hide these memory regions.  This prevents gPXE memory from being overwritten or used by another program.

The bug was my assumption that ''e820mangler.S'' would split memory regions around arbitrary hidden regions.  I haven't deciphered all of the code yet, but printing the memory map after placing a hidden region inside a larger free region shows that arbitrary splits aren't performed.  Here is the picture:
<code>
+----------------+                 +----------------+
|   free region  |                 | this region is |
|                |                 | not produced!  |
| +------------+ |  e820mangler.S  +----------------+
| | my hidden  | |   ==========>
| | region     | |
| +------------+ |                 +----------------+
|                |                 |   truncated    |
|                |                 |   region       |
+----------------+                 +----------------+
</code>

You can see only the bottom region is being produced.  The top region is not produced by ''e820mangler.S''.  At least that's what I think is going on.

I had a look at the [[http://www.uruk.org/orig-grub/mem64mb.html|E820 interface]] and will start working on a solution tomorrow.  It gets nasty when there are N hidden regions inside one free region, thereby splitting it up into many smaller regions.

==== Wed Jul 1 ====
**Updated GDB debugging documentation** now that debugging over UDP and watchpoints are in mainline.  The [[:dev:gdbstub|documentation]] still needs work but I have at least updated the parts that are there so they are correct.

==== Fri Jul 4 ====
This week I haven't kept my journal up-to-date.  I have not been writing much gPXE code.  Instead I worked on ROM-o-matic, GDB documentation, bug reports on IRC, understanding ''gpxelinux.0'' so we can merge changes into mainline, and understanding ''e820mangler.S'' to get DMA mapping working.

**b44 progress has been stuck at E820 memory splitting**.  I will talk to mcb30 today about ''e820mangler.S''.  I am misunderstanding that code because its output does not match my expectations.  I'd like to make progress on E820 mapping this weekend and it will open the door to getting DMA mapping and the b44 working and into mainline.

**I am in dialogue with hpa, mcb30, and mdc so we can merge gpxelinux.0 into gPXE**.  SYSLINUX now builds ''gpxelinux.0'', a PXE NBP that uses the UNDI driver with gPXE (aka ''undionly.kpxe'') to run PXELINUX.  A relatively small set of changes was needed to make this work on some hardware.  The aim is to get this code merged into gPXE mainline.

Next steps:
  * [b44] E820 splitting.
  * [b44] Performance.
  * [b44] Cleanup & testing.
  * [gpxelinux] Work with hpa and mcb30 to cleanly merge gpxelinux.0 modifications into gPXE.
  * [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.
Trace: • expandheap • project_plan • project_plan • gpxe_driver_api • tcpoorxtest • mdeck • week0
Navigation

Search

Toolbox

QR Code
