On Wed, Jan 06, 2016 at 06:27:54PM +0000, Andrew Baumann wrote: > Hi Piotr, > > Sorry, I just noticed this email. Please keep me in the To or CC, as I am not > good at keeping up with all the traffic on qemu-devel.
Hi Andrew, this was my fault instead reply-to-all I send reply to mailing list. I realized after sending. > > > From: qemu-devel-bounces+andrew.baumann=microsoft....@nongnu.org > > [mailto:qemu-devel- > > bounces+andrew.baumann=microsoft....@nongnu.org] On Behalf Of Piotr > > Król > > Sent: Wednesday, 30 December 2015 17:14 > > > First, I tried your code from raspi branch (ar7-raspi doesn't compile [1]). > > Using recent Raspbian 2015-11-21-raspbian-jessie (same results I saw for > > 2015-09-24). I'm getting kernel panic: > > > > [ 6.892677] random: systemd urandom read with 7 bits of entropy available > > [ 6.908292] Kernel panic - not syncing: Attempted to kill init! > > exitcode=0x00000004 > > This is most likely an unimplemented setend instruction in the > userspace memcmp. You need to mount the image, and comment out the > contents of (or just remove) /etc/ld.so.preload, then it should boot > further. Yes, I figured this out. > > BTW, I mentioned this briefly in the notes on Linux at the end of this page: > https://github.com/0xabu/qemu/wiki > > > Third test I tried is to apply patches from this series on top of master > > (38a762fec63f), what cause hang on: > > > > [ 15.094558 ] mmc0: Timeout waiting for hardware interrupt > > Hmm, I have seen this error on the raspi machine, but I don't think I > saw it on raspi2 before. Does it also occur on the older (09-24) > image? I've seen this on raspi, but it only occurs when using the DMA > controller, and in the patch series presently on list, there is no DMA > controller included, so it can't be that. > I tried v2 with qemu 38a762fec63f using: $ qemu-system-arm -M raspi2 -kernel raspbian-boot/kernel7.img -sd 2015-11-21-raspbian-jessie.img -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -dtb raspbian-boot/bcm2709-rpi-2-b.dtb -usbdevice mouse -usbdevice keyboard -serial stdio WARNING: Image format was not specified for '2015-11-21-raspbian-jessie.img' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. qemu-system-arm: -usbdevice mouse: Error: no usb bus to attach usbdevice mouse, please try -machine usb=on and check that the machine model supports USB qemu-system-arm: -usbdevice mouse: could not add USB device 'mouse' Removing USB: qemu-system-arm -M raspi2 -kernel 2015-11-21-raspbian-boot/kernel7.img -sd 2015-11-21-raspbian-jessie.img -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -dtb 2015-11-21-raspbian-boot/bcm2709-rpi-2-b.dtb -serial stdio [ 5.071960] uart-pl011 3f201000.uart: no DMA platform data [ 15.083445] mmc0: Timeout waiting for hardware interrupt. <hang> Same stuff with 2015-09-24. Trying your GitHub raspi branch everything works fine after commenting in /etc/ld.so.preload. > > I do not follow this mailing list, so maybe I missing some pieces. > > If I need some other patches to test this series please let me know. > > There are other patches (on the list) with changes to sd and sdhci > emulation needed to boot Windows, but for Linux I believe this is all > you need. > > > My questions: > > > > Does 2015-09-24-raspbian-jessie.vhd extracted Linux partition from raspbian > > image or simply img converted to vhd format ? Is there any problem with > > using img ? > > No, img is fine. I converted it to a VHD container, because it's > easier to work with on Windows (and avoids qemu's warning about raw > images). > > > Would you mind to issue tracking on GitHub and pull requests or you want > > whole > > communication and possible fixes go through QEMU mailing list ? I think that > > it > > maybe useful for code that is not ready for upstreaming. I saw you have > > issue > > tracking disabled. > > I'm in a bind here. My original goal was simply to contribute the > raspi2 + Windows guest support. Then I discovered that the raspi work > itself was not yet in mainline qemu, and so I've been working to clean > that up and get it merged along with the raspi2 work. However, I don't > have the time/resources to be a long-term maintainer of everything > Pi-related. I'm happy to enable issue tracking on github, but don't > want to give a false impression as to the level of support it's likely > to receive :) On pull requests: my goal is to get everything in my > raspi branch merged upstream (which is why I recently dropped some > stub device emulations that weren't needed); assuming that happens I'd > prefer if subsequent changes went through the qemu patch process, > since ultimately that's how they'll get into mainline and be > maintained in the longer term. (I'm happy to be CCed on patches and > provide feedback.) Understood. Will use mailing list and probably fork of your GitHub repository. > > BTW, the biggest roadblock in my plan above is the USB host controller > emulation (by Gregory), which is obviously incomplete/hacky, but still > works well enough for Linux keyboard/mouse that it's useful to people. > If someone wants to pick that up, I would be very happy :) What you mean by 'pick that up' ? Is Gregory's USB code available somewhere and have to be cleaned and upstreamed ? Please point me to this pice and I would check what I can do. > > Cheers, > Andrew Best Regards, -- Piotr Król Embedded Systems Consultant http://3mdeb.com | @3mdeb_com