[gentoo-embedded] maverick-crunch queries

[gentoo-embedded] maverick-crunch queries

[Ahmed Ammar]

Hello,

I am currently working on some QEMU patches to add support for the
EP93xx (and the ts-7200 board) I have had some general success but this
is far from complete. My main issue is the Maverick-Crunch FPU and some
question to see if anyone has had the same experience.

Which patch-set are people generally using, there seem to be two sets:
1) futaris ones which seem to be the openembedded.org ones and 2) the
cirrus linux ones which are up to version 1.4.3. I have been using the
openembedded ones with gcc-4.2.4 but compiling the arm kernel (which by
default compiles with -msoft-float) will cause a kernel panic on boot.
If on the other hand I use a *-softfloat-* toolchain the kernel boots
fine. Anyone else find the openembedded patches break softfloat
implementation?

Best Regards,

-- 
Ahmed Ammar (b33fc0d3 [at] gentoo.org)

Re: [gentoo-embedded] maverick-crunch queries

[Christopher Friedt]

On the contrary, I found that the kernel worked for both softfloat and 
maverick-enabled userspace binaries. The results I had support the 
theory too, because of the speed of encoding mp3's. It jumped from 
several minutes to a matter of seconds I believe.

Although my problem was userspace related - I didn't compile the glibc 
with the -D _MAVERICK_ use flag the first time I ran the 'lame' binary. 
Then I had to recompile glibc and lame, and it worked like a charm.

At the time, there were still floating point paranoia tests that weren't 
passed, but I've heard that some patches exist which fix many of those 
problems - I've heard but I haven't seen the patches myself.

If you want step-by-step instructions to build your own maverick 
toolchain, kernel, & userland, then follow these:

http://gentoo-wiki.com/HARDWARE_TS72xx_Single_Board_Computer

Cheers,

Chris

Ahmed Ammar wrote:
> Hello,
> 
> I am currently working on some QEMU patches to add support for the
> EP93xx (and the ts-7200 board) I have had some general success but this
> is far from complete. My main issue is the Maverick-Crunch FPU and some
> question to see if anyone has had the same experience.
> 
> Which patch-set are people generally using, there seem to be two sets:
> 1) futaris ones which seem to be the openembedded.org ones and 2) the
> cirrus linux ones which are up to version 1.4.3. I have been using the
> openembedded ones with gcc-4.2.4 but compiling the arm kernel (which by
> default compiles with -msoft-float) will cause a kernel panic on boot.
> If on the other hand I use a *-softfloat-* toolchain the kernel boots
> fine. Anyone else find the openembedded patches break softfloat
> implementation?
> 
> Best Regards,
> 

Re: [gentoo-embedded] maverick-crunch queries

[Ahmed Ammar]

On Thu, 2008-07-31 at 19:41 -0400, Christopher Friedt wrote:
> On the contrary, I found that the kernel worked for both softfloat and 
> maverick-enabled userspace binaries. The results I had support the 
> theory too, because of the speed of encoding mp3's. It jumped from 
> several minutes to a matter of seconds I believe.

You mis-understand me I am not asking about user-space I was asking
specifically about the kernel. 

You also didn't answer about which patch-set you use?

Best Regards,

-- 
Ahmed Ammar (b33fc0d3 [at] gentoo.org)

Re: [linux-cirrus] Re: [gentoo-embedded] maverick-crunch queries

[Ahmed Ammar]

On Mon, 2008-10-13 at 13:37 +0100, Martin Guy wrote:
> On 7/31/08, Ahmed Ammar <b33fc0d3@gentoo.org> wrote:
> >  I am currently working on some QEMU patches to add support for the
> >  EP93xx (and the ts-7200 board) I have had some general success but this
> >  is far from complete. My main issue is the Maverick-Crunch FPU and some
> >  question to see if anyone has had the same experience.
> >
> >  Which patch-set are people generally using, there seem to be two sets:
> >  1) futaris ones which seem to be the openembedded.org ones
> 
> Where do you find "the openembedded ones"? I have looked for them but not found.
> Do you know how to find them without setting up a whole OE build environment?

