--- a/FC-handset-spec	Fri Jun 11 18:29:06 2021 +0000
+++ b/FC-handset-spec	Sat Jun 12 02:58:47 2021 +0000
@@ -939,3 +939,42 @@
 section 1.12.2.1, that one 74LVC541A IC can serve both signal directions (5
 signals from Calypso to FT2232x and 3 signals going the other way), reducing the
 component count.
+
+1.12.3. Boot control by USB host
+
+Our DUART28C adapter (DUART28 hardware, EEPROM in the 'C' configuration) has a
+nifty feature in the form of CTL1 and CTL2 open drain outputs, intended for
+triggering Iota VRPC boot control signals on Calypso devices, i.e., boot control
+signals from the {PWON, RPWON, nTESTRESET} set.  So far none of our FreeCalypso
+development boards bring out RPWON, but both FCDEV3B and Caramel2 feature PWON
+and nTESTRESET controls, and we have an established convention for driving them
+with CTL1 and CTL2 from a DUART28C.  The end effect for the developer-operator
+is that one can run operations based on Calypso boot ROM loading path (fc-iram,
+fc-loadtool etc) purely from the host command line, without needing to press any
+buttons on the development board: adding -Prts to the command line is equivalent
+to pressing PWON, or adding -Pdtr is equivalent to pressing RESET.  rvinterf can
+also be run with the same options, allowing flashed firmware to be booted in a
+similar no-buttons-needed manner.
+
+It is the Mother's intent to replicate this boot control feature on our FC Libre
+Dumbphone handset as well, i.e., make FT2232x Channel B RTS and DTR outputs
+(otherwise unused) act as host-driven boot control triggers.  In hardware terms,
+this addition consists of just one tiny IC (74LVC2G07) and two pull-up resistors
+on the BDBUS[24] lines from FT2232x to this OD buffer.  FT2232x EEPROM will be
+programmed with the same custom USB ID as DUART28C, and the Linux kernel
+ftdi_sio driver will need to have our DUART28C support patch added to it.
+
+There will be one change from our previous convention, however: the OD buffer
+output controlled with Channel B RTS will be wired to RPWON rather than PWON;
+the other OD buffer output controlled with Channel B DTR will still be wired to
+nTESTRESET like before.  The reason for this change is that our handset firmware
+has more complex logic that treats different boot causes differently (as
+required for standard expected handset functionality), and Iota PWON is now
+reserved solely for the end user power-on button.  Host-commanded boot needs to
+be different from this end user power-on button (no long press is required, and
+the firmware should enter its misc boot state that behaves like an ACI build),
+hence we are changing the wiring so that -Prts will trigger RPWON rather than
+PWON.  The same boot effect can still be achieved with -Pdtr triggering
+nTESTRESET, but it is a bigger hammer (reset of RTC can be unwanted), hence
+-Prts will be recommended as the gentler option, leaving -Pdtr for times when
+recovery from runaway code is needed.