m68k: Build problems on some boards

U-Boot Angelo Dureghello 2 participants 7 messages Dec 1, 2014 – Jan 26, 2015

lore

Share & tools

lore

Angelo Dureghello

author

2014-12-01 20:41 UTC #0 lore raw

Dear All,

found this thread, i would have all coldfire boards correctly build here, so i am going to work on this.

I just tried to build M52277EVB, and failing too with my actual toolchain.

I'll try to find a toolchain that's able to build all coldfire boards and that is free to be downloaded.

If any of you know some m68k-elf open toolchain please let me know.

Regards,
Angelo

Angelo Dureghello

author

2014-12-01 23:17 UTC #1 lore raw

Hi,

i was be able to compile all the m68k boards (if i grepp'ed well).

In total 22 boards, and 36 defconfigs.

astro_mcf5373l.h
cobra5272.h
eb_cpu5282.h
gr_cpci_ax2000.h
TASREG.h

M5208EVBE.h
M52277EVB.h
M5235EVB.h
M5249EVB.h
M5253DEMO.h
M5253EVBE.h
M5272C3.h
M5275EVB.h
M5282EVB.h
M53017EVB.h

M5329EVB.h
M5329AFEE_defconfig
M5329BFEE_defconfig

M5373EVB.h
M54418TWR.h
M54451EVB.h
M54455EVB.h

M5475EVB.h
M5475AFE_defconfig
M5475BFE_defconfig
M5475CFE_defconfig
M5475DFE_defconfig
M5475EFE_defconfig
M5475FFE_defconfig
M5475GFE_defconfig

M5485EVB.h
M5485AFE_defconfig
M5485BFE_defconfig
M5485CFE_defconfig
M5485DFE_defconfig
M5485EFE_defconfig
M5485FFE_defconfig
M5485GFE_defconfig
M5485HFE_defconfig

The toolchain i used is:

m68k-elf-gcc (Sourcery CodeBench Lite 2011.09-21) 4.6.1

This toolchain was downloadable from Code Sourcery (Mentor) site some years ago, but actually seems not downloadable anymore.

I would like to setup a wiki page and share it as downloadable but i am not sure this is legal. I am investigating.

Regards,
Angelo

Masahiro Yamada

2014-12-02 04:26 UTC #2 lore raw

In reply to Angelo Dureghello

HI Angelo,

Quoted 9 lines · On Mon, 01 Dec 2014 21:41:59 +0100 Angelo Dureghello <[email protected]> wrote:

Dear All,
found this thread, i would have all coldfire boards correctly build here, so i am going to work on this.
I just tried to build M52277EVB, and failing too with my actual toolchain.

Quoted 5 lines

I'll try to find a toolchain that's able to build all coldfire boards and that is free to be downloaded.
If any of you know some m68k-elf open toolchain please let me know.

I recommend you to use kernel.org toolchain as I mentioned in
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/188763/focus=190993
or
"git log fbe79a17fddb7f0b"

Best Regards
Masahiro Yamada

Angelo Dureghello

author

2014-12-02 09:22 UTC #3 lore raw

Dear Masahiro,

Quoted 7 lines

I recommend you to use kernel.org toolchain as I mentioned in
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/188763/focus=190993
or
"git log fbe79a17fddb7f0b"

many thanks, i am not confident still using the archive, was using the "pipermail" archive, and clicking "next message" it was not showing your last message since it was in the next month.

Will use gmane as you did.

And thanks to your post i have also seen now how to build all the m68k boards in the correct way.

So the tool chain you posted gives no warnings and so it is the recommended one to be used actually. Will install it tonight.

In any case, i was also able to build all the boards with my current toolchain:

opt/CodeSourcery/Sourcery_CodeBench_Lite_for_ColdFire_ELF/bin/m68k-elf-gcc --version
m68k-elf-gcc (Sourcery CodeBench Lite 2011.09-21) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

--------------------- SUMMARY ---------------------------- Boards compiled: 48
Boards with warnings but no errors: 48 ( M52277EVB M52277EVB_stmicro M5235EVB M5235EVB_Flash32 cobra5272 eb_cpu5282 eb_cpu5282_internal TASREG M5208EVBE M5249EVB M5253DEMO M5272C3 M5275EVB M5282EVB astro_mcf5373l M53017EVB M5329AFEE M5329BFEE M5373EVB M54418TWR M54418TWR_nand_mii M54418TWR_nand_rmii M54418TWR_nand_rmii_lowfreq M54418TWR_serial_mii M54418TWR_serial_rmii M54451EVB M54451EVB_stmicro M54455EVB M54455EVB_a66 M54455EVB_i66 M54455EVB_intel M54455EVB_stm33 M5475AFE M5475BFE M5475CFE M5475DFE M5475EFE M5475FFE M5475GFE M5485AFE M5485BFE M5485CFE M5485DFE M5485EFE M5485FFE M5485GFE M5485HFE M5253EVBE )
----------------------------------------------------------

But it gives several warnings, more or less the same for each board, i attach them in case of any use:

Building M54455EVB_stm33 board...
text data bss dec hex filename
174005 13744 221236 408985 63d99 ./u-boot
tools/kwbimage.c: In function ?kwbimage_set_header?:
tools/kwbimage.c:803:8: warning: ?headersz? may be used uninitialized in this function [-Wmaybe-uninitialized]

   memcpy(ptr, image, headersz);
         ^

common/cli_simple.c: In function 'cli_simple_process_macros':
common/cli_simple.c:73:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat] common/cli_simple.c:162:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat] drivers/mtd/spi/sf.c: In function 'spi_flash_read_write':
drivers/mtd/spi/sf.c:30:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] drivers/mtd/spi/sf.c:36:4: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] drivers/mtd/spi/sf_ops.c: In function 'spi_flash_cmd_write_ops':
drivers/mtd/spi/sf_ops.c:324:3: warning: format '%zu' expects argument of type 'size_t', but argument 7 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'spi_flash_update_block':
common/cmd_sf.c:166:2: warning: format '%zx' expects argument of type 'size_t', but argument 4 has type 'unsigned int' [-Wformat] common/cmd_sf.c:173:3: warning: format '%zx' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'spi_flash_update':
common/cmd_sf.c:248:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_sf.c:248:9: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'do_spi_flash_read_write':
common/cmd_sf.c:303:10: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'do_spi_flash_erase':
common/cmd_sf.c:338:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_nvedit.c: In function 'do_env_export':
common/cmd_nvedit.c:914:3: warning: format '%zX' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] common/cmd_nvedit.c: In function 'do_env_import':
common/cmd_nvedit.c:1047:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_nvedit.c:1047:3: warning: format '%zX' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] lib/hashtable.c: In function 'hexport_r':
lib/hashtable.c:605:2: warning: format '%zu' expects argument of type 'size_t', but argument 5 has type 'unsigned int' [-Wformat] lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] lib/hashtable.c: In function 'himport_r':
lib/hashtable.c:793:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat]

