[Qemu-devel] ARM Cortex-R4 support ?

[Qemu-devel] ARM Cortex-R4 support ?

[Giancarlo ASNAGHI]

Hello,

Do you know which is the status of the support for Cortex-R4 support? I've seen an initial set of patches from Andreas Farber one years ago, but into the qemu-system-arm the Cortex-R4 ins't available yet.

Thanks a lot
Best Regards
Giancarlo

Re: [Qemu-devel] ARM Cortex-R4 support ?

[Andreas Färber]

Hello Giancarlo,

Am 21.09.2012 17:15, schrieb Giancarlo ASNAGHI:
> Do you know which is the status of the support for Cortex-R4 support? I've seen an initial set of patches from Andreas Farber one years ago, but into the qemu-system-arm the Cortex-R4 ins't available yet.

That's true. As a consequence of my patches we redesigned several parts
of ARM CPU modelling to facilitate this. My patches were not yet rebased
onto that. A new QOM type derived from TYPE_ARM_CPU would need to be
created now, to initialize the registers imperatively rather than
declaratively. I might manage that quickly.

Note that my published patches only took care of CPUID, FPU and a few
others to instantiate the -cpu cortex-r4 at all.

Where I got stuck was reading through the ARMv7 TRM differences between
VMSA and PMSA (chapters B3 and B4 respectively) to implement PMSA,
pointed out by Peter. And there were also some floating point width
differences to ARMv7-A (VFPv3-D16 vs. VFPv3-S32 or so).
Neither is a small patch that I can supply short-term, maybe your
colleagues can help with those parts once I've refreshed my patches?
Cédric has worked on the FPU before, cc'ing.

Regards,
Andreas

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

[Qemu-devel] [RFC v2 1/2] target-arm: Prepare support for Cortex-R4

[Andreas Färber]

Glue "cortex-r4" to r1p4, the latest available TRM.
Set MPU and Thumb division feature bit.

Signed-off-by: Andreas Färber <andreas.faerber@web.de>
---
 target-arm/cpu.c |   24 ++++++++++++++++++++++++
 1 Datei geändert, 24 Zeilen hinzugefügt(+)

diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index b00f5fa..6726498 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -382,6 +382,29 @@ static void cortex_m3_initfn(Object *obj)
     cpu->midr = 0x410fc231;
 }
 
