✎ 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.

Next steps:
  * [b44] E820 splitting.
  * [b44] Performance.
  * [b44] Cleanup & testing.
  * [gpxelinux] Work with hpa and mcb30 to cleanly merge gpxelinux.0 modifications into gPXE.
  * [GDB] Update [[:dev:gdbstub|GDB stub page]] and screencast when UDP code is merged into mainline.  See [[http://grub.enbug.org/DebuggingWithGDB|GRUB GDB wiki page]] for inspiration.
  * [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: • week6 • week6 • week11 • journal • notes • elf-ebi-initramfs-lnxi-howto • week5 • week5 • week4 • hardwareissues • stefanha • modules
Navigation

Search

Toolbox

QR Code
