On Wed, Sep 28, 2016 at 4:36 PM, Alex Bennée <alex.ben...@linaro.org> wrote: > > Seth K <skint...@gmail.com> 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 >
