All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] EABI Problem
Date: Tue, 6 Nov 2007 06:31:12 +0100	[thread overview]
Message-ID: <200711060631.12189.sr@denx.de> (raw)
In-Reply-To: <20071105212522.GA7485@sig21.net>

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

  reply	other threads:[~2007-11-06  5:31 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
2007-11-06  5:31         ` Stefan Roese [this message]
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=200711060631.12189.sr@denx.de \
    --to=sr@denx.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.