[U-Boot-Users] GCC3.4.0 Coldfire 52xx Build problems

[U-Boot-Users] GCC3.4.0 Coldfire 52xx Build problems

[Teun Grinwis]

Hello All,

I am new to U-Boot.
We develop appl. on coldfire M5275EVB with uclinux 2.6, and intent to use
U-Boot as
boot loader.

- Use the gcc3.4.0 toolchain, binutils binutils-2.15.90.0.1.1 from
  http://www.uclinux.org/pub/uClinux/m68k-elf-tools/gcc-3/

- I download u-boot from CVS, so latest version.

- Tried to compile for M5272C3_config
  did make M5272C3_config
      make

- got following error:
----------------------
  make[1]: Leaving directory
`/cygdrive/c/project/U-Boot_20050803/u-boot/post/cpu'
m68k-elf-gcc -Wa,-gstabs -D__ASSEMBLY__ -g  -Os   -ffixed-d7 -msep-data -D__
KERNEL__ -DTEXT_BASE=0xffe00000 -I/cygdrive/c/project/U-Boot_20050803/u-boot
/include -fno-builtin -ffreestanding -nostdinc -isystem
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include -pipe  -DCONFIG_M68K -D__M68K__ -m
5307 -c -o cpu/mcf52x2/start.o
/cygdrive/c/project/U-Boot_20050803/u-boot/cpu/mcf52x2/start.S
/cygdrive/c/project/U-Boot_20050803/u-boot/cpu/mcf52x2/start.S: Assembler
messages:
/cygdrive/c/project/U-Boot_20050803/u-boot/cpu/mcf52x2/start.S:345: Fatal
error: Tried to convert PC relative conditional branch to absolute jump
make: *** [cpu/mcf52x2/start.o] Error 1
-----------------------
 - found the same error in the mail list, see
http://sourceforge.net/mailarchive/message.php?msg_id=10000351
but no real solution mentioned.

 - found that the compiler option -msep-data is the reason for this error.

 - removed -msep-data from cpu/mcf52x2/config.mk

 - now compiling proceeds, but next error occurs:

make -C `dirname board/m5272c3/libm5272c3.a`
make[1]: Entering directory
`/cygdrive/c/project/U-Boot_20050803/u-boot/board/m5272c3'
m68k-elf-gcc -g  -Os   -ffixed-d7 -D__KERNEL__ -DTEXT_BASE=0xffe00000 -I/cyg
drive/c/project/U-Boot_20050803/u-boot/include -fno-builtin -ffreestanding -
nostdinc -isystem
/usr/local/m68k-uclinux-tools/lib/gcc/m68k-uclinux/3.4.0/include -pipe  -DCO
NFIG_M68K -D__M68K__ -m5307 -Wall -Wstrict-prototypes -c -o m5272c3.o
m5272c3.c
m68k-elf-gcc -g  -Os   -ffixed-d7 -D__KERNEL__ -DTEXT_BASE=0xffe00000 -I/cyg
drive/c/project/U-Boot_20050803/u-boot/include -fno-builtin -ffreestanding -
nostdinc -isystem
/usr/local/m68k-uclinux-tools/lib/gcc/m68k-uclinux/3.4.0/include -pipe  -DCO
NFIG_M68K -D__M68K__ -m5307 -Wall -Wstrict-prototypes -c -o flash.o flash.c
flash.c: In function `flash_print_info':
flash.c:68: error: label at end of compound statement
make[1]: *** [flash.o] Error 1
make[1]: Leaving directory
`/cygdrive/c/project/U-Boot_20050803/u-boot/board/m5272c3'
make: *** [board/m5272c3/libm5272c3.a] Error 2

this flash.c file is version 1.1 from 2003/12/08.

- ok, made patch in flash.c
  compiling proceeds, but next error:

