[U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND
Hi everybody,
I try to bring up fw_setenv / fw_printenv in linux kernel but first it want to start with u-boot itself. I built most recent u-boot-marvell git source and get a running u-boot with standard openrd configuration. So far so good.
version says: ArtistaNET-III>> version
U-Boot 2009.08-00208-g9ef0569-dirty (Sep 29 2009 - 15:42:42) OpenRD_base
But saveenv will not work as expected. setenv of new parameter will work but after saveenv and reboot the new parameter is lost and u-boot complains about wrong CRC again.
Any help would be very appreciated.
Dieter
Am Dienstag 29 September 2009 15:55:55 schrieb Dieter Kiermaier:
Hi everybody,
I try to bring up fw_setenv / fw_printenv in linux kernel but first it want to start with u-boot itself. I built most recent u-boot-marvell git source and get a running u-boot with standard openrd configuration. So far so good.
Hm, it looks like there is the whole nand system somewhat broken :( Haven't seen it earlier, but: U-Boot 2009.08-00208-g9ef0569-dirty (Sep 29 2009 - 15:42:42) OpenRD_base
SoC: Kirkwood 88F6281_A0 DRAM: 27535155593740288 MB NAND: 0 MiB *** Warning - bad CRC or NAND, using default environment
In: serial Out: serial Err: serial Net: egiga0 88E1116 Initialized on egiga0
But boot message state that there is no NAND detected! So I assume that is the main cause for the not working saveenv command? Cross checked it with marvell provided u-boot - this one works. So damaged hardware isn't the case.
Please could somebody check it, too?
Many thanks, Dieter
version says: ArtistaNET-III>> version
U-Boot 2009.08-00208-g9ef0569-dirty (Sep 29 2009 - 15:42:42) OpenRD_base
But saveenv will not work as expected. setenv of new parameter will work but after saveenv and reboot the new parameter is lost and u-boot complains about wrong CRC again.
Any help would be very appreciated.
Dieter _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Tue, 29 Sep 2009 17:16:42 +0200 Dieter Kiermaier dk-arm-linux@gmx.de wrote:
Hm, it looks like there is the whole nand system somewhat broken :( Haven't seen it earlier, but: U-Boot 2009.08-00208-g9ef0569-dirty (Sep 29 2009 - 15:42:42) OpenRD_base
SoC: Kirkwood 88F6281_A0 DRAM: 27535155593740288 MB NAND: 0 MiB *** Warning - bad CRC or NAND, using default environment
But boot message state that there is no NAND detected! So I assume that is the main cause for the not working saveenv command? Cross checked it with marvell provided u-boot - this one works. So damaged hardware isn't the case.
It's a EABI problem, see this thread:
http://lists.denx.de/pipermail/u-boot/2009-September/059896.html
(and the other one referred from here). We don't have a good solution yet, but you have a hacky patch to revert to the old ABI at the end of the thread above.
We still haven't found out what's actually causing this. EABI itself should be fine since Linux works well with it, but something is causing problems with multiple versions of GCC for U-boot. For now you can use the patch referred to above. For me, saveenv works fine on OpenRD, so it should be OK for you as well :-)
// Simon
Hi Simon,
On Tue, 29 Sep 2009 17:16:42 +0200 Dieter Kiermaier dk-arm-linux@gmx.de wrote:
Hm, it looks like there is the whole nand system somewhat broken :( Haven't seen it earlier, but: U-Boot 2009.08-00208-g9ef0569-dirty (Sep 29 2009 - 15:42:42) OpenRD_base
SoC: Kirkwood 88F6281_A0 DRAM: 27535155593740288 MB NAND: 0 MiB *** Warning - bad CRC or NAND, using default environment
But boot message state that there is no NAND detected! So I assume that is the main cause for the not working saveenv command? Cross checked it with marvell provided u-boot - this one works. So damaged hardware isn't the case.
It's a EABI problem, see this thread:
http://lists.denx.de/pipermail/u-boot/2009-September/059896.html
(and the other one referred from here). We don't have a good solution yet, but you have a hacky patch to revert to the old ABI at the end of the thread above.
Many thanks for the link, but now I've got other strange errors during u-boot compile:
arm-none-linux-gnueabi-ld: ERROR: Source object /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_udivsi3.o) has EABI version 4, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_udivsi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_divsi3.o) has EABI version 4, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_divsi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_umodsi3.o) has EABI version 4, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_umodsi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_modsi3.o) has EABI version 4, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_modsi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_lshrdi3.o) has EABI version 4, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_lshrdi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_ashrdi3.o) has EABI version 4, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_ashrdi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_ashldi3.o) has EABI version 4, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_ashldi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_dvmd_lnx.o) has EABI version 4, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_dvmd_lnx.o) make: *** [u-boot] Fehler 1 dieter@dk1-linux:~/git/u-boot-marvell$
I use following precompiled toolchain from marvell: dieter@dk1-linux:~/git/u-boot-gw.git$ /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/arm-none-linux-gnueabi-gcc --version arm-none-linux-gnueabi-gcc (GCC) 4.2.0 20070413 (prerelease) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Do you know how I can solve this problem? (I've read the two given mail threads but found no hint to this problem, so maybe my toolchain is broken?)
Many thanks, Dieter
We still haven't found out what's actually causing this. EABI itself should be fine since Linux works well with it, but something is causing problems with multiple versions of GCC for U-boot. For now you can use the patch referred to above. For me, saveenv works fine on OpenRD, so it should be OK for you as well :-)
// Simon
On Wed, 30 Sep 2009 09:02:14 +0200 Dieter Kiermaier dk-arm-linux@gmx.de wrote:
arm-none-linux-gnueabi-ld: ERROR: Source object /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_udivsi3.o) has EABI version 4, but target u-boot has EABI version 0
Do you know how I can solve this problem? (I've read the two given mail threads but found no hint to this problem, so maybe my toolchain is broken?)
Sounds like you might have problems with USE_PRIVATE_LIBGCC. See this mail for how to test this:
http://lists.denx.de/pipermail/u-boot/2009-August/059313.html
And see this for more info on how USE_PRIVATE_LIBGCC before trying to set it to no:
http://lists.denx.de/pipermail/u-boot/2009-August/059324.html
;-)
// Simon
Hi Simon, hi Prafulla,
On Wed, 30 Sep 2009 09:02:14 +0200 Dieter Kiermaier dk-arm-linux@gmx.de wrote:
arm-none-linux-gnueabi-ld: ERROR: Source object /home/dieter/ArtistaNET-III/Software/trunk/SDK/tools/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_udivsi3.o) has EABI version 4, but target u-boot has EABI version 0
Do you know how I can solve this problem? (I've read the two given mail threads but found no hint to this problem, so maybe my toolchain is broken?)
Sounds like you might have problems with USE_PRIVATE_LIBGCC. See this mail for how to test this:
http://lists.denx.de/pipermail/u-boot/2009-August/059313.html
export USE_PRIVATE_LIBGCC=yes seems to solve my problem - even if I don't exactly understand what I'm doing :(
But now I know what I've been searching for.
@Prafulla: Hi Prafulla, is there anywhere a document how to build open source u-boot for sheevaplug which explains all these details? (haven't found some documentation about this) I would expect that many others are no u-boot experts, too. And stumble into the same pitfalls?
Many thanks, Dieter
And see this for more info on how USE_PRIVATE_LIBGCC before trying to set it to no:
http://lists.denx.de/pipermail/u-boot/2009-August/059324.html
;-)
// Simon
On Wed, 30 Sep 2009 09:40:07 +0200 Dieter Kiermaier dk-arm-linux@gmx.de wrote:
Sounds like you might have problems with USE_PRIVATE_LIBGCC. See this mail for how to test this:
http://lists.denx.de/pipermail/u-boot/2009-August/059313.html
export USE_PRIVATE_LIBGCC=yes seems to solve my problem - even if I don't exactly understand what I'm doing :(
You use a libgcc from uboot/lib_arm, built when you build uboot, instead of the one you built with gcc. Basically you will build this with the same ABI options as you build the rest of uboot, so it will avoid the linker errors you got before.
@Prafulla: Hi Prafulla, is there anywhere a document how to build open source u-boot for sheevaplug which explains all these details? (haven't found some documentation about this)
(Wearing my Prafulla hat): I guess this should be described on the plugwiki:
http://www.openplug.org/plugwiki/index.php/Das_U-boot_plug_support#Open_U-bo...
but we really just need to solve the EABI problem.
Wolfgang/Stefan/Tom/Prafulla: Would a patch like the one below be acceptable until we find out a proper fix? I realise that this also affects other arm926ejs-boards, but is there some way to isolate this to kirkwood?
// Simon
From 29ff02ca77406e820203ad27369e0684aa1a098c Mon Sep 17 00:00:00 2001 From: Simon Kagstrom simon.kagstrom@netinsight.net Date: Fri, 4 Sep 2009 11:15:20 +0200 Subject: [PATCH] Make arm926ejs use -mabi=apcs-gnu and private libgcc
Using -mabi=apcs-gnu allows Marvell Kirkwood-based boards to boot with the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. Since this changes the ABI, USE_PRIVATE_LIBGCC is also defined.
Signed-off-by: Simon Kagstrom simon.kagstrom@netinsight.net --- cpu/arm926ejs/config.mk | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/cpu/arm926ejs/config.mk b/cpu/arm926ejs/config.mk index f8ef90f..1c9d547 100644 --- a/cpu/arm926ejs/config.mk +++ b/cpu/arm926ejs/config.mk @@ -20,10 +20,11 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # +USE_PRIVATE_LIBGCC = yes
PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
-PLATFORM_CPPFLAGS += -march=armv5te +PLATFORM_CPPFLAGS += -march=armv5te -mabi=apcs-gnu # ========================================================================= # # Supply options according to compiler version
Am Mittwoch 30 September 2009 09:57:10 schrieb Simon Kagstrom:
On Wed, 30 Sep 2009 09:40:07 +0200 Dieter Kiermaier dk-arm-linux@gmx.de wrote:
Sounds like you might have problems with USE_PRIVATE_LIBGCC. See this mail for how to test this:
http://lists.denx.de/pipermail/u-boot/2009-August/059313.html
export USE_PRIVATE_LIBGCC=yes seems to solve my problem - even if I don't exactly understand what I'm doing :(
You use a libgcc from uboot/lib_arm, built when you build uboot, instead of the one you built with gcc. Basically you will build this with the same ABI options as you build the rest of uboot, so it will avoid the linker errors you got before.
Ahh, ok. Thanks for pointing this out!
@Prafulla: Hi Prafulla, is there anywhere a document how to build open source u-boot for sheevaplug which explains all these details? (haven't found some documentation about this)
(Wearing my Prafulla hat): I guess this should be described on the plugwiki:
http://www.openplug.org/plugwiki/index.php/Das_U-boot_plug_support#Open_U-bo...
Yes - I know this page but there are no information regarding the latest u-boot changes (e.g. openrd support, movement from git.marvell.com to denx , the toolchain problems...) ;)
but we really just need to solve the EABI problem.
Wolfgang/Stefan/Tom/Prafulla: Would a patch like the one below be acceptable until we find out a proper fix? I realise that this also affects other arm926ejs-boards, but is there some way to isolate this to kirkwood?
// Simon
Again, many thanks for helping!
Dieter
From 29ff02ca77406e820203ad27369e0684aa1a098c Mon Sep 17 00:00:00 2001 From: Simon Kagstrom simon.kagstrom@netinsight.net Date: Fri, 4 Sep 2009 11:15:20 +0200 Subject: [PATCH] Make arm926ejs use -mabi=apcs-gnu and private libgcc
Using -mabi=apcs-gnu allows Marvell Kirkwood-based boards to boot with the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. Since this changes the ABI, USE_PRIVATE_LIBGCC is also defined.
Signed-off-by: Simon Kagstrom simon.kagstrom@netinsight.net
cpu/arm926ejs/config.mk | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/cpu/arm926ejs/config.mk b/cpu/arm926ejs/config.mk index f8ef90f..1c9d547 100644 --- a/cpu/arm926ejs/config.mk +++ b/cpu/arm926ejs/config.mk @@ -20,10 +20,11 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # +USE_PRIVATE_LIBGCC = yes
PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
-PLATFORM_CPPFLAGS += -march=armv5te +PLATFORM_CPPFLAGS += -march=armv5te -mabi=apcs-gnu # ========================================================================= # # Supply options according to compiler version
On Wed, 30 Sep 2009 10:15:35 +0200 Dieter Kiermaier dk-arm-linux@gmx.de wrote:
is there anywhere a document how to build open source u-boot for sheevaplug which explains all these details? (haven't found some documentation about this)
(Wearing my Prafulla hat): I guess this should be described on the plugwiki:
http://www.openplug.org/plugwiki/index.php/Das_U-boot_plug_support#Open_U-bo...
Yes - I know this page but there are no information regarding the latest u-boot changes (e.g. openrd support, movement from git.marvell.com to denx , the toolchain problems...)
It's a wiki (hint, hint!) :-)
// Simon
Am Mittwoch 30 September 2009 10:17:51 schrieb Simon Kagstrom:
On Wed, 30 Sep 2009 10:15:35 +0200 Dieter Kiermaier dk-arm-linux@gmx.de wrote:
is there anywhere a document how to build open source u-boot for sheevaplug which explains all these details? (haven't found some documentation about this)
(Wearing my Prafulla hat): I guess this should be described on the plugwiki:
http://www.openplug.org/plugwiki/index.php/Das_U-boot_plug_support#Open_U-bo...
Yes - I know this page but there are no information regarding the latest u-boot changes (e.g. openrd support, movement from git.marvell.com to denx , the toolchain problems...)
It's a wiki (hint, hint!) :-)
// Simon
yep - you're right ;) shame on me. I will create an account and try to update the required information - full of hope that Prafulla read them and fixes my bugs :)
Dieter
Hi list
We use Raw NAND/flash and copy the binary there, After copy, is there a way to check the flash sanity after we have burnt an image? (e.g. by nand reading and diffing with the binary in RAM?)
Are there any feature/utility/commands readily available for u-boot?
Regards.. Prafulla . .
Am Mittwoch 30 September 2009 11:28:15 schrieb Prafulla Wadaskar: Hi Prafulla,
Hi list
We use Raw NAND/flash and copy the binary there, After copy, is there a way to check the flash sanity after we have burnt an image? (e.g. by nand reading and diffing with the binary in RAM?)
Are there any feature/utility/commands readily available for u-boot?
I've done it in the past by reading it back to ram and use cmp command. Maybe it is usefull for you, too?
Dieter
Regards.. Prafulla . .
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Wednesday 30 September 2009 11:58:22 Dieter Kiermaier wrote:
We use Raw NAND/flash and copy the binary there, After copy, is there a way to check the flash sanity after we have burnt an image? (e.g. by nand reading and diffing with the binary in RAM?)
Are there any feature/utility/commands readily available for u-boot?
I've done it in the past by reading it back to ram and use cmp command. Maybe it is usefull for you, too?
Sure, this can be done. But the NAND driver core supports validation of written data using this configuration option:
CONFIG_MTD_NAND_VERIFY_WRITE
I would enable it only for test purposes though.
Cheers, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
-----Original Message----- From: Dieter Kiermaier [mailto:dk-arm-linux@gmx.de] Sent: Wednesday, September 30, 2009 1:55 PM To: Simon Kagstrom Cc: u-boot@lists.denx.de; Prafulla Wadaskar Subject: Re: [U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND
Am Mittwoch 30 September 2009 10:17:51 schrieb Simon Kagstrom:
On Wed, 30 Sep 2009 10:15:35 +0200 Dieter Kiermaier dk-arm-linux@gmx.de wrote:
is there anywhere a document how to build open source
u-boot for sheevaplug which explains all these details?
(haven't found some documentation about this)
(Wearing my Prafulla hat): I guess this should be
described on the
plugwiki:
http://www.openplug.org/plugwiki/index.php/Das_U-boot_plug_sup port#Open_U-boot_support_for_SheevaPlug
Yes - I know this page but there are no information
regarding the latest u-boot changes (e.g. openrd support, movement from git.marvell.com to denx , the
toolchain problems...)
It's a wiki (hint, hint!) :-)
// Simon
yep - you're right ;) shame on me. I will create an account and try to update the required information - full of hope that Prafulla read them and fixes my bugs :)
Hi Simon, Dieter
The u-boot-kw.git on git.marvell.com was a temporary arrangement, since now most of the support is mainlined and I have u-boot-marvell.git too, so I have decided to maintain only u-boot-marvell.git on git.denx.de I have updated documentation http://www.openplug.org/plugwiki/index.php/Das_U-boot_plug_support#Open_U-Bo... to point the same, also I have updated build process too. I hope with this ewiki and associated u-boot will be always in sync with latest one. I will update the same for openrd too ;-D
Regards.. Prafulla . .
Dieter
Dear Simon Kagstrom,
In message 20090930095710.3480bb58@marrow.netinsight.se you wrote:
Wolfgang/Stefan/Tom/Prafulla: Would a patch like the one below be acceptable until we find out a proper fix? I realise that this also affects other arm926ejs-boards, but is there some way to isolate this to kirkwood?
No and yes :-)
--- a/cpu/arm926ejs/config.mk +++ b/cpu/arm926ejs/config.mk @@ -20,10 +20,11 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # +USE_PRIVATE_LIBGCC = yes
I will reject this part. USE_PRIVATE_LIBGCC should only be needed on broken tool chains (at least that's the theory), and the default case is always to assume we live in a perfect world where all tools are working as they are expected to do.
PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
-PLATFORM_CPPFLAGS += -march=armv5te +PLATFORM_CPPFLAGS += -march=armv5te -mabi=apcs-gnu
I could live with this part, if it was thoroughly tested and does not cause problems with the most frequently used tool chains (which I'm afraid it would - I think I remember that I saw errors or unexpected behaviour when using multiple, different "-mabi" settings).
Best regards,
Wolfgang Denk
Using -mabi=apcs-gnu allows Marvell Kirkwood-based boards to boot with the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9.
Signed-off-by: Simon Kagstrom simon.kagstrom@netinsight.net --- Wolfgang can live with this change to make Kirkwood builds work again:
On Wed, 30 Sep 2009 22:32:08 +0200 Wolfgang Denk wd@denx.de wrote:
-PLATFORM_CPPFLAGS += -march=armv5te +PLATFORM_CPPFLAGS += -march=armv5te -mabi=apcs-gnu
I could live with this part, if it was thoroughly tested and does not cause problems with the most frequently used tool chains (which I'm afraid it would - I think I remember that I saw errors or unexpected behaviour when using multiple, different "-mabi" settings).
It would be nice though if owners of other arm926ejs-boards could test the patch and see that it doesn't break things. Depending on the compiler, you might want to build with USE_PRIVATE_LIBGCC=yes.
I've tested on a OpenRD-base board.
cpu/arm926ejs/config.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cpu/arm926ejs/config.mk b/cpu/arm926ejs/config.mk index f8ef90f..466ccff 100644 --- a/cpu/arm926ejs/config.mk +++ b/cpu/arm926ejs/config.mk @@ -23,7 +23,7 @@
PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
-PLATFORM_CPPFLAGS += -march=armv5te +PLATFORM_CPPFLAGS += -march=armv5te -mabi=apcs-gnu # ========================================================================= # # Supply options according to compiler version
-----Original Message----- From: Simon Kagstrom [mailto:simon.kagstrom@netinsight.net] Sent: Thursday, October 01, 2009 12:59 PM To: Wolfgang Denk Cc: dk-arm-linux@gmx.de; u-boot@lists.denx.de; Prafulla Wadaskar; Stefan Roese; Tom Rix; Paulraj, Sandeep; Jean-Christophe PLAGNIOL-VILLARD Subject: [PATCH] Make arm926ejs use -mabi=apcs-gnu to avoid EABI problems
Using -mabi=apcs-gnu allows Marvell Kirkwood-based boards to boot with the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9.
Signed-off-by: Simon Kagstrom simon.kagstrom@netinsight.net
Wolfgang can live with this change to make Kirkwood builds work again:
On Wed, 30 Sep 2009 22:32:08 +0200 Wolfgang Denk wd@denx.de wrote:
-PLATFORM_CPPFLAGS += -march=armv5te +PLATFORM_CPPFLAGS += -march=armv5te -mabi=apcs-gnu
I could live with this part, if it was thoroughly tested
and does not
cause problems with the most frequently used tool chains (which I'm afraid it would - I think I remember that I saw errors or unexpected behaviour when using multiple, different "-mabi" settings).
It would be nice though if owners of other arm926ejs-boards could test the patch and see that it doesn't break things. Depending on the compiler, you might want to build with USE_PRIVATE_LIBGCC=yes.
I've tested on a OpenRD-base board.
cpu/arm926ejs/config.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cpu/arm926ejs/config.mk b/cpu/arm926ejs/config.mk index f8ef90f..466ccff 100644 --- a/cpu/arm926ejs/config.mk +++ b/cpu/arm926ejs/config.mk @@ -23,7 +23,7 @@
PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
-PLATFORM_CPPFLAGS += -march=armv5te +PLATFORM_CPPFLAGS += -march=armv5te -mabi=apcs-gnu
Ack But I think ack for other Arm architecture really important here :-)
Regards. Prafulla . .
#
=========== #
# Supply options according to compiler version
1.6.0.4
Dear Prafulla & all,
in message 73173D32E9439E4ABB5151606C3E19E202EF7E99DC@SC-VEXCH1.marvell.com you wrote:
-PLATFORM_CPPFLAGS += -march=armv5te +PLATFORM_CPPFLAGS += -march=armv5te -mabi=apcs-gnu
I could live with this part, if it was thoroughly tested and does not cause problems with the most frequently used tool chains (which I'm afraid it would - I think I remember that I saw errors or unexpected behaviour when using multiple, different "-mabi" settings).
It would be nice though if owners of other arm926ejs-boards could test the patch and see that it doesn't break things. Depending on the compiler, you might want to build with USE_PRIVATE_LIBGCC=yes.
Actually testing it is just one part of the issue, and actually the less important one.
Ack But I think ack for other Arm architecture really important here :-)
I have to admit that I really hesitate ifwe should add this - the longer I think about it, the more I tend to say no.
I understand that it's a quick workaround for the acute problem that works with some tool chains and on some boards. This makes the "pro" for this patch.
On the other hand, the fact remains that we do not understand the exact nature of the problem, as nobody has debugged it to the that level yet. So even when we add this, we cannot be sure if it fixes all problems, on all systems, and with all tool chains - it might happen as well that we run into the same issue again soon, or that there are still issues left somewhere, undetected. If we check in this workaround, the motivation for digging for the real cause will fade away quickly, until it hits us really hard. This makes a big "con" for this patch.
I call upon everybody who has some time and resources and who is able to reproduce the problem (so far I was not) to help and dig into this, so we can understand what's going on, and finally fix the cause of the problem, instead of trying to hush it up.
Best regards,
Wolfgang Denk
On Thu, 01 Oct 2009 20:27:11 +0200 Wolfgang Denk wd@denx.de wrote:
-PLATFORM_CPPFLAGS += -march=armv5te +PLATFORM_CPPFLAGS += -march=armv5te -mabi=apcs-gnu
I have to admit that I really hesitate ifwe should add this - the longer I think about it, the more I tend to say no.
I call upon everybody who has some time and resources and who is able to reproduce the problem (so far I was not) to help and dig into this, so we can understand what's going on, and finally fix the cause of the problem, instead of trying to hush it up.
OK, I understand. I meant to take a look at this today again, but got busy with other things. I'll try to get some time for this again next week.
// Simon
U-boot for Marvell Kirkwood boards no longer work after the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This turns out to be caused by a stack alignment issue. The armv5te instructions ldrd/strd instructions require 8-byte alignment to work properly (otherwise undefined behavior), and start.S gave the stack a 12-byte alignment.
Tested on an OpenRD base board, where both printouts and ubifs stuff now works.
Signed-off-by: Simon Kagstrom simon.kagstrom@netinsight.net --- cpu/arm926ejs/start.S | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/cpu/arm926ejs/start.S b/cpu/arm926ejs/start.S index 8043322..ca520eb 100644 --- a/cpu/arm926ejs/start.S +++ b/cpu/arm926ejs/start.S @@ -171,7 +171,8 @@ stack_setup: #ifdef CONFIG_USE_IRQ sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) #endif - sub sp, r0, #12 /* leave 3 words for abort-stack */ + sub sp, r0, #16 /* leave 3 words for abort-stack and */ + /* align stack for ldrd/strd */
clear_bss: ldr r0, _bss_start /* find start of bss segment */
On Mon, Oct 5, 2009 at 8:23 AM, Simon Kagstrom simon.kagstrom@netinsight.net wrote:
U-boot for Marvell Kirkwood boards no longer work after the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This turns out to be caused by a stack alignment issue. The armv5te instructions ldrd/strd instructions require 8-byte alignment to work properly (otherwise undefined behavior), and start.S gave the stack a 12-byte alignment.
Tested on an OpenRD base board, where both printouts and ubifs stuff now works.
Signed-off-by: Simon Kagstrom simon.kagstrom@netinsight.net
cpu/arm926ejs/start.S | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/cpu/arm926ejs/start.S b/cpu/arm926ejs/start.S index 8043322..ca520eb 100644 --- a/cpu/arm926ejs/start.S +++ b/cpu/arm926ejs/start.S @@ -171,7 +171,8 @@ stack_setup: #ifdef CONFIG_USE_IRQ sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) #endif
- sub sp, r0, #12 /* leave 3 words for abort-stack */
- sub sp, r0, #16 /* leave 3 words for abort-stack and */
- /* align stack for ldrd/strd */
This doesn't guarantee an alignment. Right above this code is a series of subtractions by constants, any one of which could throw the alignment out of whack and be difficult to figure out.
IMHO it's much safer to do the subtraction to R0, then mask the bottom address bits out to guarantee alignment, then stuff the results into sp.
On Monday 05 October 2009 16:30:54 Andrew Dyer wrote:
diff --git a/cpu/arm926ejs/start.S b/cpu/arm926ejs/start.S index 8043322..ca520eb 100644 --- a/cpu/arm926ejs/start.S +++ b/cpu/arm926ejs/start.S @@ -171,7 +171,8 @@ stack_setup: #ifdef CONFIG_USE_IRQ sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) #endif
sub sp, r0, #12 /* leave 3 words for abort-stackabort-stack and */ + /* align stack for ldrd/strd */
This doesn't guarantee an alignment. Right above this code is a series of subtractions by constants, any one of which could throw the alignment out of whack and be difficult to figure out.
Yes, good catch.
IMHO it's much safer to do the subtraction to R0, then mask the bottom address bits out to guarantee alignment, then stuff the results into sp.
Full ack. Thanks.
Cheers, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
U-boot for Marvell Kirkwood boards no longer work after the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This turns out to be caused by a stack alignment issue. The armv5te instructions ldrd/strd instructions require 8-byte alignment to work properly (otherwise undefined behavior), and start.S gave the stack a 12-byte alignment.
Tested on an OpenRD base board, where both printouts and ubifs stuff now works.
Signed-off-by: Simon Kagstrom simon.kagstrom@netinsight.net --- ChangeLog: v2: Update after Andrews comments * Mask away the low address bits to get 16-byte alignment
cpu/arm926ejs/start.S | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/cpu/arm926ejs/start.S b/cpu/arm926ejs/start.S index 8043322..cd3a6bd 100644 --- a/cpu/arm926ejs/start.S +++ b/cpu/arm926ejs/start.S @@ -171,7 +171,10 @@ stack_setup: #ifdef CONFIG_USE_IRQ sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) #endif - sub sp, r0, #12 /* leave 3 words for abort-stack */ + sub r0, r0, #12 /* leave 3 words for abort-stack and */ + mov r1, #7 /* 8-byte align stack for ldrd/strd */ + and r1, r0 + sub sp, r0, r1
clear_bss: ldr r0, _bss_start /* find start of bss segment */
Am Montag 05 Oktober 2009 16:53:24 schrieb Simon Kagstrom:
Hi all,
congratulation and many thanks for the catch :)
Dieter
U-boot for Marvell Kirkwood boards no longer work after the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This turns out to be caused by a stack alignment issue. The armv5te instructions ldrd/strd instructions require 8-byte alignment to work properly (otherwise undefined behavior), and start.S gave the stack a 12-byte alignment.
Tested on an OpenRD base board, where both printouts and ubifs stuff now works.
Signed-off-by: Simon Kagstrom simon.kagstrom@netinsight.net
ChangeLog: v2: Update after Andrews comments
- Mask away the low address bits to get 16-byte alignment
cpu/arm926ejs/start.S | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/cpu/arm926ejs/start.S b/cpu/arm926ejs/start.S index 8043322..cd3a6bd 100644 --- a/cpu/arm926ejs/start.S +++ b/cpu/arm926ejs/start.S @@ -171,7 +171,10 @@ stack_setup: #ifdef CONFIG_USE_IRQ sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) #endif
- sub sp, r0, #12 /* leave 3 words for abort-stack */
- sub r0, r0, #12 /* leave 3 words for abort-stack and */
- mov r1, #7 /* 8-byte align stack for ldrd/strd */
- and r1, r0
- sub sp, r0, r1
clear_bss: ldr r0, _bss_start /* find start of bss segment */
Simon Kagstrom wrote:
U-boot for Marvell Kirkwood boards no longer work after the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This turns out to be caused by a stack alignment issue. The armv5te instructions ldrd/strd instructions require 8-byte alignment to work properly (otherwise undefined behavior), and start.S gave the stack a 12-byte alignment.
Tested on an OpenRD base board, where both printouts and ubifs stuff now works.
Signed-off-by: Simon Kagstrom simon.kagstrom@netinsight.net
Has this patch been tested on any other boards ? This patch looks ok, I am just concerned about regressions. Tom
ChangeLog: v2: Update after Andrews comments
- Mask away the low address bits to get 16-byte alignment
cpu/arm926ejs/start.S | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/cpu/arm926ejs/start.S b/cpu/arm926ejs/start.S index 8043322..cd3a6bd 100644 --- a/cpu/arm926ejs/start.S +++ b/cpu/arm926ejs/start.S @@ -171,7 +171,10 @@ stack_setup: #ifdef CONFIG_USE_IRQ sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) #endif
- sub sp, r0, #12 /* leave 3 words for abort-stack */
- sub r0, r0, #12 /* leave 3 words for abort-stack and */
- mov r1, #7 /* 8-byte align stack for ldrd/strd */
- and r1, r0
- sub sp, r0, r1
clear_bss: ldr r0, _bss_start /* find start of bss segment */
On Mon, 05 Oct 2009 13:37:36 -0500 Tom Tom.Rix@windriver.com wrote:
Simon Kagstrom wrote:
U-boot for Marvell Kirkwood boards no longer work after the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This turns out to be caused by a stack alignment issue. The armv5te instructions ldrd/strd instructions require 8-byte alignment to work properly (otherwise undefined behavior), and start.S gave the stack a 12-byte alignment.
Tested on an OpenRD base board, where both printouts and ubifs stuff now works.
Has this patch been tested on any other boards ? This patch looks ok, I am just concerned about regressions.
It would probably be good to have it tested on non-Kirkwood boards as well. I can't see that it should do any harm to other boards though - it's just aligning the stack to 8 bytes (disregard the Subject for now and see v3 of the patch :-)).
The strange thing is really why it worked before on other boards. Perhaps the stack by change was already 8-byte aligned there, or perhaps ldrd/strd with non-8-byte alignment is handled. The architecture manual says that the behavior of ldrd/strd is undefined unless the address is 8-byte aligned, but I suppose that allows for it to actually work.
// Simon
Simon Kagstrom simon.kagstrom@netinsight.net writes:
U-boot for Marvell Kirkwood boards no longer work after the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This turns out to be caused by a stack alignment issue. The armv5te instructions ldrd/strd instructions require 8-byte alignment to work properly (otherwise undefined behavior), and start.S gave the stack a 12-byte alignment.
Tested on an OpenRD base board, where both printouts and ubifs stuff now works.
Signed-off-by: Simon Kagstrom simon.kagstrom@netinsight.net
ChangeLog: v2: Update after Andrews comments
- Mask away the low address bits to get 16-byte alignment
cpu/arm926ejs/start.S | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/cpu/arm926ejs/start.S b/cpu/arm926ejs/start.S index 8043322..cd3a6bd 100644 --- a/cpu/arm926ejs/start.S +++ b/cpu/arm926ejs/start.S @@ -171,7 +171,10 @@ stack_setup: #ifdef CONFIG_USE_IRQ sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) #endif
- sub sp, r0, #12 /* leave 3 words for abort-stack */
- sub r0, r0, #12 /* leave 3 words for abort-stack and */
- mov r1, #7 /* 8-byte align stack for ldrd/strd */
- and r1, r0
- sub sp, r0, r1
Why not simply do this:
sub r0, r0, #12 bic sp, r0, #7
-----Original Message----- From: Simon Kagstrom [mailto:simon.kagstrom@netinsight.net] Sent: Monday, October 05, 2009 8:23 PM To: Stefan Roese Cc: Andrew Dyer; Wolfgang Denk; u-boot@lists.denx.de; Prafulla Wadaskar; Tom Rix Subject: [PATCH v2] arm926ejs: 16-byte align stack to avoid LDRD/STRD problems
U-boot for Marvell Kirkwood boards no longer work after the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This turns out to be caused by a stack alignment issue. The armv5te instructions ldrd/strd instructions require 8-byte alignment to work properly (otherwise undefined behavior), and start.S gave the stack a 12-byte alignment.
Tested on an OpenRD base board, where both printouts and ubifs stuff now works.
Hi Simon Thanks for discovering this, nice catch :-) Even this may be applicable for other arm flavors too, if Top agrees
Regards.. Prafulla . .
U-boot for Marvell Kirkwood boards no longer work after the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This turns out to be caused by a stack alignment issue. The armv5te instructions ldrd/strd instructions require 8-byte alignment to work properly (otherwise undefined behavior).
Tested on an OpenRD base board, where both printouts and ubifs stuff now works.
Signed-off-by: Simon Kagstrom simon.kagstrom@netinsight.net --- ChangeLog: v2: Update after Andrews comments * Mask away the low address bits to get 16-byte alignment v3: Update after Andrews and Måns comments * Use bic instruction to clear low address bits (I'm a ARM asm newbie as you can see) * Update description to actually match the code
Thanks again for all the comments!
cpu/arm926ejs/start.S | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/cpu/arm926ejs/start.S b/cpu/arm926ejs/start.S index 8043322..4421b6a 100644 --- a/cpu/arm926ejs/start.S +++ b/cpu/arm926ejs/start.S @@ -172,6 +172,7 @@ stack_setup: sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) #endif sub sp, r0, #12 /* leave 3 words for abort-stack */ + bic sp, r0, #7 /* 8-byte align stack for ABI compliance */
clear_bss: ldr r0, _bss_start /* find start of bss segment */
Simon Kagstrom wrote:
U-boot for Marvell Kirkwood boards no longer work after the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This turns out to be caused by a stack alignment issue. The armv5te instructions ldrd/strd instructions require 8-byte alignment to work properly (otherwise undefined behavior).
Tested on an OpenRD base board, where both printouts and ubifs stuff now works.
Signed-off-by: Simon Kagstrom simon.kagstrom@netinsight.net
I was going to hack something in omap start.S to test this for you but I see it is already being done.
There is still a chance some board is dependent on the misaligned stack or just is getting lucky.
It is better to push this change and see, than not.
Ack
Tom
ChangeLog: v2: Update after Andrews comments
- Mask away the low address bits to get 16-byte alignment
v3: Update after Andrews and Måns comments
- Use bic instruction to clear low address bits (I'm a ARM asm newbie as you can see)
- Update description to actually match the code
Thanks again for all the comments!
cpu/arm926ejs/start.S | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/cpu/arm926ejs/start.S b/cpu/arm926ejs/start.S index 8043322..4421b6a 100644 --- a/cpu/arm926ejs/start.S +++ b/cpu/arm926ejs/start.S @@ -172,6 +172,7 @@ stack_setup: sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) #endif sub sp, r0, #12 /* leave 3 words for abort-stack */
- bic sp, r0, #7 /* 8-byte align stack for ABI compliance */
clear_bss: ldr r0, _bss_start /* find start of bss segment */
Simon Kagstrom wrote:
U-boot for Marvell Kirkwood boards no longer work after the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This turns out to be caused by a stack alignment issue. The armv5te instructions ldrd/strd instructions require 8-byte alignment to work properly (otherwise undefined behavior).
Tested on an OpenRD base board, where both printouts and ubifs stuff now works.
Signed-off-by: Simon Kagstrom simon.kagstrom@netinsight.net
I have committed this to arm/master-sync Tom
ChangeLog: v2: Update after Andrews comments
- Mask away the low address bits to get 16-byte alignment
v3: Update after Andrews and Måns comments
- Use bic instruction to clear low address bits (I'm a ARM asm newbie as you can see)
- Update description to actually match the code
Thanks again for all the comments!
cpu/arm926ejs/start.S | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/cpu/arm926ejs/start.S b/cpu/arm926ejs/start.S index 8043322..4421b6a 100644 --- a/cpu/arm926ejs/start.S +++ b/cpu/arm926ejs/start.S @@ -172,6 +172,7 @@ stack_setup: sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) #endif sub sp, r0, #12 /* leave 3 words for abort-stack */
- bic sp, r0, #7 /* 8-byte align stack for ABI compliance */
clear_bss: ldr r0, _bss_start /* find start of bss segment */
On Mon, 5 Oct 2009 09:30:54 -0500 Andrew Dyer amdyer@gmail.com wrote:
sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) #endif
- sub sp, r0, #12 /* leave 3 words for abort-stack */
- sub sp, r0, #16 /* leave 3 words for abort-stack and */
- /* align stack for ldrd/strd */
This doesn't guarantee an alignment. Right above this code is a series of subtractions by constants, any one of which could throw the alignment out of whack and be difficult to figure out.
IMHO it's much safer to do the subtraction to R0, then mask the bottom address bits out to guarantee alignment, then stuff the results into sp.
Right, new patch coming up.
Thanks, // Simon
participants (8)
-
Andrew Dyer -
Dieter Kiermaier -
Måns Rullgård -
Prafulla Wadaskar -
Simon Kagstrom -
Stefan Roese -
Tom -
Wolfgang Denk