From mboxrd@z Thu Jan 1 00:00:00 1970 From: Angelo Dureghello Date: Mon, 26 Jan 2015 21:54:55 +0100 Subject: [U-Boot] m68k: Build problems on some boards In-Reply-To: References: <547CD297.4080002@sysam.it> <20141202132613.67DB.AA925319@jp.panasonic.com> <547D84E8.90900@sysam.it> Message-ID: <54C6A99F.3070308@sysam.it> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Masahiro, On 15/12/2014 17:46, Masahiro YAMADA wrote: > Hi Angelo, > > > 2014-12-02 18:22 GMT+09:00 Angelo Dureghello : >> 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 ) > to support both types of toolchains. > > > Best Regards > Masahiro Yamada Best regards, Angelo Dureghello