[Buildroot] kernel built by buildroot won't boot

[Buildroot] kernel built by buildroot won't boot

[Sven Neumann]

Hi,

we are developing for an ARM platform. Here are the relevant parts of
our buildroot .config:

BR2_ARM=Y
BR2_iwmmxt=y
BR2_ARM_TYPE="ARM_IWMMXT"
# BR2_ARM_OABI is not set
BR2_ARM_EABI=y
BR2_ARCH="arm"
BR2_ENDIAN="LITTLE"
BR2_GCC_TARGET_TUNE="iwmmxt"
BR2_GCC_TARGET_ARCH="iwmmxt"
BR2_GCC_TARGET_ABI="aapcs-linux"

So far we did compile the kernel ourselves, using the gcc from the
buildroot toolchain. Now we have changed our setup to have buildroot
create the kernel for us. The build succeeds, but the resulting kernel
can not be booted.

We tracked this down to the fact that buildroot passes the TARGET_CFLAGS
(with some minor adjustments) to the kernel build as CFLAGS_KERNEL. The
problem is that the TARGET_CFLAGS contain "-mtune=iwmmxt -march=iwmmxt",
which is fine for the user-space, but you can't build a working kernel
with these flags. Not passing any CFLAGS at all solved the problem for
us and buildroot now creates a kernel that boots and works nicely.

Is there a particular reason for passing the TARGET_CFLAGS to the kernel
build? Could this perhaps be dropped entirely or at least be made
optional?


Sven

[Buildroot] kernel built by buildroot won't boot

[Peter Korsgaard]

>>>>> "Sven" == Sven Neumann <s.neumann@raumfeld.com> writes:

Hi,

 Sven> We tracked this down to the fact that buildroot passes the
 Sven> TARGET_CFLAGS (with some minor adjustments) to the kernel build
 Sven> as CFLAGS_KERNEL. The problem is that the TARGET_CFLAGS contain
 Sven> "-mtune=iwmmxt -march=iwmmxt", which is fine for the
 Sven> user-space, but you can't build a working kernel with these
 Sven> flags. Not passing any CFLAGS at all solved the problem for us
 Sven> and buildroot now creates a kernel that boots and works nicely.

I don't use the kernel build stuff, but I think it should be fine to
just get rid of it as the kernel doesn't need to link with any user
space libraries or similar.

The kernel is also pretty good about passing the correct gcc flags for
arch variants.

 Sven> Is there a particular reason for passing the TARGET_CFLAGS to the kernel
 Sven> build? Could this perhaps be dropped entirely or at least be made
 Sven> optional?

Care to send a patch?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] linux26: do not set CFLAGS_KERNEL to TARGET_CFLAGS

[Sven Neumann]

Using TARGET_CFLAGS breaks the kernel build for the arm platform. The
result is a kernel that can not be booted. So simply do not fiddle with
the CFLAGS on a kernel build and the kernel build system will do the
right thing (TM).

Signed-off-by: Sven Neumann <s.neumann@raumfeld.com>
---
 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 9d878f2..9c11dbe 100644
--- a/target/linux/Makefile.in.advanced
+++ b/target/linux/Makefile.in.advanced
@@ -193,7 +193,6 @@ LINUX26_BZCAT:=$(BZCAT)
 __LINUX26_NO_PIC=-fPIC -fpic -DPIC -fwrapv -ftrapv
 LINUX26_MAKE_FLAGS = HOSTCC="$(HOSTCC)" HOSTCFLAGS="$(HOSTCFLAGS)" \
 	ARCH=$(KERNEL_ARCH) \
-	CFLAGS_KERNEL="$(filter-out $(__LINUX26_NO_PIC),$(TARGET_CFLAGS))" \
 	INSTALL_MOD_PATH=$(TARGET_DIR) \
 	CROSS_COMPILE=$(KERNEL_CROSS) \
 	LDFLAGS="$(TARGET_LDFLAGS)" \
@@ -549,6 +548,7 @@ linux-status:
 	@echo LINUX26_SOURCE=$(LINUX26_SOURCE)
 	@echo LINUX26_TARGETS=$(LINUX26_TARGETS)
 	@echo LINUX26_VERSION=$(LINUX26_VERSION)
+	@echo LINUX26_MAKE_FLAGS=$(LINUX26_MAKE_FLAGS)
 	@echo PROJECT_BUILD_DIR=$(PROJECT_BUILD_DIR)
 	@echo TARGETS=$(TARGETS)
 
-- 
1.6.0.4

[Buildroot] [PATCH] linux26: do not set CFLAGS_KERNEL to TARGET_CFLAGS

[Peter Korsgaard]

>>>>> "Sven" == Sven Neumann <s.neumann@raumfeld.com> writes:

 Sven> Using TARGET_CFLAGS breaks the kernel build for the arm platform. The
 Sven> result is a kernel that can not be booted. So simply do not fiddle with
 Sven> the CFLAGS on a kernel build and the kernel build system will do the
 Sven> right thing (TM).

Thanks, applied.

I did the same thing for the standard kernel compilation mode as well.

-- 
Bye, Peter Korsgaard