[Buildroot] [PATCH 1/9] Typo fix in toolchain/external-toolchain/ext-tool.mk

[Buildroot] [PATCH 1/9] Typo fix in toolchain/external-toolchain/ext-tool.mk

[Grant Likely]

From: Grant Likely <grant.likely@secretlab.ca>

Comment block header documentation typo
---

 toolchain/external-toolchain/ext-tool.mk |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/toolchain/external-toolchain/ext-tool.mk b/toolchain/external-toolchain/ext-tool.mk
index a830329..bbf430c 100644
--- a/toolchain/external-toolchain/ext-tool.mk
+++ b/toolchain/external-toolchain/ext-tool.mk
@@ -3,7 +3,7 @@
 #
 # $1: source
 # $2: destination
-# $2: strip (y|n)       default is to strip
+# $3: strip (y|n)       default is to strip
 #
 copy_toolchain_lib_root = \
 	LIB="$(strip $1)"; \

[Buildroot] [PATCH 2/9] Fix link flags of mtdutils

[Grant Likely]

From: Grant Likely <grant.likely@secretlab.ca>

The mtd makefile fragment doesn't specify LDFLAGS.  This can cause the
linking to fail when trying to find libz if using an external toolchain
---

 package/mtd/mtd-utils/mtd.mk |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)


diff --git a/package/mtd/mtd-utils/mtd.mk b/package/mtd/mtd-utils/mtd.mk
index 86acc93..fdf256e 100644
--- a/package/mtd/mtd-utils/mtd.mk
+++ b/package/mtd/mtd-utils/mtd.mk
@@ -97,6 +97,7 @@ MTD_BUILD_TARGETS := $(addprefix $(MTD_DIR)/, $(MTD_TARGETS_y))
 $(MTD_BUILD_TARGETS): $(MTD_DIR)/.unpacked
 	mkdir -p $(TARGET_DIR)/usr/sbin
 	$(MAKE) CFLAGS="-I. -I./include -I$(LINUX_HEADERS_DIR)/include -I$(STAGING_DIR)/usr/include $(TARGET_CFLAGS)" \
+		LDFLAGS="$(TARGET_LDFLAGS)" \
 		BUILDDIR=$(MTD_DIR) \
 		CROSS=$(TARGET_CROSS) CC=$(TARGET_CC) LINUXDIR=$(LINUX26_DIR) WITHOUT_XATTR=1 -C $(MTD_DIR)
 

[Buildroot] [PATCH 2/9] Fix link flags of mtdutils

[Thomas Petazzoni]

Le Thu, 16 Oct 2008 14:32:25 -0600,
Grant Likely <grant.likely@secretlab.ca> a ?crit :

> The mtd makefile fragment doesn't specify LDFLAGS.  This can cause the
> linking to fail when trying to find libz if using an external
> toolchain

This is a problem I also face with many other packages (libpng,
directfb, etc.). So I've proposed another, more radical patch:

http://buildroot.uclibc.org/lists/buildroot/2008-October/011017.html

Sadly, I didn't get any feedback about it.

Sincerly,

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

[Buildroot] [PATCH 2/9] Fix link flags of mtdutils

[hartleys]

On Thursday, October 16, 2008 1:52 PM, Thomas Petazzoni wrote:
>> The mtd makefile fragment doesn't specify LDFLAGS.  This can cause
>> the linking to fail when trying to find libz if using an external 
>> toolchain
>
> This is a problem I also face with many other packages (libpng,
> directfb, etc.). So I've proposed another, more radical patch:
>
> http://buildroot.uclibc.org/lists/buildroot/2008-October/011017.html
>
> Sadly, I didn't get any feedback about it.

Add usbutils to the list of packages with the same problem.

I figured I had something setup wrong with my external toolchain so I
just patched the .mk files to make it work. Good to know I'm not the
only one with problems.

Just did a quick glance at the patch above, I don't think it would work
for the mtd package. The patch add TARGET_LDFLAGS to the
TARGET_CONFIGURE_OPTS. The mtd package doesn't use Autotools so I don't
think it will see the change.

It should work for usbutils. But I'm not sure if the "-Wl,--rpath-link
-Wl,$(STAGING_DIR)/usr/lib" is also needed.

For reference here is what I patched to get mtd and usbutils to compile:

mtd.mk
------
 $(MTD_BUILD_TARGETS): $(MTD_DIR)/.unpacked
 	mkdir -p $(TARGET_DIR)/usr/sbin
 	$(MAKE) CFLAGS="-I. -I./include -I$(LINUX_HEADERS_DIR)/include
-I$(STAGING_DIR)/usr/include $(TARGET_CFLAGS)" \
+		LDFLAGS="$(TARGET_LDFLAGS)" \
 		BUILDDIR=$(MTD_DIR) \
 		CROSS=$(TARGET_CROSS) CC=$(TARGET_CC)
LINUXDIR=$(LINUX26_DIR) WITHOUT_XATTR=1 -C $(MTD_DIR)

usbutils.mk
-----------
 	(cd $(USBUTILS_DIR); rm -rf config.cache; \
 		$(TARGET_CONFIGURE_OPTS) \
 		$(TARGET_CONFIGURE_ARGS) \
+		LDFLAGS="$(TARGET_LDFLAGS)" \
 		ac_cv_func_malloc_0_nonnull=yes \
 		./configure \
 		--target=$(GNU_TARGET_NAME) \

Hartley

[Buildroot] [PATCH 2/9] Fix link flags of mtdutils

[Bernhard Reutner-Fischer]

On Thu, Oct 16, 2008 at 05:15:40PM -0400, hartleys wrote:
>On Thursday, October 16, 2008 1:52 PM, Thomas Petazzoni wrote:
>>> The mtd makefile fragment doesn't specify LDFLAGS.  This can cause
>>> the linking to fail when trying to find libz if using an external 
>>> toolchain
>>
>> This is a problem I also face with many other packages (libpng,
>> directfb, etc.). So I've proposed another, more radical patch:
>>
>> http://buildroot.uclibc.org/lists/buildroot/2008-October/011017.html
>>
>> Sadly, I didn't get any feedback about it.
>
>Add usbutils to the list of packages with the same problem.
>
>I figured I had something setup wrong with my external toolchain so I
>just patched the .mk files to make it work. Good to know I'm not the
>only one with problems.
>
>Just did a quick glance at the patch above, I don't think it would work
>for the mtd package. The patch add TARGET_LDFLAGS to the
>TARGET_CONFIGURE_OPTS. The mtd package doesn't use Autotools so I don't
>think it will see the change.
>
>It should work for usbutils. But I'm not sure if the "-Wl,--rpath-link
>-Wl,$(STAGING_DIR)/usr/lib" is also needed.

passing the rpath is not a proper thing imo.
>
>For reference here is what I patched to get mtd and usbutils to compile:

dead horse. Do it once but right.

[Buildroot] [PATCH 2/9] Fix link flags of mtdutils

[Thomas Petazzoni]

Le Thu, 16 Oct 2008 17:15:40 -0400,
"hartleys" <hartleys@visionengravers.com> a ?crit :

> Just did a quick glance at the patch above, I don't think it would
> work for the mtd package. The patch add TARGET_LDFLAGS to the
> TARGET_CONFIGURE_OPTS. The mtd package doesn't use Autotools so I
> don't think it will see the change.

TARGET_CONFIGURE_OPTS is supposed to be used in all packages when
calling ./configure, as far as I understand (and it's the case in the
packages I had a look at). TARGET_CONFIGURE_OPTS is of course also used
by Makefile.autotools.in.

> It should work for usbutils. But I'm not sure if the "-Wl,--rpath-link
> -Wl,$(STAGING_DIR)/usr/lib" is also needed.

Without this, I get linking problems like:

http://buildroot.uclibc.org/lists/buildroot/2008-October/010917.html

(read the whole thread for an analysis of my issue, and how I found
this solution).

Thanks,

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

[Buildroot] [PATCH 2/9] Fix link flags of mtdutils

[Thomas Petazzoni]

Le Thu, 16 Oct 2008 23:38:29 +0200,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> a ?crit :

> TARGET_CONFIGURE_OPTS is supposed to be used in all packages when
> calling ./configure, as far as I understand (and it's the case in the
> packages I had a look at). TARGET_CONFIGURE_OPTS is of course also
> used by Makefile.autotools.in.

Ok, my bad. The mtd package doesn't have a ./configure script, so it
doesn't use TARGET_CONFIGURE_OPTS, so obviously, it should be fixed in
a different way.

Sincerly,

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

[Buildroot] [PATCH 3/9] Add support for multilib external toolchains

[Grant Likely]

From: Grant Likely <grant.likely@secretlab.ca>

Fix buildroot to work with external toolchains using multilib.  Multilib
toolchains have several sets of libraries which they can choose between
depending on the optimization flags.  For example, a single toolchain
could have libraries compiled for both hard and soft floating point.
However, buildroot needs copy the correct version of the libraries to
match the flags used to compile the applications.

This patch adds the CPU optimization flags to the execution of GCC when
determining the location of the libraries to copy.  Passing the
optimization flags makes the library linking and copying consistent.

Tested using CodeSourcery PowerPC toolchain on a Xilinx Virtex5 ppc440
platform.
---

 toolchain/external-toolchain/ext-tool.mk |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)


diff --git a/toolchain/external-toolchain/ext-tool.mk b/toolchain/external-toolchain/ext-tool.mk
index bbf430c..ba10dc7 100644
--- a/toolchain/external-toolchain/ext-tool.mk
+++ b/toolchain/external-toolchain/ext-tool.mk
@@ -10,7 +10,8 @@ copy_toolchain_lib_root = \
 	DST="$(strip $2)"; \
 	STRIP="$(strip $3)"; \
  \
