[U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND

[U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND

[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.

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] kirkwood (openrd): saveenv will not work with environment in NAND

[Dieter Kiermaier]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

[U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND

[Simon Kagstrom]

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

[U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND

[Dieter Kiermaier]

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 at dk1-linux:~/git/u-boot-marvell$   

I use following precompiled toolchain from marvell:
dieter at 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
> 

[U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND

[Simon Kagstrom]

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

[U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND

[Dieter Kiermaier]

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
> 

[U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND

[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.

> @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-boot_support_for_SheevaPlug

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

[U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND

[Dieter Kiermaier]

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-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...)
;)

> 
> 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

[U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND

[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-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

[U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND

[Dieter Kiermaier]

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-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 :)

Dieter

[U-Boot] Flash sanity checks

[Prafulla Wadaskar]

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 . .

[U-Boot] Flash sanity checks

[Dieter Kiermaier]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

[U-Boot] Flash sanity checks

[Stefan Roese]

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 at denx.de

[U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND

[Prafulla Wadaskar]

 

> -----Original Message-----
> From: Dieter Kiermaier [mailto:dk-arm-linux at gmx.de] 
> Sent: Wednesday, September 30, 2009 1:55 PM
> To: Simon Kagstrom
> Cc: u-boot at 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-Boot_support_for_SheevaPlug 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
> 

[U-Boot] kirkwood (openrd): saveenv will not work with environment in NAND

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Inside every old person is a young person wondering what happened.
                              - Terry Pratchett, _Moving Pictures_

[U-Boot] [PATCH] Make arm926ejs use -mabi=apcs-gnu to avoid EABI problems

[Simon Kagstrom]

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
-- 
1.6.0.4

[U-Boot] [PATCH] Make arm926ejs use -mabi=apcs-gnu to avoid EABI problems

[Prafulla Wadaskar]

 

> -----Original Message-----
> From: Simon Kagstrom [mailto:simon.kagstrom at netinsight.net] 
> Sent: Thursday, October 01, 2009 12:59 PM
> To: Wolfgang Denk
> Cc: dk-arm-linux at gmx.de; u-boot at 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
> 

[U-Boot] [PATCH] Make arm926ejs use -mabi=apcs-gnu to avoid EABI problems

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
All a hacker needs is a tight PUSHJ, a loose pair of UUOs, and a warm
place to shift.

[U-Boot] [PATCH] Make arm926ejs use -mabi=apcs-gnu to avoid EABI problems

[Simon Kagstrom]

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] [PATCH] arm926ejs: 16-byte align stack to avoid LDRD/STRD problems

[Simon Kagstrom]

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        */
-- 
1.6.0.4

[U-Boot] [PATCH] arm926ejs: 16-byte align stack to avoid LDRD/STRD problems

[Andrew Dyer]

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.

[U-Boot] [PATCH] arm926ejs: 16-byte align stack to avoid LDRD/STRD problems

[Stefan Roese]

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-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.

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 at denx.de

[U-Boot] [PATCH v2] arm926ejs: 16-byte align stack to avoid LDRD/STRD problems

[Simon Kagstrom]

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        */
-- 
1.6.0.4

[U-Boot] [PATCH v2] arm926ejs: 16-byte align stack to avoid LDRD/STRD problems

[Dieter Kiermaier]

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        */

[U-Boot] [PATCH v2] arm926ejs: 16-byte align stack to avoid LDRD/STRD problems

[Tom]

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        */

[U-Boot] [PATCH v2] arm926ejs: 16-byte align stack to avoid LDRD/STRD problems

[Simon Kagstrom]

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

[U-Boot] [PATCH v2] arm926ejs: 16-byte align stack to avoid LDRD/STRD problems

[Måns Rullgård]

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

-- 
M?ns Rullg?rd
mans at mansr.com

[U-Boot] [PATCH v2] arm926ejs: 16-byte align stack to avoid LDRD/STRD problems

[Prafulla Wadaskar]

 

> -----Original Message-----
> From: Simon Kagstrom [mailto:simon.kagstrom at netinsight.net] 
> Sent: Monday, October 05, 2009 8:23 PM
> To: Stefan Roese
> Cc: Andrew Dyer; Wolfgang Denk; u-boot at 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] [PATCH v3] arm926ejs: 8-byte align stack to avoid LDRD/STRD problems

[Simon Kagstrom]

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        */
-- 
1.6.0.4

[U-Boot] [PATCH v3] arm926ejs: 8-byte align stack to avoid LDRD/STRD problems

[Tom]

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        */

[U-Boot] [PATCH v3] arm926ejs: 8-byte align stack to avoid LDRD/STRD problems

[Tom]

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        */

[U-Boot] [PATCH] arm926ejs: 16-byte align stack to avoid LDRD/STRD problems

[Simon Kagstrom]

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