[U-Boot-Users] EABI problem

[U-Boot-Users] EABI problem

[Patrice Vilchez]

Hello,

    I am quite new on this mailing list.

    I have tried to build u-boot with the last EABI toolchain from 
codesourcery (arm-2007q1-10 version).
    It seems that in the file "driver/nand/nand_util.c" there is some 64 
bits division which causes a crash during the link process.

bye,
    Patrice.

-----8<

From: Patrice Vilchez <patrice.vilchez@rfo.atmel.com>

Remove 64 bits division into nand driver to compile with an EABI toolchain

Signed-off-by: Patrice Vilchez   <patrice.vilchez@rfo.atmel.com>
---

driver/nand/nand_util.c |   16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

diff -Nru u-boot-1.2.0.orig/drivers/nand/nand_util.c 
u-boot-1.2.0.new/drivers/nand/nand_util.c
--- u-boot-1.2.0.orig/drivers/nand/nand_util.c    2007-01-07 
00:13:11.000000000 +0100
+++ u-boot-1.2.0.new/drivers/nand/nand_util.c    2007-07-05 
19:03:03.000000000 +0200
@@ -209,9 +209,9 @@
 
         if (!opts->quiet) {
             int percent = (int)
-                ((unsigned long long)
+                ((unsigned long)
                  (erase.addr+meminfo->erasesize-opts->offset)
-                 * 100 / erase_length);
+                 / erase_length) * 100;
 
             /* output progress message only at whole percent
              * steps to reduce the number of messages printed
@@ -476,9 +476,9 @@
 
         if (!opts->quiet) {
             int percent = (int)
-                ((unsigned long long)
-                 (opts->length-imglen) * 100
-                 / opts->length);
+                ((unsigned long)
+                 (opts->length-imglen)
+                 / opts->length) * 100;
             /* output progress message only at whole percent
              * steps to reduce the number of messages printed
              * on (slow) serial consoles
@@ -652,9 +652,9 @@
 
         if (!opts->quiet) {
             int percent = (int)
-                ((unsigned long long)
-                 (opts->length-imglen) * 100
-                 / opts->length);
+                ((unsigned long)
+                 (opts->length-imglen)
+                 / opts->length) * 100;
             /* output progress message only at whole percent
              * steps to reduce the number of messages printed
              * on (slow) serial consoles
   

[U-Boot-Users] EABI problem

[Peter Pearse]

I bottom post  

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Patrice Vilchez
> Sent: 05 July 2007 18:12
> To: U-Boot-Users at lists.sourceforge.net
> Subject: [U-Boot-Users] EABI problem
> 
> Hello,
> 
>     I am quite new on this mailing list.
> 
>     I have tried to build u-boot with the last EABI toolchain 
> from codesourcery (arm-2007q1-10 version).

Which board?

Regards

Peter

[U-Boot-Users] EABI problem

[Patrice Vilchez]

Peter Pearse a ?crit :
> I bottom post  
>
>   
>> -----Original Message-----
>> From: u-boot-users-bounces at lists.sourceforge.net 
>> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
>> Of Patrice Vilchez
>> Sent: 05 July 2007 18:12
>> To: U-Boot-Users at lists.sourceforge.net
>> Subject: [U-Boot-Users] EABI problem
>>
>> Hello,
>>
>>     I am quite new on this mailing list.
>>
>>     I have tried to build u-boot with the last EABI toolchain 
>> from codesourcery (arm-2007q1-10 version).
>>     
>
> Which board?
>
>   
    For an AT91SAM9263EK board.
    I am adding  AT91 evaluation kits support to u-boot 1.2.0 and I did 
some tests which several EABI compiler  :  codesourcery ,  open embedded 
and buildroot.
    It seems when there is a 64 bits division the compiler refers to 
"_udivdi3" which is not implemented into "u-boot/lib_arm/"  library and 
then try to link with libgcc from compiler  :

/usr/local/opt/codesourcery/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_udivsi3.o): 
In function `__aeabi_uidiv':
/scratch/paul/arm/src/gcc-4.2/gcc/config/arm/lib1funcs.asm:(.text+0x0): 
multiple definition of `__udivsi3'
lib_arm/libarm.a(_udivsi3.o):_udivsi3.S:17: first defined here
/opt/codesourcery/arm-2007q1/bin/arm-none-linux-gnueabi-ld: ERROR: 
Source object 
/usr/local/opt/codesourcery/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_udivdi3.o) 
has EABI version 4, but target u-boot has EABI version 0
/opt/codesourcery/arm-2007q1/bin/arm-none-linux-gnueabi-ld: failed to 
merge target specific data of file 
/usr/local/opt/codesourcery/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_udivdi3.o)
/opt/codesourcery/arm-2007q1/bin/arm-none-linux-gnueabi-ld: ERROR: 
Source object 
/usr/local/opt/codesourcery/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_udivsi3.o) 
has EABI version 4, but target u-boot has EABI version 0
/opt/codesourcery/arm-2007q1/bin/arm-none-linux-gnueabi-ld: failed to 
merge target specific data of file 
/usr/local/opt/codesourcery/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_udivsi3.o)
/opt/codesourcery/arm-2007q1/bin/arm-none-linux-gnueabi-ld: ERROR: 
Source object 
/usr/local/opt/codesourcery/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_clz.o) 
has EABI version 4, but target u-boot has EABI version 0
/opt/codesourcery/arm-2007q1/bin/arm-none-linux-gnueabi-ld: failed to 
merge target specific data of file 
/usr/local/opt/codesourcery/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_clz.o)
/usr/local/opt/codesourcery/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): 
undefined reference to `__aeabi_unwind_cpp_pr0'

Patrice.

[U-Boot-Users] EABI problem

[Philip Balister]

Patrice Vilchez wrote:
>> Which board?
>>
>>   
>     For an AT91SAM9263EK board.
>     I am adding  AT91 evaluation kits support to u-boot 1.2.0 and I did 
> some tests which several EABI compiler  :  codesourcery ,  open embedded 
> and buildroot.
>     It seems when there is a 64 bits division the compiler refers to 
> "_udivdi3" which is not implemented into "u-boot/lib_arm/"  library and 
> then try to link with libgcc from compiler  :

I am also using an EABI compiler (from openembedded) and see these 
messages (among some other problems):

/home/balister/oe/tmp/cross/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/libgcc.a(_dvmd_lnx.o): 
In function `__div0':
/home/balister/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gcc-cross-4.1.2-r4/gcc-4.1.2/gcc/config/arm/lib1funcs.asm:1001: 
undefined reference to `raise'
/home/balister/oe/tmp/cross/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): 
undefined reference to `__aeabi_unwind_cpp_pr0'
/home/balister/oe/tmp/cross/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): 
undefined reference to `__aeabi_unwind_cpp_pr0'
make: *** [u-boot] Error 1

Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070706/7f059977/attachment.bin 

[U-Boot-Users] EABI problem

[Patrice Vilchez]

Philip Balister a ?crit :
> Patrice Vilchez wrote:
>>> Which board?
>>>
>>>   
>>     For an AT91SAM9263EK board.
>>     I am adding  AT91 evaluation kits support to u-boot 1.2.0 and I 
>> did some tests which several EABI compiler  :  codesourcery ,  open 
>> embedded and buildroot.
>>     It seems when there is a 64 bits division the compiler refers to 
>> "_udivdi3" which is not implemented into "u-boot/lib_arm/"  library 
>> and then try to link with libgcc from compiler  :
>
> I am also using an EABI compiler (from openembedded) and see these 
> messages (among some other problems):
>
> /home/balister/oe/tmp/cross/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/libgcc.a(_dvmd_lnx.o): 
> In function `__div0':
> /home/balister/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gcc-cross-4.1.2-r4/gcc-4.1.2/gcc/config/arm/lib1funcs.asm:1001: 
> undefined reference to `raise'
> /home/balister/oe/tmp/cross/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): 
> undefined reference to `__aeabi_unwind_cpp_pr0'
> /home/balister/oe/tmp/cross/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): 
> undefined reference to `__aeabi_unwind_cpp_pr0'
> make: *** [u-boot] Error 1
>
> Philip
     Are you compiling a file with a 64 bits division ?
     I my case it was driver/nand/nand_utils.c enabled by adding 
"CFG_CMD_NAND" to CONFIG_COMMANDS.

Patrice.

[U-Boot-Users] EABI problem

[Philip Balister]

Patrice Vilchez wrote:
>> Philip
>     Are you compiling a file with a 64 bits division ?
>     I my case it was driver/nand/nand_utils.c enabled by adding 
> "CFG_CMD_NAND" to CONFIG_COMMANDS.

Yes, I have CFM_CMD_NAND set. I can build u-boot for the omap5912osk 
with the same compiler fine.

Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070706/66bcbc86/attachment.bin 

[U-Boot-Users] EABI problem

[Patrice Vilchez]

Philip Balister a ?crit :
> Patrice Vilchez wrote:
>>> Philip
>>     Are you compiling a file with a 64 bits division ?
>>     I my case it was driver/nand/nand_utils.c enabled by adding 
>> "CFG_CMD_NAND" to CONFIG_COMMANDS.
>
> Yes, I have CFM_CMD_NAND set. I can build u-boot for the omap5912osk 
> with the same compiler fine.
>
> Philip
    But have you set CFG_NAND_LEGACY flag ?
    It disables the nand_utils.c compilation and then avoid 64 bits 
division.

from driver/nand/nand_utils.c
#if (CONFIG_COMMANDS & CFG_CMD_NAND) && !defined(CFG_NAND_LEGACY)

    I do not see any CFG_CMD_NAND into include/configs/omap5912osk.h file.

Patrice.

[U-Boot-Users] EABI Problem

[Russ Ferriday]

Hello all,

I'm new here.

In reference to this message:  http://sourceforge.net/mailarchive/ 
message.php?msg_name=468E52A8.2040604%40rfo.atmel.com

I've been down the same path as Philip and Patrice. Of course when I  
define 'CFG_NAND_LEGACY', U-Boot> mtdparts returns "support for NAND  
devices not present'.

Is there another flag that I need to define to get a newer version of  
NAND support working?

I'm building for KB9202B.

--r

Russ Ferriday - Topia Systems - Open Source content management with  
Plone and Zope
russf at topia.com - office: +44 2076 1777588 - mobile: +44 7789 338868  
- skype: ferriday
a member of
Zea Partners


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20071101/53619972/attachment.htm 

[U-Boot-Users] EABI Problem

[Johannes Stezenbach]

Hi,

(add Cc: ARM custodian)

On Thu, Nov 01, 2007 at 04:02:48PM +0000, Russ Ferriday wrote:
>
> I'm new here.

me too ;-)

> In reference to this message:  
> http://sourceforge.net/mailarchive/message.php?msg_name=468E52A8.2040604%40rfo.atmel.com
>
> I've been down the same path as Philip and Patrice. Of course when I define 
> 'CFG_NAND_LEGACY', U-Boot> mtdparts returns "support for NAND devices not 
> present'.
>
> Is there another flag that I need to define to get a newer version of NAND 
> support working?
>
> I'm building for KB9202B.

I don't know about NAND, but I had problems building KB9202B with
the CodeSourcery ARM EABI toolchain, too, solved like that:

http://sourceforge.net/mailarchive/message.php?msg_name=20071025161052.790841794%40sig21.net


I'm confused to see that the toplevel Makefile has

  # Add GCC lib
  PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc

but then there are also libgcc replacement functions in lib_arm/.


Could someone knowledgable please fill me in what the goal is?

a) use libgcc and then work around issues like missing raise()
   and maybe also link libgcc_eh.a

b) don't use libgcc, provide necessary functions in lib_<arch>
   (like the Linux kernel does)

I'd be happy to cook up a corrected patch for KB9202B EABI toolchain
build support if I get some guidelines about what would be
acceptable for u-boot mainline.


Thanks,
Johannes

[U-Boot-Users] EABI Problem

[Johannes Stezenbach]

Hi again,

On Fri, Nov 02, 2007, Johannes Stezenbach wrote:
> 
> I don't know about NAND, but I had problems building KB9202B with
> the CodeSourcery ARM EABI toolchain, too, solved like that:
> 
> http://sourceforge.net/mailarchive/message.php?msg_name=20071025161052.790841794%40sig21.net
> 
> 
> I'm confused to see that the toplevel Makefile has
> 
>   # Add GCC lib
>   PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
> 
> but then there are also libgcc replacement functions in lib_arm/.

BTW, I only deleted the

  PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu)

line from cpu/arm920t/config.mk because u-boot links libgcc,
and the CodeSourcery toolchain doesn't have a non-EABI libgcc,
and I assumed it wouldn't build then.

Turns out this is unnecessary, and with this option left in place
libgcc isn't even used (confirmed by commenting out in the
PLATFORM_LIBS line in the top level Makefile).

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
 # =========================================================================
 #
 # Supply options according to compiler version


---
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)
 #define CFG_GBL_DATA_SIZE	128	/* size in bytes reserved for initial data */
 
 #define CONFIG_BAUDRATE 115200


--------------------------

For the first patch I wonder if it is compatbile with ELDK.
The arm920t _is_ arm4vt, but maybe it needs something like
  
  PLATFORM_CPPFLAGS += $(call cc-option,-march=armv4t,-march=armv4)

to support older gcc versions. It would be nice if someone could
test this, maybe the issue could then be resolved pretty easily.
I guess some others also would appreciate a proper fix in 1.3.0 final:
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=180


For the second patch I don't know what the correct fix is but
this is what KwikByte has in their u-boot patch. Works for me.
(And, grepping through include/config/, it's what most other
boards seem to do.)

> Could someone knowledgable please fill me in what the goal is?
> 
> a) use libgcc and then work around issues like missing raise()
>    and maybe also link libgcc_eh.a
> 
> b) don't use libgcc, provide necessary functions in lib_<arch>
>    (like the Linux kernel does)

