diff options
Diffstat (limited to 'results/classifier/105/other/1833101')
| -rw-r--r-- | results/classifier/105/other/1833101 | 92 |
1 files changed, 92 insertions, 0 deletions
diff --git a/results/classifier/105/other/1833101 b/results/classifier/105/other/1833101 new file mode 100644 index 00000000..4618ceb2 --- /dev/null +++ b/results/classifier/105/other/1833101 @@ -0,0 +1,92 @@ +other: 0.973 +semantic: 0.966 +device: 0.963 +instruction: 0.961 +vnc: 0.949 +assembly: 0.947 +mistranslation: 0.937 +graphic: 0.926 +socket: 0.923 +KVM: 0.920 +network: 0.905 +boot: 0.899 + +vexpress-a9 (but not -a15) creates two pl111 LCDs due to duplicate sysbus_create_simple("pl111", ...) calls + +Hi, + +Just a small report that (12ec8bd is current master) + +https://github.com/qemu/qemu/blob/12ec8bd/hw/arm/vexpress.c#L652: + + ... + vexpress_common_init() { + ... + sysbus_create_simple("pl111", map[VE_CLCD], pic[14]); + ... + ... + +and + +https://github.com/qemu/qemu/blob/12ec8bd/hw/arm/vexpress.c#L304: + + ... + a9_daughterboard_init() { + ... + sysbus_create_simple("pl111", 0x10020000, pic[44]); + ... + ... + +result in two LCD panels when using vexpress-a9. + +vexpress-a15 does not appear to be affected (my -a9 kernel does not work with it, but I see only one pl111 created). + +Understandably (but still annoyingly), -nodefaults has no effect. + +This bug is most evident when using SDL (so I can use ",frame=off"), which dumps two top-level windows onto the screen. GTK hides this because, coincidentally, the pl111 that ends up being used is the one that is selected (possibly the one created last?), relegating this to an obscure glitch only noticeable if you scrutinize the menu. + +This is a bugreport as opposed to a pull request as I have no idea which call to remove - and complete ignorance of the potential housekeeping and consideration that may be warranted first. + +FWIW, a simple testcase can be made with the vmlinuz from https://people.debian.org/~aurel32/qemu/armhf/ and + +qemu-system-arm -M vexpress-a9 -kernel vmlinuz-3.2.0-4-vexpress -nodefaults -sdl + +Thanks! + +Our vexpress-a9 model instantiates two PL111s because the hardware has two PL111s. One is on the daughterboard, at address 0x10020000, and the other is on the motherboard, at address 0x40001F000. + +The vexpress-a15 hardware has only one PL111, which is why you only see one being created for that hardware. (Instead it has one PL111 and one HDLCD controller, but QEMU has no model of the HDLCD controller at the moment. We might add one one day.) + +In an ideal world we would implement the video multiplexing that the hardware does to allow the guest to select which of the two display devices gets to send output (this is controlled by the SYS_CFG_MUXFPGA system configuration register), at which point we'd be able to only show a single screen window. + + +Ah. + +:) + +As is probably somewhat evident at this point, I'm using vexpress-a9 because it's such a convenient QEMU target, rather than because I have real hardware anywhere. + +Hm, I didn't once stop and think that maybe there actually were two LCD controllers. (And this is where software is great; I got to learn my assumptions were invalid without blowing anything up. :D) + +I tried to find the actual Versatile Express board I'm "using"; the closest I was able to come was https://community.arm.com/developer/tools-software/tools/b/tools-software-ides-blog/posts/50-off-arm-versatile-express-development-boards. It looks like it has two (...three?) processors and four PCIe slots. Very nice. + +Thanks again. + +You might want to check our advice on how to pick a machine type for Arm: https://wiki.qemu.org/Documentation/Platforms/ARM#Guidelines_for_choosing_a_QEMU_machine +Basically we suggest 'virt' unless you have a strong reason for wanting to emulate something else. + +NB that we don't support PCI in our vexpress model (this is one reason we don't recommend it, it makes it a bit inflexible). + + +Thanks for following up, and helping me figure some things out. + +I coincidentally stumbled on https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/ a few days ago, landed on the page you linked, and immediately wanted to try it. + +Thanks very much for prompting me to properly think^Wmuddle through and properly model the fussy details of my situation so I could finally see a solution :) + +I happen to be fiddling with an ARMv8 binary built with a Squeeze-era /usr/lib, so I was using vexpress-a9 primarily because a prebuilt Squeeze environment was available from https://people.debian.org/~aurel32/qemu/armel/, and I was able to copy over the /lib/modules/ and kernel image from https://people.debian.org/~aurel32/qemu/armhf/ and have a working system. + +...And so obviously I can get more or less the same result by putting a chroot of my current setup on top of a newer kernel and userspace. Duh/facepalm. That looks to be my next step. Perhaps I'll use Alpine so the environment boots quickly :D (I find Jessie takes 3min, while Wheezy takes 60sec... that was one of my hesitations to fiddle too much actually) + +But first stop, a (prebuilt, most definitely definitely prebuilt) cross compiler. I don't NEED to make my laptop get to 72°C :) + |