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

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

[Fabien Chouteau]

On 02/28/2013 07:42 PM, Peter Maydell wrote:
> On 28 February 2013 17:39, Fabien Chouteau <chouteau@adacore.com> wrote:
>> On 02/28/2013 03:16 PM, Peter Maydell wrote:
>>> On 28 February 2013 14:01, Fabien Chouteau <chouteau@adacore.com> wrote:
>>>> In fact I'm
>>>> working on a big-endian R4F (TMS570) and I have endianness issue in the
>>>> communication with GDB.
>>>
>>> If you're also trying to get big-endian mode to work (linux-user
>>> mode or system emulation?) you may have more problems than merely
>>> implementing R4 support or VFP-D16 :-)
> 
>> I already built qemu-system-armeb, and implemented few devices of the
>> TMS570 (rti, sci, and vim). Besides this GDB issue I have no endianness
>> problem so far.
> 
> This is probably some combination of luck and insufficient testing.
> If you submit some patches I will review them :-)
> 

Well my goal is not to test every ARM cpu and every devices in big-endian.

I only need a small subset of TMS570: - Cortex-R4F without MPU
                                      - Timers (RTI)
                                      - Serial port (SCI)
                                      - Interrupt manager (RTI)
and everything works good so far.


> 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. TMS570 are configured for big-endian only, so this is not a
problem for me.

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

Regards,

-- 
Fabien Chouteau

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

[Peter Maydell]

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

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

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

[Fabien Chouteau]

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

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

[Peter Maydell]

On 1 March 2013 11:21, Fabien Chouteau <chouteau@adacore.com> wrote:
> On 03/01/2013 11:40 AM, Peter Maydell wrote:
>> On 1 March 2013 10:13, Fabien Chouteau <chouteau@adacore.com> wrote:
>>> 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."

That is confusing, because ARM's R4F Technical Reference Manual
says "The processor does not support word-invariant big-endianness
(BE)-32"...

(http://translatedcode.wordpress.com/2012/04/02/this-end-up/
has a quick summary of what the various flavours of ARM
endianness actually mean.)

I think you're going to have to run some tests on the actual
hardware to find out what it really does. Specifically, what
are the values of SCTLR.IE, SCTLR.EE and CPSR.E when you think
you're in big-endian mode? (We need to sort out what parts of
the behaviour you're seeing are the CPU itself and what parts
are the SoC/board doing endianness flipping externally to the
CPU.)

thanks
-- PMM

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

[Fabien Chouteau]

On 03/01/2013 12:32 PM, Peter Maydell wrote:
> On 1 March 2013 11:21, Fabien Chouteau <chouteau@adacore.com> wrote:
>> 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."
> 
> That is confusing, because ARM's R4F Technical Reference Manual
> says "The processor does not support word-invariant big-endianness
> (BE)-32"...
> 
> (http://translatedcode.wordpress.com/2012/04/02/this-end-up/
> has a quick summary of what the various flavours of ARM
> endianness actually mean.)
> 

Confusing indeed. It seems that the documentation is not reliable. Below
the text I just quoted, there's an example showing that TMS570 is
actually BE8. And this is confirmed by our experience using the real
board.

> I think you're going to have to run some tests on the actual
> hardware to find out what it really does. Specifically, what
> are the values of SCTLR.IE, SCTLR.EE and CPSR.E when you think
> you're in big-endian mode? (We need to sort out what parts of
> the behaviour you're seeing are the CPU itself and what parts
> are the SoC/board doing endianness flipping externally to the
> CPU.)
> 

SCTLR.IE and SCTLR.EE are both set to 1 at reset and the values cannot
be changed.

BTW, our run-time works both on QEMU and a real-board, that's also why
I'm confident that there are no endianness issue.

Regards,

-- 
Fabien Chouteau

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

[Peter Maydell]

On 1 March 2013 12:07, Fabien Chouteau <chouteau@adacore.com> wrote:
> On 03/01/2013 12:32 PM, Peter Maydell wrote:
>> I think you're going to have to run some tests on the actual
>> hardware to find out what it really does. Specifically, what
>> are the values of SCTLR.IE, SCTLR.EE and CPSR.E when you think
>> you're in big-endian mode?

> SCTLR.IE and SCTLR.EE are both set to 1 at reset and the values
> cannot be changed.

OK, that makes sense. I think it's also a reasonable thing for
qemu's qemu-system-armeb model to present to the guest. Have
you changed QEMU to report IE and EE (and CPSR.E) as always-1,
or does your guest code just not look at them?

> BTW, our run-time works both on QEMU and a real-board, that's also why
> I'm confident that there are no endianness issue.

The trouble is that you can have two separate bits of QEMU
which both model the endianness incorrectly but in such
a way that the two errors cancel each other out and the
guest-visible behaviour looks correct...

-- PMM

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

[Fabien Chouteau]

