[U-Boot-Users] RFC: make new image support mandatory

[U-Boot-Users] RFC: make new image support mandatory

[Wolfgang Denk]

Hello everybody,

now that the new image  format  has  been  merged  into  mainline,  I
propose  that  we  make it mandatory for all newly added boards. That
means, that each new board that gets added shall at least contain

	#define CONFIG_FIT              1

in it's board config file; I recommend to add also

	#define CONFIG_FIT_VERBOSE      1 /* enable fit_format_{error,warning}() */


Can we agree on this?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
READ THIS BEFORE OPENING PACKAGE: According to Certain Suggested Ver-
sions of the Grand Unified Theory, the Primary Particles Constituting
this Product May Decay to Nothingness Within the  Next  Four  Hundred
Million Years.

[U-Boot-Users] RFC: make new image support mandatory

[Kumar Gala]

On Mar 26, 2008, at 9:16 AM, Wolfgang Denk wrote:
> Hello everybody,
>
> now that the new image  format  has  been  merged  into  mainline,  I
> propose  that  we  make it mandatory for all newly added boards. That
> means, that each new board that gets added shall at least contain
>
> 	#define CONFIG_FIT              1
>
> in it's board config file; I recommend to add also
>
> 	#define CONFIG_FIT_VERBOSE      1 /* enable  
> fit_format_{error,warning}() */
>
>
> Can we agree on this?

I haven't tried out the CONFIG_FIT stuff yet so some of these concerns  
might not be real issues:
1. Are their changes to linux kernel build system to create a  
FIT .uImage ?
2. if "#define CONFIG_FIT 1" can we use an "old" style uImage?

If the answer to 2. is no, I'm concerned about boards that are part of  
a family (like Freescale reference boards for PPC) and having two  
different image formats to deal with.

- k 

[U-Boot-Users] RFC: make new image support mandatory

[Bartlomiej Sieka]

Kumar Gala wrote:
[...]
> I haven't tried out the CONFIG_FIT stuff yet so some of these concerns  
> might not be real issues:
> 1. Are their changes to linux kernel build system to create a  
> FIT .uImage ?

No, new uImage support has not been integrated with the kernel build system.

> 2. if "#define CONFIG_FIT 1" can we use an "old" style uImage?

Yes, both old and new formats are supported.

Regards,
Bartlomiej

[U-Boot-Users] RFC: make new image support mandatory

[Wolfgang Denk]

In message <A3CF2817-786F-45C9-92BA-6DF8CE150C85@kernel.crashing.org> you wrote:
> 
> > Can we agree on this?
> 
> I haven't tried out the CONFIG_FIT stuff yet so some of these concerns  
> might not be real issues:
> 1. Are their changes to linux kernel build system to create a  
> FIT .uImage ?

Not yet.

> 2. if "#define CONFIG_FIT 1" can we use an "old" style uImage?

Yes, of course.

> If the answer to 2. is no, I'm concerned about boards that are part of  
> a family (like Freescale reference boards for PPC) and having two  
> different image formats to deal with.

No, I don't intend to force incompatible changes on innocent users :-)

Ideally, nobody has even to take notice of the new feature - unless
they run "help" on some of the commands.

But then, they *can* use the new features if they want.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The first rule of magic is simple. Don't waste your time waving your
hands and hoping when a rock or a club will do."
                                               - McCloctnik the Lucid

[U-Boot-Users] RFC: make new image support mandatory

[Kumar Gala]

On Mar 26, 2008, at 9:57 AM, Wolfgang Denk wrote:
> In message  
> <A3CF2817-786F-45C9-92BA-6DF8CE150C85@kernel.crashing.org> you wrote:
>>
>>> Can we agree on this?
>>
>> I haven't tried out the CONFIG_FIT stuff yet so some of these  
>> concerns
>> might not be real issues:
>> 1. Are their changes to linux kernel build system to create a
>> FIT .uImage ?
>
> Not yet.
>
>> 2. if "#define CONFIG_FIT 1" can we use an "old" style uImage?
>
> Yes, of course.
>
>> If the answer to 2. is no, I'm concerned about boards that are part  
>> of
>> a family (like Freescale reference boards for PPC) and having two
>> different image formats to deal with.
>
> No, I don't intend to force incompatible changes on innocent users :-)
>
> Ideally, nobody has even to take notice of the new feature - unless
> they run "help" on some of the commands.
>
> But then, they *can* use the new features if they want.

Than I'm all for.

- k

[U-Boot-Users] RFC: make new image support mandatory

[Bartlomiej Sieka]

Wolfgang Denk wrote:
> Hello everybody,
> 
> now that the new image  format  has  been  merged  into  mainline,  I
> propose  that  we  make it mandatory for all newly added boards. That
> means, that each new board that gets added shall at least contain
> 
> 	#define CONFIG_FIT              1
> 
> in it's board config file; I recommend to add also
> 
> 	#define CONFIG_FIT_VERBOSE      1 /* enable fit_format_{error,warning}() */

