Patchwork [U-Boot] tegra20: add back USE_PRIVATE_LIBGCC

login
register
mail settings
Submitter Lucas Stach
Date Aug. 7, 2012, 12:19 a.m.
Message ID <1344298788-7059-1-git-send-email-dev@lynxeye.de>
Download mbox | patch
Permalink /patch/175480/
State Rejected
Delegated to: Tom Warren
Headers show

Comments

Lucas Stach - Aug. 7, 2012, 12:19 a.m.
As discussed here [http://patchwork.ozlabs.org/patch/158202/] we want to
use USE_PRIVATE_LIBGCC still.

However commit 5286f1ce dropped it regardless. Adding this back fixes a
hang while handing over from SPL to U-Boot on Colibri T20.

Signed-off-by: Lucas Stach <dev@lynxeye.de>
CC: Stephen Warren <swarren@wwwdotorg.org>
CC: Tom Warren <TWarren@nvidia.com>
---
 arch/arm/cpu/armv7/tegra20/config.mk | 2 ++
 1 Datei geändert, 2 Zeilen hinzugefügt(+)
Stephen Warren - Aug. 7, 2012, 5 p.m.
On 08/06/2012 06:19 PM, Lucas Stach wrote:
> As discussed here [http://patchwork.ozlabs.org/patch/158202/] we want to
> use USE_PRIVATE_LIBGCC still.
> 
> However commit 5286f1ce dropped it regardless. Adding this back fixes a
> hang while handing over from SPL to U-Boot on Colibri T20.

This probably makes sense, but Allen should comment on this.

I wonder why I haven't seen any issue with this; perhaps SPL on all the
boards I tested ended up not using any libgcc functions? But in that
case, why would the Colibri board end up using them?
Lucas Stach - Aug. 7, 2012, 5:09 p.m.
Am Dienstag, den 07.08.2012, 11:00 -0600 schrieb Stephen Warren:
> On 08/06/2012 06:19 PM, Lucas Stach wrote:
> > As discussed here [http://patchwork.ozlabs.org/patch/158202/] we want to
> > use USE_PRIVATE_LIBGCC still.
> > 
> > However commit 5286f1ce dropped it regardless. Adding this back fixes a
> > hang while handing over from SPL to U-Boot on Colibri T20.
> 
> This probably makes sense, but Allen should comment on this.
> 
> I wonder why I haven't seen any issue with this; perhaps SPL on all the
> boards I tested ended up not using any libgcc functions? But in that
> case, why would the Colibri board end up using them?
> 
Could also be a toolchain issue. My normal workflow uses a toolchain
without a libgcc, as we didn't needed it to this point.
After porting over my changes to the new SPL boot I had to switch to a
CodeSourcery toolchain containing a libgcc. So I'm not entirely sure
where the problem lies, as I varied codebase and toolchain at one. But I
confirmed that this patch works with both of my toolchains.

So yes, I'm really in favour of some comments.

Thanks,
Lucas
Allen Martin - Aug. 7, 2012, 5:43 p.m.
On Tue, Aug 07, 2012 at 10:09:00AM -0700, Lucas Stach wrote:
> Am Dienstag, den 07.08.2012, 11:00 -0600 schrieb Stephen Warren:
> > On 08/06/2012 06:19 PM, Lucas Stach wrote:
> > > As discussed here [http://patchwork.ozlabs.org/patch/158202/] we want to
> > > use USE_PRIVATE_LIBGCC still.
> > > 
> > > However commit 5286f1ce dropped it regardless. Adding this back fixes a
> > > hang while handing over from SPL to U-Boot on Colibri T20.
> > 
> > This probably makes sense, but Allen should comment on this.
> > 
> > I wonder why I haven't seen any issue with this; perhaps SPL on all the
> > boards I tested ended up not using any libgcc functions? But in that
> > case, why would the Colibri board end up using them?
> > 
> Could also be a toolchain issue. My normal workflow uses a toolchain
> without a libgcc, as we didn't needed it to this point.
> After porting over my changes to the new SPL boot I had to switch to a
> CodeSourcery toolchain containing a libgcc. So I'm not entirely sure
> where the problem lies, as I varied codebase and toolchain at one. But I
> confirmed that this patch works with both of my toolchains.
> 
> So yes, I'm really in favour of some comments.

What's the CodeSourcery toolchain you're using?  The
USE_PRIVATE_LIBGCC was used to prevent armv5 instructions from the
toolchain's libgcc from getting into the code that executes on the AVP
which is an arm7tdmi (armv4t).  Since all the code that runs on the
AVP is built separately now as part of the SPL, using the toolchain's
libgcc should work for the main u-boot build.  USE_PRIVATE_LIBGCC is
still turned on for the SPL build.

I've tested the following toolchains on ventana and seaboard tegra20
platforms:

gcc 4.4.6 arm7tdmi-linux-gnueabi built with crosstool-ng
gcc 4.4.6 cortex_a9-linux-gnueabi built with crosstool-ng
gcc 4.6.1 cortex_a9-linux-gnueabi built with crosstool-ng

Tell me what CodeSourcery version you're using and I'll test it here
as well and see if I can reproduce the problem.

-Allen
Lucas Stach - Aug. 7, 2012, 5:53 p.m.
Hi Allen,

Am Dienstag, den 07.08.2012, 10:43 -0700 schrieb Allen Martin:
> On Tue, Aug 07, 2012 at 10:09:00AM -0700, Lucas Stach wrote:
> > Am Dienstag, den 07.08.2012, 11:00 -0600 schrieb Stephen Warren:
> > > On 08/06/2012 06:19 PM, Lucas Stach wrote:
> > > > As discussed here [http://patchwork.ozlabs.org/patch/158202/] we want to
> > > > use USE_PRIVATE_LIBGCC still.
> > > > 
> > > > However commit 5286f1ce dropped it regardless. Adding this back fixes a
> > > > hang while handing over from SPL to U-Boot on Colibri T20.
> > > 
> > > This probably makes sense, but Allen should comment on this.
> > > 
> > > I wonder why I haven't seen any issue with this; perhaps SPL on all the
> > > boards I tested ended up not using any libgcc functions? But in that
> > > case, why would the Colibri board end up using them?
> > > 
> > Could also be a toolchain issue. My normal workflow uses a toolchain
> > without a libgcc, as we didn't needed it to this point.
> > After porting over my changes to the new SPL boot I had to switch to a
> > CodeSourcery toolchain containing a libgcc. So I'm not entirely sure
> > where the problem lies, as I varied codebase and toolchain at one. But I
> > confirmed that this patch works with both of my toolchains.
> > 
> > So yes, I'm really in favour of some comments.
> 
> What's the CodeSourcery toolchain you're using?  The
> USE_PRIVATE_LIBGCC was used to prevent armv5 instructions from the
> toolchain's libgcc from getting into the code that executes on the AVP
> which is an arm7tdmi (armv4t).  Since all the code that runs on the
> AVP is built separately now as part of the SPL, using the toolchain's
> libgcc should work for the main u-boot build.  USE_PRIVATE_LIBGCC is
> still turned on for the SPL build.
> 
> I've tested the following toolchains on ventana and seaboard tegra20
> platforms:
> 
> gcc 4.4.6 arm7tdmi-linux-gnueabi built with crosstool-ng
> gcc 4.4.6 cortex_a9-linux-gnueabi built with crosstool-ng
> gcc 4.6.1 cortex_a9-linux-gnueabi built with crosstool-ng
> 
> Tell me what CodeSourcery version you're using and I'll test it here
> as well and see if I can reproduce the problem.
> 
I used CodeSourcery arm-2011.09-70-arm-none-linux-gnueabi to test this.

And to answer Tom's question: the failure was that the real U-Boot would
not come up after the SPL. All I could see was the one line printed by
the SPL and nothing more.

Thanks,
Lucas
Wolfgang Denk - Aug. 7, 2012, 6:36 p.m.
Dear Lucas Stach,

In message <1344298788-7059-1-git-send-email-dev@lynxeye.de> you wrote:
> As discussed here [http://patchwork.ozlabs.org/patch/158202/] we want to
> use USE_PRIVATE_LIBGCC still.
> 
> However commit 5286f1ce dropped it regardless. Adding this back fixes a
> hang while handing over from SPL to U-Boot on Colibri T20.
> 
> Signed-off-by: Lucas Stach <dev@lynxeye.de>
> CC: Stephen Warren <swarren@wwwdotorg.org>
> CC: Tom Warren <TWarren@nvidia.com>
> ---
>  arch/arm/cpu/armv7/tegra20/config.mk | 2 ++
>  1 Datei geändert, 2 Zeilen hinzugefügt(+)
> 
> diff --git a/arch/arm/cpu/armv7/tegra20/config.mk b/arch/arm/cpu/armv7/tegra20/config.mk
> index 6432e75..e666f6b 100644
> --- a/arch/arm/cpu/armv7/tegra20/config.mk
> +++ b/arch/arm/cpu/armv7/tegra20/config.mk
> @@ -23,4 +23,6 @@
>  # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>  # MA 02111-1307 USA
>  #
> +USE_PRIVATE_LIBGCC = yes

NAK.

USE_PRIVATE_LIBGCC is a workaround for broken tool chains only.  It
must never be automatically set for any configuration.

If you know of tool chains that require this, then complain there and
have the bugs fixed with hteir upstream.

Yes, I know this may be painful to you, and it _shall_ be painful, so
that you finally take some action to have the tool chains fixed that
need so.

I will not accept anything like this in mainline.  Sorry.

Best regards,

Wolfgang Denk
Allen Martin - Aug. 7, 2012, 8:11 p.m.
On Tue, Aug 07, 2012 at 10:53:00AM -0700, Lucas Stach wrote:
> Hi Allen,
> 
> > Tell me what CodeSourcery version you're using and I'll test it here
> > as well and see if I can reproduce the problem.
> > 
> I used CodeSourcery arm-2011.09-70-arm-none-linux-gnueabi to test this.
> 
> And to answer Tom's question: the failure was that the real U-Boot would
> not come up after the SPL. All I could see was the one line printed by
> the SPL and nothing more.
> 

I'm able to reproduce this on seaboard with the CodeSourcery
arm-2011.09-70-arm-none-linux-gnueabi.  I tried adding back
USE_PRIVATE_LIBGCC=yes and I'm still seeing it fail the same way
though, so maybe what I'm seeing is different or it's a combination of
things.  Regardless I have a JTAG debugger on the system so I'll drill
down until I figure out what's wrong.

-Allen

Patch

diff --git a/arch/arm/cpu/armv7/tegra20/config.mk b/arch/arm/cpu/armv7/tegra20/config.mk
index 6432e75..e666f6b 100644
--- a/arch/arm/cpu/armv7/tegra20/config.mk
+++ b/arch/arm/cpu/armv7/tegra20/config.mk
@@ -23,4 +23,6 @@ 
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
+USE_PRIVATE_LIBGCC = yes
+
 CONFIG_ARCH_DEVICE_TREE := tegra20