UNDEF_SYM=`m68k-elf-objdump -x lib_generic/libgeneric.a
board/m5272c3/libm5272c3.a cpu/mcf52x2/libmcf52x2.a lib_m68k/libm68k.a
fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a
fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a net/libnet.a disk/libdisk.a
rtc/librtc.a dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a
post/libpost.a post/cpu/libcpu.a common/libcommon.a |sed  -n -e
's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
        m68k-elf-ld -Bstatic -T
/cygdrive/c/project/U-Boot_20050803/u-boot/board/m5272c3/u-boot.lds -Ttext
0xffe00000  -n $UNDEF_SYM cpu/mcf52x2/start.o \
                --start-group lib_generic/libgeneric.a
board/m5272c3/libm5272c3.a cpu/mcf52x2/libmcf52x2.a lib_m68k/libm68k.a
fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a
fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a net/libnet.a disk/libdisk.a
rtc/librtc.a dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a
post/libpost.a post/cpu/libcpu.a common/libcommon.a --end-group -L
/usr/local/m68k-uclinux-tools/lib/gcc/m68k-uclinux/3.4.0/m5307 -lgcc \
                -Map u-boot.map -o u-boot
/cygdrive/x/uCLinux/install/bin/m68k-elf-ld.real: internal error
/cygdrive/x/uCLinux/binutils-2.15.90.0.1.1/ld/ldlang.c 1977
make: *** [u-boot] Error 1

code from binutils:

int
lang_symbol_definition_iteration (const char *name)
{
  struct lang_definedness_hash_entry *defentry
    = (struct lang_definedness_hash_entry *)
    bfd_hash_lookup (&lang_definedness_table, name, FALSE, FALSE);

  /* We've already created this one on the presence of DEFINED in the
     script, so it can't be NULL unless something is borked elsewhere in
     the code.  */
  if (defentry == NULL)
line 1977:    FAIL ();
^^^^^^^^^^^^^^^^^^^^^^

  return defentry->iteration;
}

======================================================

so my overall questions,
Is then main reason for this problems that I use GCC3.4.0 toolchain ??
Are other people using U-Boot for coldfire M52xx ??
and did run into same problems ??
I like to hear from their solutions/advices.

=======================================================

Thanks in advance.

Teun Grinwis

Adesys BV
Molenweer 4, 2291 NR
Postbus 60, 2290 AB
Wateringen (NL)
Tel.: +31 174 296389
Fax : +31 174 293807
www.adesys.nl

[U-Boot-Users] GCC3.4.0 Coldfire 52xx Build problems

[Wolfgang Denk]

In message <OKECIIPCKHCPJAOEEJNMMEONCAAA.teun@adesys.nl> you wrote:
> 
> Is then main reason for this problems that I use GCC3.4.0 toolchain ??

Probably.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is easier to write an incorrect program than understand a  correct
one.

[U-Boot-Users] GCC3.4.0 Coldfire 52xx Build problems

[Murray.Jensen at csiro.au]

On Thu, 04 Aug 2005 12:31:27 +0200, Wolfgang Denk writes:
>In message <OKECIIPCKHCPJAOEEJNMMEONCAAA.teun@adesys.nl> you wrote:
>> Is then main reason for this problems that I use GCC3.4.0 toolchain ??
>Probably.

I use GCC-3.4.3 to build U-Boot for our MPC8560 based board. I had an
internal linker error which I traced to the following in my linker script:

  . = + SIZEOF_HEADERS;

I changed this to:

  . = + 1024;

and it prevented the core dump in the linker.

I know your target is very different, but I thought this info might help
anyway (if not you, then maybe someone else). Cheers!
								Murray...
-- 
Murray Jensen, CSIRO Manufacturing & Infra. Tech.      Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen at csiro.au

To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.

The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.

[U-Boot-Users] GCC3.4.0 Coldfire 52xx Build problems

[Teun Grinwis]

Thanks for your time Murray,

but ... it didn't workout successful.

but, the reason for my problems is the gcc version.
I now compiled with version 2.95.3 from:
http://www.uclinux.org/pub/uClinux/m68k-elf-tools/m68k-elf-tools-20030314.sh

I have some minor compile problem
( var declaration in middle of compound statement)

I am able to build u-boot.srec with use of patch below.

Here is patch:
--- common/cmd_flash.c.orig     2005-08-05 09:56:58.659430808 +0200
+++ common/cmd_flash.c  2005-08-05 09:55:34.344248664 +0200
@@ -117,11 +117,11 @@
 addr_spec(char *arg1, char *arg2, ulong *addr_first, ulong *addr_last)
 {
        char *ep;
+       char len_used = 0; /* indicates if the "start +length" form used */
        *addr_first = simple_strtoul(arg1, &ep, 16);
        if (ep == arg1 || *ep != '\0')
                return -1;

-       char len_used = 0; /* indicates if the "start +length" form used */
        if (arg2 && *arg2 == '+'){
                len_used = 1;
                ++arg2;
@@ -132,6 +132,8 @@
                return -1;

        if (len_used){
+               char found = 0;
+               ulong bank;
                /*
                 * *addr_last has the length, compute correct *addr_last
                 * XXX watch out for the integer overflow! Right now it is
@@ -146,8 +148,6 @@
                 */

                /* find the end addr of the sector where the *addr_last is
*/
-               char found = 0;
-               ulong bank;
                for (bank = 0; bank < CFG_MAX_FLASH_BANKS && !found;
++bank){
                        int i;
                        flash_info_t *info = &flash_info[bank];



On Thu, 04 Aug 2005 12:31:27 +0200, Wolfgang Denk writes:
>In message <OKECIIPCKHCPJAOEEJNMMEONCAAA.teun@adesys.nl> you wrote:
>> Is then main reason for this problems that I use GCC3.4.0 toolchain ??
>Probably.

I use GCC-3.4.3 to build U-Boot for our MPC8560 based board. I had an
internal linker error which I traced to the following in my linker script:

  . = + SIZEOF_HEADERS;

I changed this to:

  . = + 1024;

and it prevented the core dump in the linker.

Best Regards,

Teun Grinwis

[U-Boot-Users] GCC3.4.0 Coldfire 52xx Build problems

[Wolfgang Denk]

In message <14067.1123225365@gerd> you wrote:
>
> I use GCC-3.4.3 to build U-Boot for our MPC8560 based board. I had an
> internal linker error which I traced to the following in my linker script:
> 
>   . = + SIZEOF_HEADERS;
> 
> I changed this to:
> 
>   . = + 1024;
> 
> and it prevented the core dump in the linker.

Of course this can be no more than  part  of  a  bug  report  to  the
binutils folk. I would't even consider this as a workaround.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Faith may be defined briefly as an illogical belief in the  occurence
of the improbable.                                    - H. L. Mencken

[U-Boot-Users] GCC3.4.0 Coldfire 52xx Build problems

[Wolfgang Denk]

In message <OKECIIPCKHCPJAOEEJNMIEPACAAA.teun@adesys.nl> you wrote:
> 
> I have some minor compile problem
> ( var declaration in middle of compound statement)

Thanks for pointing out. Fixed and checked in on CVS and git trees.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A Vulcan can  no  sooner  be  disloyal  than  he  can  exist  without
breathing.
	-- Kirk, "The Menagerie", stardate 3012.4

[U-Boot-Users] GCC3.4.0 Coldfire 52xx Build problems

[Murray.Jensen at csiro.au]

On Fri, 05 Aug 2005 11:07:09 +0200, Wolfgang Denk writes:
>In message <14067.1123225365@gerd> you wrote:
>>
>> I use GCC-3.4.3 to build U-Boot for our MPC8560 based board. I had an
>> internal linker error which I traced to the following in my linker script:
>> 
>>   . = + SIZEOF_HEADERS;
>> 
>> I changed this to:
>> 
>>   . = + 1024;
>> 
>> and it prevented the core dump in the linker.
>
>Of course this can be no more than  part  of  a  bug  report  to  the
>binutils folk. I would't even consider this as a workaround.

Umm.. I think I worked out what was a reasonable value for SIZEOF_HEADERS
and substituted it. The build succeeds and runs fine on our MPC8560 board.
So I would consider this a reasonable work-around, until they fix binutils
(maybe they already have - I haven't tried later versions). Cheers!
								Murray...
-- 
Murray Jensen, CSIRO Manufacturing & Infra. Tech.      Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen at csiro.au

To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.

The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.

[U-Boot-Users] GCC3.4.0 Coldfire 52xx Build problems

[Wolfgang Denk]

In message <20838.1123235458@gerd> you wrote:
>
> Umm.. I think I worked out what was a reasonable value for SIZEOF_HEADERS
> and substituted it. The build succeeds and runs fine on our MPC8560 board.

Replacing a Builtin Function which is supposed to return the  correct
size  of  the  output  file's headers by a hardwired value which just
happens to be correct in one case is definitely not  acceptable,  not
even as a temporary workaround.

Simply don't use tools that are broken on such a basic level. And  if
you  want to use them, so either bug the binutils folks iuuintil they
fix it, or fix it yourself.  But  don;t  break  perfectly  legal  and
working code.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Due to lack of disk space, this fortune database has been discontinued.