On Thu, 5 Aug 2021 00:52:04 -0300
Marcelo Schmitt [off-list ref] wrote:

[...]

quoted

quoted

Note there is loads of stuff that isn't implemented as it was developed alongside
this patch series to verify individual patches rather than with the intent of
actually emulating the device.
  

OK, will be aware of that.
  

quoted

It's hard coded to 2 a chain of 3 ad7280a devices because that seemed to hit most possible
corner cases.

The top commit has the launch string I'm using.  You'll need a filesystem, but
you can probably use one of the convenient ones debian posts as nocloud cloud
images. 

There is some info on that on people.kernel.org/jic23 as I wrote up how to test
CXL stuff on ARM recently and gave guidance on easy ways to get a filesystem.
http://cdimage.debian.org/cdimage/cloud/sid/daily/20210702-691/debian-sid-nocloud-arm64-daily-20210702-691.qcow2
will probably work and is more recent than the one linked from that blog post.   

I was using a debian imgage created from following the instructions on a
tutorial pointed by the QEMU docs.
https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/
Anyhow, I'll chance to the nocloud one if see things don't get working.
  

quoted

Give me a shout if you need more specific guidance than this very very rough guide!  

Sure, let's see if I can get through it now. Otherwise ...  

I've managed to get it running and see the emulated ad7280a working.
Still getting some trouble with the ad7150 emulation though.
I added a pull request with some comments about the ad7150 emulation on the
github repository. 

Will take a look at some point.  Thanks.

Overall I don't think it was so hacky, I just wonder if it could have been
done more cleanly by passing a custom dtb in the launching string. The hacks
at virt.c are mostly to add the busses, add the device nodes, and connect
device gpio to interrupt lines. We could do it all by editing a dt, right?
Anyhow, thanks a lot for sharing this stuff.

That's the alternative, though you also need to actually create the relevant
devices.  The dtb stuff is lengthy but really simple to do, it's also somewhat
resilient to other changes in how the virt model works (address changes etc).

Given I was there anyway, it seemed easier to do it all in one place.
 

quoted

quoted

I mentioned this thread in the diversion the rust on linux thread took into
use of QEMU to emulate devices which motivated me to stop being lazy and at least
post this hideous version.  Probably the most useful bit is how to get a working
spi device emulated on the arm virt machine as that is very handy for all manner
of testing.  One day someone might implement a large set of IIO device emulation
and bolt it into a CI...  

Agree, it's hard to get IIO drivers runtime tested because we often don't
have the required hardware to do it. I think emulation would help us with
that or, at least, would give us a little bit more confidence in our
changes than just relying on sharp eyes and compile/static tests.
Puching that into a CI would also be rather nice.
  

quoted

Jonathan
  

quoted

quoted

Being able to see it running, I may feel more confident to provide a review
for this set :)    

Guess I've been too optimistic. The way things are going I may take a few
more weeks to have a closer look at all the patches. I'll try to make it
before the next merge window or give up otherwise. It's not reasonable to
ask you wait more since this set has been sitting on the list for so long.

Don't worry about it.  Driver was in staging a long time. It can wait as
long as we know it will move forwards eventually!

Jonathan

[...]