[Buildroot] [PATCH 0/2] add u-boot.sb file format and elftosb tools

[Buildroot] [PATCH 0/2] add u-boot.sb file format and elftosb tools

[Eric Jarrige]

These patches add support for the Freescale "Safe Boot" file format:
- add elftosb host tools to package the .sb binary files 
- add u-boot.sb binary format in BR menuconfig

Eric Jarrige (2):
  Add (Freescale) elftosb host package
  u-boot: add support for u-boot.sb file format

 boot/uboot/Config.in                               |    3 ++
 boot/uboot/uboot.mk                                |    4 +++
 package/elftosb/elftosb.mk                         |   28 ++++++++++++++++++++
 .../elftosb/elftosb10.12.01-fixes_includes.patch   |   19 +++++++++++++
 4 files changed, 54 insertions(+), 0 deletions(-)
 create mode 100644 package/elftosb/elftosb.mk
 create mode 100644 package/elftosb/elftosb10.12.01-fixes_includes.patch

-- 
1.7.2.5

[Buildroot] [PATCH 1/2] Add (Freescale) elftosb host package

[Eric Jarrige]

Elftosb is a Freescale toolset to build binary image files (like U-Boot.sb)
to be used with CPUs imx23, imx28, stp37xx

Signed-off-by: Eric Jarrige <eric.jarrige@armadeus.org>
---
 package/elftosb/elftosb.mk                         |   28 ++++++++++++++++++++
 .../elftosb/elftosb10.12.01-fixes_includes.patch   |   19 +++++++++++++
 2 files changed, 47 insertions(+), 0 deletions(-)
 create mode 100644 package/elftosb/elftosb.mk
 create mode 100644 package/elftosb/elftosb10.12.01-fixes_includes.patch

diff --git a/package/elftosb/elftosb.mk b/package/elftosb/elftosb.mk
new file mode 100644
index 0000000..75b95a5
--- /dev/null
+++ b/package/elftosb/elftosb.mk
@@ -0,0 +1,28 @@
+#############################################################
+#
+# elftosb
+#
+#############################################################
+ELFTOSB_VERSION = 10.12.01
+ELFTOSB_SOURCE = elftosb-$(ELFTOSB_VERSION).tar.gz
+ELFTOSB_SITE = http://repository.timesys.com/buildsources/e/elftosb/elftosb-$(ELFTOSB_VERSION)
+
+define HOST_ELFTOSB_BUILD_CMDS
+	$(HOST_MAKE_ENV) $(MAKE) -C $(@D) all
+endef
+
+define HOST_ELFTOSB_INSTALL_CMDS
+	$(INSTALL) -D $(@D)/bld/linux/elftosb $(HOST_DIR)/usr/bin/elftosb
+	$(INSTALL) -D $(@D)/bld/linux/keygen $(HOST_DIR)/usr/bin/keygen
+	$(INSTALL) -D $(@D)/bld/linux/sbtool $(HOST_DIR)/usr/bin/sbtool
+endef
+
+define HOST_ELFTOSB_CLEAN_CMDS
+	rm -rf $(@D)/bld/linux
+	rm -f $(HOST_DIR)/usr/bin/elftosb
+	rm -f $(HOST_DIR)/usr/bin/keygen
+	rm -f $(HOST_DIR)/usr/bin/sbtool
+endef
+
+$(eval $(call GENTARGETS,host))
+
diff --git a/package/elftosb/elftosb10.12.01-fixes_includes.patch b/package/elftosb/elftosb10.12.01-fixes_includes.patch
new file mode 100644
index 0000000..eaf8eba
--- /dev/null
+++ b/package/elftosb/elftosb10.12.01-fixes_includes.patch
@@ -0,0 +1,19 @@
+This patch uses system include files instead of a hard coded system path to fixe
+potential compilation failure on systems that do not populate system header
+files in /usr/include/..
+
+Signed-off-by: Eric Jarrige <eric.jarrige@armadeus.org>
+---
+Index: host-elftosb-10.12.01/common/stdafx.h
+===================================================================
+--- host-elftosb-10.12.01.orig/common/stdafx.h	2012-01-30 12:43:35.000000000 +0100
++++ host-elftosb-10.12.01/common/stdafx.h	2012-01-30 12:43:54.000000000 +0100
+@@ -27,7 +27,7 @@
+ // For Linux systems only, types.h only defines the signed
+ // integer types.  This is not professional code.
+ // Update: They are defined in the header files in the more recent version of redhat enterprise gcc.
+-#include "/usr/include/sys/types.h"
++#include <sys/types.h>
+ #include <stdint.h>
+ //typedef unsigned long uint32_t;
+ //typedef unsigned short uint16_t;
-- 
1.7.2.5

