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

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

[Angelo Dureghello]

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

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

[Angelo Dureghello]

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

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

[Masahiro Yamada]

HI Angelo,

On Mon, 01 Dec 2014 21:41:59 +0100
Angelo Dureghello <angelo@sysam.it> 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.
> 
> 
> 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

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

[Angelo Dureghello]

Dear Masahiro,


>
> 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

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

[Masahiro YAMADA]

Hi Angelo,


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

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

[Angelo Dureghello]

Dear Masahiro,

On 15/12/2014 17:46, Masahiro YAMADA wrote:

> 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.
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

> Best Regards
> Masahiro Yamada

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

[Angelo Dureghello]

Dear Masahiro,

On 15/12/2014 17:46, Masahiro YAMADA wrote:
> Hi Angelo,
>
>
> 2014-12-02 18:22 GMT+09:00 Angelo Dureghello <angelo@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] m68k: Build problems on some boards

[Vasili Galka]

Hi,

I've installed a m68k-elf toolchain (based on gcc 4.8.1) and tried
building all m68k boards on latest u-boot/master (MAKEALL -a m68k).
While the build succeeds for most of the boards, the following four
fail with similar errors:
TASREG M5249EVB M5253DEMO M5253EVBE

m68k-elf-ld.bfd: m68k:isa-a:mac architecture of input file
`/usr/m68k-elf/lib/gcc/m68k-elf/4.8.1/m5206e/libgcc.a(_float.o)' is
incompatible with m68k:isa-a:emac output
m68k-elf-ld.bfd: m68k:isa-a:mac architecture of input file
`/usr/m68k-elf/lib/gcc/m68k-elf/4.8.1/m5206e/libgcc.a(_floatex.o)' is
incompatible with m68k:isa-a:emac output
m68k-elf-ld.bfd: m68k:isa-a:mac architecture of input file
`/usr/m68k-elf/lib/gcc/m68k-elf/4.8.1/m5206e/libgcc.a(_muldi3.o)' is
incompatible with m68k:isa-a:emac output
...

AFAIU, the architecture of chosen libgcc differs from the
architecture of generated object files (one has mac while the other
emac).

I'm not really familiar with m68k arch... What is wrong here and how
should be fixed?

Best regards,
Vasili

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

[Vasili Galka]

I'll really appreciate any help on this.

On Sun, Jun 15, 2014 at 3:57 PM, Vasili Galka <vvv444@gmail.com> wrote:
> Hi,
>
> I've installed a m68k-elf toolchain (based on gcc 4.8.1) and tried
> building all m68k boards on latest u-boot/master (MAKEALL -a m68k).
> While the build succeeds for most of the boards, the following four
> fail with similar errors:
> TASREG M5249EVB M5253DEMO M5253EVBE
>
> m68k-elf-ld.bfd: m68k:isa-a:mac architecture of input file
> `/usr/m68k-elf/lib/gcc/m68k-elf/4.8.1/m5206e/libgcc.a(_float.o)' is
> incompatible with m68k:isa-a:emac output
> m68k-elf-ld.bfd: m68k:isa-a:mac architecture of input file
> `/usr/m68k-elf/lib/gcc/m68k-elf/4.8.1/m5206e/libgcc.a(_floatex.o)' is
> incompatible with m68k:isa-a:emac output
> m68k-elf-ld.bfd: m68k:isa-a:mac architecture of input file
> `/usr/m68k-elf/lib/gcc/m68k-elf/4.8.1/m5206e/libgcc.a(_muldi3.o)' is
> incompatible with m68k:isa-a:emac output
> ...
>
> AFAIU, the architecture of chosen libgcc differs from the
> architecture of generated object files (one has mac while the other
> emac).
>
> I'm not really familiar with m68k arch... What is wrong here and how
> should be fixed?
>
> Best regards,
> Vasili

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

[Tom Rini]