As you probably read from the list, Alison Wang and me are going to be m68k custodians together, so i am starting reading all m68k things that are open.

Best Regards,
Angelo Dureghello

Masahiro YAMADA

2014-12-15 16:46 UTC #4 lore raw

Hi Angelo,

2014-12-02 18:22 GMT+09:00 Angelo Dureghello <[email protected]>:

Quoted 80 lines

And thanks to your post i have also seen now how to build all the m68k boards in the correct way.
So the tool chain you posted gives no warnings and so it is the recommended one to be used actually. Will install it tonight.
In any case, i was also able to build all the boards with my current toolchain:
opt/CodeSourcery/Sourcery_CodeBench_Lite_for_ColdFire_ELF/bin/m68k-elf-gcc --version
m68k-elf-gcc (Sourcery CodeBench Lite 2011.09-21) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--------------------- SUMMARY ---------------------------- Boards compiled: 48
Boards with warnings but no errors: 48 ( M52277EVB M52277EVB_stmicro M5235EVB M5235EVB_Flash32 cobra5272 eb_cpu5282 eb_cpu5282_internal TASREG M5208EVBE M5249EVB M5253DEMO M5272C3 M5275EVB M5282EVB astro_mcf5373l M53017EVB M5329AFEE M5329BFEE M5373EVB M54418TWR M54418TWR_nand_mii M54418TWR_nand_rmii M54418TWR_nand_rmii_lowfreq M54418TWR_serial_mii M54418TWR_serial_rmii M54451EVB M54451EVB_stmicro M54455EVB M54455EVB_a66 M54455EVB_i66 M54455EVB_intel M54455EVB_stm33 M5475AFE M5475BFE M5475CFE M5475DFE M5475EFE M5475FFE M5475GFE M5485AFE M5485BFE M5485CFE M5485DFE M5485EFE M5485FFE M5485GFE M5485HFE M5253EVBE )
----------------------------------------------------------
But it gives several warnings, more or less the same for each board, i attach them in case of any use:
Building M54455EVB_stm33 board...
text data bss dec hex filename
174005 13744 221236 408985 63d99 ./u-boot
tools/kwbimage.c: In function ?kwbimage_set_header?:
tools/kwbimage.c:803:8: warning: ?headersz? may be used uninitialized in this function [-Wmaybe-uninitialized]
  memcpy(ptr, image, headersz);
        ^
