Re: [Qemu-devel] Simulating 3 chips on one board

[Alistair Francis]

On Wed, Sep 28, 2016 at 4:36 PM, Alex Bennée <address@hidden> wrote:
>
> Seth K <address@hidden> writes:
>
>> I need to simulate 3 chips that are on one board and that talk to each
>> other through UART, SPI and GPIO. The chips verify each other's work, and I
>> need to be able to observe this communication for debugging. Can something
>> like this be done in QEMU?
>
> As Peter has mentioned this isn't supported by upstream. There are a
> number of out-of-tree QEMU's that have attempted to solve this problem
> which you might want to look at. Typically this involves some sort of
> IPC interface to share machine details. The one I'm aware of is the
> Xilinx Zynq:
>
>     
> http://www.wiki.xilinx.com/x--Running%20a%20Zynq%20UltraScale+%20Linux%20Kernel%20Image%20On%20Xilinx's%20ARM/PMU%20QEMU
>
> You might want to look at how they do things for some ideas. I'm afraid
> I've never run it myself so you'll have to investigate.

The Xilinx solution might be a good place to start. We use remote port
(which is a communication framework on top of TCP/unix sockets) to
communicate between different instances of QEMU in different
processes. It's pretty cool!

That wiki Alex mentioned is a good place to start. Everything we do is
public on GitHub and available to use.

Thanks,

Alistair

>
>>
>> My first thought was to create the chip then create a board/machine with 1
>> chip, and run 3 instances of QEMU on the host and have them talk to each
>> other via the host (/dev/uart7 for example) but that doesn't seem to be
>> possible. It seems QEMU cannot output 8 UARTS (I can't get more than 1) or
>> any GPIOs. Is that correct? Not sure about SPIs either.
>>
>> My next thought was to make 1 board with all three chips, but have some way
>> to sniff the UARTs/SPIs/GPIOs between chips. Is that possible in QEMU?
>
> I suspect the first approach is going to be the easier one to do. You
> could use sockets to link multiple QEMUs together but its probably a
> fair bit of work to get to that point.
>
> Some precursor work for building a heterogeneous QEMU (with multiple CPU
> types) was merged but I think the effort has stalled somewhat and needed
> a lot more work doing.
>
> --
> Alex Bennée
>