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

[Andrew Baumann]

Hi Peter,

Thanks for your feedback!

From: Peter Crosthwaite [mailto:address@hidden
Sent: Tuesday, 17 November 2015 23:51
> 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.

I understand the rationale here, but is there much value pursuing this for the 
Pi? As far as I know, the Pi1/2 SOCs (bcm2835 and 2836) are one-off designs 
used only in the Pi. Moreover, the 2836 is basically a copy of the 2835 with 
the addition of a new block for a multi-core interrupt controller and 
mailboxes, so trying to split those out into two separate SOC definition files 
would require either lots of duplication, or a tight coupling between the two. 
Finally, there is basically nothing on the board besides the SoC and RAM (just 
a USB-Ethernet adapter), so the actual board definition files would be almost 
empty. As it is, I've already factored out all the common devices within 
hw/arm/raspi.c -- my feeling is that this is a cleaner way to do it for the Pi.

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

Ok, understood. Even following this guidance, the first patch will be big -- Pi 
has custom interrupt and DMA controllers, and the GPU gets itself involved in 
the boot process. I think we could probably leave out fb/usb and maybe also 
dma, mphi, vchiq and power, but most of the rest will be needed to boot 
anything.

BTW, I used lan9118 as a kludge for Windows, but it isn't present on a real Pi, 
and the device definition no longer instantiates it. At present, there is no 
usable network device.

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

I believe it does on recent Raspbian images (I see a number of dtb files in 
Raspbian's boot partition), but I haven't tried to figure out how to use them. 
In general, we have limitations where the bootloader is concerned. On Pi HW, 
the boot process is driven by the GPU, which reads a plethora of options from 
config files (config.txt and cmdline.txt) on the boot partition. We don't 
emulate any of that stuff... instead, the previous raspi code did just enough 
to boot Linux using qemu's Linux loader support, and I figured out how to make 
UEFI happy on raspi2 so it can boot Windows, but that's about all.

I will take a look at the patches you referred to, and try to refactor the 
devices accordingly.

BTW, my main goal here is Windows support (surprise! :), so if anyone else is 
willing to help out with Linux that would be much appreciated. The kernel 
currently limps into early userspace before crashing on a SETEND instruction, 
and is clearly not as happy as it was when the original Pi1 support was being 
actively developed ~2 years ago.

Thanks,
Andrew