qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/3] target-xtensa: xtfpga: support noMMU cores


From: Max Filippov
Subject: Re: [Qemu-devel] [PATCH 3/3] target-xtensa: xtfpga: support noMMU cores
Date: Sun, 27 Sep 2015 22:01:54 +0300

On Sun, Sep 27, 2015 at 9:43 PM, Peter Crosthwaite
<address@hidden> wrote:
> On Sun, Sep 27, 2015 at 11:13 AM, Max Filippov <address@hidden> wrote:
>> On Sun, Sep 27, 2015 at 8:38 PM, Peter Crosthwaite
>> <address@hidden> wrote:
>>> On Sun, Sep 27, 2015 at 10:16 AM, Max Filippov <address@hidden> wrote:
>>>>      int n;
>>>
>>> Blank line.
>>
>> Why?
>>
> Just a readability suggestion. You have a collection of short defs
> that then runs straight into a lengthy self-contained table.

Ok

>>>> +    mmu = xtensa_option_enabled(env->config, XTENSA_OPTION_MMU);
>>>
>>> This looks backwards, the board should be in charge of itself and the
>>> CPU config, rather than spying on the CPU setup to rewire the board.
>>
>> Well, it's an FPGA board and all connections are a part of bitstream.
>> It's generated that way, I'm just following the specification here.
>>
>
> OK, but the xtensa-CPU is not the bitstream, this board is. What
> exactly is the user interface for switching between MMU and no-MMU?

Actually they both are. The user interface is a dropbox in the processor
generator software where user chooses memory management option.
Once it (and a bunch of other parameters) is chosen the bitstream with
CPU and peripherals can be generated.

> With the major changes of address layout, the no-MMU variation should
> be a set of new boards or a machine level parameterisation (i.e. QOM
> property of the machine). It needs to be user-visible as different on
> the machine level.

Why? The layouts are hard-coded based on MMU presence anyway.

-- 
Thanks.
-- Max



reply via email to

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