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