qemu-devel
[Top][All Lists]
Advanced

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

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


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support
Date: Thu, 26 Nov 2015 11:38:45 -0800

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

So I am looking at some recent news, and there is the RPi Zero which
reuses the bcm2835 as a different board. Can't find the schematic yet,
but from what I can see, this is a raw SoC (no USB ethernet). With
your SoC/board split we should be able pickup the Zero board quite
cheaply as follow up work.

Regards,
Peter

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



reply via email to

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