Differences

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

--- soc:2009:oremanj:journal:week12 [2009/08/14 01:32]
rwcr
+++ soc:2009:oremanj:journal:week12 [2009/08/15 01:36] (current)
rwcr
@@ Line 4: / Line 4: @@
 Also, I believe this IRC message needs to find a permanent record here:
-:45 <     mcb30> At the point you're talking about, the system is not fully initialised.  On many systems, the memory map
+:45 <mcb30> At the point you're talking about, the system is not
-                     is not yet valid.  If running normal BIOS-level code is marked with "Here be dragons", running during POST
+                fully initialised.  On many systems, the memory map
-                     is marked with "Here be huge, ugly, vindictive, sociopathic dragons with a mean sense of humour"
+                is not yet valid.  If running normal BIOS-level code
+                is marked with "Here be dragons", running during POST
+                is marked with "Here be huge, ugly, vindictive, sociopathic
+                dragons with a mean sense of humour"
 Well put indeed!
@@ Line 58: / Line 61: @@
   #define A20_KBC_RETRIES         (2^21)
 "You keep on using that operator. I do not think it means what you think it means." :-)
+==== Friday, 14 August ====
+On my test system, if we make use of a PMM buffer with A20 set, we don't even get to the BEV entry point to have a chance to set the A20 gate up properly. Adding a
+  ljmp    $0xf000, $0xfff0
+immediately after ''bev_entry:'', which reboots the system at that point on a PMMless gPXE, does not prevent the freeze. There may be a subtler issue here.
+Started taking a look at the Linux ''b43'' (Broadcom wireless) driver. It's quite well-written and -commented, especially for a reverse-engineered driver, but the hardware is really a mess. Some models have the 30-bit DMA restriction Stefan dealt with during his SoC last year. The hardware uses an SSB interface, which seems to be on the level of a whole different bus bridged to PCI. And then there's this line:
+          err = request_firmware(&blob, ctx->fwname, ctx->dev->dev->dev);
+''dev->dev->dev''? Seriously? :-)
+Figured out a possible solution for the problem for **xrom** that we can't know about the devices like APICs that don't have their mappings in PCI BARs: just read the entire space we're going to cover with our mapping before we map it. The standard on x86 is for unmapped memory to read all-ones, and designers of MMIO interfaces actively avoid all-ones being normal in a register. If all 128k or whatever read as ''0xFF'', plus we find no overlap in BARs or e820, it's almost certainly safe to map.
+The ROM-mapping logic could also be used for UNDI.
+Split up the FireWire branch into a more logical separation of commits (first the generic interface, then the gPXE code that uses it, then the host-side utilities to make it useful). Pushed it as **firewire** to my personal repository and removed it from staging, as I have other code there that I think is more important (specifically **linker** and the various things depending on it).
+==== Final Thoughts ====
+Well, Summer of Code is over, and what an adventure it's been. I've immensely enjoyed working on such a mature and well-developed codebase, with a great many talented people, and in a very interesting field with lots of room for innovation. Thank you to everyone who's helped to make it possible!
+Things I'd like to still get done, in rough order of priority:
+  * Merge branch **linker** to mainline.
+  * Merge branch **wireless** to mainline, with all the crypto and iwmgmt stuff.
+  * Get branch **firmware** ready for mainline.
+  * Get branch **firewire** ready for mainline, in one form or another. (It may be a very useful interface for driving gPXE for testing, a la DrV's project.)
+  * Write **xrom** in a fashion that's remotely valid, doing the grunt work of scanning PCI BARs and e820 and such to look for a valid place to map instead of the ugly and immoral hack I initially went with.
+  * In the Maybe category:
+    * Extend branch **eap** into some real support for EAP / WPA Enterprise authentication, with a few common methods implemented.
+    * Port driver ''ath9k'' or ''b43'' or ''iwlwifi'' from Linux. The latter two require firmware loading, and all are something of a mess.
+    * Add standardized support for NV options using the VPD area or (on EFI) RuntimeServices->SetVariable(). The storing in EEPROM using NVS is nice, but most cards don't support it because their EEPROM is earmarked for other purposes. With wireless cards especially, another spot is needed for SSID and encryption key.
+Final sanity check of local git branches related to the work I've done:
+  ath5k                  Merged (ath5k wireless driver)
+  bigrom-oremanj         Merged (small patch to support big ROMs)
+  sky2                   Merged (sky2 wired NIC driver)
+  mainline-review        Merged (initial bout of wireless code)
+  wiprocfix              Merged (small patch to wireless code)
+  linker                 In staging (improve linker macros, object-specific config)
+  firewire               Waiting (debugging interface over FireWire)
+  firmware-pretty        Waiting (firmware image embedding and loading)
+  wireless-pretty        Waiting (wireless crypto and improvements)
+  eap                    To-do (802.1X authentication, WPA Enterprise)
+  xrom                   To-do (load ROM from the PCI card)
+  ath5k-old              History (superseded by ath5k)
+  firewire-old           History (superseded by firewire)
+  firewire-really-old    History (superseded by firewire)
+  wireless               History (superseded by wireless-pretty)
+  fwtrans                Academic interest (load files over firewire debug link)
+And so we go, again.
+Thank you to everyone who's made this summer great, and I hope to be able to continue contributing! :-)

Trace:

Differences

Navigation

Search

Toolbox

QR Code