qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH v2 0/7] Raspberry Pi 2 support
Date: Wed, 6 Jan 2016 18:46:30 -0800

On Wed, Jan 6, 2016 at 4:09 PM, Piotr Król <address@hidden> 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: 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.
>

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
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]