Re: [Qemu-devel] [ARM] Cortex-R4F and VFP3-D16

[Fabien Chouteau <chouteau@adacore.com>]

On 03/01/2013 11:40 AM, Peter Maydell wrote:
> On 1 March 2013 10:13, Fabien Chouteau <chouteau@adacore.com> wrote:
>> On 02/28/2013 07:42 PM, Peter Maydell wrote:
>>> How are you handling the SCTLR IE and EE bits?
>>
>> I did nothing, as far as I know it's not possible to switch endianness
>> in QEMU.
>
> Yes, that's why I'm wondering how you're handling them.
>
>> TMS570 are configured for big-endian only, so this is not a
>> problem for me.
>
> Do you mean they are BE8 for load/stores always (ie SCTLR.EE is
> 1, or that they are both BE8 for load/stores and also for
> instruction fetches (ie that SCTLR.IE is also 1) ?
>
> Endianness in ARM is not as simple as a single flag saying
> "big or little"...
>

I'm new to this ARM architecture so I will just quote the doc.

TMS570LS31x/21x Technical Reference Manual:

"The TMS570 family is based on the ARM® CortexTM-R4F core. ARM has
designed this core to be used in big-endian and little-endian systems.
For the TI TMS570 family, the endianness has been configured to BE32."


>>>>> Are you planning to do the v7 PMSA support?
>>>
>>>> I don't know what that is, but I'll take a look :)
>>>
>>> It's the Memory Protection Unit -- QEMU currently only has the
>>> old v5 MPU, and register_cpu_regs_for_features() will assert
>>> if your CPU is v6 or v7 and has the FEATURE_MPU bit set.
>>> If you're putting in system emulation for an R4 then you must
>>> implement this (and I'm surprised you've managed to get anything
>>> significant to run without it).
>>
>> The programs I run don't need MPU, so for the moment I have no plan to
>> implement PMSA.
>
> However from an upstream point of view something that claims
> to be an R4 but doesn't actually implement the MPU is not
> terribly useful...
>

Well it is useful for us. Our safety-critical small-foot-print run-time
doesn't need MPU. Look for Ravenscar profile in Ada.

Regards,

-- 
Fabien Chouteau