Re: Qemu qurt and fastrpc?

["Dr. David Alan Gilbert" <dave@treblig.org>]

* Brian Cain (brian.cain@oss.qualcomm.com) wrote:

Hi Brian, Mohamed,
  Thanks for your replies.

> On 11/1/2026 5:41 PM, Mohamed Mediouni wrote:
> > 
> > > On 1. Nov 2026, at 23:05, Dr. David Alan Gilbert <dave@treblig.org> wrote:
> > > 
> > > Hi Brian,
> > >   I tried your hexagon support booting qurt images, very nice!
> > > I did:
> > > 
> > >   ./qemu-system-hexagon -M virt  -kernel ./qccdsp8380.mbn -nographic
> > > 
> > > and got something believable.
> > > 
> > >   Do you have glue that lets you run comms to the emulated qurt via
> > > fastrpc in the same way that, say a Llama running on a normal
> > > Linux host would?
> > >   It feels useful for debugging/watching what maths kernels are
> > > doing.
> > Hi,
> > 
> > There’s no FastRPC… however:
> 
> Until we have heterogeneous TCG + ARM apps CPUs + SMMU + SMEM/cmd-db + DSP
> machine it's not likely to support FastRPC as-is.  This seems like it's
> quite a ways away, unfortunately. But we could conceivably craft something
> that resembles glink/fastrpc using ivshmem + doorbells.  That seems very
> do-able.

Yeh it was that kind of hack I was wondering about; although just specifying
the Hexagon Qemu's guest memory as backed by a shared-memory file (like vhost-user)
would then let another process (i.e. the fastrpc library) read/modify the hexagon
ram.  So then the question is what doorbell-like things were needed.

My thoughts were something like a modified fastrpc library that spawned the qemu
(or connected to one), mmap'd the qemu's hexagon ram and then did...something to
do doorbell like things (e.g. maybe using qmp to read/write to the guest with
no change to the guest).
But no urgency etc, I might have a play.


> > You can download the Hexagon SDK from https://softwarecenter.qualcomm.com/catalog/item/Hexagon_SDK
> > 
> > That comes with a version of QuRT that is semi-hosted as runelf.pbn.
> > 
> > A working QuRT loading on top of that (w/ a semi-hosted -M option):
> > 
> > -kernel /opt/Hexagon_SDK/6.7.0.0/rtos/qurt/computev75/sdksim_bin/runelf.pbn \
> > -append '/opt/Hexagon_SDK/6.7.0.0/libs/run_main_on_hexagon/ship/hexagon_toolv19_v75/run_main_on_hexagon_sim -- libmain.so'
> 
> Indeed - sorry, should have some docs on how to do this coming Real Soon
> Now.  But that's the gist of it.

This one is a little less interesting from my side, I was more interested
in using the qemu as a way to see what was going on inside a running
fastrpc app.

> > The QEMU on Hexagon inside of the Hexagon also (used to) comes with an oddball QEMU Hexagon
> > version inside the package that has HMX emulation as a closed-source module, but that’s a
> > separate story that is going to be wound down thankfully.
> > 
> > If you don’t want to use the Hexagon SDK, there’s another option through hexagon-hypervisor which
> > has a very partial QuRT compat story. Or outright Linux on Hexagon which works too…
> > 
> > The (modern) kernel tree for Linux on Hexagon being at https://git.kernel.org/pub/scm/linux/kernel/git/bcain/linux.git/log/?h=hexagon
> 
> Yeah, now that we have a decent basis in QEMU, I'll work on upstreaming
> those kernel changes.  Some have been reviewed on-list already.
> 
> 
> > A pre-built artefact exists at https://artifacts.codelinaro.org/ui/native/codelinaro-toolchain-for-hexagon/23.1.2/qcs6490-cdsp/ with the booter at https://artifacts.codelinaro.org/ui/native/codelinaro-toolchain-for-hexagon/23.1.2/hexagon-hypervisor/
> 
> The h2 hypervisor is also available as a prebuilt rom in QEMU now, which is
> convenient for booting linux.  That h2 won't forward the QEMU-synthesized
> device tree pointer yet though :( - so it's probably easiest to build your
> kernel with its own internal DTB.
> 
> 
> > >   (Not urgent, I'm just trying to get my head around it on my
> > > X1 laptop)
> 
> If you want an X1 CDSP machine in QEMU - let me know.  We can include one in
> 12.0.  We did include the X2 CDSP - it's SC8480XP.

For me that would probably be useful only with the hack mentioned at the top
to allow a fastrpc use; but given the number of X1's out there it's probably
not a bad idea.

Thanks again.

Dave

> 
> > > 
> > >   Thanks in advance,
> > > 
> > > Dave
> > > -- 
> > > -----Open up your eyes, open up your mind, open up your code -------
> > > / Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \
> > > \        dave @ treblig.org |                               | In Hex /
> > > \ _________________________|_____ http://www.treblig.org   |_______/
> > > 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/