The Linux mainline kernel includes support for the Qualcomm Hexagon DSP architecture in arch/hexagon. The maintainer listed in MAINTAINERS is:
QUALCOMM HEXAGON ARCHITECTURE
M: Richard Kuo <rkuo@codeaurora.org>
L: linux-hexagon@vger.kernel.org
S: Supported
F: arch/hexagon/
The file arch/hexagon/configs/comet_defconfig contains a defconfig for a board called the "Comet Board" according to arch/hexagon/Kconfig.
What is this Comet board? Who made it?
Rob Landley (he "spent half a year working to get Linux on it" in the Qualcomm&quic) have some notes about the board. It was board internal to Qualcomm with unspecified Snapdragon and 256 MB or RAM, some networking and no local storage. The Chip may be same as in Nexus One: QSD8250 (Snapdragon S1), with some QDSP6 on 600 MHz fabricated on 65 nm, probably qdsp6 V2.
https://landley.net/notes-2012.html#24-02-2012
People keep asking me about Qualcomm's Hexagon in email, and I keep writing up long explanations and then never them again. So here's the most recent email I wrote on the topic, for posterity. It's been a year and a half, the basics of what we worked on shipped already, the story can come out now.
Keep in mind my contract to work on this stuff expired in October 2010, so these are my vague recollections from over a year ago: ...
They had an in-house simulator that was some horrible proprietary thing they contracted out to a third party to produce, and if I recall right qualcomm's lawyers went out of their way to make sure they didn't get source code because there was a nest of "propreitary is obviously better, duh". I expect that bit them in the ass, because the sucker was useless to the Linux port.
Mostly we just used real hardware. We had these things called "comet" boards that had a snapdragon SOC and ~256M of memory which you could boot and run code on. (No local storage to speak of, I wound up implementing nbd-client in busybox to get some.)
There was an aborted attempt to add hexagon support to qemu (Scott somebody did it, ...). Unfortunately, the guy who tried it couldn't wrap his head arount TCG (I think he was mostly a manager), and it never went anywhere. :( ...
As far as Linux is concerned, it's a 6-way SMP chip running at 100mhz, but each cycle it can dispatch up to 4 instructions so you get back closer to 300mhz performance ...
The snapdragon system-on-chip (which is what you find in the Nexus One and such) actually contains four processors:
1) An ARMv7 "Scorpion" processor qualcomm licensed from ARM and then optimized (at the Raleigh campus, they're protective of their turf, internal politics at qualcomm).
2) A QDSP6 "Scorpion" processor qualcomm developed internally (in Austin). In android this is used as a "multimedia coprocessor", but is actually a powerful 4-issue VLIW general purpose processor with a lot of vector instructions. ...
For the Linux port we powered the other 3 processors down after the Hexagon came up. I really really really wanted a bootloader I could run as an Android app on my Nexus One to boot Linux on the hexagon in that (copy the uboot and kernel+initramfs blobs into memory, kick the ARMv5 boot processor to run that uboot, halt the ARM), but I could never get Richard Kuo or anybody to write one. (And it wouldn't have been useful unless I got at least a usb-to-serial adapter working to get me a serial console, which turned out to be nontrivial. All the Snapdragon peripheral drivers were in the Android tree, but under arch/arm. One of the big things the Linutronix guys were looking at was fishing them out and moving them up to the generic architecture stuff so Hexagon could use 'em. No idea if they ever actually did this.) ...
A note on the MMU: the chip hasn't actually got one. Instead it has a set of Translation Lookaside Buffer slots loaded by software. They made a binary blob that acts as an MMU, and their snapdragon port of u-boot (running in the armv5 boot processor, I think) loads this blob and hooks it up to the page fault interrupt so it acts as a software mmu (which their Linux port then depends on).
The main problem with the Hexagon variant in the existing Snapdragon chips (um, QDSP6v2 I think) is that they don't have enough TLB slots. If you run the full 6-way SMP doing gcc compiles and such, it thrashes the hell out of the cache and slows itself way down. The performance "sweet spot" for that turned out to be around -j3 or -j4 in my testing. I don't think we found this out soon enough to fix QDSP6v3 (although since that's the 4-stage 500mhz variant, it puts less presure on the TLB anyway so is more or less in the sweet spot of what they do have). But QDSP6v4 (in development when I left) adds lots more TLB slots which should greatly improve performance under Linux.
Public minivm hypervisor from 2013 - http://permalink.gmane.org/gmane.linux.ports.hexagon/553 is for v2 and v3 only: https://www.codeaurora.org/projects/all-active-projects/hexagon-minivm "This implementation only runs on Hexagon architectures v2 and v3."
Minivm source is there: https://source.codeaurora.org/quic/hmvm/hexagonMVM/tree/minivm.S
#define TLB_ENTRIES 64 * V2/V3 User/Supervisor Strategy: * MSB of ASID is used for User/Supervisor.
QDSP6v2's parameters (600MHz / 6 threads) are hardcoded in the linux source too: http://elixir.free-electrons.com/linux/v4.12.3/source/arch/hexagon/kernel/setup.c#L56
/*
* These will eventually be pulled in via either some hypervisor
* or devicetree description. Hardwiring for now.
*/
pcycle_freq_mhz = 600;
thread_freq_mhz = 100;
sleep_clk_freq = 32000;
...
* This is just really brutal and shouldn't be used anyways,
* especially on V2. Left here just in case.
And some simulator is supported too (not sure is it hexagon-sim or not)
/*
* Simulator has a few differences from the hardware.
* For now, check uninitialized-but-mapped memory
* prior to invoking setup_arch_memory().
*/
if (*(int *)((unsigned long)_end + 8) == 0x1f1f1f1f)
on_simulator = 1;
Linux code was written around 2009-2010: http://elixir.free-electrons.com/linux/v4.12.3/source/arch/hexagon/lib/memcpy.S
* History
*
* DJH 5/15/09 Initial version 1.0
* DJH 6/ 1/09 Version 1.1 modified ABI to inlcude R16-R19
* DJH 7/12/09 Version 1.2 optimized codesize down to 760 was 840
* DJH 10/14/09 Version 1.3 added special loop for aligned case, was
..
* DJH 4/23/10 version 1.6
