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

[Andrew Baumann]

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.

> 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.

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 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.)

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 :)

Cheers,
Andrew