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: Wed, 30 Sep 2015 20:41:23 +0300

On Tue, Sep 29, 2015 at 10:20 PM, Peter Crosthwaite
<address@hidden> wrote:
> 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.

I don't get it. It can't forcibly set anything on CPU: it will change the CPU.
The CPU is primary, the machine is just a reference platform used for
demos. The user doesn't have two different machines: one for MMU cores
and another for noMMU cores, it has one, its name is the name of target
FPGA board.

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

I think this is applicable to all CPUs with long enough history.
Xtensa is not special here.

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

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

I do it now, but it has nothing to do with machine. Xtensa CPU is
configurable. I can import its configuration and create QEMU CPU
instance. We don't know anything about the machine that will use
it. XTFPGA is special, because it can be built together with the CPU.
Boards produced by customers may have much more rigid structure,
e.g. esp8266 is all fixed, the CPU is fixed as well.


That said I still don't understand, what good is having a machine with
QOM properties? And what good is having two machines, of which
only one can be used with each CPU instead of only the correct one?

-- 
Thanks.
-- Max



reply via email to

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