FreeCalypso > hg > fc-tourmaline
view README @ 220:0ed36de51973
ABB semaphore protection overhaul
The ABB semaphone protection logic that came with TCS211 from TI
was broken in several ways:
* Some semaphore-protected functions were called from Application_Initialize()
context. NU_Obtain_Semaphore() called with NU_SUSPEND fails with
NU_INVALID_SUSPEND in this context, but the return value wasn't checked,
and NU_Release_Semaphore() would be called unconditionally at the end.
The latter call would increment the semaphore count past 1, making the
semaphore no longer binary and thus no longer effective for resource
protection. The fix is to check the return value from NU_Obtain_Semaphore()
and skip the NU_Release_Semaphore() call if the semaphore wasn't properly
obtained.
* Some SPI hardware manipulation was being done before entering the semaphore-
protected critical section. The fix is to reorder the code: first obtain
the semaphore, then do everything else.
* In the corner case of L1/DSP recovery, l1_abb_power_on() would call some
non-semaphore-protected ABB & SPI init functions. The fix is to skip those
calls in the case of recovery.
* A few additional corner cases existed, all of which are fixed by making
ABB semaphore protection 100% consistent for all ABB functions and code paths.
There is still one remaining problem of priority inversion: suppose a low-
priority task calls an ABB function, and some medium-priority task just happens
to preempt right in the middle of that semaphore-protected ABB operation. Then
the high-priority SPI task is locked out for a non-deterministic time until
that medium-priority task finishes its work and goes back to sleep. This
priority inversion problem remains outstanding for now.
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Mon, 26 Apr 2021 20:55:25 +0000 |
| parents | a62e5bf88434 |
| children |
line wrap: on
line source
FreeCalypso Tourmaline firmware project ======================================= In chronological terms, FC Tourmaline is our fourth firmware offering after Citrine, Magnetite and Selenite. FC Tourmaline supports the following two fundamental modes of operation: * AT-command-controlled modem operation (no UI) is currently unchanged from Magnetite hybrid; standard modem operation is supported on Tango/Caramel2, FCDEV3B and Openmoko hardware targets. * The new work being done in Tourmaline is phone handset functionality - the goal is to produce firmware that can operate a suitable hardware unit as an untethered end user phone. Only two hardware targets are supported in this FC Tourmaline handset UI development venture: FC Luna development platform and Motorola C139. See the following articles under doc for further details: C139-notes -- running smallbw version of the UI on Mot C139 Luna-notes -- running both UI versions on FC Luna Modem-operation -- using the modem configuration Technical details ================= Just like FC Selenite, Tourmaline is derived from the hybrid config of Magnetite. Also in common with Selenite, Tourmaline uses the new source version of Nucleus. However, unlike Selenite, Tourmaline retains sole use of the original TMS470 compiler (runs under Wine), retains the original blob versions of OSL and OSX glue components of GPF in the default config (see doc/Blob-status), and includes both modem and handset functional configs. Purpose and goal ================ As of late 2020, FreeCalypso has achieved everything that needs to be done on the modem side: our Magnetite hybrid or Tourmaline stdmodem firmware running on our Tango modem module embodies complete fulfillment of our long-standing desire for a standard GSM+GPRS modem module with fully published circuit schematics and firmware source code. No more significant work beyond maintenance is deemed to be needed on the modem side. OTOH, the other need for a FreeCalypso handset that can replace proprietary phones like Mot C1xx or Pirelli DP-L10 running their original proprietary fw still remains as unmet as it was when we started back in 2013. Thus the new FreeCalypso work direction is to finally produce this FC handset, initially in the form of FC firmware running on Mot C139 (and on FC Luna to keep up the bigcolor config) and allowing the possibility of new FreeCalypso handset hw. Seen from the perspective of handset rather than modem functionality, the direction taken in Citrine and Selenite (going for 100% blob-free compilation with gcc) is the wrong way to go. That direction would make sense if one cared only about modem functionality rather than handset, but we are currently in the opposite situation. In the case of handset functionality, going for a compiler change to gcc in our current state when so many other parts are broken and in need of fixing would be pure insanity, and we are not going there. Let us first produce a working FreeCalypso handset (with fw compiled with TMS470 under Wine, keeping the tiny remaining blobs) that can replace Mot/Pirelli's original proprietary firmwares for daily use, and *then* think about moving to 100% blob-free gcc - in this order.