They used to have their repository available for online viewing but as
far as i can see it's been removed. Maybe too many people grabbing what
they wanted via http. 

> I know there is the tarball under files.futaris.org/gcc for 4.1.2 and 4.2.0
> > 2) the cirrus linux ones which are up to version 1.4.3.
> 
> I dunno about "people" :) but the only set ever to pass the gcc
> testsuite are the ones under files.futaris.org/gcc for 4.1.2 and
> 4.2.0. To achieve this they get round one of the problems by disabling
> all conditional instruction execution. In theory this disables some
> optimisation but in practice, if you are doing FP and can enable the
> FPU, the loss is negligable.
> Of the two, 4.1.2 requires less memory to build it and to compile
> things, compiles things faster and seems to produce smaller faster
> code.

I have moved back to 4.1.2 now as that seems to provide the best working
tool-chain, although there are the known issues that you have also
posted about (Hasjim's April ideas).

> > I have been using the
> >  openembedded ones with gcc-4.2.4 but compiling the arm kernel (which by
> >  default compiles with -msoft-float) will cause a kernel panic on boot.
> 
> The kernel does not use any floating point by design, so you should
> not be worrying about this. I would guess that the breakage you are
> seeing by adding -mhard-float or whatever changes the function call
> ABI and breaks something in the kernel that knows about that, like the
> assembly routines. Compiling with floating point instructions is only
> an issue in userland.

The 4.2.4 patches that i was using as i said probably produced a broken
tool-chain so i moved back to 4.1.2 as you recommended. 

I am pleased to hear that you are now being financed to continue where
others have left off as getting around certain bugs is very annoying
(broken unwind support)

I can help with any testing you may require as I am currently using this
arch in a product we are developing. 

Best Regards,
Ahmed Ammar

Re: [linux-cirrus] Re: [gentoo-embedded] maverick-crunch queries

[Martin Guy]

On 11/17/08, Ahmed Ammar <b33fc0d3@gentoo.org> wrote:
> On Mon, 2008-10-13 at 13:37 +0100, Martin Guy wrote:
>  > Where do you find "the openembedded ones"? I have looked for them but not found.
>  > Do you know how to find them without setting up a whole OE build environment?
>
> They used to have their repository available for online viewing but as
>  far as i can see it's been removed. Maybe too many people grabbing what
>  they wanted via http.

>  > Of the two, 4.1.2 requires less memory to build it and to compile
>  > things, compiles things faster and seems to produce smaller faster
>  > code.
oops, smaller, but not faster, though the difference is just a few %

> The 4.2.4 patches that i was using as i said probably produced a broken
>  tool-chain so i moved back to 4.1.2 as you recommended.
Yes, none of the others produced working executables as is.

>  I am pleased to hear that you are now being financed to continue where
>  others have left off as getting around certain bugs is very annoying
>  (broken unwind support)

There is support called arm-crunch-unwind.patch in the later tarballs
that is independent of the other patches and it should apply OK to the
earlier GCC versions too.
You can see it my most recent complete set under
http://martinwguy.co.uk/martin/crunch/gcc-4.3.2-patches
though this isn't prodution quality (sometimes Internal Compiler Errors)
If you'd like to try adding that patch and running some tests with
unwinds,  I'd be glad to hear of your results .

    M

Re: [linux-cirrus] Re: [gentoo-embedded] maverick-crunch queries

[Ahmed Ammar]

On Mon, 2008-11-17 at 17:21 +0000, Martin Guy wrote:
> There is support called arm-crunch-unwind.patch in the later tarballs
> that is independent of the other patches and it should apply OK to the
> earlier GCC versions too.
> You can see it my most recent complete set under
> http://martinwguy.co.uk/martin/crunch/gcc-4.3.2-patches
> though this isn't prodution quality (sometimes Internal Compiler
> Errors)
> If you'd like to try adding that patch and running some tests with
> unwinds,  I'd be glad to hear of your results .