+static void cortex_r4_initfn(Object *obj)
+{
+    ARMCPU *cpu = ARM_CPU(obj);
+    set_feature(&cpu->env, ARM_FEATURE_V7);
+    set_feature(&cpu->env, ARM_FEATURE_THUMB_DIV);
+    set_feature(&cpu->env, ARM_FEATURE_MPU);
+    cpu->midr = 0x411FC144; /* r1p4 */
+    cpu->id_pfr0 = 0x0131;
+    cpu->id_pfr1 = 0x001;
+    cpu->id_dfr0 = 0x010400;
+    cpu->id_afr0 = 0x0;
+    cpu->id_mmfr0 = 0x0210030;
+    cpu->id_mmfr1 = 0x00000000;
+    cpu->id_mmfr2 = 0x01200000;
+    cpu->id_mmfr3 = 0x0211;
+    cpu->id_isar0 = 0x1101111;
+    cpu->id_isar1 = 0x13112111;
+    cpu->id_isar2 = 0x21232131;
+    cpu->id_isar3 = 0x01112131;
+    cpu->id_isar4 = 0x0010142;
+    cpu->id_isar5 = 0x0;
+}
+
 static const ARMCPRegInfo cortexa8_cp_reginfo[] = {
     { .name = "L2LOCKDOWN", .cp = 15, .crn = 9, .crm = 0, .opc1 = 1, .opc2 = 0,
       .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
@@ -737,6 +760,7 @@ static const ARMCPUInfo arm_cpus[] = {
     { .name = "arm1176",     .initfn = arm1176_initfn },
     { .name = "arm11mpcore", .initfn = arm11mpcore_initfn },
     { .name = "cortex-m3",   .initfn = cortex_m3_initfn },
+    { .name = "cortex-r4",   .initfn = cortex_r4_initfn },
     { .name = "cortex-a8",   .initfn = cortex_a8_initfn },
     { .name = "cortex-a9",   .initfn = cortex_a9_initfn },
     { .name = "cortex-a15",  .initfn = cortex_a15_initfn },
-- 
1.7.10.4

[Qemu-devel] [RFC v2 2/2] target-arm: Add support for Cortex-R4F

[Andreas Färber]

With QOM ARMCPU we can now distinguish between -cpu cortex-r4 and
-cpu cortex-r4f despite identical MIDR.

Signed-off-by: Andreas Färber <andreas.faerber@web.de>
---
 target-arm/cpu.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 Datei geändert, 47 Zeilen hinzugefügt(+)

diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 6726498..e176559 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -405,6 +405,52 @@ static void cortex_r4_initfn(Object *obj)
     cpu->id_isar5 = 0x0;
 }
 
+static const struct {
+    uint8_t r;
+    uint8_t p;
+    uint8_t value;
+} cortexr4_fpsid_revs[] = {
+    { 1, 0, 0x3 },
+    { 1, 1, 0x4 },
+    { 1, 2, 0x6 },
+    { 1, 3, 0x7 },
+    { 1, 4, 0x8 },
+    {}
+};
+
+static void cortex_r4f_initfn(Object *obj)
+{
+    ARMCPU *cpu = ARM_CPU(obj);
+
+    /* Cortex-R4F = Cortex-R4 + FPU */
+    cortex_r4_initfn(obj);
+
+    set_feature(&cpu->env, ARM_FEATURE_VFP3);
+    /* TODO VFPv3-D16 */
+    {
+        /* PMM didn't like this dynamic revision lookup... */
+        /* TODO: maybe weave cross-checks into QOM properties instead? */
+        uint8_t r = (cpu->midr >> 20) & 0xf;
+        uint8_t p = cpu->midr & 0xf;
+        uint8_t rev = 0;
+        int i;
+        /* Calculate FPSID value matching to MIDR */
+        for (i = 0; cortexr4_fpsid_revs[i].r != 0; i++) {
+            if (cortexr4_fpsid_revs[i].r == r &&
+                cortexr4_fpsid_revs[i].p == p) {
+                rev = cortexr4_fpsid_revs[i].value;
+                break;
+            }
+        }
+        if (rev == 0) {
+            cpu_abort(&cpu->env,
+                      "Cortex-R4F r%" PRIu8 "p%" PRIu8 " unsupported",
+                      r, p);
+        }
+        cpu->reset_fpsid = 0x41023140 | (rev & 0xf);
+    }
+}
+
 static const ARMCPRegInfo cortexa8_cp_reginfo[] = {
     { .name = "L2LOCKDOWN", .cp = 15, .crn = 9, .crm = 0, .opc1 = 1, .opc2 = 0,
       .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
@@ -761,6 +807,7 @@ static const ARMCPUInfo arm_cpus[] = {
     { .name = "arm11mpcore", .initfn = arm11mpcore_initfn },
     { .name = "cortex-m3",   .initfn = cortex_m3_initfn },
     { .name = "cortex-r4",   .initfn = cortex_r4_initfn },
+    { .name = "cortex-r4f",  .initfn = cortex_r4f_initfn },
     { .name = "cortex-a8",   .initfn = cortex_a8_initfn },
     { .name = "cortex-a9",   .initfn = cortex_a9_initfn },
     { .name = "cortex-a15",  .initfn = cortex_a15_initfn },
-- 
1.7.10.4

Re: [Qemu-devel] [RFC v2 1/2] target-arm: Prepare support for Cortex-R4

[Peter Maydell]

On 22 September 2012 12:45, Andreas Färber <andreas.faerber@web.de> wrote:
> +static void cortex_r4_initfn(Object *obj)
> +{
> +    ARMCPU *cpu = ARM_CPU(obj);
> +    set_feature(&cpu->env, ARM_FEATURE_V7);
> +    set_feature(&cpu->env, ARM_FEATURE_THUMB_DIV);
> +    set_feature(&cpu->env, ARM_FEATURE_MPU);

This will trip the assert in register_cp_regs_for_features():

    if (arm_feature(env, ARM_FEATURE_MPU)) {
        /* These are the MPU registers prior to PMSAv6. Any new
         * PMSA core later than the ARM946 will require that we
         * implement the PMSAv6 or PMSAv7 registers, which are
         * completely different.
         */
        assert(!arm_feature(env, ARM_FEATURE_V6));

...indicating that R4 support is more work than is contained
in this patch :-)

-- PMM

Re: [Qemu-devel] [RFC v2 1/2] target-arm: Prepare support for Cortex-R4

[Andreas Färber]

Am 22.09.2012 15:05, schrieb Peter Maydell:
> On 22 September 2012 12:45, Andreas Färber <andreas.faerber@web.de> wrote:
>> +static void cortex_r4_initfn(Object *obj)
>> +{
>> +    ARMCPU *cpu = ARM_CPU(obj);
>> +    set_feature(&cpu->env, ARM_FEATURE_V7);
>> +    set_feature(&cpu->env, ARM_FEATURE_THUMB_DIV);
>> +    set_feature(&cpu->env, ARM_FEATURE_MPU);
> 
> This will trip the assert in register_cp_regs_for_features():

Thanks for the pointer. This rebased version is only compile-tested and
is provided mainly for the ST guys to build upon, during my absence.

>     if (arm_feature(env, ARM_FEATURE_MPU)) {
>         /* These are the MPU registers prior to PMSAv6. Any new
>          * PMSA core later than the ARM946 will require that we
>          * implement the PMSAv6 or PMSAv7 registers, which are
>          * completely different.
>          */
>         assert(!arm_feature(env, ARM_FEATURE_V6));
> 
> ...indicating that R4 support is more work than is contained
> in this patch :-)

...which confirms what I stated in the message this is threaded to, and
is reflected by "prepare". :)

Same for VFPv3-D16 in the second RFC patch (which used to "add" to
cortex-r4, now should've been updated to "prepare" as well).

And of course the Cortex-R4's lock-step mode that seems to make it so
interesting for automotive customers.

/-F

Re: [Qemu-devel] [RFC v2 1/2] target-arm: Prepare support for Cortex-R4

[Peter Maydell]

On 22 September 2012 14:56, Andreas Färber <andreas.faerber@web.de> wrote:
> And of course the Cortex-R4's lock-step mode that seems to make it so
> interesting for automotive customers.

Lock-step is trivial to emulate: just do nothing and never raise a
"cores out of sync" error :-)

-- PMM

Re: [Qemu-devel] [RFC v2 2/2] target-arm: Add support for Cortex-R4F

[Blue Swirl]

On Sat, Sep 22, 2012 at 11:45 AM, Andreas Färber <andreas.faerber@web.de> wrote:
> With QOM ARMCPU we can now distinguish between -cpu cortex-r4 and
> -cpu cortex-r4f despite identical MIDR.
>
> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
> ---
>  target-arm/cpu.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 Datei geändert, 47 Zeilen hinzugefügt(+)
>
> diff --git a/target-arm/cpu.c b/target-arm/cpu.c
> index 6726498..e176559 100644
> --- a/target-arm/cpu.c
> +++ b/target-arm/cpu.c
> @@ -405,6 +405,52 @@ static void cortex_r4_initfn(Object *obj)
>      cpu->id_isar5 = 0x0;
>  }
>
> +static const struct {
> +    uint8_t r;
> +    uint8_t p;
> +    uint8_t value;
> +} cortexr4_fpsid_revs[] = {
> +    { 1, 0, 0x3 },
> +    { 1, 1, 0x4 },
> +    { 1, 2, 0x6 },
> +    { 1, 3, 0x7 },
> +    { 1, 4, 0x8 },
> +    {}
> +};
> +
> +static void cortex_r4f_initfn(Object *obj)
> +{
> +    ARMCPU *cpu = ARM_CPU(obj);
> +
> +    /* Cortex-R4F = Cortex-R4 + FPU */
> +    cortex_r4_initfn(obj);
> +
> +    set_feature(&cpu->env, ARM_FEATURE_VFP3);
> +    /* TODO VFPv3-D16 */
> +    {
> +        /* PMM didn't like this dynamic revision lookup... */
> +        /* TODO: maybe weave cross-checks into QOM properties instead? */
> +        uint8_t r = (cpu->midr >> 20) & 0xf;
> +        uint8_t p = cpu->midr & 0xf;
> +        uint8_t rev = 0;
> +        int i;
> +        /* Calculate FPSID value matching to MIDR */
> +        for (i = 0; cortexr4_fpsid_revs[i].r != 0; i++) {

You could use ARRAY_SIZE() to determine max index without the zero
entry. That way the number of entries would be known by the compiler
too.

> +            if (cortexr4_fpsid_revs[i].r == r &&
> +                cortexr4_fpsid_revs[i].p == p) {
> +                rev = cortexr4_fpsid_revs[i].value;
> +                break;
> +            }
> +        }
> +        if (rev == 0) {
> +            cpu_abort(&cpu->env,
> +                      "Cortex-R4F r%" PRIu8 "p%" PRIu8 " unsupported",
> +                      r, p);
> +        }
> +        cpu->reset_fpsid = 0x41023140 | (rev & 0xf);
> +    }
> +}
> +
>  static const ARMCPRegInfo cortexa8_cp_reginfo[] = {
>      { .name = "L2LOCKDOWN", .cp = 15, .crn = 9, .crm = 0, .opc1 = 1, .opc2 = 0,
>        .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
> @@ -761,6 +807,7 @@ static const ARMCPUInfo arm_cpus[] = {
>      { .name = "arm11mpcore", .initfn = arm11mpcore_initfn },
>      { .name = "cortex-m3",   .initfn = cortex_m3_initfn },
>      { .name = "cortex-r4",   .initfn = cortex_r4_initfn },
> +    { .name = "cortex-r4f",  .initfn = cortex_r4f_initfn },
>      { .name = "cortex-a8",   .initfn = cortex_a8_initfn },
>      { .name = "cortex-a9",   .initfn = cortex_a9_initfn },
>      { .name = "cortex-a15",  .initfn = cortex_a15_initfn },
> --
> 1.7.10.4
>
>

Re: [Qemu-devel] [RFC v2 2/2] target-arm: Add support for Cortex-R4F

[Peter Maydell]

On 22 September 2012 12:45, Andreas Färber <andreas.faerber@web.de> wrote:
> With QOM ARMCPU we can now distinguish between -cpu cortex-r4 and
> -cpu cortex-r4f despite identical MIDR.

I'm not convinced that we should treat the R4 any differently
to any of the other CPUs which we model which might or might
not have an FPU. For the others we basically model the "all
options enabled" version of the CPU. It might be nice to have
the ability to separately toggle options on and off in general.
Basically if we add 'cortex-r4f' then we're stuck with supporting
that name forever for backwards compatibility.

(I have a feeling we've had this conversation before but I forget
the outcome.)

-- PMM

Re: [Qemu-devel] ARM Cortex-R4 support ?

[Giancarlo ASNAGHI]

Hi Andreas,

thanks to share the status. I've doubts that some of my collegues may helps here, because we are focusing on the uclinux kernel and user side. Anyway I check and I let you know.

Best Regards
Giancarlo

> -----Original Message-----
> From: Andreas Färber [mailto:afaerber@suse.de]
> Sent: venerdì 21 settembre 2012 19:05
> To: Giancarlo ASNAGHI
> Cc: qemu-devel@nongnu.org; Peter Maydell; Cedric VINCENT
> Subject: Re: [Qemu-devel] ARM Cortex-R4 support ?
> 
> Hello Giancarlo,
> 
> Am 21.09.2012 17:15, schrieb Giancarlo ASNAGHI:
> > Do you know which is the status of the support for Cortex-R4 support? I've
> seen an initial set of patches from Andreas Farber one years ago, but into the
> qemu-system-arm the Cortex-R4 ins't available yet.
> 
> That's true. As a consequence of my patches we redesigned several parts of
> ARM CPU modelling to facilitate this. My patches were not yet rebased onto
> that. A new QOM type derived from TYPE_ARM_CPU would need to be
> created now, to initialize the registers imperatively rather than declaratively.
> I might manage that quickly.
> 
> Note that my published patches only took care of CPUID, FPU and a few
> others to instantiate the -cpu cortex-r4 at all.
> 
> Where I got stuck was reading through the ARMv7 TRM differences between
> VMSA and PMSA (chapters B3 and B4 respectively) to implement PMSA,
> pointed out by Peter. And there were also some floating point width
> differences to ARMv7-A (VFPv3-D16 vs. VFPv3-S32 or so).
> Neither is a small patch that I can supply short-term, maybe your colleagues
> can help with those parts once I've refreshed my patches?
> Cédric has worked on the FPU before, cc'ing.
> 
> Regards,
> 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-R4 support ?

[Giancarlo ASNAGHI]

Hi Andreas,

just a question.
Due to the fact that we don't have the FPU on our Cortex-R4 and that we don't plan using floating point do you mind that we may use it even with the VFPv3-D16 vs. VFPv3-S32 issue?



Thanks and Best Regads

Giancarlo





> -----Original Message-----
> From: Andreas Färber [mailto:afaerber@suse.de]
> Sent: venerdì 21 settembre 2012 19:05
> To: Giancarlo ASNAGHI
> Cc: qemu-devel@nongnu.org; Peter Maydell; Cedric VINCENT
> Subject: Re: [Qemu-devel] ARM Cortex-R4 support ?
> 
> Hello Giancarlo,
> 
> Am 21.09.2012 17:15, schrieb Giancarlo ASNAGHI:
> > Do you know which is the status of the support for Cortex-R4 support? I've
> seen an initial set of patches from Andreas Farber one years ago, but into the
> qemu-system-arm the Cortex-R4 ins't available yet.
> 
> That's true. As a consequence of my patches we redesigned several parts of
> ARM CPU modelling to facilitate this. My patches were not yet rebased onto
> that. A new QOM type derived from TYPE_ARM_CPU would need to be
> created now, to initialize the registers imperatively rather than declaratively.
> I might manage that quickly.
> 
> Note that my published patches only took care of CPUID, FPU and a few
> others to instantiate the -cpu cortex-r4 at all.
> 
> Where I got stuck was reading through the ARMv7 TRM differences between
> VMSA and PMSA (chapters B3 and B4 respectively) to implement PMSA,
> pointed out by Peter. And there were also some floating point width
> differences to ARMv7-A (VFPv3-D16 vs. VFPv3-S32 or so).
> Neither is a small patch that I can supply short-term, maybe your colleagues
> can help with those parts once I've refreshed my patches?
> Cédric has worked on the FPU before, cc'ing.
> 
> Regards,
> Andreas
> 
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg