[U-Boot-Users] EABI Problem
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@topia.com - office: +44 2076 1777588 - mobile: +44 7789 338868 - skype: ferriday a member of Zea Partners
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%40r...
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.79084...
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
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.79084...
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
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
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
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@denx.de =====================================================================
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
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
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+pro... and let me know what you think.
Best regards,
Wolfgang Denk
participants (5)
-
Johannes Stezenbach -
Philip Balister -
Russ Ferriday -
Stefan Roese -
Wolfgang Denk