On 3 November 2016 at 18:56, Brooke Wallace <bwall...@ramlabs.com> wrote: > Thanks for the sympathy Peter. Unfortunately the lack of documentation > and reasonable introductory guide is making this a non-starter for us.
Yeah, I was surprised there wasn't a decent guide to getting the 'virt' board working; I've spent this afternoon writing up a blog post describing how to get Debian working on it, which I'll finish off and publish this evening. > 2. I still don't understand why I can't map the disk image > "arm_root.img" to my host. > $ sudo mount -t auto -o loop arm_root.img /mnt/qemu > mount: wrong fs type, bad option, bad superblock on /dev/loop1, > missing codepage or helper program, or other error initrd images aren't the same thing as disk images (they're usually gzipped, and may be cpio archives rather than actual filesystems). I would really forget about this ancient image, it is just leading you down the wrong path. > I'll can give "virt" a try, but I'm looking for a working > example that can be mapped to real hardware, eg. RaspberryPI, > Beagle Bone Black or something similar. Working in a emulation > for a virtual machine does me no good. Our goal is to emulate > actual hardware and ultimately understand how to modify QEMU > to add hooks and add emulations for new hardware. We have a raspi2 model, but it is a bit half-finished, so it won't actually boot current Raspbian. (It is supposedly able to boot Windows...) You can play with that if you like but you'll be spending a lot of time figuring out how to fix bugs in the device emulation. On the other hand, if you are interested in learning about how device models work then fixing bugs in an existing model might be a good way to start. Let me know if you'd like to try going down this path and I'll look up the current state of this (ie command lines and images that work up until the point where the kernel falls over because it wants to talk to a device that isn't in our model). Note that although "virt" is not a piece of real hardware, the principles of what an emulated machine looks like are still very similar, and it does include numerous components that are exactly models of real hardware (like the interrupt controller, serial ports, GPIO controller...) The only difference from our models of 'real hardware' is that: * it is free to include devices that are useful even if there isn't an SoC in the world that happens to have them (like the PCI controller) * it doesn't need to bother to model silly details of real hardware (like only having 256MB of RAM or having PS/2 keyboard and mouse ports, or whatever) So it sounds to me like it might be pretty much as good for your purposes as the 'raspi2' model would be. > I can see that lack of any API for adding emulations, or > documentation of an API is also going to be an issue for > us here as well when considering whether or not to invest > our time in this effort. We don't have public-facing device documentation, no. We've been trying to enforce having documentation comments in the header files for new APIs, but old ones still have no documentation and there's a bit of a lack of overview-level guides. This is all something we'd like to do better with. > I know that QEMU is part of the Android emulation, and I > wonder if going that route may be more productive - > although were really not interested in android. I think you will find it no different in the areas that you are having difficulty with. (The android emulator is also a "virtual" platform that's not real hardware, for instance, and the codebase is pretty much the same except with a lot of extra code for Android-emulator specific handling of OpenGL and so on.) thanks -- PMM