I'm still hoping to get an answer. If the goal is to get
rid of libgcc dependency then I guess people would start
sending patches to do so. Currently it seems no one knows.
I think this is an essential point which needs to be documented.


Thanks,
Johannes

[U-Boot-Users] EABI Problem

[Wolfgang Denk]

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?

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

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are two ways to write error-free programs. Only the  third  one
works.

[U-Boot-Users] EABI Problem

[Johannes Stezenbach]

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

[U-Boot-Users] EABI Problem

[Stefan Roese]

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

[U-Boot-Users] EABI Problem

[Wolfgang Denk]

In message <200711060631.12189.sr@denx.de> you wrote:
>
> > > > -#define CFG_MALLOC_LEN	(CFG_ENV_SIZE + 128*1024)
> > > > +#define CFG_MALLOC_LEN	(128*1024)
...
> > > 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.
...
> > 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

My gut feeling is that this is not the root of the  problem.  I  feel
that probably the assembler does not see a pure numerical expression,
but  instead  is  confronted  with the (unsubstituted) string literal
CFG_ENV_SIZE, and that this is causing the problem.

This is what I think needs to be checked and fixed, as the same
problem might be present (eventually undetected) somewhere else, too.

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

Please try out if "(132*1024)" works... that would give a some
helpful additional information.

