qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] target-moxie: Add moxie Marin SoC support


From: Anthony Green
Subject: Re: [Qemu-devel] [PATCH] target-moxie: Add moxie Marin SoC support
Date: Sun, 15 Dec 2013 22:35:39 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Peter Crosthwaite <address@hidden> writes:

> On Mon, Dec 16, 2013 at 7:02 AM, Anthony Green <address@hidden> wrote:
>> Andreas Färber <address@hidden> writes:
>>
>>>> The Marin SoC currently runs on two boards: the Nexys3 (Xilinx) and DE-2
>>>> (Altera).  They are pretty much identical from the software side of
>>>> things.
>
> Ok but do they have the same peripheral set? We had this discussion
> with Allwinner where it was decided that even though the initial
> peripheral set was generic enough for software to boot, going forward
> it would not be true to the actual hardware. Sooner or later as you
> add peripherals the difference between Altera and Xilinx board
> definitions will stop your all-in-one approach wont it?

The peripherals are mostly similar.  All the important ones are the
same.  I will probably ignore where they differ (different numbers of
programmable buttons, for instance).

>>>>  Marin currently provides the UART, PIC, 7 segment display and
>>>> timer devices, as well as various memory controllers.  There's no useful
>>>> distinction between SoC and board at this time.
>
> I see the definition of Marin as a proper QEMU SoC quite useful here.
> Marin is then instantiated on Nexys3 or DE2 on the board level.
>
> Ideally we have a nexys3 or DE2 board definition that can instantiate
> a number of soft SoCs (e.g. swap out Microblaze or Marin even), but
> i'd leave that as follow up as its kind of hard to pull off.

I'm not sure it even makes sense.  The common elements between
Microblaze, Marin and Milkymist (for instance) are things like "has 16MB
of pseudo static RAM".  These are thin things to hang an abstraction on.

>  I'd like to keep it
>>>> simple as per my patch rather than try to factor them out prematurely.
>>>
>>> I thought I've seen a number of odd embedded systems already, but I'm
>>> having trouble understanding your combination of SoC and FPGA: Xilinx
>>> and Altera both have SoCs combining a Cortex-A9 with an FPGA. But your
>>> reference to Xilinx and Altera boards rather sounds as if Moxie is used
>>> as a soft-core processor on the FPGA? In that case the term "SoC" would
>>> be really confusing to me... Can you clarify or aid with some links?
>
> So we need to clarify terminology. SoC and FPGA are not mutually
> exclusive, and not just talking about Zynq and Altera hard ARM
> FPGA+SoC. If you just have a raw FPGA and configure it with a
> processor and peripherals then isn't that now a SoC in its own right?
>
> I have seen the SoC term used for years when referring to soft
> Microblaze systems so I think Anthonys terminology is good. You don't
> need hard silicon to be a SoC.
>
> Google this (exluding Zynq from the search helps a lot):
>
> microblaze SoC -zynq
>
>>
>> Moxie is an architecture.  MoxieLite is one implementation of that
>> architecture (non-pipelined, resource-light).  Marin is a kind of SoC -
>> the combination of the MoxieLite core along with various peripherals and
>> controllers.
>>
>> http://github.com/atgreen/moxie-cores
>>
>
> So you just synthesize this Verilog into a FPGA bistream right?

Correct.  Marin is actually a mix of Verilog and VHDL.

> Have a Nexys bitstream and linux boot instructions handy?

1. Nexys3 bitstream:
    https://dl.dropboxusercontent.com/u/3786210/marin.bit.gz 
   This will bring you to the on-chip srecord-loader/gdbstub.  The tools
   directory in the moxie-cores github project has scripts to build a
   toolchain so you can start hacking.

2. Linux boot instructions: step 1. port linux.  you can guess the rest.
   Actually, I have a very early uClinux kernel port that boots to
   userland here: https://github.com/atgreen/linux-2.6-moxie . It will
   die once it hits userland thanks to vfork() madness that will
   actually require an architectural change to fix.

>> It is similar, in a way, to the Miklymist SoC, which uses an LM32
>> soft-core (and is supported by qemu).
>>
>
> And the PetaLogix+Microblaze stuff.
>
>> The Xilinx and Altera parts with Cortex-A9 cores are similar, except
>> that that Cortex-A9 is an on-chip ASIC, instead of a soft SoC.
>>
>
> I don't see the need for QEMU to make this hard/soft distinction. It
> shouldn't have to worry too much about underlying silicon
> implementation.
>
> Regards,
> Peter
>
>> AG
>>



reply via email to

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