On Wed, Jan 6, 2016 at 4:09 PM, Piotr Król <piotr.k...@3mdeb.com> wrote: > 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. >
Do you need BE8 or BE32? Some BE8 support can be found here: https://github.com/Xilinx/qemu/commits/mainline/big_endian Paolo did have BE32 in the original work but I simplified it out of my own BE work, as I didn't have any tests for it. (I was focussed on AArch64 BE at the time). Watch out for this bug: https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg05762.html Which is probably still at large in that Xilinx branch. Regards, Peter >> >> 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 >