Sorry I've been very busy lately and didn't have a chance to try the
patches before you released them publicly. Although, I have tried the
above link and i get a 403 'Forbidden' error. I was trying to find the
arm-crunch-unwind.patch in an attempt to try to understand/debug/solve
the following problem:

I have compiled a brand new tool-chain using your 4.3.2 patch series but
I am hitting a certain bug (that also existed with the older 4.1.2
patches); an assembler error when trying to compiler certain c++ files.

The assembly generated is:
.LCFI141:
	.save {mv8}			<-- Error: register expected
	cfstrd	mvd8, [sp, #-8]!


I don't know if the arm-crunch-unwind.patch was supposed to solve this,
as it's not included in the public patches. I could give you the source
code that is causing this bug too but it's part of a large library and
therefore didn't want to clutter this message with it's details (and
patches which are needed to get it to cross-compile).


Best Regards,
-- 
Ahmed Ammar (b33fc0d3 [at] gentoo.org)

Re: [linux-cirrus] Re: [gentoo-embedded] maverick-crunch queries

[Ahmed Ammar]

On Mon, 2008-12-22 at 17:39 +0200, Ahmed Ammar wrote:
> The assembly generated is:
> .LCFI141:
>         .save {mv8}                     <-- Error: register expected
>         cfstrd  mvd8, [sp, #-8]!

If i disable optimization (-O0) the same code compiles, I searched for
the same identifier as above and found the following;

.LCFI141:
@(insn/f 29 28
30 /usr/lib/gcc/armv4tl-maverick-linux-gnueabi/4.3.2/include/g
++-v4/bits/stl_vector.h:562 (set (reg/f:SI 11 fp)
@        (plus:SI (reg:SI 12 ip)
@            (const_int -4 [0xfffffffffffffffc]))) 4 {*arm_addsi3}
(nil))
	.setfp fp, ip, #-4
	sub	fp, ip, #4	@ 29	*arm_addsi3/2	[length = 4]

Hope this helps,

-- 
Ahmed Ammar (b33fc0d3 [at] gentoo.org)

Re: [linux-cirrus] Re: [gentoo-embedded] maverick-crunch queries

[Martin Guy]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

On 12/22/08, Ahmed Ammar <b33fc0d3@gentoo.org> wrote:
> On Mon, 2008-11-17 at 17:21 +0000, Martin Guy wrote:
>  > http://martinwguy.co.uk/martin/crunch/gcc-4.3.2-patches
>  above link and i get a 403 'Forbidden' error.

Yes. I published the working set under simplemachines.it/tools and
closed that dir since its contents are the same.

>         .save {mv8}                     <-- Error: register expected
>  I don't know if the arm-crunch-unwind.patch was supposed to solve this,

No. This needs a modification to binutils, not gcc.
The "crunch unwind patch" for gcc-4.3.0 is attached, though I don't
know if it makes any sense.

I assume your optimization issue is because it changes the code to use
one of the callee-saved registers 8-15

    M

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: arm-crunch-unwind.patch --]
[-- Type: text/x-diff; name=arm-crunch-unwind.patch, Size: 7605 bytes --]

diff -urN gcc-4.3.0/gcc/config/arm-original/arm/libunwind.S gcc-4.3.0/gcc/config/arm/libunwind.S
--- gcc-4.3.0/gcc/config/arm-original/arm/libunwind.S	2007-09-05 01:05:01.000000000 +1000
+++ gcc-4.3.0/gcc/config/arm/libunwind.S	2008-04-10 17:25:47.000000000 +1000
@@ -191,6 +191,52 @@
 	stc2  p1, cr11, [r0], #4 /* wstrw wcgr3, [r0], #4 */
 	RET
 
+
+/* Load CRUNCH registers mv0-mv15 from the address in r0.  */
+ARM_FUNC_START gnu_Unwind_Restore_CRUNCH
+	/* Use the generic coprocessor form so that gas doesn't complain
+	   on soft-float targets.  */
+	ldcl  p4, cr0, [r0], #8 /* cfldrd mv0, [r0], #8 */
+	ldcl  p4, cr1, [r0], #8 /* cfldrd mv1, [r0], #8 */
+	ldcl  p4, cr2, [r0], #8 /* cfldrd mv2, [r0], #8 */
+	ldcl  p4, cr3, [r0], #8 /* cfldrd mv3, [r0], #8 */
+	ldcl  p4, cr4, [r0], #8 /* cfldrd mv4, [r0], #8 */
+	ldcl  p4, cr5, [r0], #8 /* cfldrd mv5, [r0], #8 */
+	ldcl  p4, cr6, [r0], #8 /* cfldrd mv6, [r0], #8 */
+	ldcl  p4, cr7, [r0], #8 /* cfldrd mv7, [r0], #8 */
+	ldcl  p4, cr8, [r0], #8 /* cfldrd mv8, [r0], #8 */
+	ldcl  p4, cr9, [r0], #8 /* cfldrd mv9, [r0], #8 */
+	ldcl  p4, cr10, [r0], #8 /* cfldrd mv10, [r0], #8 */
+	ldcl  p4, cr11, [r0], #8 /* cfldrd mv11, [r0], #8 */
+	ldcl  p4, cr12, [r0], #8 /* cfldrd mv12, [r0], #8 */
+	ldcl  p4, cr13, [r0], #8 /* cfldrd mv13, [r0], #8 */
+	ldcl  p4, cr14, [r0], #8 /* cfldrd mv14, [r0], #8 */
+	ldcl  p4, cr15, [r0], #8 /* cfldrd mv15, [r0], #8 */
+	RET
+
+/* Store CRUNCH regsters mv0-mv15 to the address in r0.  */
+ARM_FUNC_START gnu_Unwind_Save_CRUNCH
+	/* Use the generic coprocessor form so that gas doesn't complain
+	   on soft-float targets.  */
+	stcl  p4, cr0, [r0], #8 /* cfstrd mv0, [r0], #8 */
+	stcl  p4, cr1, [r0], #8 /* cfstrd mv1, [r0], #8 */
+	stcl  p4, cr2, [r0], #8 /* cfstrd mv2, [r0], #8 */
+	stcl  p4, cr3, [r0], #8 /* cfstrd mv3, [r0], #8 */
+	stcl  p4, cr4, [r0], #8 /* cfstrd mv4, [r0], #8 */
+	stcl  p4, cr5, [r0], #8 /* cfstrd mv5, [r0], #8 */
+	stcl  p4, cr6, [r0], #8 /* cfstrd mv6, [r0], #8 */
+	stcl  p4, cr7, [r0], #8 /* cfstrd mv7, [r0], #8 */
+	stcl  p4, cr8, [r0], #8 /* cfstrd mv8, [r0], #8 */
+	stcl  p4, cr9, [r0], #8 /* cfstrd mv9, [r0], #8 */
+	stcl  p4, cr10, [r0], #8 /* cfstrd mv10, [r0], #8 */
+	stcl  p4, cr11, [r0], #8 /* cfstrd mv11, [r0], #8 */
+	stcl  p4, cr12, [r0], #8 /* cfstrd mv12, [r0], #8 */
+	stcl  p4, cr13, [r0], #8 /* cfstrd mv13, [r0], #8 */
+	stcl  p4, cr14, [r0], #8 /* cfstrd mv14, [r0], #8 */
+	stcl  p4, cr15, [r0], #8 /* cfstrd mv15, [r0], #8 */
+
+	RET
+
 /* Wrappers to save core registers, then call the real routine.   */
 
 .macro  UNWIND_WRAPPER name nargs
diff -urN gcc-4.3.0/gcc/config/arm-original/arm/pr-support.c gcc-4.3.0/gcc/config/arm/pr-support.c
--- gcc-4.3.0/gcc/config/arm-original/arm/pr-support.c	2006-12-14 03:32:47.000000000 +1000
+++ gcc-4.3.0/gcc/config/arm/pr-support.c	2008-04-10 17:26:11.000000000 +1000
@@ -322,6 +322,33 @@
 	    return _URC_FAILURE;
 	  continue;
 	}
