From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marek.vasut@gmail.com>
Date: Wed, 14 Apr 2010 21:42:37 +0200
Subject: [U-Boot] [PATCH] PXA: Align stack to 8 bytes
In-Reply-To: <i2pf17812d71004121007xa6a88b8di7bd930a1958b7753@mail.gmail.com>
References: <1270970516-4282-1-git-send-email-marek.vasut@gmail.com>
	<i2pf17812d71004121007xa6a88b8di7bd930a1958b7753@mail.gmail.com>
Message-ID: <201004142142.37301.marek.vasut@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dne Po 12. dubna 2010 19:07:31 Eric Miao napsal(a):
> On Sun, Apr 11, 2010 at 3:21 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > Stack must be aligned to 8 bytes on PXA (possibly all armv5te) for
> > LDRD/STRD instructions. In case LDRD/STRD is issued on an unaligned
> > address, the behaviour is undefined.
> 
> Well, I guess this is true for all ARMv5. ARMv6 and later however, provides
> support for such unaligned accesses. According to ARM DDI 0100I, A2.8
> 
> Prior to ARMv6, doubleword (LDRD/STRD) accesses to memory, where the
> address is not doubleword-aligned, are UNPREDICTABLE. Also, data accesses
> to non-aligned word and halfword data are treated as aligned from
> the memory interface perspective. That is:
> 
> ? the address is treated as truncated, with address bits[1:0] treated as
>   zero for word accesses, and address bit[0] treated as zero for halfword
>   accesses.
> ? load single word ARM instructions are architecturally defined to rotate
>   right the word-aligned data transferred by a non word-aligned address
>   one, two or three bytes depending on the value of the two least
>   significant address bits.
> ? alignment checking is defined for implementations supporting a System
>   Control coprocessor using the A bit in CP15 register 1. When this bit
>   is set, a Data Abort indicating an alignment fault is reported for
>   unaligned accesses.
> 
> ARMv6 introduces unaligned word and halfword load and store data access
> support. When this is enabled, the processor uses one or more memory
> accesses to generate the required transfer of adjacent bytes transparently
> to the programmer, apart from a potential access time penalty where the
> transaction crosses an IMPLEMENTATION DEFINED cache-line, bus-width or
> page boundary condition. Doubleword accesses must be word-aligned in this
> configuration.
> 
> > The issue was observed when working with the NAND code, which was
> > rendered disfunctional. Also, the vsprintf() function had serious
> > problems with printing 64bit wide long longs. After aligning the stack,
> > this wrong behaviour is no longer present.
> > 
> > Tested on:
> >        Marvell Littleton PXA310 board
> >        Toradex Colibri PXA320 board
> >        Aeronix Zipit Z2 PXA270 handheld
> >        Voipac PXA270 board
> > 
> > Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> > ---
> >  cpu/pxa/start.S |    5 ++++-
> >  1 files changed, 4 insertions(+), 1 deletions(-)
> > 
> > diff --git a/cpu/pxa/start.S b/cpu/pxa/start.S
> > index 13e2edb..bbfcfd1 100644
> > --- a/cpu/pxa/start.S
> > +++ b/cpu/pxa/start.S
> > @@ -140,7 +140,10 @@ stack_setup:
> >  #ifdef CONFIG_USE_IRQ
> >        sub     r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ)
> >  #endif /* CONFIG_USE_IRQ */
> > -       sub     sp, r0, #12             /* leave 3 words for abort-stack
> >    */ +       bic     sp, r0, #7              /* leave 4 words for
> > abort-stack    */ +                                       /* NOTE: stack
> > MUST be aligned to   */ +                                       /* 8
> > bytes in case we want to use   */ +                                    
> >   /* 64bit datatypes (eg. VSPRINTF64) */
> > 
> >  clear_bss:
> >        ldr     r0, _bss_start          /* find start of bss segment      
> >  */ --
> > 1.7.0

Ok, applied.