[U-Boot] [PATCH] tegra20: add back USE_PRIVATE_LIBGCC
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 + CONFIG_ARCH_DEVICE_TREE := tegra20
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?
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
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
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
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
On Tue, Aug 07, 2012 at 10:53:00AM -0700, Lucas Stach wrote:
Hi Allen,
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 think I found the problem. It's the following code from start.S:
ENTRY(cpu_init_crit) /* * Jump to board specific initialization... * The Mask ROM will have already initialized * basic memory. Go here to bump up clock rate and handle * wake up conditions. */ mov ip, lr @ persevere link reg across call bl lowlevel_init @ go setup pll,mux,memory mov lr, ip @ restore link mov pc, lr @ back to my caller ENDPROC(cpu_init_crit)
The "ip" register is not preserved across function calls, and the CodeSourcery compiler is using it in lowlevel_init or one of the functions it calls. This code was there before the SPL changes, but wasn't being called because CONFIG_SKIP_LOWLEVEL_INIT was set, but now it isn't.
Lucas, can you try the following change? I tested it on seaboard with CodeSourcery arm-2011.09-70-arm-none-linux-gnueabi and I'm able to boot a kernel.
Tom if this works we probably want to get it into your pull request to Albert. CodeSourcery toolchain is probably used by a lot of people.
-Allen
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 2506f27..02e47fa 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -152,7 +152,7 @@ reset: /* the mask ROM code should have PLL and others stable */ #ifndef CONFIG_SKIP_LOWLEVEL_INIT bl cpu_init_cp15 - bl cpu_init_crit + bl lowlevel_init @ go setup pll,mux,memory #endif
/* Set stackpointer in internal RAM to call board_init_f */ @@ -339,29 +339,6 @@ ENTRY(cpu_init_cp15) mov pc, lr @ back to my caller ENDPROC(cpu_init_cp15)
-#ifndef CONFIG_SKIP_LOWLEVEL_INIT -/************************************************************************* - * - * CPU_init_critical registers - * - * setup important registers - * setup memory timing - * - *************************************************************************/ -ENTRY(cpu_init_crit) - /* - * Jump to board specific initialization... - * The Mask ROM will have already initialized - * basic memory. Go here to bump up clock rate and handle - * wake up conditions. - */ - mov ip, lr @ persevere link reg across -call - bl lowlevel_init @ go setup pll,mux,memory - mov lr, ip @ restore link - mov pc, lr @ back to my caller -ENDPROC(cpu_init_crit) -#endif - #ifndef CONFIG_SPL_BUILD /* *************************************************************************
Am Dienstag, den 07.08.2012, 15:28 -0700 schrieb Allen Martin:
On Tue, Aug 07, 2012 at 10:53:00AM -0700, Lucas Stach wrote:
Hi Allen,
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 think I found the problem. It's the following code from start.S:
ENTRY(cpu_init_crit) /* * Jump to board specific initialization... * The Mask ROM will have already initialized * basic memory. Go here to bump up clock rate and handle * wake up conditions. */ mov ip, lr @ persevere link reg across call bl lowlevel_init @ go setup pll,mux,memory mov lr, ip @ restore link mov pc, lr @ back to my caller ENDPROC(cpu_init_crit)
The "ip" register is not preserved across function calls, and the CodeSourcery compiler is using it in lowlevel_init or one of the functions it calls. This code was there before the SPL changes, but wasn't being called because CONFIG_SKIP_LOWLEVEL_INIT was set, but now it isn't.
Lucas, can you try the following change? I tested it on seaboard with CodeSourcery arm-2011.09-70-arm-none-linux-gnueabi and I'm able to boot a kernel.
Yes I can confirm this fixes the issue without further workarounds. Thanks, and:
Tested-by: Lucas Stach dev@lynxeye.de
Tom if this works we probably want to get it into your pull request to Albert. CodeSourcery toolchain is probably used by a lot of people.
-Allen
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 2506f27..02e47fa 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -152,7 +152,7 @@ reset: /* the mask ROM code should have PLL and others stable */ #ifndef CONFIG_SKIP_LOWLEVEL_INIT bl cpu_init_cp15
bl cpu_init_crit
bl lowlevel_init @ go setup pll,mux,memory#endif
/* Set stackpointer in internal RAM to call board_init_f */ @@ -339,29 +339,6 @@ ENTRY(cpu_init_cp15) mov pc, lr @ back to my caller ENDPROC(cpu_init_cp15)
-#ifndef CONFIG_SKIP_LOWLEVEL_INIT -/*************************************************************************
- CPU_init_critical registers
- setup important registers
- setup memory timing
- *************************************************************************/
-ENTRY(cpu_init_crit)
/** Jump to board specific initialization...* The Mask ROM will have already initialized* basic memory. Go here to bump up clock rate and handle* wake up conditions.*/mov ip, lr @ persevere link reg across-call
bl lowlevel_init @ go setup pll,mux,memorymov lr, ip @ restore linkmov pc, lr @ back to my caller-ENDPROC(cpu_init_crit) -#endif
#ifndef CONFIG_SPL_BUILD /*
On Tue, Aug 07, 2012 at 03:42:45PM -0700, Lucas Stach wrote:
Am Dienstag, den 07.08.2012, 15:28 -0700 schrieb Allen Martin:
On Tue, Aug 07, 2012 at 10:53:00AM -0700, Lucas Stach wrote:
Hi Allen,
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 think I found the problem. It's the following code from start.S:
ENTRY(cpu_init_crit) /* * Jump to board specific initialization... * The Mask ROM will have already initialized * basic memory. Go here to bump up clock rate and handle * wake up conditions. */ mov ip, lr @ persevere link reg across call bl lowlevel_init @ go setup pll,mux,memory mov lr, ip @ restore link mov pc, lr @ back to my caller ENDPROC(cpu_init_crit)
The "ip" register is not preserved across function calls, and the CodeSourcery compiler is using it in lowlevel_init or one of the functions it calls. This code was there before the SPL changes, but wasn't being called because CONFIG_SKIP_LOWLEVEL_INIT was set, but now it isn't.
Lucas, can you try the following change? I tested it on seaboard with CodeSourcery arm-2011.09-70-arm-none-linux-gnueabi and I'm able to boot a kernel.
Yes I can confirm this fixes the issue without further workarounds. Thanks, and:
Tested-by: Lucas Stach dev@lynxeye.de
Digging a little deeper into this, cpu_init_crit() and lowlevel_init() are called before the stack is setup, so the fact that we call into C code on tegra here is probably the bigger issue. I think the correct fix here is for me to move the code from lowlevel_init() to board_init_f().
-Allen
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
participants (4)
-
Allen Martin -
Lucas Stach -
Stephen Warren -
Wolfgang Denk