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

Mon Jan 26 21:54:55 CET 2015

Dear Masahiro,

On 15/12/2014 17:46, Masahiro YAMADA wrote:
> 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".

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