qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/6] [RFC] New SPARC machine: Leon3


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 0/6] [RFC] New SPARC machine: Leon3
Date: Mon, 6 Dec 2010 18:12:12 +0000

On Mon, Dec 6, 2010 at 3:07 PM, Fabien Chouteau <address@hidden> wrote:
> On 12/06/2010 11:44 AM, Artyom Tarasenko wrote:
>>
>> On Mon, Dec 6, 2010 at 10:26 AM, Fabien Chouteau<address@hidden>
>>  wrote:
>>>
>>> Hi everyone,
>>> I'm glad to submit my first patches to the Qemu-devel list.
>>>
>>> This patch set introduces a new SPARC V8 machine: Leon3. It's an
>>> open-source
>>> VHDL System-On-Chip, well known in space industry (more information on
>>> http://www.gaisler.com).
>>
>> Nice! Haven't looked into the code yet, but it's great to have someone
>> who cares for V8.
>
> And if this patch is accepted, we will try to submit more machines like
> erc32 and leon2.
>
>> Do you also have a firmware which runs on these machines?
>>
>
> I can give you a binary running some basic tests.

Is the binary generally available? Otherwise it would be very hard to
test any changes and the code would bitrot. I'm not sure we even want
to support such machines.

Are the sources available? That would help debugging.

>>> Leon3 is made of multiple components available in the GrLib VHDL library.
>>> Three devices are implemented: uart, timers and IRQ manager.
>>> You can find code for these peripherals in the grlib_* files.
>>>
>>> Modifications have been done to the SPARC cpu emulation code to handle
>>> Leon3's specific behavior:
>>>  - IRQ management
>>>  - Cache control
>>>  - Asr17 (implementation-dependent Ancillary State Registers)
>>
>> Is it the only implementation-dependent asr in Leon3? Thought there were
>> more.
>>
>
> Yes, there's also asr19 for power-down, asr16 for FPU control and others for
> hardware breakpoints.
> These are not required for this first implementation, but If there's a need
> for more ASRs, we may have to find a generic implementation to handle those
> registers.

So far I'd handle these in target-sparc/op_helper.c. If the registers
are also available as MMIO like MXCC, then we should invent a way to
handle both.



reply via email to

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