On Sun, Jun 22, 2014 at 12:19:21PM +0300, Vasili Galka wrote:
> I'll really appreciate any help on this.
> 
> On Sun, Jun 15, 2014 at 3:57 PM, Vasili Galka <vvv444@gmail.com> wrote:
> > Hi,
> >
> > I've installed a m68k-elf toolchain (based on gcc 4.8.1) and tried
> > building all m68k boards on latest u-boot/master (MAKEALL -a m68k).
> > While the build succeeds for most of the boards, the following four
> > fail with similar errors:
> > TASREG M5249EVB M5253DEMO M5253EVBE
> >
> > m68k-elf-ld.bfd: m68k:isa-a:mac architecture of input file
> > `/usr/m68k-elf/lib/gcc/m68k-elf/4.8.1/m5206e/libgcc.a(_float.o)' is
> > incompatible with m68k:isa-a:emac output
> > m68k-elf-ld.bfd: m68k:isa-a:mac architecture of input file
> > `/usr/m68k-elf/lib/gcc/m68k-elf/4.8.1/m5206e/libgcc.a(_floatex.o)' is
> > incompatible with m68k:isa-a:emac output
> > m68k-elf-ld.bfd: m68k:isa-a:mac architecture of input file
> > `/usr/m68k-elf/lib/gcc/m68k-elf/4.8.1/m5206e/libgcc.a(_muldi3.o)' is
> > incompatible with m68k:isa-a:emac output
> > ...
> >
> > AFAIU, the architecture of chosen libgcc differs from the
> > architecture of generated object files (one has mac while the other
> > emac).
> >
> > I'm not really familiar with m68k arch... What is wrong here and how
> > should be fixed?
> >
> > Best regards,
> > Vasili

Jason, is there a toolchain that can work for all m68k boards?  Should
we start removing some boards perhaps?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140623/1e3a1ce2/attachment.pgp>

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

[Masahiro Yamada]

Tom, Vasili


On Mon, 23 Jun 2014 09:10:01 -0400
Tom Rini <trini@ti.com> wrote:

> On Sun, Jun 22, 2014 at 12:19:21PM +0300, Vasili Galka wrote:
> > I'll really appreciate any help on this.
> > 
> > On Sun, Jun 15, 2014 at 3:57 PM, Vasili Galka <vvv444@gmail.com> wrote:
> > > Hi,
> > >
> > > I've installed a m68k-elf toolchain (based on gcc 4.8.1) and tried
> > > building all m68k boards on latest u-boot/master (MAKEALL -a m68k).
> > > While the build succeeds for most of the boards, the following four
> > > fail with similar errors:
> > > TASREG M5249EVB M5253DEMO M5253EVBE
> > >
> > > m68k-elf-ld.bfd: m68k:isa-a:mac architecture of input file
> > > `/usr/m68k-elf/lib/gcc/m68k-elf/4.8.1/m5206e/libgcc.a(_float.o)' is
> > > incompatible with m68k:isa-a:emac output
> > > m68k-elf-ld.bfd: m68k:isa-a:mac architecture of input file
> > > `/usr/m68k-elf/lib/gcc/m68k-elf/4.8.1/m5206e/libgcc.a(_floatex.o)' is
> > > incompatible with m68k:isa-a:emac output
> > > m68k-elf-ld.bfd: m68k:isa-a:mac architecture of input file
> > > `/usr/m68k-elf/lib/gcc/m68k-elf/4.8.1/m5206e/libgcc.a(_muldi3.o)' is
> > > incompatible with m68k:isa-a:emac output
> > > ...
> > >
> > > AFAIU, the architecture of chosen libgcc differs from the
> > > architecture of generated object files (one has mac while the other
> > > emac).
> > >
> > > I'm not really familiar with m68k arch... What is wrong here and how
> > > should be fixed?
> > >
> > > Best regards,
> > > Vasili
> 
> Jason, is there a toolchain that can work for all m68k boards?  Should
> we start removing some boards perhaps?
> 


I think all m68k boards can build file with my series.
http://lists.denx.de/pipermail/u-boot/2014-July/184135.html
http://patchwork.ozlabs.org/patch/372320/
http://patchwork.ozlabs.org/patch/372321/



Best Regards
Masahiro Yamada