Hi Jonas,
I agree you can remove Kalimba as a platform.
We'll manage bringing it back upstream should we re-engage with llvm/lldb for Kalimba.
Some background:
As CSR (Cambridge Silicon Radio plc) we experimented with using lldb for the Kalimba DSP.
CSR plc was acquired by Qualcomm in August 2015 and became Qualcomm Technologies International, Ltd.
o Kalimba Architecture 3 is a Harvard 24bit word-addressable deeply embedded DSP found in
Qualcomm CSR8675 SoC | Low-Power Audio Headset Chipset | Qualcomm used for Bluetooth aptX stereo headsets and speakers.
o Kalimba Architecture 4 is a Harvard 32bit octet-addressable deeply embedded DSP and application processor
first used for the multi-core CSRA6810x https://www.qualcomm.com/media/documents/files/csra68105-product-brief.pdf
and now gaining wider adoption in QCC5100 Series | Bluetooth 5.0 Chipset for Headsets and Speakers | Qualcomm and
QCC30xx Series | Bluetooth Earbud and Headset Chipsets | Qualcomm based products which are typically
used for Bluetooth aptX HD earbuds, headphones and speakers.
o Kalimba Architecture 5 is a Harvard 24bit word-addressable deeply embedded audio DSP used in
Qualcomm Atlas 7 | CSR atlas7 Automotive Audio Product - an in-vehicle info and entertainment system-on-chip.
The word-addressable feature of Architecture 3 and 5 Kalimba was nearly a total blocker for lldb adoption;
an issue also faced by Embecosm for the 16bit AAP.
http://lists.llvm.org/pipermail/llvm-dev/2017-February/109776.html
Being deeply embedded, the cores provide some other unique system-level challenges for debug, development and test -
including memory regions of different widths, power management, hardware breakpoint and memory patch units that made
lldb not quite right for Kalimba. We also care deeply about optimised code debug fidelity (for example, our toolchain exploits
DWARF's DW_LNS_negate_stmt).
Such factors meant work was suspended on Kalimba as an lldb target around the time of the Qualcomm acquisition.
(*)
Providing infra-structure to run platform tests upstream is somewhat difficult. Development boards and custom debug probes can
be expensive. Often we are creating the development tools for a new chip in advance of any silicon by using FPGAs or proprietary
instruction set simulators that we cannot share. Nor can you usually easily repurpose end-consumer devices
for tool testing because premium audio devices are also costly, run off a battery, and the code and const-data is fixed
in none volatile memory or its debug port is not physically accessible or locked down since it contains an OEM's
intellectual property.
best regards,
David Earlam
Staff-Senior Engineer / Manager.
Software Development Tools.
Qualcomm Technologies International, Ltd.