view doc/Blob-status @ 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

State of blobs in FreeCalypso firmware
======================================

FC Tourmaline is almost completely deblobbed.  Only the following very small
components exist in the form of blobs (prebuilt binary objects for which we
have no exact corresponding source) in the standard Tourmaline build:

* OSL and OSX glue components of GPF: 14992 bytes of code
* TMS470 compiler's RTS library (libc/libgcc equivalent): 13152 bytes of code

For OSL and OSX we do have reconstructed C code written based on disassembly of
the blobs, but I (Mother Mychaela) do not consider the current state of this C
reconstruction to be fit for production use - hence standard Tourmaline fw
builds use blob versions of these components.  However, our configuration and
build system gives you the freedom to select which version of each component
you would rather use; the selection is made with Bourne shell config variables
on the configure.sh invokation line:

OSL=0	use the blob version of OSL
OSL=1	use the reconstructed C version of OSL
OSX=0	use the blob version of OSX
OSX=1	use the reconstructed C version of OSX

The current default is OSL=0 and OSX=0.

RTS library
===========

We do have source code for some versions of the TMS470 compiler's RTS library,
but they may not be exactly corresponding to the blob version from TCS211 which
we are using.  This area is deemed to be such a low priority that no real
investigation has been done yet.