+      if ((op & 0xf8) == 0xd8)
+ 	{
+	  if (op == 0xde)
+	    {
+	      /* Pop CRUNCH MV registers.  */
+	      op = next_unwind_byte (uws);
+	      op = ((op & 0xf0) << 12) | ((op & 0xf) + 1);
+	      if (_Unwind_VRS_Pop (context, _UVRSC_CRUNCH, op, _UVRSD_DOUBLE)
+		  != _UVRSR_OK)
+		return _URC_FAILURE;
+	      continue;
+	    }
+	  if (op == 0xdf)
+	    {
+		/* Spare.  */
+		return _URC_FAILURE;
+	    }
+	  /* op == 0xd8 to 0xdd */
+	    {
+	      /* Pop CRUNCH MV[10]-MV[10+nnn].  */
+	      op = 0xa0000 | ((op & 0xf) + 1);
+	      if (_Unwind_VRS_Pop (context, _UVRSC_CRUNCH, op, _UVRSD_DOUBLE)
+		  != _UVRSR_OK)
+		return _URC_FAILURE;
+	      continue;
+	    }
+    }
       /* Spare.  */
       return _URC_FAILURE;
     }
diff -urN gcc-4.3.0/gcc/config/arm-original/arm/unwind-arm.c gcc-4.3.0/gcc/config/arm/unwind-arm.c
--- gcc-4.3.0/gcc/config/arm-original/arm/unwind-arm.c	2007-09-05 01:05:01.000000000 +1000
+++ gcc-4.3.0/gcc/config/arm/unwind-arm.c	2008-04-10 17:27:25.000000000 +1000
@@ -101,6 +101,11 @@
   _uw wc[4];
 };
 
