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

[Peter Crosthwaite]

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:
>> On Wed, Sep 30, 2015 at 3:42 PM, Max Filippov <address@hidden> wrote:
>>> On Thu, Oct 1, 2015 at 1:23 AM, Peter Crosthwaite
>>> <address@hidden> wrote:
>>>> On Wed, Sep 30, 2015 at 3:07 PM, Max Filippov <address@hidden> wrote:
>>>>> On Thu, Oct 1, 2015 at 12:02 AM, Peter Crosthwaite
>>>>> <address@hidden> wrote:
>>>>>> Which makes MMU vs noMMU a board level property, not a CPU property.
>>>>>> It should appear in QEMU as such.
>>>>>
>>>>> Ok, one last try: can this property be queried from the selected CPU
>>>>> and passed to SoC initialization code?
>>>>
>>>> No, what I am trying to say is go the other way round. The property is
>>>> on the SoC, and it is used to select the CPU type.
>>>
>>> This is not what happens in reality. In reality the MMU type is the
>>> CPU property.
>>> A set of CPU properties comes from the outside along with the CPU name, and
>>> that's the only possible set of properties for this name.
>>> XTFPGA bitstream build scripts lay out its address space based on MMU
>>> type of the selected CPU.
>>>
>>> So let's make XTFPGA an SoC with a property that selects its address space
>>> layout. The machine (lx60/lx200/ml605/kc705) is configured with a CPU,
>>
>> So lx60/lx200 sound like isolated FPGA chips (Virtex 4 lx60?) while
>> ml605/kc705 are commonly available fully-featured FPGA dev boards.
>
> Actually they're all fully-featured FPGA dev boards, from different times.
> lx60 and lx200 boards were produced by Avnet (yes, Virtex 4 based),
> ml605 and kc705 are from Xilinx.
>
>> Is lx60 short for a particular board featuring this part or is it more 
>> abstract?
>
> Less memory, smaller onboard FLASH, different audio subsystem (not
> currently modeled).
>
>>> it
>>> queries MMU type from it and instantiates XTFPGA SoC with proper address
>>> space. That seems to be closest to what happens in reality.
>>
>> 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.

Regards,
Peter

> --
> Thanks.
> -- Max