common/cli_simple.c: In function 'cli_simple_process_macros':
common/cli_simple.c:73:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat] common/cli_simple.c:162:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat] drivers/mtd/spi/sf.c: In function 'spi_flash_read_write':
drivers/mtd/spi/sf.c:30:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] drivers/mtd/spi/sf.c:36:4: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] drivers/mtd/spi/sf_ops.c: In function 'spi_flash_cmd_write_ops':
drivers/mtd/spi/sf_ops.c:324:3: warning: format '%zu' expects argument of type 'size_t', but argument 7 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'spi_flash_update_block':
common/cmd_sf.c:166:2: warning: format '%zx' expects argument of type 'size_t', but argument 4 has type 'unsigned int' [-Wformat] common/cmd_sf.c:173:3: warning: format '%zx' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'spi_flash_update':
common/cmd_sf.c:248:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_sf.c:248:9: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'do_spi_flash_read_write':
common/cmd_sf.c:303:10: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'do_spi_flash_erase':
common/cmd_sf.c:338:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_nvedit.c: In function 'do_env_export':
common/cmd_nvedit.c:914:3: warning: format '%zX' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] common/cmd_nvedit.c: In function 'do_env_import':
common/cmd_nvedit.c:1047:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_nvedit.c:1047:3: warning: format '%zX' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] lib/hashtable.c: In function 'hexport_r':
lib/hashtable.c:605:2: warning: format '%zu' expects argument of type

Quoted 9 lines

'size_t', but argument 5 has type 'unsigned int' [-Wformat] lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] lib/hashtable.c: In function 'himport_r':
lib/hashtable.c:793:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat]

This is a known (and unfortunate) problem.

The Linux m68k toolchains (as I am using) define size_t as "unsigned int", whereas bare-metal m68k toolchains (as you are using) define size_t as "unsigned long".

People often want to adjust the type definition to the toolchains they are using.

Commit ddc94378d changed __kernel_size_t definition from "unsigned int" to "unsigned long".

Commit fbe79a17 changed it back to "unsigned int" again.

BTW, Linux Kernel has the same problem as we have for U-Boot.

I posted a question about this to LKML.

If you are interested in it, check out this thread:
https://lkml.org/lkml/2014/12/15/110

According to that thread, the solution the kernel folks chose is to always use toolchains configured for Linux.

For U-Boot, I think we have two options

[1] Follow the Linux's way:
Ban bare-metal toolchains and always use kernel.org ones

[2] Use __SIZE_TYPE__ (or include <stddef.h>)
to support both types of toolchains.

Best Regards
Masahiro Yamada

Angelo Dureghello

author

2014-12-22 18:06 UTC #5 lore raw

Dear Masahiro,

Quoted 27 lines · Masahiro YAMADA

This is a known (and unfortunate) problem.
The Linux m68k toolchains (as I am using) define size_t as "unsigned int", whereas bare-metal m68k toolchains (as you are using) define size_t as "unsigned long".
People often want to adjust the type definition to the toolchains they are using.
Commit ddc94378d changed __kernel_size_t definition from "unsigned int" to "unsigned long".
Commit fbe79a17 changed it back to "unsigned int" again.
BTW, Linux Kernel has the same problem as we have for U-Boot.
I posted a question about this to LKML.
If you are interested in it, check out this thread:
https://lkml.org/lkml/2014/12/15/110
According to that thread, the solution the kernel folks chose is to always use toolchains configured for Linux.

Quoted 7 lines

For U-Boot, I think we have two options
[1] Follow the Linux's way:
Ban bare-metal toolchains and always use kernel.org ones
[2] Use __SIZE_TYPE__ (or include <stddef.h>)
to support both types of toolchains.

Many thanks for the deep analysis and clarifications.

For me, it is good we know [1] is compiling properly, so i am fine to adopt the kernel.org 32/64 bit toolchains for m68k development, if the community agree, i can prepare a u.boot m68k wiki page with this information.

The discussion for [2] is interesting to me, i am trying to understand the thing properly but i still have some doubts: from my understanding, a bare-metal toolchain should be without libc support (or minimal), so the kernel.org "nolibc" should be considered bare-metal ? If so, could the issue be related to "certain" toolchain only ?

Also, i am not understanding, i am comparing now 2 different toolchains:

CROSS_COMPILE=/opt/toolchains/Sourcery_CodeBench_Lite_for_ColdFire_ELF/bin/m68k-elf- /MAKEALL -a m68k
compiles with warning: format '%zx' expects argument of type 'size_t', but argument 4 has type 'unsigned int' [-Wformat]

CROSS_COMPILE=/opt/toolchains/Sourcery_CodeBench_Lite_for_ColdFire_uClinux/bin/m68k-uclinux- ./MAKEALL -a m68k
this compiles fine, no warnings

But if i look to the <stddef.h> of the 2 toolchains, they are exactly the same. So why the compilers expects different definitions of size_t ?

Regards,
Angelo Dureghello

Option [2] would be better of course, could the change to use __SIZE_TYPE__ (or include <stddef.h>) be done in a single place ? What impact it can have for other architectures then ?

We can also simply collect in a wiki page for m68k dev this informations, (to use kernel.org, and explain the warning reason).

Best Regards
Angelo Dureghello

Quoted 2 lines

Best Regards
Masahiro Yamada

Angelo Dureghello

author

2015-01-26 20:54 UTC #6 lore raw

In reply to Masahiro YAMADA

Dear Masahiro,

Quoted 94 lines · Masahiro YAMADA

Hi Angelo,
2014-12-02 18:22 GMT+09:00 Angelo Dureghello <[email protected]>:
Quoted 80 lines
And thanks to your post i have also seen now how to build all the m68k boards in the correct way.
So the tool chain you posted gives no warnings and so it is the recommended one to be used actually. Will install it tonight.
In any case, i was also able to build all the boards with my current toolchain:
opt/CodeSourcery/Sourcery_CodeBench_Lite_for_ColdFire_ELF/bin/m68k-elf-gcc --version
m68k-elf-gcc (Sourcery CodeBench Lite 2011.09-21) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--------------------- SUMMARY ---------------------------- Boards compiled: 48
Boards with warnings but no errors: 48 ( M52277EVB M52277EVB_stmicro M5235EVB M5235EVB_Flash32 cobra5272 eb_cpu5282 eb_cpu5282_internal TASREG M5208EVBE M5249EVB M5253DEMO M5272C3 M5275EVB M5282EVB astro_mcf5373l M53017EVB M5329AFEE M5329BFEE M5373EVB M54418TWR M54418TWR_nand_mii M54418TWR_nand_rmii M54418TWR_nand_rmii_lowfreq M54418TWR_serial_mii M54418TWR_serial_rmii M54451EVB M54451EVB_stmicro M54455EVB M54455EVB_a66 M54455EVB_i66 M54455EVB_intel M54455EVB_stm33 M5475AFE M5475BFE M5475CFE M5475DFE M5475EFE M5475FFE M5475GFE M5485AFE M5485BFE M5485CFE M5485DFE M5485EFE M5485FFE M5485GFE M5485HFE M5253EVBE )
----------------------------------------------------------
But it gives several warnings, more or less the same for each board, i attach them in case of any use:
Building M54455EVB_stm33 board...
text data bss dec hex filename
174005 13744 221236 408985 63d99 ./u-boot
tools/kwbimage.c: In function ?kwbimage_set_header?:
tools/kwbimage.c:803:8: warning: ?headersz? may be used uninitialized in this function [-Wmaybe-uninitialized]
   memcpy(ptr, image, headersz);
         ^
