Re: [Qemu-devel] [ARM] Cortex-R4F and VFP3-D16
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 chout...@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
Re: [Qemu-devel] [ARM] Cortex-R4F and VFP3-D16
On 02/28/2013 07:42 PM, Peter Maydell wrote: On 28 February 2013 17:39, Fabien Chouteau chout...@adacore.com wrote: On 02/28/2013 03:16 PM, Peter Maydell wrote: On 28 February 2013 14:01, Fabien Chouteau chout...@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
On 1 March 2013 10:13, Fabien Chouteau chout...@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
On 03/01/2013 11:40 AM, Peter Maydell wrote: On 1 March 2013 10:13, Fabien Chouteau chout...@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
On 1 March 2013 11:21, Fabien Chouteau chout...@adacore.com wrote: On 03/01/2013 11:40 AM, Peter Maydell wrote: On 1 March 2013 10:13, Fabien Chouteau chout...@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
On 03/01/2013 12:32 PM, Peter Maydell wrote: On 1 March 2013 11:21, Fabien Chouteau chout...@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
On 1 March 2013 12:07, Fabien Chouteau chout...@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
On 03/01/2013 01:16 PM, Peter Maydell wrote: On 1 March 2013 12:07, Fabien Chouteau chout...@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
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 chout...@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
On 1 March 2013 15:10, Fabien Chouteau chout...@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
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 chout...@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
On 02/27/2013 09:49 PM, Paul Brook wrote: I've got a patch to implement this as a side-effect of a different feature, I'll look at pushing it out. Great, don't hesitate to ask if you want some help. In the meantime I have another question for you. In helper.c:vfp_gdb_get_reg(), there's a comment: /* VFP data registers are always little-endian. */ and all the load and store are stfq_le_p and ldfq_le_p. I don't understand why VFP registers should always be little-endian. In fact I'm working on a big-endian R4F (TMS570) and I have endianness issue in the communication with GDB. Thanks, -- Fabien Chouteau
Re: [Qemu-devel] [ARM] Cortex-R4F and VFP3-D16
On 28 February 2013 14:01, Fabien Chouteau chout...@adacore.com wrote: On 02/27/2013 09:49 PM, Paul Brook wrote: I've got a patch to implement this as a side-effect of a different feature, I'll look at pushing it out. Great, don't hesitate to ask if you want some help. In the meantime I have another question for you. In helper.c:vfp_gdb_get_reg(), there's a comment: /* VFP data registers are always little-endian. */ and all the load and store are stfq_le_p and ldfq_le_p. I don't understand why VFP registers should always be little-endian. This is a question of how GDB defines these registers to be transmitted over the remote protocol -- you'd need to find the corresponding gdb docs/code. 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 :-) Are you planning to do the v7 PMSA support? -- PMM
Re: [Qemu-devel] [ARM] Cortex-R4F and VFP3-D16
On 02/28/2013 03:16 PM, Peter Maydell wrote: On 28 February 2013 14:01, Fabien Chouteau chout...@adacore.com wrote: On 02/27/2013 09:49 PM, Paul Brook wrote: I've got a patch to implement this as a side-effect of a different feature, I'll look at pushing it out. Great, don't hesitate to ask if you want some help. In the meantime I have another question for you. In helper.c:vfp_gdb_get_reg(), there's a comment: /* VFP data registers are always little-endian. */ and all the load and store are stfq_le_p and ldfq_le_p. I don't understand why VFP registers should always be little-endian. This is a question of how GDB defines these registers to be transmitted over the remote protocol -- you'd need to find the corresponding gdb docs/code. I will ask to our GDB experts. 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. Are you planning to do the v7 PMSA support? I don't know what that is, but I'll take a look :) Regards, -- Fabien Chouteau
Re: [Qemu-devel] [ARM] Cortex-R4F and VFP3-D16
On 28 February 2013 17:39, Fabien Chouteau chout...@adacore.com wrote: On 02/28/2013 03:16 PM, Peter Maydell wrote: On 28 February 2013 14:01, Fabien Chouteau chout...@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 :-) How are you handling the SCTLR IE and EE bits? 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). -- PMM
Re: [Qemu-devel] [ARM] Cortex-R4F and VFP3-D16
On 27 February 2013 16:37, Fabien Chouteau chout...@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). My question is: where do I check that an instruction is accessing an unimplemented register (i.e. d16-31)? It could be in the macro VFP_DREG, but it's specification is not clear to me. Check the ARM ARM and how dregs are encoded into instructions. VFP_DREG is approximately set reg to the register number, but return 1 if the encoding isn't valid where valid here means accessing d16..d31 in VFP2 (since VFP2 has only 16 dregs). Probably what you'll want is to have a separate feature bit for 32 dregs which is set by default for vfpv3, and then use that in VFP_DREG rather than the vfpv3 feature bit. -- PMM
Re: [Qemu-devel] [ARM] Cortex-R4F and VFP3-D16
On 02/27/2013 05:58 PM, Peter Maydell wrote:
On 27 February 2013 16:37, Fabien Chouteau chout...@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.
My question is: where do I check that an instruction is accessing an
unimplemented register (i.e. d16-31)? It could be in the macro VFP_DREG,
but it's specification is not clear to me.
Check the ARM ARM and how dregs are encoded into instructions.
VFP_DREG is approximately set reg to the register number, but return 1
if the encoding isn't valid where valid here means accessing d16..d31
in VFP2 (since VFP2 has only 16 dregs).
Probably what you'll want is to have a separate feature bit for 32
dregs which is set by default for vfpv3, and then use that in
VFP_DREG rather than the vfpv3 feature bit.
Right, it might be easier than I though. Maybe add a
ARM_FEATURE_VFP3_D16 and do:
#define VFP_DREG(reg, insn, bigbit, smallbit) do { \
if (arm_feature(env, ARM_FEATURE_VFP3) \
!arm_feature(env, ARM_FEATURE_VFP3_D16)) { \
reg = (((insn) (bigbit)) 0x0f) \
| (((insn) ((smallbit) - 4)) 0x10); \
} else { \
if (insn (1 (smallbit))) \
return 1; \
reg = ((insn) (bigbit)) 0x0f; \
}} while (0)
Thanks for your help,
--
Fabien Chouteau
Re: [Qemu-devel] [ARM] Cortex-R4F and VFP3-D16
Probably what you'll want is to have a separate feature bit for 32
dregs which is set by default for vfpv3, and then use that in
VFP_DREG rather than the vfpv3 feature bit.
Right, it might be easier than I though. Maybe add a
ARM_FEATURE_VFP3_D16 and do:
#define VFP_DREG(reg, insn, bigbit, smallbit) do { \
if (arm_feature(env, ARM_FEATURE_VFP3) \
!arm_feature(env, ARM_FEATURE_VFP3_D16)) { \
There's no need to check both flags.
I've got a patch to implement this as a side-effect of a different feature,
I'll look at pushing it out.
Paul