-	LIB_DIR=`$(TARGET_CC) -print-file-name=$${LIB} | sed -e "s,/$${LIB}\$$,,"`; \
+	LIB_DIR=`$(TARGET_CC) $(subst ",,$(BR2_TARGET_OPTIMIZATION)) -print-file-name=$${LIB} | sed -e "s,/$${LIB}\$$,,"`; \
+	MULTILIB=`$(TARGET_CC) $(subst ",,$(BR2_TARGET_OPTIMIZATION)) -print-multi-directory`; \
  \
 	if test -z "$${LIB_DIR}"; then \
 		echo "copy_toolchain_lib_root: lib=$${LIB} not found"; \
@@ -21,7 +22,7 @@ copy_toolchain_lib_root = \
 	for FILE in `find $${LIB_DIR} -maxdepth 1 -type l -name "$${LIB}*"`; do \
 		LIB=`basename $${FILE}`; \
 		while test \! -z "$${LIB}"; do \
-			echo "copy_toolchain_lib_root lib=$${LIB} dst=$${DST}"; \
+			echo "copy_toolchain_lib_root multilib=$${MULTILIB} lib=$${LIB} dst=$${DST}"; \
 			rm -fr $(TARGET_DIR)$${DST}/$${LIB}; \
 			mkdir -p $(TARGET_DIR)$${DST}; \
 			if test -h $${LIB_DIR}/$${LIB}; then \

[Buildroot] [PATCH 3/9] Add support for multilib external toolchains

[Shinya Kuribayashi]

Hi Grant,

Grant Likely wrote:
> However, buildroot needs copy the correct version of the libraries to
> match the flags used to compile the applications.

Right.  External toolchain + Multilib support has been one of buildroot
problems.  I also have some hacks on this , but could not make it into
good shape.

I gave it a try, and it works fine; appropriate libraries are copied to
rootfs.  Here's a log with MIPS toolchain (Sourcery G++ Lite):

----------------------------------------------------------------
mkdir -p /home/skuribay/devel/buildroot/project_build_mips/uclibc/root/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libc.so.0 dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libuClibc-0.9.29.so dst=/lib
for libs in ld-uClibc.so.0 libcrypt.so.0 libdl.so.0 libgcc_s.so libm.so.0 libnsl.so.0 libpthread.so.0 libresolv.so.0 librt.so.0 libutil.so.0; do \
                LIB="$libs"; DST="/lib"; STRIP="y"; LIB_DIR=`/opt/codesourcery/mips-4.2/bin/mips-linux-gnu-gcc -Os -pipe -muclibc -msoft-float -print-file-name=${LIB} | sed -e "s,/${LIB}\$,,"`; MULTILIB=`/opt/codesourcery/mips-4.2/bin/mips-linux-gnu-gcc -Os -pipe -muclibc -msoft-float -print-multi-directory`; if test -z "${LIB_DIR}"; then echo "copy_toolchain_lib_root: lib=${LIB} not found"; exit -1; fi; LIB="$libs"; for FILE in `find ${LIB_DIR} -maxdepth 1 -type l -name "${LIB}*"`; do LIB=`basename ${FILE}`; while test \! -z "${LIB}"; do echo "copy_toolchain_lib_root multilib=${MULTILIB} lib=${LIB} dst=${DST}"; rm -fr /home/skuribay/devel/buildroot/project_build_mips/uclibc/root${DST}/${LIB}; mkdir -p /home/skuribay/devel/buildroot/project_build_mips/uclibc/root${DST}; if test -h ${LIB_DIR}/${LIB}; then cp -d ${LIB_DIR}/${LIB} /home/skuribay/devel/buildroot/project_build_mips/uclibc/root${DST}/; elif test -f ${LIB_DIR}/${LIB}; then cp ${LIB_DIR}/${LIB} /home/skuribay/devel/b
uildroot/project_build_mips/uclibc/root${DST}/${LIB}; case "${STRIP}" in (0 | n | no) ;; (*) /opt/codesourcery/mips-4.2/bin/mips-linux-gnu-strip "/home/skuribay/devel/buildroot/project_build_mips/uclibc/root${DST}/${LIB}"; ;; esac; else exit -1; fi; LIB="`readlink ${LIB_DIR}/${LIB}`"; done; done; echo -n; \
        done
copy_toolchain_lib_root multilib=uclibc/soft-float lib=ld-uClibc.so.0 dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=ld-uClibc-0.9.29.so dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libcrypt.so.0 dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libcrypt-0.9.29.so dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libdl.so.0 dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libdl-0.9.29.so dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libgcc_s.so dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libgcc_s.so.1 dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libm.so.0 dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libm-0.9.29.so dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libnsl.so.0 dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libnsl-0.9.29.so dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libpthread.so.0 dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libpthread-0.9.29.so dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libresolv.so.0 dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libresolv-0.9.29.so dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=librt.so.0 dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=librt-0.9.29.so dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libutil.so.0 dst=/lib
copy_toolchain_lib_root multilib=uclibc/soft-float lib=libutil-0.9.29.so dst=/lib
*** Using kernel-headers generated from kernel source
rm -rf /home/skuribay/devel/buildroot/toolchain_build_mips/linux
[ -d /home/skuribay/devel/buildroot/toolchain_build_mips ] || /usr/bin/install -d /home/skuribay/devel/buildroot/toolchain_build_mips
bzcat /home/skuribay/devel/buildroot/dl/linux-2.6.27.tar.bz2 | tar -C /home/skuribay/devel/buildroot/toolchain_build_mips   -xf -
make: *** [/home/skuribay/devel/buildroot/toolchain_build_mips/linux-2.6.27/.unpacked] Interrupt

skuribay at ubuntu:~/devel/buildroot$ 
skuribay at ubuntu:~/devel/buildroot$ mips-linux-gnu-gcc --version
mips-linux-gnu-gcc (Sourcery G++ Lite 4.2-177) 4.2.3
Copyright (C) 2007 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.

skuribay at ubuntu:~/devel/buildroot$ 
----------------------------------------------------------------

So, ack.

Acked-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>

> diff --git a/toolchain/external-toolchain/ext-tool.mk b/toolchain/external-toolchain/ext-tool.mk
> index bbf430c..ba10dc7 100644
> --- a/toolchain/external-toolchain/ext-tool.mk
> +++ b/toolchain/external-toolchain/ext-tool.mk
> @@ -10,7 +10,8 @@ copy_toolchain_lib_root = \
>  	DST="$(strip $2)"; \
>  	STRIP="$(strip $3)"; \
>   \
> -	LIB_DIR=`$(TARGET_CC) -print-file-name=$${LIB} | sed -e "s,/$${LIB}\$$,,"`; \
> +	LIB_DIR=`$(TARGET_CC) $(subst ",,$(BR2_TARGET_OPTIMIZATION)) -print-file-name=$${LIB} | sed -e "s,/$${LIB}\$$,,"`; \
> +	MULTILIB=`$(TARGET_CC) $(subst ",,$(BR2_TARGET_OPTIMIZATION)) -print-multi-directory`; \

