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

[Peter Crosthwaite]

On Sun, Sep 27, 2015 at 12:01 PM, Max Filippov <address@hidden> wrote:
> 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.
>

So this really means that MMUness is board level property, not a CPU
level property.

To clarify, can you tell me the QEMU command line difference between
MMU and noMMU?

Regards,
Peter

> --
> Thanks.
> -- Max