On Sun, Sep 27, 2015 at 12:01 PM, Max Filippov <jcmvb...@gmail.com> wrote: > On Sun, Sep 27, 2015 at 9:43 PM, Peter Crosthwaite > <crosthwaitepe...@gmail.com> wrote: >> On Sun, Sep 27, 2015 at 11:13 AM, Max Filippov <jcmvb...@gmail.com> wrote: >>> On Sun, Sep 27, 2015 at 8:38 PM, Peter Crosthwaite >>> <crosthwaitepe...@gmail.com> wrote: >>>> On Sun, Sep 27, 2015 at 10:16 AM, Max Filippov <jcmvb...@gmail.com> 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
