[U-Boot] m68k: Build problems on some boards

Masahiro YAMADA yamada.m at jp.panasonic.com
Mon Dec 15 17:46:45 CET 2014


Hi Angelo,


2014-12-02 18:22 GMT+09:00 Angelo Dureghello <angelo at 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".

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


More information about the U-Boot mailing list