qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [ARM] Cortex-R4F and VFP3-D16
Date: Fri, 1 Mar 2013 10:40:43 +0000

On 1 March 2013 10:13, Fabien Chouteau <address@hidden> 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"...

>>>> 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...

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]