Dear Masahiro,
On 15/12/2014 17:46, Masahiro YAMADA wrote:
Hi Angelo, 2014-12-02 18:22 GMT+09:00 Angelo Dureghello <ang...@sysam.it>: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]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,
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
Best regards, Angelo Dureghello _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
