FreeCalypso > hg > fc-tourmaline
annotate doc/C139-notes @ 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 |
rev | line source |
---|---|
50
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
1 FC Tourmaline firmware differs from Magnetite in two principal ways when it |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
2 comes to Mot C139 target support: |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
3 |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
4 * C139 LCD support is implemented in a more forward-looking manner: instead of |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
5 emulating TI's C-Sample at the lowest R2D driver level and therefore being |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
6 forever limited to 84x48 pixel display size, Tourmaline implements a new |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
7 96x64 pixel framebuffer, matching the native LCD size of C1xx phones. The UI |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
8 configuration is still black&white only though - the Mother of FreeCalypso |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
9 has no current plans to support color UI on smaller LCD sizes than TI's |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
10 original 176x220 pix. |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
11 |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
12 * Our aftermarket FFS configuration has been changed from 64x3 at 0x3C0000 to |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
13 64x7 at 0x300000. Our earlier 64x3 config was chosen back in 2015, at that |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
14 time we didn't know how much room we would end up needing for the firmware |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
15 image vs. how much FFS content we would eventually have, and this 64x3 config |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
16 is now deemed to be too small, allowing only one 64 KiB sector for FFS |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
17 content. Our new FC Tourmaline aftermarket FFS config supports up to 320 KiB |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
18 of FFS content, matches what we use on other platforms with 4 MiB flash chips, |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
19 leaves 3 MiB for the firmware image (our current smallbw UI fw is only 2 MiB), |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
20 and still avoids intersection with Motorola's (or rather Compal's) original |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
21 FFS, which is important for avoiding problems in converting C139 phones back |
a62e5bf88434
first round of documentation
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
22 and forth between Motorola and FreeCalypso firmwares. |