[Buildroot] [PATCH 2/2] u-boot: add support for u-boot.sb file format

[Eric Jarrige]

add u-boot.sb binary format in BR menuconfig - Safe Boot (.sb) file format
have to be used with Freescale CPUs like imx23, imx28, stp37xx

Signed-off-by: Eric Jarrige <eric.jarrige@armadeus.org>
---
 boot/uboot/Config.in |    3 +++
 boot/uboot/uboot.mk  |    4 ++++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in
index c8db9fb..5fd5258 100644
--- a/boot/uboot/Config.in
+++ b/boot/uboot/Config.in
@@ -90,6 +90,9 @@ config BR2_TARGET_UBOOT_FORMAT_LDR
 	depends on BR2_bfin
 	bool "u-boot.ldr"
 
+config BR2_TARGET_UBOOT_FORMAT_SB
+	bool "u-boot.sb"
+
 endchoice
 
 menuconfig BR2_TARGET_UBOOT_NETWORK
diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
index db9de8d..1394400 100644
--- a/boot/uboot/uboot.mk
+++ b/boot/uboot/uboot.mk
@@ -29,6 +29,10 @@ else ifeq ($(BR2_TARGET_UBOOT_FORMAT_LDR),y)
 UBOOT_BIN          = u-boot.ldr
 else ifeq ($(BR2_TARGET_UBOOT_FORMAT_NAND_BIN),y)
 UBOOT_BIN          = u-boot-nand.bin
+else ifeq ($(BR2_TARGET_UBOOT_FORMAT_SB),y)
+UBOOT_DEPENDENCIES += host-elftosb
+UBOOT_BIN          = u-boot.sb
+UBOOT_MAKE_TARGET  = $(UBOOT_BIN)
 else
 UBOOT_BIN          = u-boot.bin
 endif
-- 
1.7.2.5

[Buildroot] [PATCH 2/2] u-boot: add support for u-boot.sb file format

[Thomas Petazzoni]

Le Tue, 13 Mar 2012 13:52:11 +0100,
Eric Jarrige <eric.jarrige@armadeus.org> a ?crit :

> add u-boot.sb binary format in BR menuconfig - Safe Boot (.sb) file
> format have to be used with Freescale CPUs like imx23, imx28, stp37xx

Forgive my ignorance about this .sb format, but does U-Boot
automatically uses the elftosb tool? I don't see it being directly used
in your patch, so I'm confused.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 2/2] u-boot: add support for u-boot.sb file format

[Eric Jarrige]

Hi Thomas,

On 13 mars 2012, at 15:17, Thomas Petazzoni wrote:

> Forgive my ignorance about this .sb format, but does U-Boot
> automatically uses the elftosb tool? I don't see it being directly used
> in your patch, so I'm confused.

That's it. when asked to build the u-boot.sb build target (make 
u-boot.sb) U-Boot automatically call the elftosb tool to finalize the Safe
Boot build process. So this tool should already be accessible through 
the system PATH. I mean U-Boot assumes this tool to be installed on
the host environment. The link is done in patch by changing the
UBOOT_MAKE_TARGET.

Eric

[Buildroot] [PATCH 2/2] u-boot: add support for u-boot.sb file format

[Thomas Petazzoni]

Hello,

Le Tue, 13 Mar 2012 15:52:51 +0100,
Eric Jarrige <eric.jarrige@armadeus.org> a ?crit :

> That's it. when asked to build the u-boot.sb build target (make 
> u-boot.sb) U-Boot automatically call the elftosb tool to finalize the
> Safe Boot build process. So this tool should already be accessible
> through the system PATH. I mean U-Boot assumes this tool to be
> installed on the host environment. The link is done in patch by
> changing the UBOOT_MAKE_TARGET.

Ok, thanks for those details. Sounds good.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/2] Add (Freescale) elftosb host package

[Thomas Petazzoni]

Le Tue, 13 Mar 2012 13:52:10 +0100,
Eric Jarrige <eric.jarrige@armadeus.org> a ?crit :

> Elftosb is a Freescale toolset to build binary image files (like
> U-Boot.sb) to be used with CPUs imx23, imx28, stp37xx
> 
> Signed-off-by: Eric Jarrige <eric.jarrige@armadeus.org>

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 2/2] u-boot: add support for u-boot.sb file format

[Thomas Petazzoni]

Le Tue, 13 Mar 2012 13:52:11 +0100,
Eric Jarrige <eric.jarrige@armadeus.org> a ?crit :

> add u-boot.sb binary format in BR menuconfig - Safe Boot (.sb) file
> format have to be used with Freescale CPUs like imx23, imx28, stp37xx
> 
> Signed-off-by: Eric Jarrige <eric.jarrige@armadeus.org>

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/2] Add (Freescale) elftosb host package

[Arnout Vandecappelle]

On Tuesday 13 March 2012 13:52:10 Eric Jarrige wrote:
> +define HOST_ELFTOSB_CLEAN_CMDS
> +       rm -rf $(@D)/bld/linux
> +       rm -f $(HOST_DIR)/usr/bin/elftosb
> +       rm -f $(HOST_DIR)/usr/bin/keygen
> +       rm -f $(HOST_DIR)/usr/bin/sbtool
> +endef

 These look like UNINSTALL commands, not CLEAN commands.

 Not that it's terribly important.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 1/2] Add (Freescale) elftosb host package

[Thomas Petazzoni]

Hello,

Le Wed, 14 Mar 2012 01:05:44 +0100,
Arnout Vandecappelle <arnout@mind.be> a ?crit :

> On Tuesday 13 March 2012 13:52:10 Eric Jarrige wrote:
> > +define HOST_ELFTOSB_CLEAN_CMDS
> > +       rm -rf $(@D)/bld/linux
> > +       rm -f $(HOST_DIR)/usr/bin/elftosb
> > +       rm -f $(HOST_DIR)/usr/bin/keygen
> > +       rm -f $(HOST_DIR)/usr/bin/sbtool
> > +endef
> 
>  These look like UNINSTALL commands, not CLEAN commands.

Ah right. Actually the first line should be part of CLEAN commands, and
the three last lines should be part of the UNINSTALL commands.

Are they people who actually care about those CLEAN and UNINSTALL
commands? Is it worth keeping support for them?

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/2] Add (Freescale) elftosb host package

[Luca Ceresoli]

Thomas Petazzoni wrote:
> Hello,
>
> Le Wed, 14 Mar 2012 01:05:44 +0100,
> Arnout Vandecappelle<arnout@mind.be>  a ?crit :
>
>> On Tuesday 13 March 2012 13:52:10 Eric Jarrige wrote:
>>> +define HOST_ELFTOSB_CLEAN_CMDS
>>> +       rm -rf $(@D)/bld/linux
>>> +       rm -f $(HOST_DIR)/usr/bin/elftosb
>>> +       rm -f $(HOST_DIR)/usr/bin/keygen
>>> +       rm -f $(HOST_DIR)/usr/bin/sbtool
>>> +endef
>>   These look like UNINSTALL commands, not CLEAN commands.
> Ah right. Actually the first line should be part of CLEAN commands, and
> the three last lines should be part of the UNINSTALL commands.
>
> Are they people who actually care about those CLEAN and UNINSTALL
> commands? Is it worth keeping support for them?

IIRC these targets cannot in general work correctly with the Buildroot
structure, and making them work would require a massive change, with a
big increase in complexity.

Moreover, many packages do not implement the CLEAN and UNINSTALL targets:

$ git grep -l GENTARGETS package/|grep -E '^package/[a-z]'|wc -l
111
$ git grep -l GENTARGETS package/|grep -E '^package/[a-z]'| \
     xargs grep -l '_CLEAN_CMDS'|wc -l
51
$ git grep -l GENTARGETS package/|grep -E '^package/[a-z]'| \
     xargs grep -l '_UNINSTALL_.*_CMDS'|wc -l
73

meaning that probably they are not so interesting to everybody out there.

As for me, I have never been relying on them. I prefer to distclean and
rebuild when necessary. It's reliable, and not that painful with a
reasonably recent build machine and ccache enabled.

So, my vote for dropping them.
(Or should there be a specific thread for this topic?)

Luca

[Buildroot] [PATCH 1/2] Add (Freescale) elftosb host package

[Thomas Petazzoni]

Le Wed, 14 Mar 2012 12:11:21 +0100,
Luca Ceresoli <luca@lucaceresoli.net> a ?crit :

> IIRC these targets cannot in general work correctly with the Buildroot
> structure, and making them work would require a massive change, with a
> big increase in complexity.
> 
> Moreover, many packages do not implement the CLEAN and UNINSTALL targets:
> 
> $ git grep -l GENTARGETS package/|grep -E '^package/[a-z]'|wc -l
> 111
> $ git grep -l GENTARGETS package/|grep -E '^package/[a-z]'| \
>      xargs grep -l '_CLEAN_CMDS'|wc -l
> 51
> $ git grep -l GENTARGETS package/|grep -E '^package/[a-z]'| \
>      xargs grep -l '_UNINSTALL_.*_CMDS'|wc -l
> 73
> 
> meaning that probably they are not so interesting to everybody out there.
> 
> As for me, I have never been relying on them. I prefer to distclean and
> rebuild when necessary. It's reliable, and not that painful with a
> reasonably recent build machine and ccache enabled.
> 
> So, my vote for dropping them.
> (Or should there be a specific thread for this topic?)

I definitely agree with you here. If they exist, then they should be
reliable. But I'm not sure it's going to be easy to make them fully
reliable. And then can be dangerous, because they are not recursive:
you can remove a given library without removing the other libraries or
applications that depend on it.

So I would also vote for dropping them. But we should then also drop it
from AUTOTARGETS/CMAKETARGETS packages.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Remove clean and uninstall targets [was: Re: [PATCH 1/2] Add (Freescale) elftosb host package]

[Arnout Vandecappelle]

On Wednesday 14 March 2012 12:11:21 Luca Ceresoli wrote:
> Moreover, many packages do not implement the CLEAN and UNINSTALL targets:
> 
> $ git grep -l GENTARGETS package/|grep -E '^package/[a-z]'|wc -l
> 111
> $ git grep -l GENTARGETS package/|grep -E '^package/[a-z]'| \
>      xargs grep -l '_CLEAN_CMDS'|wc -l
> 51
> $ git grep -l GENTARGETS package/|grep -E '^package/[a-z]'| \
>      xargs grep -l '_UNINSTALL_.*_CMDS'|wc -l
> 73
> 
> meaning that probably they are not so interesting to everybody out there.

 Uninstall doesn't really work, as Thomas pointed out, so I'm all for 
removing it.

 For the clean target I can imagine a use case, but it's not very
convincing.  Say you're preparing a package patch the painful way 
(i.e. save a copy the source tree, modify the files of the source tree, 
and if all is well run a diff).  Then you may have some modifications 
which are not detected by make (e.g. when you're actually editing the 
Makefile).  So you want to run a make clean.  make foo-dirclean is not
possible because then you loose your changes.  This is where a clean
target could be useful.

 However, it's such a corner case that I don't think it's important.
And if you're hacking away at a package, you can afford to run
'make -C output/build/foo-0.1 clean' manually.


 Removing the clean and uninstall targets will make tab completion
slightly faster as well :-)


 So let's get rid of them!


 Regards,
 Arnout


-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Remove clean and uninstall targets [was: Re: [PATCH 1/2] Add (Freescale) elftosb host package]

[Thomas Petazzoni]

Le Thu, 15 Mar 2012 22:06:34 +0100,
Arnout Vandecappelle <arnout@mind.be> a ?crit :

>  Uninstall doesn't really work, as Thomas pointed out, so I'm all for 
> removing it.
> 
>  For the clean target I can imagine a use case, but it's not very
> convincing.  Say you're preparing a package patch the painful way 
> (i.e. save a copy the source tree, modify the files of the source tree, 
> and if all is well run a diff).  Then you may have some modifications 
> which are not detected by make (e.g. when you're actually editing the 
> Makefile).  So you want to run a make clean.  make foo-dirclean is not
> possible because then you loose your changes.  This is where a clean
> target could be useful.
> 
>  However, it's such a corner case that I don't think it's important.
> And if you're hacking away at a package, you can afford to run
> 'make -C output/build/foo-0.1 clean' manually.

Or, better, you can do:

	make <pkg>-rebuild

Why would you need to do a 'make clean'? If you did some changes in the
package source code, running 'make' is sufficient to get things
rebuilt, unless the package has a broken build system, no?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Remove clean and uninstall targets [was: Re: [PATCH 1/2] Add (Freescale) elftosb host package]

[Arnout Vandecappelle]

On Thursday 15 March 2012 22:28:13 Thomas Petazzoni wrote:
> Or, better, you can do:
> 
>         make <pkg>-rebuild
> 
> Why would you need to do a 'make clean'? If you did some changes in the
> package source code, running 'make' is sufficient to get things
> rebuilt, unless the package has a broken build system, no?

 For instance, modifying a Makefile to add a '-DFOO' to CFLAGS usually
doesn't force recompilation of all C files.

 But as I said, it's really a corner case.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F