new uImage format also requires:

#define CONFIG_OF_LIBFDT		1


> Can we agree on this?

I'm all for it :)


Regards,
Bartlomiej

[U-Boot-Users] RFC: make new image support mandatory

[Haavard Skinnemoen]

On Wed, 26 Mar 2008 15:16:44 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Can we agree on this?

Can we please un-break the existing tree first?

gcc -g -Wall -idirafter /home/hskinnemoen/git/u-boot/upstream/include -idirafter /home/hskinnemoen/git/u-boot/upstream/include2 -idirafter /home/hskinnemoen/git/u-boot/upstream/include -DTEXT_BASE=0x00000000 -DUSE_HOSTCC -O -c -o fdt.o fdt.c
In file included from fdt_host.h:24,
                 from fdt.c:57:
../include/fdt.h:7: error: expected specifier-qualifier-list before ?uint32_t?
../include/fdt.h:26: error: expected specifier-qualifier-list before ?uint64_t?
../include/fdt.h:31: error: expected specifier-qualifier-list before ?uint32_t?
../include/fdt.h:36: error: expected specifier-qualifier-list before ?uint32_t?
In file included from fdt_host.h:25,
                 from fdt.c:57:
../include/libfdt.h:131: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?fdt_next_tag?
../include/libfdt.h:156: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_magic?:
../include/libfdt.h:156: error: ?struct fdt_header? has no member named ?magic?
../include/libfdt.h:156: error: ?val? undeclared (first use in this function)
../include/libfdt.h:156: error: (Each undeclared identifier is reported only once
../include/libfdt.h:156: error: for each function it appears in.)
../include/libfdt.h: At top level:
../include/libfdt.h:157: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_totalsize?:
../include/libfdt.h:157: error: ?struct fdt_header? has no member named ?totalsize?
../include/libfdt.h:157: error: ?val? undeclared (first use in this function)
../include/libfdt.h: At top level:
../include/libfdt.h:158: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_off_dt_struct?:
../include/libfdt.h:158: error: ?struct fdt_header? has no member named ?off_dt_struct?
../include/libfdt.h:158: error: ?val? undeclared (first use in this function)
../include/libfdt.h: At top level:
../include/libfdt.h:159: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_off_dt_strings?:
../include/libfdt.h:159: error: ?struct fdt_header? has no member named ?off_dt_strings?
../include/libfdt.h:159: error: ?val? undeclared (first use in this function)
../include/libfdt.h: At top level:
../include/libfdt.h:160: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_off_mem_rsvmap?:
../include/libfdt.h:160: error: ?struct fdt_header? has no member named ?off_mem_rsvmap?
../include/libfdt.h:160: error: ?val? undeclared (first use in this function)
../include/libfdt.h: At top level:
../include/libfdt.h:161: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_version?:
../include/libfdt.h:161: error: ?struct fdt_header? has no member named ?version?
../include/libfdt.h:161: error: ?val? undeclared (first use in this function)
../include/libfdt.h: At top level:
../include/libfdt.h:162: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_last_comp_version?:
../include/libfdt.h:162: error: ?struct fdt_header? has no member named ?last_comp_version?
../include/libfdt.h:162: error: ?val? undeclared (first use in this function)
../include/libfdt.h: At top level:
../include/libfdt.h:163: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_boot_cpuid_phys?:
../include/libfdt.h:163: error: ?struct fdt_header? has no member named ?boot_cpuid_phys?
../include/libfdt.h:163: error: ?val? undeclared (first use in this function)
../include/libfdt.h: At top level:
../include/libfdt.h:164: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_size_dt_strings?:
../include/libfdt.h:164: error: ?struct fdt_header? has no member named ?size_dt_strings?
../include/libfdt.h:164: error: ?val? undeclared (first use in this function)
../include/libfdt.h: At top level:
../include/libfdt.h:165: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_size_dt_struct?:
../include/libfdt.h:165: error: ?struct fdt_header? has no member named ?size_dt_struct?
../include/libfdt.h:165: error: ?val? undeclared (first use in this function)
../include/libfdt.h: At top level:
../include/libfdt.h:251: error: expected declaration specifiers or ?...? before ?uint64_t?
../include/libfdt.h:251: error: expected declaration specifiers or ?...? before ?uint64_t?
../include/libfdt.h:423: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?fdt_get_phandle?
../include/libfdt.h:590: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h:718: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_setprop_inplace_cell?:
../include/libfdt.h:720: error: ?val? undeclared (first use in this function)
../include/libfdt.h: At top level:
../include/libfdt.h:779: error: expected declaration specifiers or ?...? before ?uint64_t?
../include/libfdt.h:779: error: expected declaration specifiers or ?...? before ?uint64_t?
../include/libfdt.h:783: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_property_cell?:
../include/libfdt.h:785: error: ?val? undeclared (first use in this function)
../include/libfdt.h: At top level:
../include/libfdt.h:822: error: expected declaration specifiers or ?...? before ?uint64_t?
../include/libfdt.h:822: error: expected declaration specifiers or ?...? before ?uint64_t?
../include/libfdt.h:908: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_setprop_cell?:
../include/libfdt.h:910: error: ?val? undeclared (first use in this function)
In file included from fdt.c:60:
libfdt_internal.h: At top level:
libfdt_internal.h:61: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?_fdt_next_tag?
libfdt_internal.h: In function ?_fdt_offset_ptr?:
libfdt_internal.h:67: error: ?const struct fdt_header? has no member named ?off_dt_struct?
libfdt_internal.h:67: error: ?const struct fdt_header? has no member named ?off_dt_struct?
libfdt_internal.h:67: error: ?const struct fdt_header? has no member named ?off_dt_struct?
libfdt_internal.h:67: error: ?const struct fdt_header? has no member named ?off_dt_struct?
libfdt_internal.h:67: error: ?const struct fdt_header? has no member named ?off_dt_struct?
libfdt_internal.h:67: error: ?const struct fdt_header? has no member named ?off_dt_struct?
libfdt_internal.h: In function ?_fdt_mem_rsv?:
libfdt_internal.h:78: error: ?const struct fdt_header? has no member named ?off_mem_rsvmap?
libfdt_internal.h:78: error: ?const struct fdt_header? has no member named ?off_mem_rsvmap?
libfdt_internal.h:78: error: ?const struct fdt_header? has no member named ?off_mem_rsvmap?
libfdt_internal.h:78: error: ?const struct fdt_header? has no member named ?off_mem_rsvmap?
libfdt_internal.h:78: error: ?const struct fdt_header? has no member named ?off_mem_rsvmap?
libfdt_internal.h:78: error: ?const struct fdt_header? has no member named ?off_mem_rsvmap?
fdt.c: In function ?fdt_check_header?:
fdt.c:64: error: ?const struct fdt_header? has no member named ?magic?
fdt.c:64: error: ?const struct fdt_header? has no member named ?magic?
fdt.c:64: error: ?const struct fdt_header? has no member named ?magic?
fdt.c:64: error: ?const struct fdt_header? has no member named ?magic?
fdt.c:64: error: ?const struct fdt_header? has no member named ?magic?
fdt.c:64: error: ?const struct fdt_header? has no member named ?magic?
fdt.c:66: error: ?const struct fdt_header? has no member named ?version?
fdt.c:66: error: ?const struct fdt_header? has no member named ?version?
fdt.c:66: error: ?const struct fdt_header? has no member named ?version?
fdt.c:66: error: ?const struct fdt_header? has no member named ?version?
fdt.c:66: error: ?const struct fdt_header? has no member named ?version?
fdt.c:66: error: ?const struct fdt_header? has no member named ?version?
fdt.c:68: error: ?const struct fdt_header? has no member named ?last_comp_version?
fdt.c:68: error: ?const struct fdt_header? has no member named ?last_comp_version?
fdt.c:68: error: ?const struct fdt_header? has no member named ?last_comp_version?
fdt.c:68: error: ?const struct fdt_header? has no member named ?last_comp_version?
fdt.c:68: error: ?const struct fdt_header? has no member named ?last_comp_version?
fdt.c:68: error: ?const struct fdt_header? has no member named ?last_comp_version?
fdt.c:70: error: ?const struct fdt_header? has no member named ?magic?
fdt.c:70: error: ?const struct fdt_header? has no member named ?magic?
fdt.c:70: error: ?const struct fdt_header? has no member named ?magic?
fdt.c:70: error: ?const struct fdt_header? has no member named ?magic?
fdt.c:70: error: ?const struct fdt_header? has no member named ?magic?
fdt.c:70: error: ?const struct fdt_header? has no member named ?magic?
fdt.c:72: error: ?const struct fdt_header? has no member named ?size_dt_struct?
fdt.c:72: error: ?const struct fdt_header? has no member named ?size_dt_struct?
fdt.c:72: error: ?const struct fdt_header? has no member named ?size_dt_struct?
fdt.c:72: error: ?const struct fdt_header? has no member named ?size_dt_struct?
fdt.c:72: error: ?const struct fdt_header? has no member named ?size_dt_struct?
fdt.c:72: error: ?const struct fdt_header? has no member named ?size_dt_struct?
fdt.c: In function ?fdt_offset_ptr?:
fdt.c:85: error: ?const struct fdt_header? has no member named ?version?
fdt.c:85: error: ?const struct fdt_header? has no member named ?version?
fdt.c:85: error: ?const struct fdt_header? has no member named ?version?
fdt.c:85: error: ?const struct fdt_header? has no member named ?version?
fdt.c:85: error: ?const struct fdt_header? has no member named ?version?
fdt.c:85: error: ?const struct fdt_header? has no member named ?version?
fdt.c:87: error: ?const struct fdt_header? has no member named ?size_dt_struct?
fdt.c:87: error: ?const struct fdt_header? has no member named ?size_dt_struct?
fdt.c:87: error: ?const struct fdt_header? has no member named ?size_dt_struct?
fdt.c:87: error: ?const struct fdt_header? has no member named ?size_dt_struct?
fdt.c:87: error: ?const struct fdt_header? has no member named ?size_dt_struct?
fdt.c:87: error: ?const struct fdt_header? has no member named ?size_dt_struct?
fdt.c: At top level:
fdt.c:97: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?fdt_next_tag?
fdt.c: In function ?fdt_move?:
fdt.c:155: error: ?const struct fdt_header? has no member named ?totalsize?
fdt.c:155: error: ?const struct fdt_header? has no member named ?totalsize?
fdt.c:155: error: ?const struct fdt_header? has no member named ?totalsize?
fdt.c:155: error: ?const struct fdt_header? has no member named ?totalsize?
fdt.c:155: error: ?const struct fdt_header? has no member named ?totalsize?
fdt.c:155: error: ?const struct fdt_header? has no member named ?totalsize?
fdt.c:158: error: ?const struct fdt_header? has no member named ?totalsize?
fdt.c:158: error: ?const struct fdt_header? has no member named ?totalsize?
fdt.c:158: error: ?const struct fdt_header? has no member named ?totalsize?
fdt.c:158: error: ?const struct fdt_header? has no member named ?totalsize?
fdt.c:158: error: ?const struct fdt_header? has no member named ?totalsize?
fdt.c:158: error: ?const struct fdt_header? has no member named ?totalsize?
make[1]: *** [fdt.o] Error 1
make[1]: Leaving directory `/home/hskinnemoen/git/u-boot/upstream/tools'
make: *** [tools] Error 2

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libmudflap --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Debian 4.2.3-2)

Haavard

[U-Boot-Users] RFC: make new image support mandatory

[Bartlomiej Sieka]

Haavard Skinnemoen wrote:
> On Wed, 26 Mar 2008 15:16:44 +0100
> Wolfgang Denk <wd@denx.de> wrote:
> 
>> Can we agree on this?
> 
> Can we please un-break the existing tree first?
> 
> gcc -g -Wall -idirafter /home/hskinnemoen/git/u-boot/upstream/include -idirafter /home/hskinnemoen/git/u-boot/upstream/include2 -idirafter /home/hskinnemoen/git/u-boot/upstream/include -DTEXT_BASE=0x00000000 -DUSE_HOSTCC -O -c -o fdt.o fdt.c
> In file included from fdt_host.h:24,
>                  from fdt.c:57:
> ../include/fdt.h:7: error: expected specifier-qualifier-list before ?uint32_t?
[...]
er named ?totalsize?
> fdt.c:158: error: ?const struct fdt_header? has no member named ?totalsize?
> make[1]: *** [fdt.o] Error 1
> make[1]: Leaving directory `/home/hskinnemoen/git/u-boot/upstream/tools'
> make: *** [tools] Error 2
> 
> $ gcc -v
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libmudflap --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
> Thread model: posix
> gcc version 4.2.3 (Debian 4.2.3-2)

