From ams at codesourcery.com Tue May 3 09:33:09 2011 From: ams at codesourcery.com (Andrew Stubbs) Date: Tue, 03 May 2011 10:33:09 +0100 Subject: [superh-gnu-discuss] gcc flag: what to add In-Reply-To: References: <4DB94C36.3030808@codesourcery.com> Message-ID: <4DBFCBD5.9090703@codesourcery.com> On 29/04/11 08:47, Prasanta Sadhukhan wrote: > If you revert back to the GCC 4.4 based Lite toolchain [1], you'll > find that that supported SH4AL-DSP, which is essentially the same as > -m4-nofpu, so you might get further with that. > > Thanks for the information. However, when I tried Sourcery G++ Lite > 4.4-200 and compiled the program with > -m4-nofpu > I am still getting "Illegal instruction". [also tried with the above > options] Sorry, I should have been clearer, the 4.4-200 release does not support -m4-nofpu, but it does support -m4al which is essentially the same thing. If you build with -m4-nofpu it will still link the default libraries (i.e. -m4a) because it is not smart enough to figure out that it has a better option. The result is the illegal instructions you're seeing. Please try again with -m4al instead of -m4-nofpu. > I guess -m4-nofpu generated code will still not run in SH7712 sh3 > architecture, am I right? This may be true; I have not confirmed it. However, I do not believe -m4-nofpu supports any instructions that -m3 does not. > Can any of this lite toolchain in > http://www.codesourcery.com/sgpp/lite/superh/portal/subscription6790 > generate code that will run in SH7712 sh3 chipset? No, there are no CodeSourcery toolchains that target SH-3. We currently support SH-4A Linux, SH4AL-DSP Linux, and SH-2A FDPIC uClinux only. As I said, if you would like CodeSourcery toolchains to support SH3, please contact sales at codesourcery.com. Andrew From PHIL.EDWORTHY at renesas.com Mon May 16 15:32:47 2011 From: PHIL.EDWORTHY at renesas.com (PHIL.EDWORTHY at renesas.com) Date: Mon, 16 May 2011 16:32:47 +0100 Subject: SH2A uCLinux toolchain Message-ID: Hi, I have just tried to build a linux kernel using the latest CodeSourcery SH2A toolchain, Sourcery G++ Lite 2010.09-60 The toolchain is only provided with fdpic libraries, but this is only useful for userspace code afaik. The kernel already forces -mno-fdpic, so should I use this option with U-Boot as well? The problem is that both the kernel, when building a zImage, and U-Boot, link against libgcc. This leads to "attempt to mix FDPIC and non-FDPIC objects" errors. So my question is, how can I use this toolchain for uCLinux development? Thanks Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From ams at codesourcery.com Mon May 16 16:09:44 2011 From: ams at codesourcery.com (Andrew Stubbs) Date: Mon, 16 May 2011 17:09:44 +0100 Subject: [superh-gnu-discuss] SH2A uCLinux toolchain In-Reply-To: References: Message-ID: <4DD14C48.9050909@codesourcery.com> On 16/05/11 16:32, PHIL.EDWORTHY at renesas.com wrote: > The toolchain is only provided with fdpic libraries, but this is only > useful for userspace code afaik. The kernel already forces -mno-fdpic, > so should I use this option with U-Boot as well? > > The problem is that both the kernel, when building a zImage, and U-Boot, > link against libgcc. This leads to "attempt to mix FDPIC and non-FDPIC > objects" errors. The problem is that libgcc (a behind-the-scenes library containing essential helper functions for compiled code) is compiled for FDPIC. This is necessary for user-space, as you say. The kernel and u-boot are special cases in that they are bare-metal applications that are typically built with a (normally unsuitable) Linux/uClinux user-space toolchain. This means they should provide a complete set of libgcc-compatible replacement routines that work in a bare-metal context. The kernel does, in fact, provide sufficient routines to build a normal kernel, but apparently is missing (at least) one used by the compressed kernel. I'm not familiar with U-boot, but presumably it should be doing the same. You can probably copy many of the routines from the kernel sources. The rest can be obtained from the compiler sources, or by building a reconfigured compiler. Note that this problem is not SH-specific, but true on all platforms. That said, the FDPIC user-space *is* more incompatible with bare-metal than in most cases. > So my question is, how can I use this toolchain for uCLinux development? The toolchain can be used for user-space uClinux development, but the kernel and u-boot must either be built with a bare-metal toolchain, or else have patches applied to work with the Linux toolchain (as the kernel mostly does). Sorry, but the our Renesas contract does not specify any bare-metal configurations. If you think that should be changed, I believe you should talk to Paul Mundt or Hisao Munakata on your side. Paul might also have a technical solution for u-boot already. Andrew From PHIL.EDWORTHY at renesas.com Tue May 17 07:59:56 2011 From: PHIL.EDWORTHY at renesas.com (PHIL.EDWORTHY at renesas.com) Date: Tue, 17 May 2011 08:59:56 +0100 Subject: [superh-gnu-discuss] SH2A uCLinux toolchain In-Reply-To: <4DD14C48.9050909@codesourcery.com> References: <4DD14C48.9050909@codesourcery.com> Message-ID: Hi Andrew, > From: Andrew Stubbs > To: PHIL.EDWORTHY at renesas.com > Cc: "superh-gnu-discuss at codesourcery.com" > Date: 16/05/2011 17:09 > Subject: Re: [superh-gnu-discuss] SH2A uCLinux toolchain > Sent by: ams at codesourcery.com > > On 16/05/11 16:32, PHIL.EDWORTHY at renesas.com wrote: > > The toolchain is only provided with fdpic libraries, but this is only > > useful for userspace code afaik. The kernel already forces -mno-fdpic, > > so should I use this option with U-Boot as well? > > > > The problem is that both the kernel, when building a zImage, and U-Boot, > > link against libgcc. This leads to "attempt to mix FDPIC and non-FDPIC > > objects" errors. > > The problem is that libgcc (a behind-the-scenes library containing > essential helper functions for compiled code) is compiled for FDPIC. > This is necessary for user-space, as you say. > > The kernel and u-boot are special cases in that they are bare-metal > applications that are typically built with a (normally unsuitable) > Linux/uClinux user-space toolchain. This means they should provide a > complete set of libgcc-compatible replacement routines that work in a > bare-metal context. > > The kernel does, in fact, provide sufficient routines to build a normal > kernel, but apparently is missing (at least) one used by the compressed > kernel. I'm not familiar with U-boot, but presumably it should be doing > the same. You can probably copy many of the routines from the kernel > sources. The rest can be obtained from the compiler sources, or by > building a reconfigured compiler. > > Note that this problem is not SH-specific, but true on all platforms. > That said, the FDPIC user-space *is* more incompatible with bare-metal > than in most cases. > > > So my question is, how can I use this toolchain for uCLinux development? > > The toolchain can be used for user-space uClinux development, but the > kernel and u-boot must either be built with a bare-metal toolchain, or > else have patches applied to work with the Linux toolchain (as the > kernel mostly does). > > Sorry, but the our Renesas contract does not specify any bare-metal > configurations. If you think that should be changed, I believe you > should talk to Paul Mundt or Hisao Munakata on your side. Paul might > also have a technical solution for u-boot already. Ok, that's a nice and clear summary, thanks. I'll talk to Paul about uboot. Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: