--- a/gsm-fw/L1/stand/README	Fri Aug 29 18:41:55 2014 +0000
+++ b/gsm-fw/L1/stand/README	Sat Aug 30 22:52:35 2014 +0000
@@ -31,3 +31,27 @@
 regular fw build, and not at all like TI's standalone L1, we do NOT define
 OP_L1_STANDALONE.  Instead we have a different preprocessor symbol:
 CONFIG_L1_STANDALONE.
+
+The standard version of l1_pei calls vsi_c_open() to get queue handles of
+several G23 stack entities; it connects by name to "PL", "MMI", and if GPRS is
+enabled, also to "GRR", "LLC" and "SND".  If we leave these connect-by-name
+calls unchanged in our L1 standalone version, our pei_init() will always return
+PEI_ERROR and never successfully initialize, which would not be very useful.
+If we removed these vsi_c_open() calls and the associated OSX queue setup, the
+first osx_send_prim() addressed to the queue in question will crash, so that
+approach wouldn't be useful either.
+
+What we would like to do is redirect all outbound messages emitted by our
+standalone L1 to the debug serial interface, using GPF's TST entity, just as if
+an L1 REDIRECT or DUPLICATE command was given to a complete GSM fw image.
+However, simply connecting our queues to TST won't work, as TST is not designed
+to receive "internal" protocol stack primitives directly.  When the routing
+facility is used to DUPLICATE or REDIRECT a prim to an external entity, the
+code in gpf/frame/route.c sends a special "wrapper" prim to TST, and we need to
+replicate this wrapping in order to achieve the same effect.
+
+Our solution: we are going to construct a special forwarder entity called L1IF,
+and the connect-by-name calls in l1_pei which normally point to PL, MMI etc
+will point to L1IF instead.  L1IF will run in the passive body variant, and its
+pei_primitive() function will replicate the routing facility's logic for
+forwarding PS primitives to TST.  Whew!