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. I still can't understand what's wrong with that. -- Thanks. -- Max
