<div dir="ltr"><div dir="ltr">Thanks for the background, David!<div><br></div><div>I've removed the platform in r357086.</div><div><br></div><div>Cheers,</div><div>Jonas</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 27, 2019 at 5:42 AM David Earlam <<a href="mailto:dearlam@qti.qualcomm.com">dearlam@qti.qualcomm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Jonas, <br>
<br>
I agree you can remove Kalimba as a platform.<br>
We'll manage bringing it back upstream should we re-engage with llvm/lldb for Kalimba.<br>
<br>
<br>
<br>
Some background:<br>
<br>
As CSR (Cambridge Silicon Radio plc) we experimented with using lldb for the Kalimba DSP. <br>
CSR plc was acquired by Qualcomm in August 2015 and became Qualcomm Technologies International, Ltd.<br>
<br>
o Kalimba Architecture 3 is a Harvard 24bit word-addressable deeply embedded DSP found in<br>
<a href="https://www.qualcomm.com/products/csr8675" rel="noreferrer" target="_blank">https://www.qualcomm.com/products/csr8675</a> used for Bluetooth aptX stereo headsets and speakers.<br>
<br>
o Kalimba Architecture 4 is a Harvard 32bit octet-addressable deeply embedded DSP and application processor <br>
first used for the multi-core CSRA6810x <a href="https://www.qualcomm.com/media/documents/files/csra68105-product-brief.pdf" rel="noreferrer" target="_blank">https://www.qualcomm.com/media/documents/files/csra68105-product-brief.pdf</a><br>
and now gaining wider adoption in <a href="https://www.qualcomm.com/products/qcc5100-series" rel="noreferrer" target="_blank">https://www.qualcomm.com/products/qcc5100-series</a> and <br>
<a href="https://www.qualcomm.com/products/qcc30xx-series" rel="noreferrer" target="_blank">https://www.qualcomm.com/products/qcc30xx-series</a> based products which are typically <br>
used for Bluetooth aptX HD earbuds, headphones and speakers.<br>
<br>
o Kalimba Architecture 5 is a Harvard 24bit word-addressable deeply embedded audio DSP used in<br>
<a href="https://www.qualcomm.com/products/qualcomm-atlas-7" rel="noreferrer" target="_blank">https://www.qualcomm.com/products/qualcomm-atlas-7</a> - an in-vehicle info and entertainment system-on-chip.<br>
<br>
The word-addressable feature of Architecture 3 and 5 Kalimba was nearly a total blocker for lldb adoption;<br>
an issue also faced by Embecosm for the 16bit AAP.<br>
<a href="http://lists.llvm.org/pipermail/llvm-dev/2017-February/109776.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2017-February/109776.html</a><br>
<br>
Being deeply embedded, the cores provide some other unique system-level challenges for debug, development and test -<br>
including memory regions of different widths, power management, hardware breakpoint and memory patch units that made<br>
lldb not quite right for Kalimba. We also care deeply about optimised code debug fidelity (for example, our toolchain exploits <br>
DWARF's DW_LNS_negate_stmt). <br>
<br>
Such factors meant work was suspended on Kalimba as an lldb target around the time of the Qualcomm acquisition.<br>
<br>
<br>
(*)<br>
Providing infra-structure to run platform tests upstream is somewhat difficult. Development boards and custom debug probes can<br>
be expensive. Often we are creating the development tools for a new chip in advance of any silicon by using FPGAs or proprietary <br>
instruction set simulators that we cannot share. Nor can you usually easily repurpose end-consumer devices <br>
for tool testing because premium audio devices are also costly, run off a battery, and the code and const-data is fixed<br>
in none volatile memory or its debug port is not physically accessible or locked down since it contains an OEM's <br>
intellectual property.<br>
<br>
best regards,<br>
<br>
David Earlam<br>
Staff-Senior Engineer / Manager. <br>
Software  Development Tools.<br>
Qualcomm Technologies International, Ltd.<br>
<br>
-----Original Message-----<br>
From: lldb-dev <<a href="mailto:lldb-dev-bounces@lists.llvm.org" target="_blank">lldb-dev-bounces@lists.llvm.org</a>> On Behalf Of Pavel Labath via lldb-dev<br>
Sent: 27 March 2019 09:32<br>
To: Jonas Devlieghere <<a href="mailto:jonas@devlieghere.com" target="_blank">jonas@devlieghere.com</a>>; LLDB <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>><br>
Subject: [EXT] Re: [lldb-dev] Can we remove this platform?<br>
<br>
On 26/03/2019 23:16, Jonas Devlieghere via lldb-dev wrote:<br>
> Yesterday I stumbled upon the initialization code for the "Kalimba" <br>
> platform. It looks like this was added in 2014 and never had any tests. <br>
> If nobody is relying on this platform, I propose to remove it.<br>
> <br>
> Review: <a href="https://reviews.llvm.org/D59850" rel="noreferrer" target="_blank">https://reviews.llvm.org/D59850</a><br>
> <br>
> Thanks,<br>
> Jonas<br>
> <br>
<br>
Sounds good to me. I've had to touch this file a couple of times in the past due to interface changes, and I came close to proposing the same thing.<br>
<br>
<br>
[To be fair, none of the other platforms (except a single PlatformDarwin <br>
tests checking one very particular aspect of it) have specific tests <br>
either, though most of their code would be exercised if you run the test <br>
suite against a target supported by that particular platform. However, I <br>
doubt anyone if doing that for PlatformKalimba these days.]<br>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div>