common/cli_simple.c: In function 'cli_simple_process_macros':
common/cli_simple.c:73:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat] common/cli_simple.c:162:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat] drivers/mtd/spi/sf.c: In function 'spi_flash_read_write':
drivers/mtd/spi/sf.c:30:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] drivers/mtd/spi/sf.c:36:4: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] drivers/mtd/spi/sf_ops.c: In function 'spi_flash_cmd_write_ops':
drivers/mtd/spi/sf_ops.c:324:3: warning: format '%zu' expects argument of type 'size_t', but argument 7 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'spi_flash_update_block':
common/cmd_sf.c:166:2: warning: format '%zx' expects argument of type 'size_t', but argument 4 has type 'unsigned int' [-Wformat] common/cmd_sf.c:173:3: warning: format '%zx' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'spi_flash_update':
common/cmd_sf.c:248:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_sf.c:248:9: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'do_spi_flash_read_write':
common/cmd_sf.c:303:10: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'do_spi_flash_erase':
common/cmd_sf.c:338:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_nvedit.c: In function 'do_env_export':
common/cmd_nvedit.c:914:3: warning: format '%zX' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] common/cmd_nvedit.c: In function 'do_env_import':
common/cmd_nvedit.c:1047:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_nvedit.c:1047:3: warning: format '%zX' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] lib/hashtable.c: In function 'hexport_r':
lib/hashtable.c:605:2: warning: format '%zu' expects argument of type
Quoted 9 lines
'size_t', but argument 5 has type 'unsigned int' [-Wformat] lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] lib/hashtable.c: In function 'himport_r':
lib/hashtable.c:793:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat]

Quoted 5 lines

This is a known (and unfortunate) problem.
The Linux m68k toolchains (as I am using) define size_t as "unsigned int", whereas bare-metal m68k toolchains (as you are using) define size_t as "unsigned long".

You said you are using the kernel.org toolchain:

https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_m68k-linux.tar.gz

I have a 32 bit machine, the only kernel.org toolchain available i can find on that folder is:

https://www.kernel.org/pub/tools/crosstool/files/bin/i686/4.6.3/i686-gcc-4.6.3-nolibc_m68k-linux.tar.gz

Here seems i found a bug into binutils 2.22 assembler "as". Executable was continuously resetting on the target for a wrong opcode, at least for m5307 target, see here eventually:

https://sourceware.org/bugzilla/show_bug.cgi?id=17877

Btw, binutils "as" 2.21.53 works fine.

I solved for now replacing only the "gnu as" with 2.21.53.

If you have any idea for a working "warning-less" coldfire kernel.org toolchain, even older, please let me know.

Thanks,

Quoted 28 lines

People often want to adjust the type definition to the toolchains they are using.
Commit ddc94378d changed __kernel_size_t definition from "unsigned int" to "unsigned long".
Commit fbe79a17 changed it back to "unsigned int" again.
BTW, Linux Kernel has the same problem as we have for U-Boot.
I posted a question about this to LKML.
If you are interested in it, check out this thread:
https://lkml.org/lkml/2014/12/15/110
According to that thread, the solution the kernel folks chose is to always use toolchains configured for Linux.
For U-Boot, I think we have two options
[1] Follow the Linux's way:
Ban bare-metal toolchains and always use kernel.org ones

Quoted 6 lines

[2] Use __SIZE_TYPE__ (or include <stddef.h>)
to support both types of toolchains.
Best Regards
Masahiro Yamada

Best regards,
Angelo Dureghello