On Wed, Sep 30, 2015 at 1:54 PM, Max Filippov <jcmvb...@gmail.com> wrote: > On Wed, Sep 30, 2015 at 11:45 PM, Peter Maydell > <peter.mayd...@linaro.org> wrote: >> On 30 September 2015 at 21:17, Max Filippov <jcmvb...@gmail.com> wrote: >>> On Tue, Sep 29, 2015 at 11:42 PM, Peter Maydell >>> <peter.mayd...@linaro.org> wrote: >>>> On 29 September 2015 at 11:34, Max Filippov <jcmvb...@gmail.com> 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