Haavard,

What were the make invocations that let the above errors? I'll try to
reproduce this and have a look.

Regards,
Bartlomiej

[U-Boot-Users] RFC: make new image support mandatory

[Jerry Van Baren]

Bartlomiej Sieka wrote:
> Haavard Skinnemoen wrote:
>> On Wed, 26 Mar 2008 15:16:44 +0100
>> Wolfgang Denk <wd@denx.de> wrote:
>>
>>> Can we agree on this?
>> Can we please un-break the existing tree first?
>>
>> gcc -g -Wall -idirafter /home/hskinnemoen/git/u-boot/upstream/include -idirafter /home/hskinnemoen/git/u-boot/upstream/include2 -idirafter /home/hskinnemoen/git/u-boot/upstream/include -DTEXT_BASE=0x00000000 -DUSE_HOSTCC -O -c -o fdt.o fdt.c
>> In file included from fdt_host.h:24,
>>                  from fdt.c:57:
>> ../include/fdt.h:7: error: expected specifier-qualifier-list before ?uint32_t?
> [...]
> er named ?totalsize?
>> fdt.c:158: error: ?const struct fdt_header? has no member named ?totalsize?
>> make[1]: *** [fdt.o] Error 1
>> make[1]: Leaving directory `/home/hskinnemoen/git/u-boot/upstream/tools'
>> make: *** [tools] Error 2
>>
>> $ gcc -v
>> Using built-in specs.
>> Target: i486-linux-gnu
>> Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libmudflap --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
>> Thread model: posix
>> gcc version 4.2.3 (Debian 4.2.3-2)
> 
> Haavard,
> 
> What were the make invocations that let the above errors? I'll try to
> reproduce this and have a look.
> 
> Regards,
> Bartlomiej

Hi Bartlomiej,

I also am running debian and am getting the error.  Apparently our 
/usr/include/linux/types.h files are different from yours, or we have 
something set up differently/wrongly.

Adding -isystem ../include (to override the host's include files) to 
FIT_FLAGS "fixes" the problem.

--------------------------------------------------------------------
diff --git a/tools/Makefile b/tools/Makefile
index 8784a6d..9b2f6fa 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -124,7 +124,7 @@ CPPFLAGS   = -idirafter $(SRCTREE)/include \
  CFLAGS     = $(HOST_CFLAGS) $(CPPFLAGS) -O

  # No -pedantic switch to avoid libfdt compilation warnings
-FIT_CFLAGS = -Wall $(CPPFLAGS) -O
+FIT_CFLAGS = -Wall -isystem ../include $(CPPFLAGS) -O

  AFLAGS    = -D__ASSEMBLY__ $(CPPFLAGS)
  CC        = $(HOSTCC)
--------------------------------------------------------------------

I've also attached the diff between /usr/include/linux/types.h and 
u-boot's include/linux/types.h in case it is helpful.  Nothing jumps out 
at me.  :-/

Best regards,
gvb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: types.h.diff
Type: text/x-diff
Size: 2979 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080326/cc9c643f/attachment.diff 

[U-Boot-Users] RFC: make new image support mandatory

[Stefan Roese]

On Thursday 27 March 2008, Jerry Van Baren wrote:
> I also am running debian and am getting the error.  Apparently our
> /usr/include/linux/types.h files are different from yours, or we have
> something set up differently/wrongly.
>
> Adding -isystem ../include (to override the host's include files) to
> FIT_FLAGS "fixes" the problem.

I'm running Ubuntu and am getting this errors too. Even without
enabling CONFIG_FIT:

[stefan at ubuntu u-boot-ppc4xx (master)]$ ./MAKEALL sequoia
Configuring for sequoia board...
In file included from fdt_host.h:24,
                 from fdt.c:57:
../include/fdt.h:7: error: expected specifier-qualifier-list before ?uint32_t?
../include/fdt.h:26: error: expected specifier-qualifier-list before ?uint64_t?
../include/fdt.h:31: error: expected specifier-qualifier-list before ?uint32_t?
../include/fdt.h:36: error: expected specifier-qualifier-list before ?uint32_t?
In file included from fdt_host.h:25,
                 from fdt.c:57:
../include/libfdt.h:131: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?fdt_next_tag?
../include/libfdt.h:162: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_magic?:
../include/libfdt.h:162: error: ?struct fdt_header? has no member named ?magic?
../include/libfdt.h:162: error: ?val? undeclared (first use in this function)
../include/libfdt.h:162: error: (Each undeclared identifier is reported only once
../include/libfdt.h:162: error: for each function it appears in.)
../include/libfdt.h: At top level:
../include/libfdt.h:163: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_totalsize?:
../include/libfdt.h:163: error: ?struct fdt_header? has no member named ?totalsize?
../include/libfdt.h:163: error: ?val? undeclared (first use in this function)
../include/libfdt.h: At top level:
../include/libfdt.h:164: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_off_dt_struct?:
../include/libfdt.h:164: error: ?struct fdt_header? has no member named ?off_dt_struct?
../include/libfdt.h:164: error: ?val? undeclared (first use in this function)
../include/libfdt.h: At top level:
../include/libfdt.h:165: error: expected declaration specifiers or ?...? before ?uint32_t?
../include/libfdt.h: In function ?fdt_set_off_dt_strings?:
../include/libfdt.h:165: error: ?struct fdt_header? has no member named ?off_dt_strings?

....


Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] RFC: make new image support mandatory

[Liu Dave]

> 
> I'm running Ubuntu and am getting this errors too. Even without
> enabling CONFIG_FIT:

When I build MPC8360EMDS/MPC837XEMDS on Ubuntu, the same error
happen to me. 

Thanks,
Dave

[U-Boot-Users] RFC: make new image support mandatory

[Wolfgang Denk]

In message <58A20A281BAF1047B4EAE68DE5C0BDC2DD833B@zch01exm21.fsl.freescale.net> you wrote:
> PiANCj4gSSdtIHJ1bm5pbmcgVWJ1bnR1IGFuZCBhbSBnZXR0aW5nIHRoaXMgZXJyb3JzIHRvby4g
> RXZlbiB3aXRob3V0DQo+IGVuYWJsaW5nIENPTkZJR19GSVQ6DQoNCldoZW4gSSBidWlsZCBNUEM4
> MzYwRU1EUy9NUEM4MzdYRU1EUyBvbiBVYnVudHUsIHRoZSBzYW1lIGVycm9yDQpoYXBwZW4gdG8g
> bWUuIA0KDQpUaGFua3MsDQpEYXZlDQo=
> 

Please do not send base 64 encoded messages.

Please send plain text only.

Message unreadable, ignored. Sorry.

[U-Boot-Users] RFC: make new image support mandatory

[Dave Liu]

> I'm running Ubuntu and am getting this errors too. Even without
> enabling CONFIG_FIT:

When I build the MPC837XEMDS/MPC8360EMDS on Ubuntu, I happen the same
error.

[U-Boot-Users] RFC: make new image support mandatory

[Haavard Skinnemoen]

On Wed, 26 Mar 2008 15:16:44 +0100
Wolfgang Denk <wd@denx.de> wrote:

> now that the new image  format  has  been  merged  into  mainline,  I
> propose  that  we  make it mandatory for all newly added boards. That
> means, that each new board that gets added shall at least contain
> 
> 	#define CONFIG_FIT              1
> 
> in it's board config file; I recommend to add also
> 
> 	#define CONFIG_FIT_VERBOSE      1 /* enable fit_format_{error,warning}() */
> 
> 
> Can we agree on this?

Oh my...

Configuring for atstk1002 board...
   text	   data	    bss	    dec	    hex	filename
 112936	   8032	 216860	 337828	  527a4	./u-boot

with CONFIG_FIT and CONFIG_OF_LIBFDT enabled, compared to

   text	   data	    bss	    dec	    hex	filename
  87724	   6840	 215848	 310412	  4bc8c	./u-boot

on v1.3.2. That's 26KB...do we really want to make something _that_
expensive mandatory? Or can I somehow disable the old code to reclaim
some of it?

Haavard

[U-Boot-Users] RFC: make new image support mandatory

[Bartlomiej Sieka]

Haavard Skinnemoen wrote:
> On Wed, 26 Mar 2008 15:16:44 +0100
> Wolfgang Denk <wd@denx.de> wrote:
> 
>> now that the new image  format  has  been  merged  into  mainline,  I
>> propose  that  we  make it mandatory for all newly added boards. That
>> means, that each new board that gets added shall at least contain
>>
>> 	#define CONFIG_FIT              1
>>
>> in it's board config file; I recommend to add also
>>
>> 	#define CONFIG_FIT_VERBOSE      1 /* enable fit_format_{error,warning}() */
>>
>>
>> Can we agree on this?
> 
> Oh my...
> 
> Configuring for atstk1002 board...
>    text	   data	    bss	    dec	    hex	filename
>  112936	   8032	 216860	 337828	  527a4	./u-boot
> 
> with CONFIG_FIT and CONFIG_OF_LIBFDT enabled, compared to
> 
>    text	   data	    bss	    dec	    hex	filename
>   87724	   6840	 215848	 310412	  4bc8c	./u-boot

BTW: were you able to compile the tools/ directory for the above board?
If yes, what were the differences versus the failing build you posted in
your other email?

> 
> on v1.3.2. That's 26KB...do we really want to make something _that_
> expensive mandatory? Or can I somehow disable the old code to reclaim
> some of it?

There's no easy way to disable support for the old format currently.

Regards,
Bartlomiej

[U-Boot-Users] RFC: make new image support mandatory

[Haavard Skinnemoen]

On Wed, 26 Mar 2008 17:31:40 +0100
Bartlomiej Sieka <tur@semihalf.com> wrote:

> BTW: were you able to compile the tools/ directory for the above board?
> If yes, what were the differences versus the failing build you posted in
> your other email?

Ah, sorry. I sent a patch, but didn't realize it went only to Wolfgang.
Here it is.

Haavard

[U-Boot-Users] RFC: make new image support mandatory

[Stefan Roese]

On Thursday 27 March 2008, Haavard Skinnemoen wrote:
> > BTW: were you able to compile the tools/ directory for the above board?
> > If yes, what were the differences versus the failing build you posted in
> > your other email?
>
> Ah, sorry. I sent a patch, but didn't realize it went only to Wolfgang.
> Here it is.
>
> Haavard
>
> >From b69cca7525e66808fed7fcd04e74900a2fb6db91 Mon Sep 17 00:00:00 2001
>
> From: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
> Date: Wed, 26 Mar 2008 16:56:12 +0100
> Subject: [PATCH] Fix host tool build breakage
>
> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>

This fixes the problem for me too. Thanks.

Acked-by: Stefan Roese <sr@denx.de>

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] RFC: make new image support mandatory

[Roy Zang]

Before applying this patch, I encounter the same issue as Stefan on
mpc8544 and mpc8548 boards.
After applying this patch, they are OK.
This patch should be applied ASAP, which affetcs boundle of boards.
Roy
On Thu, 2008-03-27 at 17:01 +0800, Stefan Roese wrote:
> On Thursday 27 March 2008, Haavard Skinnemoen wrote: 
> > > BTW: were you able to compile the tools/ directory for the above
> board? 
> > > If yes, what were the differences versus the failing build you
> posted in 
> > > your other email? 
> > 
> > Ah, sorry. I sent a patch, but didn't realize it went only to
> Wolfgang. 
> > Here it is. 
> > 
> > Haavard 
> > 
> > >From b69cca7525e66808fed7fcd04e74900a2fb6db91 Mon Sep 17 00:00:00
> 2001 
> > 
> > From: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> 
> > Date: Wed, 26 Mar 2008 16:56:12 +0100 
> > Subject: [PATCH] Fix host tool build breakage 
> > 
> > Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
> 
> This fixes the problem for me too. Thanks.
> 
> Acked-by: Stefan Roese <sr@denx.de>
> 
> Best regards, 
> Stefan
> 
> ===================================================================== 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel 
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany 
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de 
> =====================================================================
> 
> ------------------------------------------------------------------------- 
> Check out the new SourceForge.net Marketplace. 
> It's the best place to buy or sell services for 
> just about anything Open Source. 
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace 
> _______________________________________________ 
> U-Boot-Users mailing list 
> U-Boot-Users at lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 

[U-Boot-Users] RFC: make new image support mandatory

[Markus Klotzbücher]

Stefan Roese <sr@denx.de> writes:

> On Thursday 27 March 2008, Haavard Skinnemoen wrote:
>> > BTW: were you able to compile the tools/ directory for the above board?
>> > If yes, what were the differences versus the failing build you posted in
>> > your other email?
>>
>> Ah, sorry. I sent a patch, but didn't realize it went only to Wolfgang.
>> Here it is.
>>
>> Haavard
>>
>> >From b69cca7525e66808fed7fcd04e74900a2fb6db91 Mon Sep 17 00:00:00 2001
>>
>> From: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
>> Date: Wed, 26 Mar 2008 16:56:12 +0100
>> Subject: [PATCH] Fix host tool build breakage
>>
>> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
>
> This fixes the problem for me too. Thanks.
>
> Acked-by: Stefan Roese <sr@denx.de>

Me too.

Acked-by: Markus Klotzbuecher <mk@denx.de>

Best regards

Markus Klotzbuecher

--
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de

[U-Boot-Users] RFC: make new image support mandatory

[Dave Liu]

> Ah, sorry. I sent a patch, but didn't realize it went only to Wolfgang.
> Here it is.

Thanks, the patch works for me.

[U-Boot-Users] RFC: make new image support mandatory

[Bartlomiej Sieka]

Haavard Skinnemoen wrote:
> On Wed, 26 Mar 2008 17:31:40 +0100
> Bartlomiej Sieka <tur@semihalf.com> wrote:
> 
>> BTW: were you able to compile the tools/ directory for the above board?
>> If yes, what were the differences versus the failing build you posted in
>> your other email?
> 
> Ah, sorry. I sent a patch, but didn't realize it went only to Wolfgang.
> Here it is.

Haavard,

This patch breaks build on FC. I'm about to send another patch that
will hopefully restore the build for everyone.

Regards,
Bartlomiej

[U-Boot-Users] RFC: make new image support mandatory

[Luigi 'Comio' Mantellini]

Hi Bartlomiej,

I posted a week ago some considerations about the new image format (with
subject ?"?[U-Boot-Users] New Image format: headers hashes."). Please,
can you give an your opinion about these consideration? I'm really
interested to support new image in my firmwares, but I need to
understand if the new format is "robust" respect to the accidental
errors.

Thanks a lot for your work and your answers on the ml.

Ciao

luigi
?

-- 
     ______       Luigi Mantellini
   .'______'.     R&D - Software
  (.'      '.)    Industrie Dial Face S.p.A.
  ( :=----=: )    Via Canzo, 4
  ('.______.')    20068 Peschiera Borromeo (MI), Italy
   '.______.'     Tel.: +39 02 5167 2813
                  Fax:  +39 02 5167 2459
Ind.  Dial Face   Email: luigi.mantellini at idf-hit.com
www.idf-hit.com   GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
                                   B003 175F E979 907E 1650



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080401/9287a5d6/attachment.htm 

[U-Boot-Users] RFC: make new image support mandatory

[Bartlomiej Sieka]

Luigi 'Comio' Mantellini wrote:
> Hi Bartlomiej,
> 
> I posted a week ago some considerations about the new image format (with
> subject "[U-Boot-Users] New Image format: headers hashes."). Please,
> can you give an your opinion about these consideration? I'm really
> interested to support new image in my firmwares, but I need to
> understand if the new format is "robust" respect to the accidental
> errors.
> 
> Thanks a lot for your work and your answers on the ml.

Hi Luigi,

Sorry for being slow to respond -- I'm processing ML comments on the new
image, and will reply to your postings today/tomorrow.

Regards,
Bartlomiej

[U-Boot-Users] RFC: make new image support mandatory

[Guennadi Liakhovetski]

On Wed, 26 Mar 2008, Haavard Skinnemoen wrote:

> On Wed, 26 Mar 2008 15:16:44 +0100
> Wolfgang Denk <wd@denx.de> wrote:
> 
> > now that the new image  format  has  been  merged  into  mainline,  I
> > propose  that  we  make it mandatory for all newly added boards. That
> > means, that each new board that gets added shall at least contain
> > 
> > 	#define CONFIG_FIT              1
> > 
> > in it's board config file; I recommend to add also
> > 
> > 	#define CONFIG_FIT_VERBOSE      1 /* enable fit_format_{error,warning}() */
> > 
> > 
> > Can we agree on this?
> 
> Oh my...
> 
> Configuring for atstk1002 board...
>    text	   data	    bss	    dec	    hex	filename
>  112936	   8032	 216860	 337828	  527a4	./u-boot
> 
> with CONFIG_FIT and CONFIG_OF_LIBFDT enabled, compared to
> 
>    text	   data	    bss	    dec	    hex	filename
>   87724	   6840	 215848	 310412	  4bc8c	./u-boot
> 
> on v1.3.2. That's 26KB...do we really want to make something _that_
> expensive mandatory? Or can I somehow disable the old code to reclaim
> some of it?

I'm getting 34KB increase iin the resulting binary just by enabling the 
required for FIT config macros in an arm11 build with the current git 
HEAD. Which is almost 30% increase... Sorry, I didn't follow the "new 
format" discussion, is it also going to be useful on ARM and on other 
platforms not using FDT?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de

[U-Boot-Users] RFC: make new image support mandatory

[Wolfgang Denk]

In message <Pine.LNX.4.64.0803262132010.5050@axis700.grange> you wrote:
>
> I'm getting 34KB increase iin the resulting binary just by enabling the 
> required for FIT config macros in an arm11 build with the current git 

We need to check where this size penalty is  coming  from.  It's  not
supposed top be that big.

> HEAD. Which is almost 30% increase... Sorry, I didn't follow the "new 
> format" discussion, is it also going to be useful on ARM and on other 
> platforms not using FDT?

Yes, it is useful for all architectures.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Q:  How many DEC repairman does it take to fix a flat ?
A:  Five; four to hold the car up and one to swap tires.

[U-Boot-Users] RFC: make new image support mandatory

[Shinya Kuribayashi]

Guennadi Liakhovetski wrote:
> HEAD. Which is almost 30% increase... Sorry, I didn't follow the "new 
> format" discussion, is it also going to be useful on ARM and on other 
> platforms not using FDT?

As MIPS custodian I feel the same, too.

I'm just wondering, if this feature is useful for all architectures
and you say it's mandaroty, why not defining it in <common.h> or so?

If you make it selectable, I hope we could build existing targets
without CONFIG_FIT.

  Shinya

[U-Boot-Users] RFC: make new image support mandatory

[Jerry Van Baren]

Haavard Skinnemoen wrote:
> On Wed, 26 Mar 2008 15:16:44 +0100
> Wolfgang Denk <wd@denx.de> wrote:
> 
>> now that the new image  format  has  been  merged  into  mainline,  I
>> propose  that  we  make it mandatory for all newly added boards. That
>> means, that each new board that gets added shall at least contain
>>
>> 	#define CONFIG_FIT              1
>>
>> in it's board config file; I recommend to add also
>>
>> 	#define CONFIG_FIT_VERBOSE      1 /* enable fit_format_{error,warning}() */
>>
>>
>> Can we agree on this?
> 
> Oh my...
> 
> Configuring for atstk1002 board...
>    text	   data	    bss	    dec	    hex	filename
>  112936	   8032	 216860	 337828	  527a4	./u-boot
> 
> with CONFIG_FIT and CONFIG_OF_LIBFDT enabled, compared to
> 
>    text	   data	    bss	    dec	    hex	filename
>   87724	   6840	 215848	 310412	  4bc8c	./u-boot
> 
> on v1.3.2. That's 26KB...do we really want to make something _that_
> expensive mandatory? Or can I somehow disable the old code to reclaim
> some of it?
> 
> Haavard

On a PowerPC target that includes libfdt already...

Configuring for MPC8360EMDS board with CONFIG_FIT:

    text	   data	    bss	    dec	    hex	filename
  231588	  12072	  26836	 270496	  420a0	./u-boot

without CONFIG_FIT:

    text	   data	    bss	    dec	    hex	filename
  211648	  11604	  26796	 250048	  3d0c0	./u-boot

delta text = 19940 (19.5K).  Still pretty heavy.  :-/  I have not looked 
at where the weight is coming from, just thought it would be interesting 
to see what the delta looked like when libfdt was already included.  I 
was expecting a bigger hit from libfdt and less from FIT.  Hmmmm.

Best regards,
gvb

[U-Boot-Users] RFC: make new image support mandatory

[Jean-Christophe PLAGNIOL-VILLARD]

On 15:16 Wed 26 Mar     , Wolfgang Denk wrote:
> Hello everybody,
> 
> now that the new image  format  has  been  merged  into  mainline,  I
> propose  that  we  make it mandatory for all newly added boards. That
> means, that each new board that gets added shall at least contain

I'll personnaly do it in the next merge windows. I'll prefer to have a
better hindsight on the new image format before used as default.

Best Regards,
J.