From mboxrd@z Thu Jan  1 00:00:00 1970
From: Johannes Stezenbach <js@sig21.net>
Date: Mon, 5 Nov 2007 22:25:22 +0100
Subject: [U-Boot-Users] EABI Problem
In-Reply-To: <20071105192625.3D741247F4@gemini.denx.de>
References: <20071105161853.GA28049@sig21.net>
	<20071105192625.3D741247F4@gemini.denx.de>
Message-ID: <20071105212522.GA7485@sig21.net>
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 Mon, Nov 05, 2007, Wolfgang Denk wrote:
> In message <20071105161853.GA28049@sig21.net> you wrote:
> > 
> > So I now only need two tiny patches:
> > 
> > ---
> > fix warning: "warning: target CPU does not support interworking"
> > when compiling with CodeSourcery gcc-4.2.1/binutils-2.18.50
> > 
> > diff -ruNp u-boot-1.3.0-rc3/cpu/arm920t/config.mk u-boot-1.3.0-rc3.my/cpu/arm920t/config.mk
> > --- u-boot-1.3.0-rc3/cpu/arm920t/config.mk	2007-10-14 00:13:19.000000000 +0200
> > +++ u-boot-1.3.0-rc3.my/cpu/arm920t/config.mk	2007-11-05 14:31:19.000000000 +0100
> > @@ -24,7 +24,7 @@
> >  PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
> >  	-msoft-float
> >  
> > -PLATFORM_CPPFLAGS += -march=armv4
> > +PLATFORM_CPPFLAGS += -march=armv4t
> 
> Has this change been verified by anybody using another toolchain?

I'm still hoping someone else will test it. If all else fails I
could download and install ELDK or whatever and test myself, but
it feels wrong if I'd have to do that.

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


Thanks,
Johannes