On 03/01/2013 01:16 PM, Peter Maydell wrote:
> On 1 March 2013 12:07, Fabien Chouteau <chouteau@adacore.com> wrote:
>> On 03/01/2013 12:32 PM, Peter Maydell wrote:
>>> I think you're going to have to run some tests on the actual
>>> hardware to find out what it really does. Specifically, what
>>> are the values of SCTLR.IE, SCTLR.EE and CPSR.E when you think
>>> you're in big-endian mode?
>
>> SCTLR.IE and SCTLR.EE are both set to 1 at reset and the values
>> cannot be changed.
>
> OK, that makes sense. I think it's also a reasonable thing for
> qemu's qemu-system-armeb model to present to the guest. Have
> you changed QEMU to report IE and EE (and CPSR.E) as always-1,
> or does your guest code just not look at them?
>

We don't look at them so I didn't change anything, but maybe it's not
difficult to do.

-- 
Fabien Chouteau

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

[Fabien Chouteau]

On 03/01/2013 02:43 PM, Fabien Chouteau wrote:
> On 03/01/2013 01:16 PM, Peter Maydell wrote:
>> On 1 March 2013 12:07, Fabien Chouteau <chouteau@adacore.com> wrote:
>>> On 03/01/2013 12:32 PM, Peter Maydell wrote:
>>>> I think you're going to have to run some tests on the actual
>>>> hardware to find out what it really does. Specifically, what
>>>> are the values of SCTLR.IE, SCTLR.EE and CPSR.E when you think
>>>> you're in big-endian mode?
>>
>>> SCTLR.IE and SCTLR.EE are both set to 1 at reset and the values
>>> cannot be changed.
>>
>> OK, that makes sense. I think it's also a reasonable thing for
>> qemu's qemu-system-armeb model to present to the guest. Have
>> you changed QEMU to report IE and EE (and CPSR.E) as always-1,
>> or does your guest code just not look at them?
>>
> 
> We don't look at them so I didn't change anything, but maybe it's not
> difficult to do.
> 

These fields are ARMv6/7 only, right?

-- 
Fabien Chouteau

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

[Peter Maydell]

On 1 March 2013 15:10, Fabien Chouteau <chouteau@adacore.com> wrote:
> On 03/01/2013 02:43 PM, Fabien Chouteau wrote:
>> On 03/01/2013 01:16 PM, Peter Maydell wrote:
>>> OK, that makes sense. I think it's also a reasonable thing for
>>> qemu's qemu-system-armeb model to present to the guest. Have
>>> you changed QEMU to report IE and EE (and CPSR.E) as always-1,
>>> or does your guest code just not look at them?
>>>
>>
>> We don't look at them so I didn't change anything, but maybe it's not
>> difficult to do.

> These fields are ARMv6/7 only, right?

That's correct -- they're part of the BE8 big-endian model which
was introduced with ARMv6. (The old v5 BE32 model uses SCTLR.B,
ie bit 7 -- on a BE8-only core, which all v7 cores are, SCTLR.B is
always 0.) On older versions of the architecture the IE and EE bits
were reserved, and read as zero. (Technically we are supposed to
implement reserved bits as 'read zero, writes ignored' but QEMU
often ignores this and implements as reads-as-written. Well
behaved guests will not notice the difference.)

-- PMM

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

[Andreas Färber]

Am 27.02.2013 18:25, schrieb Fabien Chouteau:
> On 02/27/2013 05:58 PM, Peter Maydell wrote:
>> On 27 February 2013 16:37, Fabien Chouteau <chouteau@adacore.com> wrote:
>>> I'm making my first steps in the ARM world by looking at R4F
>>> implementation. More specifically I'm trying to add VFP3-D16 support
>>> which is, as far as I understand, a regular VFP3 with only 16 D
>>> registers instead of 32.
>>
>> Andreas was looking at Cortex-R4(F) support a while back; you should
>> talk to him about how far he got with that (and google for the mailing
>> list archives for my comments on his patches, probably).
>>
> 
> I already found these patches, and I base my work on them. I also
> contacted Andreas to know if he made progress on this support, but
> didn't get the answer yet.

I've sent one in the meantime, you can't expect me to be available 24/7.

In short:
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/cortex-r4f is
about what I've got. Feel free to reuse and extend/change as you see fit.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Fabien Chouteau]

On 03/01/2013 07:54 PM, Andreas Färber wrote:
> Am 27.02.2013 18:25, schrieb Fabien Chouteau:
>> On 02/27/2013 05:58 PM, Peter Maydell wrote:
>>> On 27 February 2013 16:37, Fabien Chouteau <chouteau@adacore.com> wrote:
>>>> I'm making my first steps in the ARM world by looking at R4F
>>>> implementation. More specifically I'm trying to add VFP3-D16 support
>>>> which is, as far as I understand, a regular VFP3 with only 16 D
>>>> registers instead of 32.
>>>
>>> Andreas was looking at Cortex-R4(F) support a while back; you should
>>> talk to him about how far he got with that (and google for the mailing
>>> list archives for my comments on his patches, probably).
>>>
>>
>> I already found these patches, and I base my work on them. I also
>> contacted Andreas to know if he made progress on this support, but
>> didn't get the answer yet.
> 
> I've sent one in the meantime, you can't expect me to be available 24/7.
> 

It's OK, I wasn't complaining :)

> In short:
> http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/cortex-r4f is
> about what I've got. Feel free to reuse and extend/change as you see fit.
>

Thanks, I already started to use it.

Regards,

-- 
Fabien Chouteau