diff --git a/enforcement-case-studies.tex b/enforcement-case-studies.tex
index adfa828..41d65d5 100644
--- a/enforcement-case-studies.tex
+++ b/enforcement-case-studies.tex
@@ -901,10 +901,6 @@ image for your router. It is advised that you use this configuration.
   
 * The "make" step completed successfully on our system and resulted in several
   files being generated in the bin/ar71xx directory, namely firmware images.
-  There appeared to be several filesystem and kernel images, for different
-  hardware versions.  It was unclear which one to install on the particular
-  device we received or how to install it, both of which should have been
-  mentioned in the README.
 ** This step is normally where we run into the greatest number of build issues
    (and thus compliance problems).  In many cases, the "make" step will fail due
    to a missing package or because toolchain paths are not setup correctly.  As
@@ -915,6 +911,11 @@ image for your router. It is advised that you use this configuration.
    instructions makes it easier for the end user to successfully build the
    source release.
 
+* There appeared to be several filesystem and kernel images, for different
+  hardware versions.  It was unclear which one to install on the particular
+  device we received or how to install it, both of which should have been
+  mentioned in the README.
+
 % FIXME: Below, we probably want to talk to them to add this, and also, be a
 % bit more expansive.
   
@@ -924,6 +925,27 @@ image for your router. It is advised that you use this configuration.
   were included in the README, as the user cannot be expected to infer that or
   to find such a link.
 
+\section{Root Filesystem and Kernel Installation}
+
+As mentioned above, the specific steps for installing an updated firmware image
+were not provided, but we found that the firmware update method available in the
+web interface worked fine.  In particular, we went to http://192.168.10.1/ in
+our browser, then logged in and chose System -> Backup / Flash Firmware.  From
+there, we went to the "Flash new firmware image" section and selected the
+librecmc-ar71xx-generic-tl-wr841n-v8-squashfs-sysupgrade.bin image in the
+bin/ar71xx directory mentioned above.  We chose the "v8" image because we found
+our router said "v8.2" on the bottom and "sysupgrade" because we were doing a
+firmware upgrade rather than a fresh install.
+
+When we clicked "Flash image...", we were prompted to confirm the MD5 hash of
+the image to flash and then clicked "Proceed" to flash the image.  The process
+took about one minute, at which point we were back at the web UI login screen.
+We logged in and found that the Kernel Log section showed we were running the
+new kernel.
+
+We then logged in via SSH again and ran "busybox", which printed the new version
+string, showing it was using our newly-compiled version (given the date).
+
 \section{U-Boot Compilation}
 
 * As mentioned above, we also found a "u-boot_reflash" file at the top level of
@@ -960,9 +982,55 @@ mips-librecmc-linux-uclibc-gcc.bin: /lib/libc.so.6: version `GLIBC_2.14' not fou
 
      enforcement-case-studies_log-output/thinkpenguin_u-boot-finish_build.log
 
-\section{Installation}
+\section{U-Boot Installation}
 
-% FIXME: add more details once install tests have been completed
+We obtained a serial cable along with our router, in order to complete the
+U-Boot installation per the instructions in u-boot_reflash.  However, we were
+only able to read data from the serial port; we were unable to interrupt the
+boot process or access the U-Boot console to complete the U-Boot re-flash.  Here
+are the steps we tried:
+
+* We found the serial cable included was a USB serial adapter that had a male
+  USB type A connector on one end and 4 female jumper wires at the other end.
+  These female jumper wires were red, black, white, and green.
+* The instructions did not specify how to connect these wires, but we were able
+  to determine this in part using the "v8.4" image (close to our "v8.2" router)
+  at http://wiki.openwrt.org/toh/tp-link/tl-wr841nd#serial.console .  Aside from
+  power and ground (red and black), we did have to guess which of the wires was
+  RX and TX.  By experimentation we found that green was RX and white was TX.
+  When we tried the other way, we received no data to our serial console at boot
+  time.
+* We did have to use the included jumper pin gender changer with the USB serial
+  adapter, which we put through the holes on the router's mainboard and then
+  connected to the USB serial adapter.  The fit was fairly loose so it would be
+  nice if future router versions included a tighter gender changer or (ideally)
+  had the jumper pins soldered onto the board to begin with (so no gender
+  changer would be required).
+* We used 115200 8N1 as our serial console settings (with no hardware or
+  software flow control).  This was tested with both the minicom and screen
+  commands.  We found that if we connected all 4 wires on the USB serial adapter
+  that the router would start without additional power and our console would
+  receive the startup messages.  We could replicate the same behavior by
+  omitting the power cable from the USB serial adapter (red wire) and connecting
+  the main power adapter to the router instead.
+* While we did see the U-Boot and kernel boot logs in our serial console, we
+  were unable to interrupt the boot process as u-boot_reflash indicated we
+  should.  We suspect this is a misconfiguration of our serial console, but it's
+  unclear exactly how it is misconfigured, as we were able to receive data fine
+  (we just couldn't send data to the router).
+* As a result, we were unable to complete the U-Boot installation test.  We did
+  appreciate that installation instructions were included, though these
+  instructions should be updated to include more specifics about connecting the
+  serial cable.  Since ThinkPenguin does have the option to ship a serial
+  adapter with the router, it would be helpful if instructions specific to that
+  adapter were included, as the wiring configuration one should use was unclear.
+* Additionally, instructions for removing the router's case should be included.
+  We found that the two screws that needed removal to open the case were hidden
+  underneath rubber feet on the case.  Indicating which feet need removal to
+  unscrew the case would be helpful.  The instructions should also note that the
+  case needs to be carefully separated once the screws are removed; it
+  effectively snaps apart, but care must be taken to avoid breaking the plastic
+  fasteners that keep the case together after the screws are removed.
 
 \section{Firmware Comparison}
 
@@ -996,8 +1064,14 @@ were:
    some bits to be different.
 ** Do the above two steps for /lib/modules, /usr/bin, and other directories with
    a significant number of binaries.
-
-% FIXME: add details about how to compare the kernel binary
+** To check that the kernel is sufficiently similar, compare the "dmesg" output
+   both before and after flashing the new firmware.  The kernel version string
+   should be similar, but should have a different build date and user@host
+   indicator.  The kernel binary itself is not easily accessible from an SSH
+   login, but may be retrievable using the U-Boot console (the start address of
+   the kernel in flash appears to be 0x9F000000, based on the u-boot_reflash
+   instructions).  We were not able to verify this, due to the serial connection
+   issues (see above section on U-Boot installation).
 
 \section{Minor Infractions}
 
@@ -1018,6 +1092,13 @@ are both more problematic infractions.  These minor infractions were:
   otherwise have been since the web-based firmware update process is well-known.
 * Using pre-built toolchain binaries that don't work on all systems instead of
   the ones that are built in a separate step, but not moved to the right place.
+  We were able to build corresponding toolchain binaries from source (though
+  for a slightly different target) so this is not a severe toolchain violation
+  of the type we normally find (where toolchain binaries are provided without
+  source).  However, including instructions to use the built toolchain binaries
+  instead would be best, or alternatively specifying the distribution on which
+  the toolchain binaries must be run (to avoid being unable to run them as we
+  were).
 
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%