> > #ifdef CONFIG_KB9202
> > #define CFG_ENV_OFFSET                  0x3E00
> > #define CFG_ENV_SIZE                    0x0200

This is broken. 512 bytes of environmnt is much too small to be
useful.

> > #define CFG_MALLOC_LEN	(CFG_ENV_SIZE + 128*1024 + 0x4e00)

This is broken,too. Where is the 0x4e00 coming from here?

> > #else
> > #define CFG_ENV_OFFSET                  0x1000
> > #define CFG_ENV_SIZE                    0x1000
> > #define CFG_MALLOC_LEN	(CFG_ENV_SIZE + 128*1024 + 0x3000)

Where is the 0x3000 coming from here?

> Why not just increasing. It's normally no problem having bigger malloc area:
> 
> #define CFG_MALLOC_LEN	(256*1024)

If this works, then it is another indication that there is a
preprocessing problem. This problem should be fixed and not hidden.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Houston, Tranquillity Base here.  The Eagle has landed.
                                                    -- Neil Armstrong

[U-Boot-Users] EABI Problem

[Philip Balister]

Wolfgang Denk wrote:
> In message <200711060631.12189.sr@denx.de> you wrote:
>>>>> -#define CFG_MALLOC_LEN	(CFG_ENV_SIZE + 128*1024)
>>>>> +#define CFG_MALLOC_LEN	(128*1024)
> ...
>>>> 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.
> ...
>>> 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
> 
> My gut feeling is that this is not the root of the  problem.  I  feel
> that probably the assembler does not see a pure numerical expression,
> but  instead  is  confronted  with the (unsubstituted) string literal
> CFG_ENV_SIZE, and that this is causing the problem.
> 
> This is what I think needs to be checked and fixed, as the same
> problem might be present (eventually undetected) somewhere else, too.

Look at the davinci specific files. U-boot builds fine with an EABI 
compiler for davinci. I know we had some problems with EAVI compilers at 
first.

Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071106/61ed6c63/attachment.bin 

[U-Boot-Users] EABI Problem

[Wolfgang Denk]

Hello,

in message <20071105212522.GA7485@sig21.net> you wrote:
> 
> I'm open for suggestions, but with a simple NAK I don't
> know what to do and it will stay unfixed.

After this, and the followups by Stefan Roese and me again there was
no more response from you.

Please see
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/33139/match=eabi+problem
and let me know what you think.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Nothing is easier than to denounce  the  evildoer;  nothing  is  more
difficult than to understand him.                 - Fyodor Dostoevski