By the way,
I have to mention about one more known problem.  External toolchain +
Software-floating-point-option also doesn't work.  So, we have to give
`-msoft-float' option to $(BR2_TARGET_OPTIMIZATION) directly.

The curprit is package/Makefile.in.  $(BR2_SOFT_FLOAT) is only effective
when buildroot toolchain is selected.  This is not soft-float-point only
issue, but also applied to other remaining menu-options of external
toolchain.  Nothing is handled with external toolchains as below:

(package/Makefile.in)-------------------------------------------
# else it's an external toolchain
#########################################################################
else
TARGET_CFLAGS=$(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING) -I$(STAGING_DIR)/include -I$(STAGING_DIR)/usr/include -I$(TOOLCHAIN_EXTERNAL_PATH)/$(TOOLCHAIN_EXTERNAL_PREFIX)/include
TARGET_CXXFLAGS=$(TARGET_CFLAGS)
TARGET_LDFLAGS=-L$(STAGING_DIR)/lib -L$(STAGING_DIR)/usr/lib
endif
#########################################################################
----------------------------------------------------------------

If someone has some patches on this, we'd like to see them.

Thanks,

  Shinya

[Buildroot] [PATCH 3/9] Add support for multilib external toolchains

[Thomas Petazzoni]

Hi Grant,

I've recently tried to work again on integrating CodeSourcery
toolchains into Buildroot, but I'm facing issues related to multilib.
I've summed up these issues in the following post:

 http://lists.busybox.net/pipermail/buildroot/2010-January/031421.html

If you have any idea on how to solve the issues, don't hesitate to tell
me.

Thanks!

Thomas

On Thu, 16 Oct 2008 14:32:30 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:

> From: Grant Likely <grant.likely@secretlab.ca>
> 
> Fix buildroot to work with external toolchains using multilib.
> Multilib toolchains have several sets of libraries which they can
> choose between depending on the optimization flags.  For example, a
> single toolchain could have libraries compiled for both hard and soft
> floating point. However, buildroot needs copy the correct version of
> the libraries to match the flags used to compile the applications.
> 
> This patch adds the CPU optimization flags to the execution of GCC
> when determining the location of the libraries to copy.  Passing the
> optimization flags makes the library linking and copying consistent.
> 
> Tested using CodeSourcery PowerPC toolchain on a Xilinx Virtex5 ppc440
> platform.
> ---
> 
>  toolchain/external-toolchain/ext-tool.mk |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/toolchain/external-toolchain/ext-tool.mk
> b/toolchain/external-toolchain/ext-tool.mk index bbf430c..ba10dc7
> 100644 --- a/toolchain/external-toolchain/ext-tool.mk
> +++ b/toolchain/external-toolchain/ext-tool.mk
> @@ -10,7 +10,8 @@ copy_toolchain_lib_root = \
>  	DST="$(strip $2)"; \
>  	STRIP="$(strip $3)"; \
>   \
> -	LIB_DIR=`$(TARGET_CC) -print-file-name=$${LIB} | sed -e
> "s,/$${LIB}\$$,,"`; \
> +	LIB_DIR=`$(TARGET_CC) $(subst ",,$(BR2_TARGET_OPTIMIZATION))
> -print-file-name=$${LIB} | sed -e "s,/$${LIB}\$$,,"`; \
> +	MULTILIB=`$(TARGET_CC) $(subst
> ",,$(BR2_TARGET_OPTIMIZATION)) -print-multi-directory`; \ \
>  	if test -z "$${LIB_DIR}"; then \
>  		echo "copy_toolchain_lib_root: lib=$${LIB} not
> found"; \ @@ -21,7 +22,7 @@ copy_toolchain_lib_root = \
>  	for FILE in `find $${LIB_DIR} -maxdepth 1 -type l -name
> "$${LIB}*"`; do \ LIB=`basename $${FILE}`; \
>  		while test \! -z "$${LIB}"; do \
> -			echo "copy_toolchain_lib_root lib=$${LIB}
> dst=$${DST}"; \
> +			echo "copy_toolchain_lib_root
> multilib=$${MULTILIB} lib=$${LIB} dst=$${DST}"; \ rm -fr
> $(TARGET_DIR)$${DST}/$${LIB}; \ mkdir -p $(TARGET_DIR)$${DST}; \
>  			if test -h $${LIB_DIR}/$${LIB}; then \
> 
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot


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

[Buildroot] [PATCH 3/9] Add support for multilib external toolchains

[Grant Likely]

On Tue, Jan 12, 2010 at 4:06 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hi Grant,
>
> I've recently tried to work again on integrating CodeSourcery
> toolchains into Buildroot, but I'm facing issues related to multilib.
> I've summed up these issues in the following post:
>
> ?http://lists.busybox.net/pipermail/buildroot/2010-January/031421.html
>
> If you have any idea on how to solve the issues, don't hesitate to tell
> me.

I'm not a gcc expert so I don't know.  It would be ideal if gcc could
tell you the subdirectory for a given set of flags (instead of trying
to parse -print-multi-lib output) and then copy only those libraries.
Include files would need to be copied separately of course.  Then
you'd either need a symlink in the target directory so that gcc
doesn't get confused, or a flag to tell gcc to turn off multilib.

You might try asking Segher Boessenkool (cc'd).  He's quite adept at gcc-fu.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

[Buildroot] [PATCH 4/9] Add Xilinx UARTLITE and MPC5200 PSC device files (serial ports)

[Grant Likely]

From: Grant Likely <grant.likely@secretlab.ca>

The Xilinx UART Lite and MPC5200 Programmable Serial Controller (PSC)
devices have dedicated major/minor numbers.  Add them to the device
table data file so they get are present in the root filesystem
---

 target/generic/device_table.txt              |    2 ++
 target/generic/target_skeleton/etc/securetty |    4 ++++
 2 files changed, 6 insertions(+), 0 deletions(-)


diff --git a/target/generic/device_table.txt b/target/generic/device_table.txt
index 1efc161..2016eb3 100644
--- a/target/generic/device_table.txt
+++ b/target/generic/device_table.txt
@@ -72,6 +72,8 @@
 #/dev/ttySA	c	666	0	0	204	5	0	1	3
 /dev/psaux	c	666	0	0	10	1	0	0	-
 #/dev/ppp	c	666	0	0	108	0	-	-	-
+/dev/ttyPSC	c	666	0	0	204	148	0	1	4
+/dev/ttyUL	c	666	0	0	204	187	0	1	4
 
 # Input stuff
 /dev/input		d	755	0	0	-	-	-	-	-
diff --git a/target/generic/target_skeleton/etc/securetty b/target/generic/target_skeleton/etc/securetty
index 1b084ac..15288e8 100644
--- a/target/generic/target_skeleton/etc/securetty
+++ b/target/generic/target_skeleton/etc/securetty
@@ -14,3 +14,7 @@ ttyUL0
 ttyUL1
 ttyUL2
 ttyUL3
+ttyPSC0
+ttyPSC1
+ttyPSC2
+ttyPSC3

[Buildroot] [PATCH 4/9] Add Xilinx UARTLITE and MPC5200 PSC device files (serial ports)

[Peter Korsgaard]

>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:

 Grant> From: Grant Likely <grant.likely@secretlab.ca>
 Grant> The Xilinx UART Lite and MPC5200 Programmable Serial Controller (PSC)
 Grant> devices have dedicated major/minor numbers.  Add them to the device
 Grant> table data file so they get are present in the root filesystem
 Grant> ---

I was convinced that I had done this long time ago, but I apparently
only added them to /etc/securetty ..

Anyway, thanks - Committed as r23701.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 5/9] Refactor invocation of make for kernel compiles

[Grant Likely]

From: Grant Likely <grant.likely@secretlab.ca>

The same invocation of make is repeated several time in the Linux makefiles.
Refactor this code to assign all of it into a single make variable which
can be used everywhere.
---

 target/linux/Makefile.in          |   21 +++++++++++++--------
 target/linux/Makefile.in.advanced |   29 +++++++++++++++++------------
 2 files changed, 30 insertions(+), 20 deletions(-)


diff --git a/target/linux/Makefile.in b/target/linux/Makefile.in
index ca6b352..6126f46 100644
--- a/target/linux/Makefile.in
+++ b/target/linux/Makefile.in
@@ -93,6 +93,9 @@ LINUX26_MAKE_FLAGS = HOSTCC="$(HOSTCC)" HOSTCFLAGS="$(HOSTCFLAGS)" \
 	LDFLAGS="$(TARGET_LDFLAGS)" \
 	LZMA="$(LZMA)"
 
+LINUX26_MAKE = $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR)
+
+
 $(LINUX26_KCONFIG):
 	@if [ ! -f "$(LINUX26_KCONFIG)" ] ; then \
 		echo ""; \
@@ -181,25 +184,24 @@ ifeq ($(BR2_PACKAGE_BUSYBOX_INITRAMFS),y)
 	echo "CONFIG_INITRAMFS_ROOT_UID=0" >> $(LINUX26_DIR)/.config
 	echo "CONFIG_INITRAMFS_ROOT_GID=0" >> $(LINUX26_DIR)/.config
 endif
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) oldconfig
+	$(LINUX26_MAKE) oldconfig
 	touch $@
 
 $(LINUX26_DIR)/.depend_done: $(LINUX26_DIR)/.configured
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) prepare
+	$(LINUX26_MAKE) prepare
 	touch $@
 
 $(LINUX26_KERNEL): $(INITRAMFS_TARGET) $(BB_INITRAMFS_TARGET) \
 		$(LINUX26_DIR)/.depend_done
-	$(MAKE) $(LINUX26_MAKE_FLAGS) \
-		-C $(LINUX26_DIR) $(LINUX26_FORMAT)
+	$(LINUX26_MAKE) $(LINUX26_FORMAT)
 	cp -pf $(LINUX26_DIR)/$(LINUX26_BINLOC) $(LINUX26_KERNEL)
 	touch -c $@
 
 $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION)/modules.dep: $(LINUX26_DIR)/.configured
 	rm -rf $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION)
 	rm -f $(TARGET_DIR)/sbin/cardmgr
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) modules
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) \
+	$(LINUX26_MAKE) modules
+	$(LINUX26_MAKE) \
 		DEPMOD=$(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26 \
 		INSTALL_MOD_PATH=$(TARGET_DIR) modules_install
 	rm -f $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION)/build
@@ -209,12 +211,12 @@ $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION)/modules.dep: $(LINUX26_DIR)/.config
 
 linux26-menuconfig: $(LINUX26_DIR)/.patched host-sed
 	[ -f $(LINUX26_DIR)/.config ] || cp $(LINUX26_KCONFIG) $(LINUX26_DIR)/.config
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) menuconfig
+	$(LINUX26_MAKE) menuconfig
 	-[ -f $(LINUX26_DIR)/.config ] && touch $(LINUX26_DIR)/.configured
 
 linux26-xconfig: $(LINUX26_DIR)/.patched host-sed
 	[ -f $(LINUX26_DIR)/.config ] || cp $(LINUX26_KCONFIG) $(LINUX26_DIR)/.config
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) xconfig
+	$(LINUX26_MAKE) xconfig
 	-[ -f $(LINUX26_DIR)/.config ] && touch $(LINUX26_DIR)/.configured
 
 linux26: $(LINUX26_KERNEL)
@@ -240,6 +242,9 @@ linux26-force:
 # This has been renamed so we do _NOT_ by default run this on 'make clean'
 linux26clean:
 	rm -f $(LINUX26_KERNEL) $(LINUX26_DIR)/.configured
+	# Note; this invocation of make is different from the rest.  Why
+	# does 'PATH' need to be assigned here?  Can this be replaced with
+	# $(LINUX26_MAKE) like all the others?
 	-$(MAKE) PATH=$(TARGET_PATH) -C $(LINUX26_DIR) clean
 
 linux26-dirclean:
diff --git a/target/linux/Makefile.in.advanced b/target/linux/Makefile.in.advanced
index cfdba95..90f8e01 100644
--- a/target/linux/Makefile.in.advanced
+++ b/target/linux/Makefile.in.advanced
@@ -189,6 +189,8 @@ LINUX26_MAKE_FLAGS = HOSTCC="$(HOSTCC)" HOSTCFLAGS="$(HOSTCFLAGS)" \
 	LDFLAGS="$(TARGET_LDFLAGS)" \
 	LZMA="$(LZMA)"
 
+LINUX26_MAKE = $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR)
+
 # =============================================================================
 # ifneq ($(strip $(LINUX26_VERSION)),$(strip $(LINUX_HEADERS_VERSION)))
 
@@ -300,10 +302,10 @@ KERNEL_EXTRA_VERSION:=$(strip $(subst ",,$(BR2_EXTRA_VERSION)))
 
 $(LINUX26_DIR)/.config:	$(LINUX26_DIR)/.patched.board
 ifeq ($(BR2_PACKAGE_LINUX_USE_DEFCONFIG),y)
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) $(BOARD_NAME)_defconfig
+	$(LINUX26_MAKE) $(BOARD_NAME)_defconfig
 endif
 ifeq ($(BR2_PACKAGE_LINUX_USE_XCONFIG),y)
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) $(KERNEL_CONFIG_METHOD)
+	$(LINUX26_MAKE) $(KERNEL_CONFIG_METHOD)
 endif
 ifeq ($(BR2_PACKAGE_LINUX_USE_KCONFIG),y)
 	# Try user defined config
@@ -322,12 +324,12 @@ ifeq ($(BR2_PACKAGE_LINUX_USE_KCONFIG),y)
 	fi
 	# Use a board config defined in the linux source.
 	if [ ! -f "$(LINUX26_DIR)/.config" ] ; then \
-		$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) $(BOARD_NAME)_defconfig || \
+		$(LINUX26_MAKE) $(BOARD_NAME)_defconfig || \
 			echo "$(BOARD_NAME)_defconfig failed..." ; \
 	fi
 	# let the user create his/her own config
 	if [ ! -f "$(LINUX26_DIR)/.config" ] ; then \
-		$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) $(KERNEL_CONFIG_METHOD) ; \
+		$(LINUX26_MAKE) $(KERNEL_CONFIG_METHOD) ; \
 	fi
 endif
 ifneq ($(strip $(subst ",,$(BR2_EXTRA_VERSION))),)
@@ -370,29 +372,29 @@ ifeq ($(BR2_PACKAGE_BUSYBOX_INITRAMFS),y)
 	echo "CONFIG_INITRAMFS_ROOT_UID=0" >> $(LINUX26_DIR)/.config
 	echo "CONFIG_INITRAMFS_ROOT_GID=0" >> $(LINUX26_DIR)/.config
 endif
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) oldconfig
+	$(LINUX26_MAKE) oldconfig
 	touch $@
 
 # -----------------------------------------------------------------------------
 $(LINUX26_DIR)/.depend_done: $(LINUX26_DIR)/.configured
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) prepare
+	$(LINUX26_MAKE) prepare
 	touch $@
 
 $(LINUX26_DIR)/$(LINUX26_BINLOC): $(INITRAMFS_TARGET) $(BB_INITRAMFS_TARGET) \
 		$(LINUX26_DIR)/.depend_done
-	$(MAKE) $(LINUX26_MAKE_FLAGS) \
-		-C $(LINUX26_DIR) $(LINUX26_FORMAT)
+	$(LINUX26_MAKE) $(LINUX26_FORMAT)
 
 $(LINUX26_KERNEL): $(LINUX26_DIR)/$(LINUX26_BINLOC)
 	cp -pf $(LINUX26_DIR)/$(LINUX26_BINLOC) $(LINUX26_KERNEL)
 	touch -c $@
 
 # -----------------------------------------------------------------------------
+
 $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION)/modules.dep: $(LINUX26_DIR)/.configured
 	rm -rf $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION)
 	rm -f $(TARGET_DIR)/sbin/cardmgr
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) modules
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) \
+	$(LINUX26_MAKE) modules
+	$(LINUX26_MAKE) \
 		DEPMOD=$(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26 \
 		INSTALL_MOD_PATH=$(TARGET_DIR) modules_install
 	rm -f $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION)/build
@@ -402,12 +404,12 @@ $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION)/modules.dep: $(LINUX26_DIR)/.config
 
 linux26-menuconfig: $(LINUX26_DIR)/.patched host-sed
 	[ -f $(LINUX26_DIR)/.config ] || cp $(LINUX26_KCONFIG) $(LINUX26_DIR)/.config
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) menuconfig
+	$(LINUX26_MAKE) menuconfig
 	-[ -f $(LINUX26_DIR)/.config ] && touch $(LINUX26_DIR)/.configured
 
 linux26-xconfig: $(LINUX26_DIR)/.patched host-sed
 	[ -f $(LINUX26_DIR)/.config ] || cp $(LINUX26_KCONFIG) $(LINUX26_DIR)/.config
-	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) xconfig
+	$(LINUX26_MAKE) xconfig
 	-[ -f $(LINUX26_DIR)/.config ] && touch $(LINUX26_DIR)/.configured
 
 $(TARGET_DIR)/boot/$(LINUX26_KERNEL_NAME): $(LINUX26_KERNEL)
@@ -461,6 +463,9 @@ linux26-force:
 # This has been renamed so we do _NOT_ by default run this on 'make clean'
 linux26clean:
 	rm -f $(LINUX26_KERNEL) $(LINUX26_DIR)/.configured
+	# Note; this invocation of make is different from the rest.  Why
+	# does 'PATH' need to be assigned here?  Can this be replaced with
+	# $(LINUX26_MAKE) like all the others?
 	-$(MAKE) PATH=$(TARGET_PATH) -C $(LINUX26_DIR) clean
 
 linux26-dirclean:

[Buildroot] [PATCH 5/9] Refactor invocation of make for kernel compiles

[Markus Heidelberg]

Grant Likely, 16.10.2008:
> 
> -	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) modules
> -	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) \
> +	$(LINUX26_MAKE) modules
> +	$(LINUX26_MAKE) \
>  		DEPMOD=$(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26 \
>  		INSTALL_MOD_PATH=$(TARGET_DIR) modules_install

DEPMOD could be defined in LINUX26_MAKE_FLAGS, INSTALL_MOD_PATH is already
there. Then it would be a small line here.

> @@ -240,6 +242,9 @@ linux26-force:
>  # This has been renamed so we do _NOT_ by default run this on 'make clean'
>  linux26clean:
>  	rm -f $(LINUX26_KERNEL) $(LINUX26_DIR)/.configured
> +	# Note; this invocation of make is different from the rest.  Why
> +	# does 'PATH' need to be assigned here?  Can this be replaced with
> +	# $(LINUX26_MAKE) like all the others?
>  	-$(MAKE) PATH=$(TARGET_PATH) -C $(LINUX26_DIR) clean

I think so, maybe a leftover, but I don't know. Git-grepping for TARGET_PATH
through the repository shows some uses of this in 4 devices but not restricted
to the clean target.

> -	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) modules
> -	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) \
> +	$(LINUX26_MAKE) modules
> +	$(LINUX26_MAKE) \
>  		DEPMOD=$(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26 \
>  		INSTALL_MOD_PATH=$(TARGET_DIR) modules_install

Same as above.

> @@ -461,6 +463,9 @@ linux26-force:
>  # This has been renamed so we do _NOT_ by default run this on 'make clean'
>  linux26clean:
>  	rm -f $(LINUX26_KERNEL) $(LINUX26_DIR)/.configured
> +	# Note; this invocation of make is different from the rest.  Why
> +	# does 'PATH' need to be assigned here?  Can this be replaced with
> +	# $(LINUX26_MAKE) like all the others?
>  	-$(MAKE) PATH=$(TARGET_PATH) -C $(LINUX26_DIR) clean

Same as above.


Markus

[Buildroot] [PATCH 5/9] Refactor invocation of make for kernel compiles

[Grant Likely]

On Thu, Oct 16, 2008 at 3:55 PM, Markus Heidelberg
<markus.heidelberg@web.de> wrote:
> Grant Likely, 16.10.2008:
>>
>> -     $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) modules
>> -     $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) \
>> +     $(LINUX26_MAKE) modules
>> +     $(LINUX26_MAKE) \
>>               DEPMOD=$(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26 \
>>               INSTALL_MOD_PATH=$(TARGET_DIR) modules_install
>
> DEPMOD could be defined in LINUX26_MAKE_FLAGS, INSTALL_MOD_PATH is already
> there. Then it would be a small line here.

Yes, that makes sense.  fixed.

>> @@ -240,6 +242,9 @@ linux26-force:
>>  # This has been renamed so we do _NOT_ by default run this on 'make clean'
>>  linux26clean:
>>       rm -f $(LINUX26_KERNEL) $(LINUX26_DIR)/.configured
>> +     # Note; this invocation of make is different from the rest.  Why
>> +     # does 'PATH' need to be assigned here?  Can this be replaced with
>> +     # $(LINUX26_MAKE) like all the others?
>>       -$(MAKE) PATH=$(TARGET_PATH) -C $(LINUX26_DIR) clean
>
> I think so, maybe a leftover, but I don't know. Git-grepping for TARGET_PATH
> through the repository shows some uses of this in 4 devices but not restricted
> to the clean target.

I've just tried this, and it seems to work.  Next version of this
patch will have this like look like all the rest.  I'll wait another
day or so for more comments and then repost.

Thanks,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

[Buildroot] [PATCH 6/9] Ask the kernel source where it will install modules

[Grant Likely]

From: Grant Likely <grant.likely@secretlab.ca>

Originally, $(LINUX26_VERSION) was used to figure out which directory
modules would get installed in under /lib/modules.  This causes problems
when $(LINUX26_VERSION) differs from what version the kernel source
thinks it is using because it will try to use depmod in the wrong directory.

This patch adds a new variable $(LINUX26_VERSION_MOD) which resolves to the
exact version string that the kernel uses.  Module install then uses this
value instead of $(LINUX26_VERSION) when running depmod

This patch also eliminates the modules.dep target and makes
.modules_installed depend on $(LINUX26_DIR)/.configured directly.  This is
necessary because the value of $(LINUX26_VERSION_MOD) is unavailable before
the kernel is unpacked.  Trying to use it in a target or dependency name
confuses make.
---

 target/linux/Makefile.in.advanced |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)


diff --git a/target/linux/Makefile.in.advanced b/target/linux/Makefile.in.advanced
index 90f8e01..3018ab3 100644
--- a/target/linux/Makefile.in.advanced
+++ b/target/linux/Makefile.in.advanced
@@ -42,6 +42,9 @@ LINUX26_VERSION:=$(LINUX_HEADERS_VERSION)
 endif
 endif
 
+# Ask the kernel what version number it will use when installing modules
+LINUX26_VERSION_MOD = `$(LINUX26_MAKE) -s kernelrelease`
+
 ifeq ($(BOARD_PATH),)
 BOARD_PATH:=$(strip $(subst ",,$(BR2_BOARD_PATH)))
 #"))
@@ -390,16 +393,16 @@ $(LINUX26_KERNEL): $(LINUX26_DIR)/$(LINUX26_BINLOC)
 
 # -----------------------------------------------------------------------------
 
-$(TARGET_DIR)/lib/modules/$(LINUX26_VERSION)/modules.dep: $(LINUX26_DIR)/.configured
-	rm -rf $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION)
+$(LINUX26_DIR)/.modules_installed: $(LINUX26_DIR)/.configured
+	rm -rf $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION_MOD)
 	rm -f $(TARGET_DIR)/sbin/cardmgr
 	$(LINUX26_MAKE) modules
 	$(LINUX26_MAKE) \
 		DEPMOD=$(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26 \
 		INSTALL_MOD_PATH=$(TARGET_DIR) modules_install
-	rm -f $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION)/build
-	rm -f $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION)/source
-	$(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26 -b $(TARGET_DIR) $(LINUX26_VERSION)	#$(LINUX_HEADERS_VERSION)
+	rm -f $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION_MOD)/build
+	rm -f $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION_MOD)/source
+	$(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26 -b $(TARGET_DIR) $(LINUX26_VERSION_MOD)	#$(LINUX_HEADERS_VERSION)
 	touch -c $@
 
 linux26-menuconfig: $(LINUX26_DIR)/.patched host-sed
@@ -442,9 +445,6 @@ $(LINUX_COPYTO)/$(LINUX26_KERNEL_NAME): $(LINUX26_KERNEL)
 
 linux26: $(LINUX26_TARGETS)
 
-$(LINUX26_DIR)/.modules_installed: $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION)/modules.dep
-	touch $@
-
 linux26-modules: cross-depmod26 $(LINUX26_DIR)/.modules_installed
 
 linux26-source: $(DL_DIR)/$(LINUX26_SOURCE)

[Buildroot] [PATCH 6/9] Ask the kernel source where it will installmodules

[Hans-Christian Egtvedt]

On Thu, 16 Oct 2008 22:32:46 +0200
"Grant Likely" <grant.likely@secretlab.ca> wrote:

> From: Grant Likely <grant.likely@secretlab.ca>
> 
> Originally, $(LINUX26_VERSION) was used to figure out which directory
> modules would get installed in under /lib/modules.  This causes
> problems when $(LINUX26_VERSION) differs from what version the kernel
> source thinks it is using because it will try to use depmod in the
> wrong directory.
> 

I like this stuff, I'll give it a spin and see how it performs. If it
works well I'll add it to the repo (unless somebody beat me to it).

> This patch adds a new variable $(LINUX26_VERSION_MOD) which resolves
> to the exact version string that the kernel uses.  Module install
> then uses this value instead of $(LINUX26_VERSION) when running depmod
> 
> This patch also eliminates the modules.dep target and makes
> .modules_installed depend on $(LINUX26_DIR)/.configured directly.
> This is necessary because the value of $(LINUX26_VERSION_MOD) is
> unavailable before the kernel is unpacked.  Trying to use it in a
> target or dependency name confuses make.

And what about using the $(PROJECT_DIR)/autotools-stamp directory
instead for the depend file? Follow with the stream, etc... Easier to
know how to trigger a reinstall as well.

<snip patch>

-- 
Best regards,
Hans-Christian Egtvedt

[Buildroot] [PATCH 6/9] Ask the kernel source where it will installmodules

[Hans-Christian Egtvedt]

On Thu, 30 Oct 2008 10:52:50 +0100
Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> wrote:

> On Thu, 16 Oct 2008 22:32:46 +0200
> "Grant Likely" <grant.likely@secretlab.ca> wrote:
> 
> > From: Grant Likely <grant.likely@secretlab.ca>
> > 
> > Originally, $(LINUX26_VERSION) was used to figure out which
> > directory modules would get installed in under /lib/modules.  This
> > causes problems when $(LINUX26_VERSION) differs from what version
> > the kernel source thinks it is using because it will try to use
> > depmod in the wrong directory.
> > 
> 
> I like this stuff, I'll give it a spin and see how it performs. If it
> works well I'll add it to the repo (unless somebody beat me to it).
> 

Not present, and the stuff you posted was a little buggy. I cleaned it
up a bit, see the attached patch.

What do people think? I'll add it today/tomorrow unless somebody
objects.

> > This patch adds a new variable $(LINUX26_VERSION_MOD) which resolves
> > to the exact version string that the kernel uses.  Module install
> > then uses this value instead of $(LINUX26_VERSION) when running
> > depmod
> > 
> > This patch also eliminates the modules.dep target and makes
> > .modules_installed depend on $(LINUX26_DIR)/.configured directly.
> > This is necessary because the value of $(LINUX26_VERSION_MOD) is
> > unavailable before the kernel is unpacked.  Trying to use it in a
> > target or dependency name confuses make.
> 
> And what about using the $(PROJECT_DIR)/autotools-stamp directory
> instead for the depend file? Follow with the stream, etc... Easier to
> know how to trigger a reinstall as well.
> 

I also added this, since I like gathering all the stamp files at one
place for the target installations.

-- 
Best regards,
Hans-Christian Egtvedt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux26.advanced-probe-kernel-version-before-installing-modules.patch
Type: text/x-patch
Size: 2119 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20081030/ff50e343/attachment.bin 

[Buildroot] [PATCH 6/9] Ask the kernel source where it will install modules

[Thomas Petazzoni]

Le Thu, 16 Oct 2008 14:32:46 -0600,
Grant Likely <grant.likely@secretlab.ca> a ?crit :

> Originally, $(LINUX26_VERSION) was used to figure out which directory
> modules would get installed in under /lib/modules.  This causes
> problems when $(LINUX26_VERSION) differs from what version the kernel
> source thinks it is using because it will try to use depmod in the
> wrong directory.

Just for curiosity, in what cases $(LINUX26_VERSION) can differ from
the ? version the kernel source thinks it is using ? ?

Otherwise, the version proposed by Hans-Christian Egtvedt looks good to
me.

Thanks,

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

[Buildroot] [PATCH 6/9] Ask the kernel source where it will install modules

[Grant Likely]

On Thu, Oct 30, 2008 at 7:20 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Le Thu, 16 Oct 2008 14:32:46 -0600,
> Grant Likely <grant.likely@secretlab.ca> a ?crit :
>
>> Originally, $(LINUX26_VERSION) was used to figure out which directory
>> modules would get installed in under /lib/modules.  This causes
>> problems when $(LINUX26_VERSION) differs from what version the kernel
>> source thinks it is using because it will try to use depmod in the
>> wrong directory.
>
> Just for curiosity, in what cases $(LINUX26_VERSION) can differ from
> the ? version the kernel source thinks it is using ? ?

When using a git kernel tree for instance, LINUX26_VERSION is set to
"linux-git" to match the directory that the kernel is unpacked into
but the kernel source could be reporting just about any
"linux-vX.Y.Z-<sha1>".

>
> Otherwise, the version proposed by Hans-Christian Egtvedt looks good to
> me.

Looks good to me too.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

[Buildroot] [PATCH 6/9] Ask the kernel source where it will install modules

[Thomas Petazzoni]

Le Thu, 30 Oct 2008 07:23:53 -0600,
"Grant Likely" <grant.likely@secretlab.ca> a ?crit :

> When using a git kernel tree for instance, LINUX26_VERSION is set to
> "linux-git" to match the directory that the kernel is unpacked into
> but the kernel source could be reporting just about any
> "linux-vX.Y.Z-<sha1>".

Ok, got it. Thanks for the precision.

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

[Buildroot] [PATCH 6/9] Ask the kernel source where it will install modules

[Hans-Christian Egtvedt]

On Thu, 30 Oct 2008 14:20:18 +0100
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Le Thu, 16 Oct 2008 14:32:46 -0600,
> Grant Likely <grant.likely@secretlab.ca> a ?crit :
> 
> > Originally, $(LINUX26_VERSION) was used to figure out which
> > directory modules would get installed in under /lib/modules.  This
> > causes problems when $(LINUX26_VERSION) differs from what version
> > the kernel source thinks it is using because it will try to use
> > depmod in the wrong directory.
> 
> Just for curiosity, in what cases $(LINUX26_VERSION) can differ from
> the ? version the kernel source thinks it is using ? ?
> 

Vendor specific patch to a kernel, which adds localversion file or
changes the top level Makefile.

Example: 2.6.25.10.atmel.2, which is a patch based on the 2.6.25.10
kernel.

<snipp>

-- 
Best regards,
Hans-Christian Egtvedt

[Buildroot] [PATCH 6/9] Ask the kernel source where it will install modules

[Hans-Christian Egtvedt]

On Thu, 30 Oct 2008 14:20:18 +0100
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Le Thu, 16 Oct 2008 14:32:46 -0600,
> Grant Likely <grant.likely@secretlab.ca> a ?crit :
> 
> > Originally, $(LINUX26_VERSION) was used to figure out which
> > directory modules would get installed in under /lib/modules.  This
> > causes problems when $(LINUX26_VERSION) differs from what version
> > the kernel source thinks it is using because it will try to use
> > depmod in the wrong directory.
> 
> Just for curiosity, in what cases $(LINUX26_VERSION) can differ from
> the ? version the kernel source thinks it is using ? ?
> 
> Otherwise, the version proposed by Hans-Christian Egtvedt looks good
> to me.
> 

Committed as r23858, and sorry I forgot to add Grant Likely as
author :/

-- 
Best regards,
Hans-Christian Egtvedt

[Buildroot] [PATCH 7/9] Add last resort setting of $(LINUX26_BINLOC) for kernel image filename

[Grant Likely]

From: Grant Likely <grant.likely@secretlab.ca>

When building a custom image type, LINUX26_BINLOC will not get set and
the image file will not get copied into the binaries directory.  This
patch adds a last resort setting of the LINUX26_BINLOC value so that
at the very least it will be the same name as the requested custom
kernel image format
---

 target/linux/Makefile.in.advanced |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)


diff --git a/target/linux/Makefile.in.advanced b/target/linux/Makefile.in.advanced
index 3018ab3..42384f1 100644
--- a/target/linux/Makefile.in.advanced
+++ b/target/linux/Makefile.in.advanced
@@ -147,9 +147,6 @@ endif
 # --------------
 # ZIMAGE
 ifeq ($(LINUX26_FORMAT),zImage)
-ifeq ($(LINUX26_BINLOC),)
-LINUX26_BINLOC:=arch/$(KERNEL_ARCH)/boot/$(LINUX26_FORMAT)
-endif
 KERNEL_EXT:=.z
 endif
 
@@ -162,6 +159,11 @@ endif
 KERNEL_EXT:=.bz
 endif
 
+# --------------
+# Last resort; if BINLOC is not set, then use the target name
+ifeq ($(LINUX26_BINLOC),)
+LINUX26_BINLOC:=arch/$(KERNEL_ARCH)/boot/$(LINUX26_FORMAT)
+endif
 
 # -----------------------------------------------------------------------------
 # File name for the Linux kernel binary

[Buildroot] [PATCH 8/9] RFC: Remove HOSTCFLAGS from kernel compile

[Grant Likely]

From: Grant Likely <grant.likely@secretlab.ca>

Setting HOSTCFLAGS when calling make for the kernel compile messes up
the tools that the kernel builds for itself.  Specifically, the
building of the device tree compiler (dtc) in arch/powerpc adds some
required flags to HOSTCFLAGS.  However, if HOSTCFLAGS= is specified
when calling make, then the local flags are never added and the kernel
compile fails.

This patch removes the HOSTCFLAGS= from $(LINUX26_MAKE_FLAGS).  I've
marked this patch as an RFC because I don't know what is really required
here.  Removing it works for me (of course), but it may break other users.
I just don't know if there is a better way to set HOSTCFLAGS so that it
doesn't override the settings that the kernel uses itself.
---

 target/linux/Makefile.in.advanced |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/target/linux/Makefile.in.advanced b/target/linux/Makefile.in.advanced
index 42384f1..9c6df1f 100644
--- a/target/linux/Makefile.in.advanced
+++ b/target/linux/Makefile.in.advanced
@@ -186,7 +186,7 @@ LINUX_KERNEL:=$(LINUX26_KERNEL)
 LINUX26_BZCAT:=$(BZCAT)
 
 __LINUX26_NO_PIC=-fPIC -fpic -DPIC -fwrapv -ftrapv
-LINUX26_MAKE_FLAGS = HOSTCC="$(HOSTCC)" HOSTCFLAGS="$(HOSTCFLAGS)" \
+LINUX26_MAKE_FLAGS = HOSTCC="$(HOSTCC)" \
 	ARCH=$(KERNEL_ARCH) \
 	CFLAGS_KERNEL="$(filter-out $(__LINUX26_NO_PIC),$(TARGET_CFLAGS))" \
 	INSTALL_MOD_PATH=$(TARGET_DIR) \

[Buildroot] [PATCH 8/9] RFC: Remove HOSTCFLAGS from kernel compile

[Bernhard Reutner-Fischer]

On Thu, Oct 16, 2008 at 02:32:56PM -0600, Grant Likely wrote:
>From: Grant Likely <grant.likely@secretlab.ca>
>
>Setting HOSTCFLAGS when calling make for the kernel compile messes up
>the tools that the kernel builds for itself.  Specifically, the
>building of the device tree compiler (dtc) in arch/powerpc adds some
>required flags to HOSTCFLAGS.  However, if HOSTCFLAGS= is specified
>when calling make, then the local flags are never added and the kernel
>compile fails.

One could argue that this is really a bug in the kernel.

>
>This patch removes the HOSTCFLAGS= from $(LINUX26_MAKE_FLAGS).  I've
>marked this patch as an RFC because I don't know what is really required
>here.  Removing it works for me (of course), but it may break other users.
>I just don't know if there is a better way to set HOSTCFLAGS so that it
>doesn't override the settings that the kernel uses itself.

you could append it to HOSTCC, but that didn't work either (at least for
some earlier 2.6.x). The problem with HOSTCFLAGS and HOSTCC is that for
some hosts the HOSTCFLAGS are integral part of having a working HOSTCC,
you can't separate them without rendering your HOSTCC completely
dysfunctional (since the stuff is supposed to run, too).

>---
>
> target/linux/Makefile.in.advanced |    2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>
>diff --git a/target/linux/Makefile.in.advanced b/target/linux/Makefile.in.advanced
>index 42384f1..9c6df1f 100644
>--- a/target/linux/Makefile.in.advanced
>+++ b/target/linux/Makefile.in.advanced
>@@ -186,7 +186,7 @@ LINUX_KERNEL:=$(LINUX26_KERNEL)
> LINUX26_BZCAT:=$(BZCAT)
> 
> __LINUX26_NO_PIC=-fPIC -fpic -DPIC -fwrapv -ftrapv
>-LINUX26_MAKE_FLAGS = HOSTCC="$(HOSTCC)" HOSTCFLAGS="$(HOSTCFLAGS)" \
>+LINUX26_MAKE_FLAGS = HOSTCC="$(HOSTCC)" \
> 	ARCH=$(KERNEL_ARCH) \
> 	CFLAGS_KERNEL="$(filter-out $(__LINUX26_NO_PIC),$(TARGET_CFLAGS))" \
> 	INSTALL_MOD_PATH=$(TARGET_DIR) \
>

[Buildroot] [PATCH 8/9] RFC: Remove HOSTCFLAGS from kernel compile

[Grant Likely]

On Thu, Oct 16, 2008 at 3:09 PM, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
> On Thu, Oct 16, 2008 at 02:32:56PM -0600, Grant Likely wrote:
>>From: Grant Likely <grant.likely@secretlab.ca>
>>
>>Setting HOSTCFLAGS when calling make for the kernel compile messes up
>>the tools that the kernel builds for itself.  Specifically, the
>>building of the device tree compiler (dtc) in arch/powerpc adds some
>>required flags to HOSTCFLAGS.  However, if HOSTCFLAGS= is specified
>>when calling make, then the local flags are never added and the kernel
>>compile fails.
>
> One could argue that this is really a bug in the kernel.

Indeed, but in which case; how *should* the kernel be adding to the
list of HOSTCFLAGS?.  I'll need to do more research methinks.

>>This patch removes the HOSTCFLAGS= from $(LINUX26_MAKE_FLAGS).  I've
>>marked this patch as an RFC because I don't know what is really required
>>here.  Removing it works for me (of course), but it may break other users.
>>I just don't know if there is a better way to set HOSTCFLAGS so that it
>>doesn't override the settings that the kernel uses itself.
>
> you could append it to HOSTCC, but that didn't work either (at least for
> some earlier 2.6.x). The problem with HOSTCFLAGS and HOSTCC is that for
> some hosts the HOSTCFLAGS are integral part of having a working HOSTCC,
> you can't separate them without rendering your HOSTCC completely
> dysfunctional (since the stuff is supposed to run, too).

Yeah, I figured as much (grumble).

Thanks for the comments.
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

[Buildroot] [PATCH 9/9] Add support for cloning Linux git trees

[Grant Likely]

From: Grant Likely <grant.likely@secretlab.ca>

Add an option in Linux advanced configuration to clone a git repository
directly (without a snapshot tarball).

---

This patch depends on the earlier patch to add the variable
$(LINUX26_VERSION_MOD) because the value of $(LINUX26_VERSION) is set
to 'git' here, but the kernel could report just about any version string.
---

 target/linux/Config.in.advanced   |   30 ++++++++++++++++++++++++++++++
 target/linux/Makefile.in.advanced |   12 ++++++++++++
 2 files changed, 42 insertions(+), 0 deletions(-)


diff --git a/target/linux/Config.in.advanced b/target/linux/Config.in.advanced
index 798a662..350129b 100644
--- a/target/linux/Config.in.advanced
+++ b/target/linux/Config.in.advanced
@@ -15,6 +15,10 @@ if BR2_KERNEL_LINUX_ADVANCED
 # BR2_CUSTOM_LINUX26_PATCH_SITE
 # BR2_CUSTOM_LINUX26_PATCH
 #
+# BR2_LINUX26_GIT
+# BR2_LINUX26_GIT_URL
+# BR2_LINUX26_GIT_BRANCH
+#
 # BR2_LINUX_BSP_PATCH
 #
 # BR2_PACKAGE_LINUX_USE_KCONFIG
@@ -140,6 +144,11 @@ config BR2_LINUX_2_6_STABLE
 	help
 	  Linux 2.6.26.3
 
+config BR2_LINUX26_GIT
+	bool "Use a Linux git repository"
+	help
+	  Clone from a git tree.
+
 config BR2_LINUX_2_6_26
 	bool "Linux 2.6.26"
 	select BR2_KERNEL_BASE
@@ -253,6 +262,26 @@ config BR2_CUSTOM_LINUX26_PATCH_SITE
 
 endif
 
+if BR2_LINUX26_GIT
+config BR2_LINUX26_GIT_URL
+	string "git URL"
+	default "file:///path/to/git/tree/linux-2.6/"
+	help
+	  URL to git repository
+
+	  Any git URL works here, but you may find it more efficient to
+	  clone from a tree on the same local filesystem using the file:///
+	  protocol.  The file:/// protocol allows git to hardlink to the
+	  respository database which is faster and is requires less disk
+	  space.
+
+config BR2_LINUX26_GIT_BRANCH
+	string "git branch"
+	default "master"
+	help
+	  Name of branch to use in get repository
+endif
+
 # -----------------------------------------------
 
 menu "Patches"
@@ -418,6 +447,7 @@ config BR2_LINUX26_VERSION
 	default "2.6.22.10" if BR2_LINUX_2_6_22_10
 	default "$(BR2_KERNEL_CURRENT_VERSION)"if BR2_LINUX_2_6_STABLE
 	default $(BR2_CUSTOM_LINUX26_VERSION) if BR2_LINUX26_CUSTOM
+	default "git" if BR2_LINUX26_GIT
 
 menu "Linux Kernel Configuration"
 
diff --git a/target/linux/Makefile.in.advanced b/target/linux/Makefile.in.advanced
index 9c6df1f..b0cb03e 100644
--- a/target/linux/Makefile.in.advanced
+++ b/target/linux/Makefile.in.advanced
@@ -209,6 +209,7 @@ $(DL_DIR)/$(LINUX26_PATCH_SOURCE):
 	 $(WGET) -P $(DL_DIR) $(LINUX26_PATCH_SITE)/$(LINUX26_PATCH_SOURCE)
 endif
 
+ifneq ($(BR2_LINUX26_GIT),y)
 $(LINUX26_DIR)/.unpacked: $(DL_DIR)/$(LINUX26_SOURCE)
 	rm -rf $(LINUX26_DIR)
 	@echo "*** Unpacking kernel source"
@@ -218,6 +219,14 @@ ifneq ($(DOWNLOAD_LINUX26_VERSION),$(LINUX26_VERSION))
 	mv -f $(PROJECT_BUILD_DIR)/linux-$(DOWNLOAD_LINUX26_VERSION) $(LINUX26_DIR)
 endif
 	touch $@
+else
+$(LINUX26_DIR)/.unpacked:
+	@echo "*** Cloning kernel git tree"
+	git clone --depth 1 $(BR2_LINUX26_GIT_URL) $(LINUX26_DIR)
+	cd $(LINUX26_DIR) && \
+		git reset --hard origin/$(BR2_LINUX26_GIT_BRANCH)
+	touch $@
+endif # BR2_LINUX26_GIT
 
 
 # -----------------------------------------------------------------------------
@@ -499,6 +508,9 @@ linux-status:
 	@echo BR2_LINUX26_CUSTOM=$(BR2_LINUX26_CUSTOM)
 	@echo BR2_CUSTOM_LINUX26_PATCH_SITE=$(BR2_CUSTOM_LINUX26_PATCH_SITE)
 	@echo BR2_CUSTOM_LINUX26_PATCH=$(BR2_CUSTOM_LINUX26_PATCH)
+	@echo BR2_LINUX26_GIT=$(BR2_LINUX26_GIT)
+	@echo BR2_LINUX26_GIT_URL=$(BR2_LINUX26_GIT_URL)
+	@echo BR2_LINUX26_GIT_BRANCH=$(BR2_LINUX26_GIT_BRANCH)
 	@echo BR2_LINUX_BSP_PATCH=$(BR2_LINUX_BSP_PATCH)
 	@echo BR2_PACKAGE_LINUX_USE_KCONFIG=$(BR2_PACKAGE_LINUX_USE_KCONFIG)
 	@echo BR2_PACKAGE_LINUX_USE_DEFCONFIG=$(BR2_PACKAGE_LINUX_USE_DEFCONFIG)

[Buildroot] [PATCH 9/9] Add support for cloning Linux git trees

[Bernhard Reutner-Fischer]

On Thu, Oct 16, 2008 at 02:33:01PM -0600, Grant Likely wrote:
>From: Grant Likely <grant.likely@secretlab.ca>
>
>Add an option in Linux advanced configuration to clone a git repository
>directly (without a snapshot tarball).
>
>---
>
>This patch depends on the earlier patch to add the variable
>$(LINUX26_VERSION_MOD) because the value of $(LINUX26_VERSION) is set
>to 'git' here, but the kernel could report just about any version string.
>---
>
> target/linux/Config.in.advanced   |   30 ++++++++++++++++++++++++++++++
> target/linux/Makefile.in.advanced |   12 ++++++++++++
> 2 files changed, 42 insertions(+), 0 deletions(-)
>
>
>diff --git a/target/linux/Config.in.advanced b/target/linux/Config.in.advanced
>index 798a662..350129b 100644
>--- a/target/linux/Config.in.advanced
>+++ b/target/linux/Config.in.advanced
>@@ -15,6 +15,10 @@ if BR2_KERNEL_LINUX_ADVANCED
> # BR2_CUSTOM_LINUX26_PATCH_SITE
> # BR2_CUSTOM_LINUX26_PATCH
> #
>+# BR2_LINUX26_GIT
>+# BR2_LINUX26_GIT_URL
>+# BR2_LINUX26_GIT_BRANCH
>+#
> # BR2_LINUX_BSP_PATCH
> #
> # BR2_PACKAGE_LINUX_USE_KCONFIG
>@@ -140,6 +144,11 @@ config BR2_LINUX_2_6_STABLE
> 	help
> 	  Linux 2.6.26.3
> 
>+config BR2_LINUX26_GIT
>+	bool "Use a Linux git repository"
>+	help
>+	  Clone from a git tree.
>+
> config BR2_LINUX_2_6_26
> 	bool "Linux 2.6.26"
> 	select BR2_KERNEL_BASE
>@@ -253,6 +262,26 @@ config BR2_CUSTOM_LINUX26_PATCH_SITE
> 
> endif
> 
>+if BR2_LINUX26_GIT
>+config BR2_LINUX26_GIT_URL
>+	string "git URL"
>+	default "file:///path/to/git/tree/linux-2.6/"
>+	help
>+	  URL to git repository
>+
>+	  Any git URL works here, but you may find it more efficient to
>+	  clone from a tree on the same local filesystem using the file:///
>+	  protocol.  The file:/// protocol allows git to hardlink to the
>+	  respository database which is faster and is requires less disk
>+	  space.
>+
>+config BR2_LINUX26_GIT_BRANCH
>+	string "git branch"
>+	default "master"
>+	help
>+	  Name of branch to use in get repository
>+endif
>+
> # -----------------------------------------------
> 
> menu "Patches"
>@@ -418,6 +447,7 @@ config BR2_LINUX26_VERSION
> 	default "2.6.22.10" if BR2_LINUX_2_6_22_10
> 	default "$(BR2_KERNEL_CURRENT_VERSION)"if BR2_LINUX_2_6_STABLE

looking at the URI of this file. No wonder.

> 	default $(BR2_CUSTOM_LINUX26_VERSION) if BR2_LINUX26_CUSTOM
>+	default "git" if BR2_LINUX26_GIT
> 
> menu "Linux Kernel Configuration"
> 
>diff --git a/target/linux/Makefile.in.advanced b/target/linux/Makefile.in.advanced
>index 9c6df1f..b0cb03e 100644
>--- a/target/linux/Makefile.in.advanced
>+++ b/target/linux/Makefile.in.advanced
>@@ -209,6 +209,7 @@ $(DL_DIR)/$(LINUX26_PATCH_SOURCE):
> 	 $(WGET) -P $(DL_DIR) $(LINUX26_PATCH_SITE)/$(LINUX26_PATCH_SOURCE)
> endif
> 
>+ifneq ($(BR2_LINUX26_GIT),y)
> $(LINUX26_DIR)/.unpacked: $(DL_DIR)/$(LINUX26_SOURCE)
> 	rm -rf $(LINUX26_DIR)
> 	@echo "*** Unpacking kernel source"
>@@ -218,6 +219,14 @@ ifneq ($(DOWNLOAD_LINUX26_VERSION),$(LINUX26_VERSION))
> 	mv -f $(PROJECT_BUILD_DIR)/linux-$(DOWNLOAD_LINUX26_VERSION) $(LINUX26_DIR)
> endif
> 	touch $@
>+else
>+$(LINUX26_DIR)/.unpacked:
>+	@echo "*** Cloning kernel git tree"
>+	git clone --depth 1 $(BR2_LINUX26_GIT_URL) $(LINUX26_DIR)
>+	cd $(LINUX26_DIR) && \
>+		git reset --hard origin/$(BR2_LINUX26_GIT_BRANCH)
>+	touch $@
>+endif # BR2_LINUX26_GIT

I've done something like this for libtool, and i *think* that i will not
waste _that_ much bandwith over and over again. Not my call, though.
> 
> 
> # -----------------------------------------------------------------------------
>@@ -499,6 +508,9 @@ linux-status:

linux-status. If you have make, you most likely have grep, too.

> 	@echo BR2_LINUX26_CUSTOM=$(BR2_LINUX26_CUSTOM)
> 	@echo BR2_CUSTOM_LINUX26_PATCH_SITE=$(BR2_CUSTOM_LINUX26_PATCH_SITE)
> 	@echo BR2_CUSTOM_LINUX26_PATCH=$(BR2_CUSTOM_LINUX26_PATCH)
>+	@echo BR2_LINUX26_GIT=$(BR2_LINUX26_GIT)
>+	@echo BR2_LINUX26_GIT_URL=$(BR2_LINUX26_GIT_URL)
>+	@echo BR2_LINUX26_GIT_BRANCH=$(BR2_LINUX26_GIT_BRANCH)
> 	@echo BR2_LINUX_BSP_PATCH=$(BR2_LINUX_BSP_PATCH)
> 	@echo BR2_PACKAGE_LINUX_USE_KCONFIG=$(BR2_PACKAGE_LINUX_USE_KCONFIG)
> 	@echo BR2_PACKAGE_LINUX_USE_DEFCONFIG=$(BR2_PACKAGE_LINUX_USE_DEFCONFIG)
>

[Buildroot] [PATCH 9/9] Add support for cloning Linux git trees

[Grant Likely]

On Thu, Oct 16, 2008 at 3:14 PM, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
> On Thu, Oct 16, 2008 at 02:33:01PM -0600, Grant Likely wrote:
>>From: Grant Likely <grant.likely@secretlab.ca>
>>
>>Add an option in Linux advanced configuration to clone a git repository
>>directly (without a snapshot tarball).
>>
>>---
>>
>>This patch depends on the earlier patch to add the variable
>>$(LINUX26_VERSION_MOD) because the value of $(LINUX26_VERSION) is set
>>to 'git' here, but the kernel could report just about any version string.

Hi Bernhard, thanks for the comments.  Replies below.

>>+if BR2_LINUX26_GIT
>>+config BR2_LINUX26_GIT_URL
>>+      string "git URL"
>>+      default "file:///path/to/git/tree/linux-2.6/"
>>+      help
>>+        URL to git repository
>>+
>>+        Any git URL works here, but you may find it more efficient to
>>+        clone from a tree on the same local filesystem using the file:///
>>+        protocol.  The file:/// protocol allows git to hardlink to the
>>+        respository database which is faster and is requires less disk
>>+        space.
>>+
>>+config BR2_LINUX26_GIT_BRANCH
>>+      string "git branch"
>>+      default "master"
>>+      help
>>+        Name of branch to use in get repository
>>+endif
>>+
>> # -----------------------------------------------
>>
>> menu "Patches"
>>@@ -418,6 +447,7 @@ config BR2_LINUX26_VERSION
>>       default "2.6.22.10" if BR2_LINUX_2_6_22_10
>>       default "$(BR2_KERNEL_CURRENT_VERSION)"if BR2_LINUX_2_6_STABLE
>
> looking at the URI of this file. No wonder.

Umm, I don't know what you are referring to here.  Are you referring
to using 'git' as the value of BR2_LINUX26_VERSION instead of the full
URL?

>>       default $(BR2_CUSTOM_LINUX26_VERSION) if BR2_LINUX26_CUSTOM
>>+      default "git" if BR2_LINUX26_GIT
>>
>> menu "Linux Kernel Configuration"
>>


>>@@ -218,6 +219,14 @@ ifneq ($(DOWNLOAD_LINUX26_VERSION),$(LINUX26_VERSION))
>>       mv -f $(PROJECT_BUILD_DIR)/linux-$(DOWNLOAD_LINUX26_VERSION) $(LINUX26_DIR)
>> endif
>>       touch $@
>>+else
>>+$(LINUX26_DIR)/.unpacked:
>>+      @echo "*** Cloning kernel git tree"
>>+      git clone --depth 1 $(BR2_LINUX26_GIT_URL) $(LINUX26_DIR)
>>+      cd $(LINUX26_DIR) && \
>>+              git reset --hard origin/$(BR2_LINUX26_GIT_BRANCH)
>>+      touch $@
>>+endif # BR2_LINUX26_GIT
>
> I've done something like this for libtool, and i *think* that i will not
> waste _that_ much bandwith over and over again. Not my call, though.

It should be okay.  Using the --depth flag keeps the download size to
the bear minimum.  Using it on current mainline results in ~100MB of
git repo (as opposed to ~50MB for a bz2 tarball and ~300MB for a full
git clone).  Also, in the help text I recommend to use a local git
tree to keep clone bandwidth costs to a minimum.

>>@@ -499,6 +508,9 @@ linux-status:
>
> linux-status. If you have make, you most likely have grep, too.
>
>>       @echo BR2_LINUX26_CUSTOM=$(BR2_LINUX26_CUSTOM)
>>       @echo BR2_CUSTOM_LINUX26_PATCH_SITE=$(BR2_CUSTOM_LINUX26_PATCH_SITE)
>>       @echo BR2_CUSTOM_LINUX26_PATCH=$(BR2_CUSTOM_LINUX26_PATCH)
>>+      @echo BR2_LINUX26_GIT=$(BR2_LINUX26_GIT)
>>+      @echo BR2_LINUX26_GIT_URL=$(BR2_LINUX26_GIT_URL)
>>+      @echo BR2_LINUX26_GIT_BRANCH=$(BR2_LINUX26_GIT_BRANCH)
>>       @echo BR2_LINUX_BSP_PATCH=$(BR2_LINUX_BSP_PATCH)
>>       @echo BR2_PACKAGE_LINUX_USE_KCONFIG=$(BR2_PACKAGE_LINUX_USE_KCONFIG)
>>       @echo BR2_PACKAGE_LINUX_USE_DEFCONFIG=$(BR2_PACKAGE_LINUX_USE_DEFCONFIG)
>>

I had mostly just been following the existing lead.  I can drop this
change if it is preferred.

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

[Buildroot] [PATCH 9/9] Add support for cloning Linux git trees

[Bernhard Reutner-Fischer]

On Thu, Oct 16, 2008 at 05:09:13PM -0600, Grant Likely wrote:
>On Thu, Oct 16, 2008 at 3:14 PM, Bernhard Reutner-Fischer
><rep.dot.nop@gmail.com> wrote:
>> On Thu, Oct 16, 2008 at 02:33:01PM -0600, Grant Likely wrote:

>>>@@ -418,6 +447,7 @@ config BR2_LINUX26_VERSION

>>>       default "$(BR2_KERNEL_CURRENT_VERSION)"if BR2_LINUX_2_6_STABLE
>>
>> looking at the URI of this file. No wonder.
>
>Umm, I don't know what you are referring to here.  Are you referring
>to using 'git' as the value of BR2_LINUX26_VERSION instead of the full
>URL?

No, sorry. I was referring to the preexisting line cited above.

>> I've done something like this for libtool, and i *think* that i will not
>> waste _that_ much bandwith over and over again. Not my call, though.
>
>It should be okay.  Using the --depth flag keeps the download size to
>the bear minimum.  Using it on current mainline results in ~100MB of
>git repo (as opposed to ~50MB for a bz2 tarball and ~300MB for a full
>git clone).  Also, in the help text I recommend to use a local git
>tree to keep clone bandwidth costs to a minimum.

Yes. I'll do this differently though, never mind.
>
>>>@@ -499,6 +508,9 @@ linux-status:
>>
>> linux-status. If you have make, you most likely have grep, too.

>I had mostly just been following the existing lead.  I can drop this
>change if it is preferred.

I don't care about this bit, leave it in if you liked it.

PS:
So what about powerpc's crtsavres.o. Since i don't have a powerpc (and
as such only stumbled across this accidentally) and furthermore don't
need real external modules as opposed to in-tree modules for compile
tests, i will not pursue this further. Perhaps you want to take care
of it (kernel bugzilla #11143)? TIA.. :)

[Buildroot] [PATCH 1/9] Typo fix in toolchain/external-toolchain/ext-tool.mk

[Peter Korsgaard]

>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:

 Grant> From: Grant Likely <grant.likely@secretlab.ca>
 Grant> Comment block header documentation typo
 Grant> ---

Thanks, committed as r23700.

-- 
Bye, Peter Korsgaard