public inbox for u-boot@lists.denx.de
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox