qemu-arm
[Top][All Lists]
Advanced

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

Re: [Qemu-arm] [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM sup


From: Peter Crosthwaite
Subject: Re: [Qemu-arm] [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support
Date: Tue, 17 Nov 2015 23:51:19 -0800

On Mon, Nov 16, 2015 at 2:22 PM, Andrew Baumann
<address@hidden> wrote:
> Hi all,
>
> I have been working on Raspberry Pi 2 emulation, building on the previous 
> work of Gregory Estrade, Stefan Weil and others on the original Raspberry Pi 
> target. My current working tree (based off a recent master) is here:
>     https://github.com/0xabu/qemu/tree/raspi
>
> The present status is:
>  * The original Raspberry Pi (-M raspi) support works only with older kernels 
> from Raspbian releases up to 2014-09-09, for unknown reasons that I haven't 
> investigated. [1]
>  * Pi 2 (-M raspi2) supports both Raspbian and Windows.
>  * Raspbian boots on pi2, but fails on an implemented SETEND instruction in 
> early userspace. I'm told there are patches/workarounds for this floating 
> around, but have not tried them.
>  * The Windows IoT image [2] boots completely, but the USB emulation is 
> broken, so the only IO devices are framebuffer and serial console (which can 
> be used for a kernel debugger).
>  * All four Pi2 cores must be enabled for Windows, since the bootloader 
> panics if the expected cores are not present. Conversely, Raspbian fails to 
> boot if multiple cores are enabled, but I haven't debugged this, since qemu 
> is faster with a single-core guest.
>
> I realise that getting this code integrated will require a series of smaller 
> patches, but wanted to solicit any early feedback before I start doing that. 
> I've verified that checkpatch.pl is happy, but if there are other stylistic 
> or general problems with the code it would be helpful to know about them 
> sooner rather than later :) If anyone has specific suggestions for how to 
> split up the patch, that would also be welcome. If not, I will start 
> submitting patches for the individual pieces, probably starting with the 
> machine definition and then the larger devices, followed by the 
> Windows-specific fixes described below.
>

For splitting, there are some good examples in any of the recent ARM
SoC+Board bringups. The most recent full bringup from scratch would
probably be the STM/Netduino board. Myself and Jean-Christophe added
Xilinx ZynqMP and i.MX25 respectively, although in both those works we
used existing peripheral IP (with patches) rather than fresh.

https://lists.nongnu.org/archive/html/qemu-devel/2015-02/msg03398.html
https://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg01194.html
https://lists.nongnu.org/archive/html/qemu-devel/2015-03/msg04683.html

I haven't looked beyond the diffstat yet, but a top level
architectural comment, I only see the one file in hw/arm. We are
promoting the split of board and SoC now as two separate objects. Each
of the patch series linked above demonstrates this. The BCM SoC would
be an object in its own right, then the board instantiates the SoC as
a composite device.

> There are also a couple of significant (non Pi-specific) changes that I made 
> in order to boot a Windows on ARM guest, which also I plan to submit:
> 1. UEFI (TianoCore / EDK2) has a couple of bugs in its MMC support -- it 
> assumes support for CMD23 (set multiple block count, which is supposed to be 
> optional), and also fails to initialise correctly if the card is ready 
> immediately upon issuing ACMD41. My tree includes workarounds for both issues 
> -- I implemented CMD23, and modelled a small delay when initialising the SD 
> card.
> 2. For better or worse, Windows relies on taking alignment faults on a 
> misaligned LDREX, however qemu doesn't perform any alignment checks, leading 
> to a bluescreen very early in boot. The changes in target-arm implement a 
> generic infrastructure for testing/raising alignment exceptions, and add a 
> suitable check to LDREX. (This is almost certainly applicable to arm64 as 
> well, but I don't have a means to test it.)
>

I would send that as a single, and you would be able to do that
without any thing else as prerequisite.

> Here's the current diffstat (ignore the minor unrelated bugfixes in lan9118 
> and tap-win32):
>  default-configs/arm-softmmu.mak      |    1 +
>  hw/arm/Makefile.objs                 |    1 +
>  hw/arm/raspi.c                       |  514 ++++++++++++++++
>  hw/char/Makefile.objs                |    1 +
>  hw/char/bcm2835_aux.c                |  250 ++++++++
>  hw/display/Makefile.objs             |    1 +
>  hw/display/bcm2835_fb.c              |  384 ++++++++++++
>  hw/dma/Makefile.objs                 |    1 +
>  hw/dma/bcm2835_dma.c                 |  352 +++++++++++

New devices should have the state struct in a header file, the
referenced work gives an example on this.

>  hw/intc/Makefile.objs                |    1 +
>  hw/intc/bcm2835_ic.c                 |  248 ++++++++
>  hw/intc/bcm2836_control.c            |  373 ++++++++++++
>  hw/misc/Makefile.objs                |    5 +
>  hw/misc/bcm2835_mphi.c               |  176 ++++++
>  hw/misc/bcm2835_power.c              |  113 ++++
>  hw/misc/bcm2835_property.c           |  409 +++++++++++++
>  hw/misc/bcm2835_sbm.c                |  294 ++++++++++
>  hw/misc/bcm2835_vchiq.c              |  113 ++++
>  hw/net/lan9118.c                     |   18 +-
>  hw/sd/Makefile.objs                  |    1 +
>  hw/sd/bcm2835_emmc.c                 |  844 +++++++++++++++++++++++++++
>  hw/sd/sd.c                           |   78 ++-
>  hw/timer/Makefile.objs               |    2 +
>  hw/timer/arm_timer.c                 |   39 ++
>  hw/timer/bcm2835_st.c                |  201 +++++++
>  hw/timer/bcm2835_timer.c             |  242 ++++++++
>  hw/usb/Makefile.objs                 |    2 +
>  hw/usb/bcm2835_usb.c                 |  655 +++++++++++++++++++++
>  hw/usb/bcm2835_usb_regs.h            | 1061 
> ++++++++++++++++++++++++++++++++++
>  include/hw/arm/bcm2835_arm_control.h |  481 +++++++++++++++
>  include/hw/arm/bcm2835_common.h      |   35 ++
>  include/hw/arm/raspi_platform.h      |  155 +++++
>  net/tap-win32.c                      |   51 +-
>  target-arm/helper.c                  |    8 +
>  target-arm/helper.h                  |    1 +
>  target-arm/internals.h               |    3 +
>  target-arm/op_helper.c               |   21 +
>  target-arm/translate.c               |   29 +
>  38 files changed, 7141 insertions(+), 23 deletions(-)

It is big. Work of this magnitude is generally better managed as
multiple series (each of multiple patches). A general approach with
new ARM boards is the first series is the bare minimum needed to get a
linux boot over the UART console. This usually means any CPU
customisations, timer, UART, intc, SoC and boards, maybe the
system/power controllers (if the kernel touches them in boot) and
optionally network or emmc. With network you can do an NFS root (this
was the only option on Allwinner/cubieboard for quite some time) and
with emmc you can do your root=/dev/mmcblk0p2 style boot as normal. If
you are using existing lan9118, network first might be a clear win,
although emmc is more realistic. Can always do both.

The you can follow up with the USB, DMA, AUX, ... each independently
or as a follow up series'.

Any core code and ARM CPU work that is a bugfix or stands in its own
right, you should send straight up as a separate work.

>
> The command line I've used for Raspbian is:
> qemu-system-arm -M raspi2 -m 1024 -kernel kernel7.img -sd 
> 2015-09-24-raspbian-jessie.img -append "rw earlyprintk loglevel=8 
> bcm2708_fb.fbwidth=1024 bcm2708_fb.fbheight=768 bcm2708.boardrev=0xf 
> bcm2708.serial=0xcad0eedf vc_mem.mem_base=0x1c000000 
> vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2"
>

Curious, does rPi kernel support device tree boot? This would be nice
for testing with a generic kernel.

Regards,
Peter

> The command line for Windows is:
> qemu-system-arm -M raspi2 -smp 4 -m 1024 -bios kernel.img -sd 
> th2preview_pi2_iot.vhd
> (where kernel.img is the EDK2 bootloader from the first partition of the 
> Windows image).
>
> Cheers,
> Andrew
>
> [1] https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=26561&start=125
> [2] http://ms-iot.github.io/content/en-US/Downloads.htm
>



reply via email to

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