Re: [Qemu-devel] [PATCH v2 0/7] Raspberry Pi 2 support

[Piotr Król]

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: address@hidden
> > [mailto:qemu-devel-
> > address@hidden 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