+struct crunch_regs
+{
+  _uw64 mv[16];
+};
+
 /* Unwind descriptors.  */
 
 typedef struct
@@ -135,6 +140,7 @@
   struct fpa_regs fpa;
   struct wmmxd_regs wmmxd;
   struct wmmxc_regs wmmxc;
+  struct crunch_regs crunch;
 } phase1_vrs;
 
 #define DEMAND_SAVE_VFP 1	/* VFP state has been saved if not set */
@@ -145,6 +151,8 @@
 				   saved if not set.  */
 #define DEMAND_SAVE_WMMXC 16	/* iWMMXt control registers have been
 				   saved if not set.  */
+#define DEMAND_SAVE_CRUNCH 32   /* CRUNCH registers have been
+				   saved if not set.  */
 
 /* This must match the structure created by the assembly wrappers.  */
 typedef struct
@@ -187,6 +195,10 @@
 void __gnu_Unwind_Save_VFP_D_16_to_31 (struct vfpv3_regs * p);
 void __gnu_Unwind_Restore_VFP_D_16_to_31 (struct vfpv3_regs * p);
 
+/* Routines for CRUNCH */
+void __gnu_Unwind_Save_CRUNCH (struct crunch_regs * p);
+void __gnu_Unwind_Restore_CRUNCH (struct crunch_regs * p);
+
 /* Restore coprocessor state after phase1 unwinding.  */
 static void
 restore_non_core_regs (phase1_vrs * vrs)
@@ -206,6 +218,9 @@
     __gnu_Unwind_Restore_WMMXD (&vrs->wmmxd);
   if ((vrs->demand_save_flags & DEMAND_SAVE_WMMXC) == 0)
     __gnu_Unwind_Restore_WMMXC (&vrs->wmmxc);
