From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefan Roese <sr@denx.de>
Date: Tue, 6 Nov 2007 06:31:12 +0100
Subject: [U-Boot-Users] EABI Problem
In-Reply-To: <20071105212522.GA7485@sig21.net>
References: <20071105161853.GA28049@sig21.net>
	<20071105192625.3D741247F4@gemini.denx.de>
	<20071105212522.GA7485@sig21.net>
Message-ID: <200711060631.12189.sr@denx.de>
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

On Monday 05 November 2007, Johannes Stezenbach wrote:
> > > ---
> > > fix compile error: "start.S:205: Error: invalid constant (20200) after
> > > fixup"
> > >
> > > diff -ruNp u-boot-1.3.0-rc3/include/configs/kb9202.h
> > > u-boot-1.3.0-rc3.my/include/configs/kb9202.h ---
> > > u-boot-1.3.0-rc3/include/configs/kb9202.h	2007-10-14 00:13:19.000000000
> > > +0200 +++ u-boot-1.3.0-rc3.my/include/configs/kb9202.h	2007-11-05
> > > 14:37:17.000000000 +0100 @@ -57,7 +57,7 @@
> > >  /*
> > >   * Size of malloc() pool
> > >   */
> > > -#define CFG_MALLOC_LEN	(CFG_ENV_SIZE + 128*1024)
> > > +#define CFG_MALLOC_LEN	(128*1024)
> >
> > This is definitely a bad change; reducing the  size  of  thje  malloc
> > area  below  what is actually needed is not a good ide. Also, I don't
> > see why this change would be needed. If there is a compi8le  problem,
> > the  reason  for  that  problem  should be located and fixed, without
> > changing this code.
> >
> > This is a definitve NAK for this change, as it fixzes the symptoms
> > while leaving the problem unfixed.
>
> Well ARM assembly only accepts immediate values with certain
> properties (representable as an 8-bit value plus a 5-bit shift
> or something, I forgot the details). My ARM assembly skills
> are pretty weak, so changing start.S to accept an arbitrary constant
> is out of scope for me. We could maybe just set CFG_MALLOC_LEN
> to 132*1024 (untested), or we could move the CFG_MALLOC_LEN
> down in the file next to the
>
> #ifdef CONFIG_KB9202
> #define CFG_ENV_OFFSET                  0x3E00
> #define CFG_ENV_SIZE                    0x0200
> #define CFG_MALLOC_LEN	(CFG_ENV_SIZE + 128*1024 + 0x4e00)
> #else
> #define CFG_ENV_OFFSET                  0x1000
> #define CFG_ENV_SIZE                    0x1000
> #define CFG_MALLOC_LEN	(CFG_ENV_SIZE + 128*1024 + 0x3000)
> #endif
>
> to show how they depend on each other, or if you know
> how to express the ARM restrictions in a C macro we
> could use that.
>
> I'm open for suggestions, but with a simple NAK I don't
> know what to do and it will stay unfixed.

Why not just increasing. It's normally no problem having bigger malloc area:

#define CFG_MALLOC_LEN	(256*1024)

Best regards,
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
=====================================================================