Re: [Qemu-devel] [PATCH 3/3] target-xtensa: xtfpga: support noMMU cores

[Peter Crosthwaite]

On Thu, Oct 1, 2015 at 1:13 PM, Max Filippov <address@hidden> wrote:
> On Thu, Oct 1, 2015 at 10:18 PM, Peter Crosthwaite
> <address@hidden> wrote:
>> On Thu, Oct 1, 2015 at 11:25 AM, Max Filippov <address@hidden> wrote:
>>> On Thu, Oct 1, 2015 at 9:06 PM, Peter Crosthwaite
>>> <address@hidden> wrote:
>>>> What is your intended user command lines? E.g. how do I boot with
>>>> ml605 no-mmu and then with mmu.
>>>
>>> '-M ml605 -cpu de108' will boot noMMU variant (de108 is not in the mainline 
>>> yet,
>>> can be seen in the 
>>> https://github.com/OSLL/qemu-xtensa/commits/xtensa-cores),
>>> '-M ml605 -cpu dc233c' will boot full MMU variant, as de108 doesn't
>>> have full MMU
>>> and dc233c does.
>>
>> So where I was going with this, is due to the way your devtools do
>> memory maps, -cpu is the wrong switch altogether as what your tools
>> call a "CPU" is different to what QEMU does. I am thinking:
>>
>> -M ml605 -global ml605.bitstream=xtensa-dc233c
>>
>> dc233c is a SoC that selects the correct xtensa CPU (either via
>> property or an target-extensa CPU also named "dc233c"). When you set
>> the bitstream property on the machine, it instantiates the correct SoC
>> which in turn already knows the correct memory map and selects the CPU
>> for you.
>>
>> When we have multi-arch working, we can then code-share the FPGA board
>> definitions between arches e.g. petalogix-ml605 can be rewritten so
>> that this works:
>>
>> qemu-system-multi -M ml605 -global ml605.bitstream=petalogix-mmu
>> qemu-system-multi -M ml605 -global ml605.bitstream=xtensa-dc233c
>>
>> Names may needs some fine tuning.
>
> I'm completely lost here. I have a problem at hand: noMMU cores
> can't run on XTFPGA boards because of wrong device memory map.

I would word it differently, - You have no support for your noMMU
designs at all.

The two designs may have the same peripheral set so they can and
should code share (probably to the point where they just have two
const tables just diffing the memory maps) but they are ultimately
different.

> The board is not meant to be used outside target-xtensa at all, and
> even for target-xtensa it's just a demo board.
>
> What problem do I solve by implementing it in the way you suggest?
>

You change the interchangable component from just a CPU (QEMU
definition of "CPU") to the whole FPGA bitstream which in reality is
what happens (unless we open the FPGA partial reconfiguration
can-of-worms). So the user interface is matched to what really happens
on the boards. The code is also more easily patched in the future,
should anyone want to reuse xtensa ml605 with total FPGA design
replacement.

Regards,
Peter

> --
> Thanks.
> -- Max