✎ soc:2009:oremanj:journal:week12

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Joshua Oreman: 802.11 wireless development ======
===== Journal Week 12 =====
I can hardly believe there's only a week left of SoC. It's been a wonderful experience working with such talented developers, and I hope my coursework in the fall will leave me enough time to continue contributing :-)

Also, I believe this IRC message needs to find a permanent record here:
  10:45 <     mcb30> At the point you're talking about, the system is not fully initialised.  On many systems, the memory map
                     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.

==== Monday, 10 August ====
Not too much gPXE work today. I pushed a cleaned-up version of the large-ROM fix from my ath5k branch to staging as **bigrom-oremanj** (following the new [[:staging|staging tree protocol]]). A suggestion by Michael for making some of the condition checks for overflow more intuitive revealed the rather surprising fact that bit-shifting in C by more places than the size of the variable is undefined; on gcc-x86, ''1ul << var'' when var is 32 will be not zero but one! This led to a small-scale [[:todo:audit-the-shifts|audit of variable-amount bitshifts]] in the gPXE source, but I didn't find any code that would cause problems with this undefined behavior.

I received a new e1000 card, and was able to use it to restore the flash on the old one following a procedure that I've outlined on the [[:romburning#recovering_from_a_bad_flash|ROM burning page]]. The issue was indeed one of option ROM overflow; gPXE loads to segment ''CC00'', meaning it has exactly 80kB of ROM space on my test system. The ROM that had caused trouble was about 90kB.

I found a regression in the 802.11 code caused by recent changes to ''process_add()'' to ensure the same process is not added twice. The changes assume that all callers use ''process_init_stopped()'' to initialize all fields of the process structure, instead of setting just ''step'' and ''refcnt'' manually (which has worked fine in the past). The 802.11 code used the later method, and now does not start the association process at all. I pushed a two-line fix to staging as **wiprocfix**, and it probably will be merged tomorrow.

I rebased my **linker** branch against recent changes and pushed it to staging.

I updated my **firmware** branch to use the new symbol requirement macros defined in linker, and pushed it to my personal repository as **firmware-pretty**. It will go to staging after linker is merged, since it depends on the macros in linker.

Priorities for the rest of the week:
  * Write a page for 802.11 users and a page for driver developers
  * Post a brain-dump of the 802.11 knowledge I've gained working on this project (about halfway done writing it)
  * Once linker is merged, rebase and push firmware and wireless branches
  * Start working on flash-stub large ROM idea

Regarding the last bullet point, I think I'm going to try using the PCI ROM BAR before device-specific flash code. Video cards almost universally have very large memory regions compared to a typical flash size, so it should be easy enough to look for a BAR larger than the flash size, disable it, and map the flash in its place for long enough to copy its contents to RAM. Disabling the BAR doesn't affect the card's internal operation, so as long as we don't output anything while the flash is mapped this method should work. (If anyone reading this knows something I don't about PCI architecture and can see that this is a stupid idea, please let me know.)
Trace: • week5 • week1 • tftpd-hpa • week12 • dhcp_-_build_instructions • week1 • the_kernel
Navigation

Search

Toolbox

QR Code
