From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4770 invoked by alias); 9 Sep 2009 18:06:12 -0000 Received: (qmail 4643 invoked by uid 22791); 9 Sep 2009 18:06:09 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_38,J_CHICKENPOX_41 X-Spam-Check-By: sourceware.org Received: from exprod6ob111.obsmtp.com (HELO psmtp.com) (64.18.1.26) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Wed, 09 Sep 2009 18:06:05 +0000 Received: from source ([63.240.6.3]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKSqfui7zVD7m2WUUg1QjAcO66LgjsbXp5@postini.com; Wed, 09 Sep 2009 11:06:05 PDT Received: from d01smtp06.Mi8.com ([172.16.1.239]) by Outbound02.Mi8.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 14:06:02 -0400 Received: from mi8nycmail19.Mi8.com ([172.16.7.219]) by d01smtp06.Mi8.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 14:06:02 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target) Date: Wed, 09 Sep 2009 18:06:00 -0000 Message-ID: In-Reply-To: <56d259a00909090401i42a852e4g3764219d8a597ae5@mail.gmail.com> References: <56d259a00909090401i42a852e4g3764219d8a597ae5@mail.gmail.com> From: "H Hartley Sweeten" To: "Martin Guy" Cc: , Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00039.txt.bz2 On Wednesday, September 09, 2009 4:01 AM, Martin Guy wrote: >>> (maverick) Use specific FPU >>> Floating point: ---> hardware (FPU) > > Don't do that! :) Mainline GCC's code generation for Maverick is > completely broken, glibc needs patches, binutils barfs on some GCC > output for C++, and the FPU itself is full of hardware timing bugs > that GCC fails miserably to work around. > I have a set of working GCC patches for C, and OE have collected the > glibc and binutils patches but I've never heard of anyone getting a > fully working rootfs yet. OK. I removed the "maverick" setting and set the Floating point to software. >>> NB: do not enable EABI, I think it requires at least armv5t, but I'm >>> not sure. So stay on the safe side, and stick with OABI. > > EABI requires armv4t. The only thing v5t has at an ISA level is an > extra instruction, count leading zeros, which is used in glibc's asm > division routine ifdef armv5t. armv4t would have been a better GCC > default. I agree. Would have made my life easier with the CodeSourcery toolchain. ;= -) > I think we can safely ditch OABI these days, unless you have an armv4 > (the StrongARM) or armv3. It has no technical advantages, and most > programs that had bugs needing fixing have now been fixed. There are a > few stragglers: gnat ADA, clisp common lisp, fpc free pascal compiler > and any version of GCC <4.1.0 >=20 >> I used arm920t instead of ep9312 but I believe ep9312 is just an alias. > for arm920t, yes. It also passes "armv4t+maverick" to the assembler so > that maverick insns are not rejected by the assembler. (cpu=3Darm920t > fpu=3Dmaverick makes the assembler barf. Yes, this is a mess!) So with "arm920t" does the assembler work ok for the ep93xx or should it be "ep9312"? What should my target options be for the ep93xx? Right now I have: CT_ARCH=3D"arm" CT_ARCH_SUPPORTS_BOTH_ENDIAN=3Dy CT_ARCH_SUPPORT_ARCH=3Dy CT_ARCH_SUPPORT_CPU=3Dy CT_ARCH_SUPPORT_TUNE=3Dy CT_ARCH_SUPPORT_FPU=3Dy CT_ARCH_DEFAULT_LE=3Dy CT_ARCH_ARCH=3D"armv4t" CT_ARCH_CPU=3D"arm920t" CT_ARCH_TUNE=3D"arm920t" CT_ARCH_FPU=3D"" CT_ARCH_LE=3Dy CT_ARCH_FLOAT_SW=3Dy CT_TARGET_CFLAGS=3D"" CT_TARGET_LDFLAGS=3D"" Thanks for any help! Regards, Hartley -- For unsubscribe information see http://sourceware.org/lists.html#faq