Rob Landley (ele "passou meio ano trabalhando para obter o Linux" na Qualcomm & quic) tem algumas anotações sobre o fórum. Foi placa interna da Qualcomm com Snapdragon não especificado e 256 MB ou RAM, algumas redes e nenhum armazenamento local. O Chip pode ser o mesmo do Nexus One: QSD8250 (Snapdragon S1), com alguns QDSP6 em 600 MHz fabricados em 65 nm, provavelmente qdsp6 V2.
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.
Hipervisor minivm público de 2013 - link é apenas para v2 e v3: link "Esta implementação é executada apenas nas arquiteturas Hexagon v2 e v3."
A origem do Minivm está lá: link
#define TLB_ENTRIES 64 * V2/V3 User/Supervisor Strategy: * MSB of ASID is used for User/Supervisor.
Os parâmetros do QDSP6v2 (600MHz / 6 threads) são codificados na fonte do Linux também: link
/*
* 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.
E algum simulador é suportado também (não tenho certeza se é hexagonal ou não)
/*
* 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;
O código Linux foi escrito por volta de 2009-2010: link
* 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