FreeCalypso > hg > fc-tourmaline
view doc/Blob-status @ 78:c632896652ba
mfw/ti1_key.c: properly initialize notified_keys array
The code in this ti1_key.c layer needs to call kpd_subscribe() and
kpd_define_key_notification() functions in order to register with the
KPD driver. The original code passed KPD_NB_PHYSICAL_KEYS in
nb_notified_keys - this constant is defined to 24 in kpd_cfg.h on all
platforms of interest to us - but it only filled the first 23 slots
in the notified_keys array, resulting in stack garbage being passed
to KPD API functions. The fix consists of initializing the last
missed array slot to KPD_KEY_RECORD, the key ID for the right side
button on the D-Sample handset.
On our current hw targets this "Record" button exists as the EXTRA
button on our Luna keypad board and as the camera button on the
Pirelli DP-L10. There is no support whatsoever for this button
in current BMI+MFW, we have no plans of doing anything with Pirelli's
camera button even if we do get our UI fw running on that phone,
and the Mother's dream of building our own FreeCalypso handset with
the same button arrangement as D-Sample (including the right side
button) is currently very nebulous - but let us nonetheless handle
the full set of buttons on the KPD to MFW interface, and let upper
layers weed out unsupported buttons.
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sun, 25 Oct 2020 23:41:01 +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.