+
+  if ((vrs->demand_save_flags & DEMAND_SAVE_CRUNCH) == 0)
+    __gnu_Unwind_Restore_CRUNCH (&vrs->crunch);
 }
 
 /* A better way to do this would probably be to compare the absolute address
@@ -249,6 +264,7 @@
     case _UVRSC_FPA:
     case _UVRSC_WMMXD:
     case _UVRSC_WMMXC:
+    case _UVRSC_CRUNCH:
       return _UVRSR_NOT_IMPLEMENTED;
 
     default:
@@ -281,6 +297,7 @@
     case _UVRSC_FPA:
     case _UVRSC_WMMXD:
     case _UVRSC_WMMXC:
+    case _UVRSC_CRUNCH:
       return _UVRSR_NOT_IMPLEMENTED;
 
     default:
@@ -521,6 +538,45 @@
       }
       return _UVRSR_OK;
 
+    case _UVRSC_CRUNCH:
+      {
+       _uw start = discriminator >> 16;
+	   _uw count = discriminator & 0xffff;
+	   struct crunch_regs tmp;
+	   _uw *sp;
+	   _uw *dest;
+
+       if ((representation != _UVRSD_DOUBLE) || start + count > 16)
+	      return _UVRSR_FAILED;
+
+       if (vrs->demand_save_flags & DEMAND_SAVE_CRUNCH)
+       {
+         /* Demand-save resisters for stage1.  */
+         vrs->demand_save_flags &= ~DEMAND_SAVE_CRUNCH;
+         __gnu_Unwind_Save_CRUNCH (&vrs->crunch);
+	   }
+
+       /* Restore the registers from the stack.  Do this by saving the
+	   current CRUNCH registers to a memory area, moving the in-memory
+       values into that area, and restoring from the whole area.  */
+       __gnu_Unwind_Save_CRUNCH (&tmp);
+
+       /* The stack address is only guaranteed to be word aligned, so
+       we can't use doubleword copies.  */
+       sp = (_uw *) vrs->core.r[R_SP];
+       dest = (_uw *) &tmp.mv[start];
+       count *= 2;
+       while (count--)
+         *(dest++) = *(sp++);
+
+       /* Set the new stack pointer.  */
+       vrs->core.r[R_SP] = (_uw) sp;
+
+       /* Reload the registers.  */
+       __gnu_Unwind_Restore_CRUNCH (&tmp);
+      }
+      return _UVRSR_OK;
+
     default:
       return _UVRSR_FAILED;
     }
--- gcc-4.3.0/gcc/config/arm/unwind-arm.h-original	2008-04-11 10:04:38.000000000 +1000
+++ gcc-4.3.0/gcc/config/arm/unwind-arm.h	2008-04-11 10:05:06.000000000 +1000
@@ -132,7 +132,8 @@
       _UVRSC_VFP = 1,       /* vfp */
       _UVRSC_FPA = 2,       /* fpa */
       _UVRSC_WMMXD = 3,     /* Intel WMMX data register */
-      _UVRSC_WMMXC = 4      /* Intel WMMX control register */
+      _UVRSC_WMMXC = 4,     /* Intel WMMX control register */
+      _UVRSC_CRUNCH = 5     /* crunch */
     }
   _Unwind_VRS_RegClass;
 

Re: [linux-cirrus] Re: [gentoo-embedded] maverick-crunch queries

[Martin Guy]

On 12/23/08, Martin Guy <martinwguy@yahoo.it> wrote:
> On 12/22/08, Ahmed Ammar <b33fc0d3@gentoo.org> wrote:
>  >         .save {mv8}                     <-- Error: register expected
>
> No. This needs a modification to binutils, not gcc.

Oops. And gcc, since it should spit out the register as mvf0 mvd0 or
mvdx0 according to the mode it's being used in

Good luck!

    M

Re: [linux-cirrus] Re: [gentoo-embedded] maverick-crunch queries

[Ahmed Ammar]

On Tue, 2008-12-23 at 13:38 +0000, Martin Guy wrote:
> On 12/23/08, Martin Guy <martinwguy@yahoo.it> wrote:
> > On 12/22/08, Ahmed Ammar <b33fc0d3@gentoo.org> wrote:
> >  >         .save {mv8}                     <-- Error: register expected
> >
> > No. This needs a modification to binutils, not gcc.
> 
> Oops. And gcc, since it should spit out the register as mvf0 mvd0 or
> mvdx0 according to the mode it's being used in
> 

Not sure where to look for this stuff in both binutils and gcc, any
help/pointers would be greatly appreciated.

AA