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!