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

[Peter Crosthwaite]

On Wed, Sep 30, 2015 at 1:54 PM, Max Filippov <address@hidden> wrote:
> On Wed, Sep 30, 2015 at 11:45 PM, Peter Maydell
> <address@hidden> wrote:
>> On 30 September 2015 at 21:17, Max Filippov <address@hidden> wrote:
>>> On Tue, Sep 29, 2015 at 11:42 PM, Peter Maydell
>>> <address@hidden> wrote:
>>>> On 29 September 2015 at 11:34, Max Filippov <address@hidden> wrote:
>>>>> Changing address space layout according to CPU type is what happens
>>>>> in actual hardware. There are no user-controllable settings that would
>>>>> allow mismatching address space layout and CPU type on XTFPGA
>>>>> boards. There's also no SoC level mentioned in the developer guides
>>>>> for the corresponding boards. So I'm not sure what you're proposing to do.
>>>>
>>>> I think this should clearly be different machine models
>>>> (possibly implemented using different SoC models).
>>>
>>> There are already 4 different machine models, lx60, lx200, ml605 and
>>> kc705, these are real boards for which bitstreams can be created.
>>>
>>>> This isn't a
>>>> CPU-dependent thing at all, it's just your dev tools are hiding
>>>> "change the devices and other board/soc level things" behind a
>>>> CPU-type dropdown, which it can get away with because the whole
>>>> implementation is in a single FPGA.
>>>
>>> Why duplicating each machine and then only allowing each CPU to be
>>> used with only one variant of each machine? It doesn't match what
>>> users do with boards and bitstreams, at all.
>>
>> Because for QEMU the CPU is really just the CPU. Your other
>> random devices don't live in the CPU, even if you're
>> programming your FPGA with a single bitstream that's
>> got the CPUs and a set of devices in it. You can't push
>> that stuff into the CPU model, it should live in the
>> board model.
>
> I'm not pushing them into CPU model and they do live in the board
> model. After all the changes in question were for the hw/xtensa/xtfpga.c
> But the board is made in such way that CPUs with and without MMU
> see onboard RAM and peripherals at different physical addresses.

Which makes MMU vs noMMU a board level property, not a CPU property.
It should appear in QEMU as such.

Regards,
Peter

> I still can't understand what's wrong with that.
>
> --
> Thanks.
> -- Max