--- a/FC-handset-spec	Fri Apr 15 04:55:26 2022 +0000
+++ b/FC-handset-spec	Fri Apr 15 05:59:36 2022 +0000
@@ -1507,7 +1507,7 @@
 Our Venus development board will include the same USB subsystem as intended for
 the final FC Libre Dumbphone handset, as described in sections 1.11 and 1.12,
 consisting of a USB mini-B interface connector, a charging on/off switch with
-the charging circuit behind it, and the FT2232x subsystem of section 1.12.
+the charging circuit behind it, and the FT2232D subsystem of section 1.12.
 
 This design is a radical departure from our previous development boards which
 bring out the two Calypso UARTs in their raw LVCMOS form, leaving the USB
@@ -1559,7 +1559,7 @@
 
 3.3.2.1. Linux kernel patch requirement
 
-The FT2232x USB subsystem implemented on FC Venus will include the boot control
+The FT2232D USB subsystem implemented on FC Venus will include the boot control
 feature originating from DUART28C, as described in section 1.12.3.  This
 hardware feature has an implication for developer-users of this board: anyone
 wishing to play with a Venus board beyond already-flashed fw (i.e., anyone
@@ -1586,15 +1586,22 @@
 
 3.3.2.2. Board bring-up order
 
-With the FT2232x USB subsystem integrated on the Venus board, this subsystem
-will become the only way to access Calypso UARTs for initial bring-up of a
-freshly populated board.  Furthermore, our DUART28C-based boot control mechanism
-will be the only way to trigger RPWON and nTESTRESET boot controls - there will
-also be a PWON button (see section 3.6), but that one is intended for higher-
-level end user functions after FC handset fw has been loaded and after all other
-bring-up tasks are completed on each board.  As a result of these factors, our
-FT2232x USB subsystem becomes part of the critical path for board bring-up, and
-it will in fact become the very first part to be brought up, before Calypso.
+The on-board FT2232D subsystem will be the preferred way to interface to the
+two Calypso UARTs on FC Venus, and also the preferred way of driving RPWON and
+nTESTRESET boot controls - if everything goes according to plan.  However, to
+guard against inoperable boards in the unfortunate event that the built-in USB
+subsystem doesn't work as designed, there will also be a "rescue" 10-pin DUART
+header on the board.  If all USB subsystem components are populated on the
+board as we currently intend, the "rescue" DUART header MUST NOT have anything
+connected to it, other than oscilloscope probes - however, if a need arises to
+operate a Venus board via an external DUART28 or other adapter, then some
+components will need to be removed from the USB section of the board to prevent
+the scenario of two fighting drivers.
+
+There will also be a 3-pin boot control header, bringing out RPWON and
+nTESTRESET, but this provision does not present the same stringent single driver
+requirements as the "rescue" DUART header, as all drivers for these boot control
+signals are open drain.
 
 The charging switch will need to be off during board bring-up, and it is
 expected to remain off during most development activities on FC Venus, to be
@@ -1696,14 +1703,20 @@
 fw architecture - instead its control will be absorbed into our R2D BLRR control
 mechanism on the final handset where this backlight will be added.
 
-3.6.1. No boot control buttons
+3.6.1. Limited boot control buttons
 
 The Mother's original idea for FC Venus was to implement pushbutton switches for
 all 3 boot controls as in PWON, RPWON and nTESTRESET.  However, now that we are
-integrating the FT2232x USB subsystem of section 1.12 and the boot control
+integrating the FT2232D USB subsystem of section 1.12 and the boot control
 mechanism of section 1.12.3 as a non-removable part of the Venus board itself,
-pushbutton switches for RPWON and RESET are being eliminated, leaving only PWON
-in the "END" position in the main keypad.
+the pushbutton switch for RPWON is being eliminated, leaving only PWON in the
+"END" position in the main keypad and a rare-use RESET button.  For additional
+context, when I first decided to integrate the FT2232D subsystem with boot
+control, I was going to drop the RESET button as well - but then I decided that
+it would be more proper to include at least a footprint for one.  My current
+intent is to populate an actual button for RESET, but to use a different switch
+part with a shorter actuator and a greater operating force, reducing the
+probability of accidental resets.
 
 3.7. Audio interfaces