FreeCalypso > hg > freecalypso-citrine
comparison L1/stand/README @ 0:75a11d740a02
initial import of gsm-fw from freecalypso-sw rev 1033:5ab737ac3ad7
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Thu, 09 Jun 2016 00:02:41 +0000 |
| parents | |
| children |
comparison
equal
deleted
inserted
replaced
| -1:000000000000 | 0:75a11d740a02 |
|---|---|
| 1 In their internal development environment, TI had a way to build L1 standalone, | |
| 2 i.e., omitting the G23 protocol stack and other large and complex pieces of the | |
| 3 full firmware. Such an ability is essential for sane development, and the | |
| 4 abundant references to OP_L1_STANDALONE throughout the codebase confirm that TI | |
| 5 had it indeed. | |
| 6 | |
| 7 However, we (FreeCalypso) don't have a way to build an OP_L1_STANDALONE image | |
| 8 exactly the way TI did it - we don't have all of the necessary source - the | |
| 9 glue pieces specific to this configuration are missing. Nor do we necessarily | |
| 10 need to imitate what TI did in this department: it appears that TI's standalone | |
| 11 L1 build omitted GPF (with the exception of OS and OSX) and everything that | |
| 12 lives in Riviera land, but for us the situation is different: we already have | |
| 13 a successful build with Riviera and GPF, but no L1, thus we simply need to add | |
| 14 L1 to what we have. Our idea of standalone L1 simply means building without | |
| 15 the G23 stack, which we have yet to begin integrating. | |
| 16 | |
| 17 In the standard firmware build, there is a component called L1 PEI. It is part | |
| 18 of the G23 stack, and has header and library dependencies of the latter - thus | |
| 19 it is *not* part of the L1 code proper. However, it performs some essential | |
| 20 initialization steps, and runs the L1A task. We don't know how TI handled | |
| 21 these functions in their standalone L1 build - we don't have that part of their | |
| 22 source, not even in the otherwise complete LoCosto version, not even if we were | |
| 23 targeting LoCosto hardware. | |
| 24 | |
| 25 Our solution: we are going to lift l1_pei out of LoCosto's g23m-gsm, and hack | |
| 26 up a special version of it that won't have the standard complement of G23 | |
| 27 header and library dependencies. It is virtually certain that TI did something | |
| 28 different, but our hack-solution should work for our needs. | |
| 29 | |
| 30 Because our standalone L1 build is a specially stripped-down version of the | |
| 31 regular fw build, and not at all like TI's standalone L1, we do NOT define | |
| 32 OP_L1_STANDALONE. Instead we have a different preprocessor symbol: | |
| 33 CONFIG_L1_STANDALONE. | |
| 34 | |
| 35 The standard version of l1_pei calls vsi_c_open() to get queue handles of | |
| 36 several G23 stack entities; it connects by name to "PL", "MMI", and if GPRS is | |
| 37 enabled, also to "GRR", "LLC" and "SND". If we leave these connect-by-name | |
| 38 calls unchanged in our L1 standalone version, our pei_init() will always return | |
| 39 PEI_ERROR and never successfully initialize, which would not be very useful. | |
| 40 If we removed these vsi_c_open() calls and the associated OSX queue setup, the | |
| 41 first osx_send_prim() addressed to the queue in question will crash, so that | |
| 42 approach wouldn't be useful either. | |
| 43 | |
| 44 What we would like to do is redirect all outbound messages emitted by our | |
| 45 standalone L1 to the debug serial interface, using GPF's TST entity, just as if | |
| 46 an L1 REDIRECT or DUPLICATE command was given to a complete GSM fw image. | |
| 47 However, simply connecting our queues to TST won't work, as TST is not designed | |
| 48 to receive "internal" protocol stack primitives directly. When the routing | |
| 49 facility is used to DUPLICATE or REDIRECT a prim to an external entity, the | |
| 50 code in gpf/frame/route.c sends a special "wrapper" prim to TST, and we need to | |
| 51 replicate this wrapping in order to achieve the same effect. | |
| 52 | |
| 53 Our solution: we are going to construct a special forwarder entity called L1IF, | |
| 54 and the connect-by-name calls in l1_pei which normally point to PL, MMI etc | |
| 55 will point to L1IF instead. L1IF will run in the passive body variant, and its | |
| 56 pei_primitive() function will replicate the routing facility's logic for | |
| 57 forwarding PS primitives to TST. Whew! |
