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

[Peter Crosthwaite]

On Tue, Sep 29, 2015 at 3:34 AM, Max Filippov <address@hidden> wrote:
> On Mon, Sep 28, 2015 at 12:59 AM, Peter Crosthwaite
> <address@hidden> wrote:
>> On Sun, Sep 27, 2015 at 2:48 PM, Max Filippov <address@hidden> wrote:
>>> On Mon, Sep 28, 2015 at 12:28 AM, Peter Crosthwaite
>>> <address@hidden> wrote:
>>>> To clarify, can you tell me the QEMU command line difference between
>>>> MMU and noMMU?
>>>
>>> There is no difference. You specify -cpu without full MMU -- you get
>>> noMMU address space layout.
>>
>> Ok but I think this is what we want to avoid. Using -cpu to switch up
>> the board/SoC architecture. The address space layout is SoC level (and
>> in your case a bitstream constitutes and entire SoC). There's a
>> lengthy discussion on this here:
>>
>> http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg03979.html
>>
>> going back and forth from that point in the thread. Your hardware
>> model is more accurate that what was proposed by OP in that thread,
>> but it is good to keep the interfaces consistent with other machine
>> models.
>
> The message by the link says:
>
>   As Andreas says, we need to model real actual hardware,
>   not some abstraction that kind of matches the kernel's
>   abstractions.
>
> 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.

But that would actually be the semantics of -cpu. Change just the CPU.

>From earlier in this thread:

"
>> 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.
"

The key part to me is "bitstream with peripherals". Using qemu
terminology, the dropbox you describe is not a CPU configurator, it is
a machine (or SoC) configuration. Changing the MMU option in your
devtools configurates both the CPU proper and the system address map.

You want some sort of container that can serve as this higher level
configurable object. The drop down menus in your cad tools then map to
QOM props on the container level (not the CPU level). Currently you
don't have a SoC/Machine split, but that is OK, you can make these
props on the Machine (now that machines are fully QOMified). I suggest
whatever that MMU dropbox is textually labelled as in you cad tools,
you create the QOM property with the same name. The machine level then
forcibly sets the same feature on the CPU.

If you do that, there may no longer be a need for multiple xtensa CPU
types. There is only one xtensa-cpu type, It is just massively
configurable with all the devtool options propagated from the machine.
This was the general plan with microblaze and Alistair started on
propertyifying the cad tool configurable options individually (theres
a long way to go on that project).

-cpu is then defeatured for xtensa, which makes sense, as based on
your description, it is impossible to substitute an xtensa CPU without
global consequences.

You can then create a handful of reference machines with common
favourable settings, or take some sort of generated output from you
cad to drive a fully custom configuration.

> There's also no SoC level mentioned in the developer guides
> for the corresponding boards.

Just terminology mismatch. The output of your software tools is really
a SoC, not a CPU.

Regards,
Peter

> So I'm not sure what you're proposing to do.
>
> --
> Thanks.
> -- Max