public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Johannes Stezenbach <js@sig21.net>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] EABI Problem
Date: Mon, 5 Nov 2007 22:25:22 +0100	[thread overview]
Message-ID: <20071105212522.GA7485@sig21.net> (raw)
In-Reply-To: <20071105192625.3D741247F4@gemini.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

  reply	other threads:[~2007-11-05 21:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-01 16:02 [U-Boot-Users] EABI Problem Russ Ferriday
2007-11-02 15:37 ` Johannes Stezenbach
2007-11-05 16:18   ` Johannes Stezenbach
2007-11-05 19:26     ` Wolfgang Denk
2007-11-05 21:25       ` Johannes Stezenbach [this message]
2007-11-06  5:31         ` Stefan Roese
2007-11-06  7:33           ` Wolfgang Denk
2007-11-06 13:30             ` Philip Balister
2007-11-16 20:39         ` Wolfgang Denk
  -- strict thread matches above, loose matches on Subject: below --
2007-07-05 17:11 [U-Boot-Users] EABI problem Patrice Vilchez
2007-07-06 13:29 ` Peter Pearse
2007-07-06 13:45   ` Patrice Vilchez
2007-07-06 14:02     ` Philip Balister
2007-07-06 14:15       ` Patrice Vilchez
2007-07-06 14:22         ` Philip Balister
2007-07-06 14:33           ` Patrice Vilchez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071105212522.GA7485@sig21.net \
    --to=js@sig21.net \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox