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

[Peter Crosthwaite]

On Wed, Nov 18, 2015 at 10:16 AM, Andrew Baumann
<address@hidden> wrote:
> 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.

Duplication is not right. You can code share by either having a QOM
inheritance between the two SoCs (the QOM object oriented model allows
this) from a common abstraction, or a QOM property that drives the
needed iffery. Even if the board is thin, I would still do it split,
and several of the in-tree machine models are like this. If anyone
wants to model the lower level stuff like the power supplies or play
with the GPIOs etc there some framework there. If the board ever gets
cloned and modded then the SoC is ready to go.

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

USB-Ethernet is non trivial though isn't it? I'm looking at the
schematic and my gut is the lan9152 warrants a board/SoC split.

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

You will probably find that the way to do it is covert your board as
it stands to SoC, rebadging rPi as BCM SoC then put a thin rPI board
around it that sets just the RAM initially.

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

Ok I guess just start with emmc. If that diff to sd.c is for emmc card
support (currently missing), I would start early and send that
straight away.

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

Yeh I think Paolo tried to fix that with the ARM BE support. I
reworked that recently but for v7+ ARM, so I didn't have the BE32
support anymore (I had no test cases). That BE work really needs to go
up as you are at least the 4th person to need it.

Regards,
Peter

> Thanks,
> Andrew