Bug 6392

Summary:	Extended ARM uImage kernel options
Product:	buildroot	Reporter:	Philipp Rahns <philipp.rahns>
Component:	Other	Assignee:	Philipp Rahns <philipp.rahns>
Status:	RESOLVED WONTFIX
Severity:	minor	CC:	buildroot
Priority:	P5
Version:	2013.05
Target Milestone:	---
Hardware:	Other
OS:	Linux
Host:		Target:
Build:
Attachments:	ARM uImage kernel compilation patches

Description Philipp Rahns 2013-07-17 06:34:59 UTC

In same cases, and especially for self hosted Linux kernels and ARM projects, you need additional kernel compiling options. This is what the patch does including making life easier to use the "native" kernel config used in its source tree.

Comment 1 Philipp Rahns 2013-07-17 06:36:19 UTC

Created attachment 4994 [details]
ARM uImage kernel compilation patches

Comment 2 Thomas Petazzoni 2013-07-17 07:39:43 UTC

Thanks for this contribution.

Can you give examples of usage of BR2_LINUX_KERNEL_MAKE_FLAGS ? Why would it be limited to ARM and uImage ?

Also, I don't quite understand BR2_LINUX_KERNEL_NATIVE_CONFIG. When you unpack a kernel tarball or a Git tree, there's normally no .config in the kernel tree, and it has to be created, either starting from a defconfig, or using one of the menuconfig/nconfig/gconfig/xconfig configuration interfaces.

Could you expand a bit on the use cases? Thanks!

Comment 3 Philipp Rahns 2013-07-17 08:01:49 UTC

(In reply to comment #2)
> Thanks for this contribution.
> 
> Can you give examples of usage of BR2_LINUX_KERNEL_MAKE_FLAGS ? Why would it be
> limited to ARM and uImage ?
> 
> Also, I don't quite understand BR2_LINUX_KERNEL_NATIVE_CONFIG. When you unpack
> a kernel tarball or a Git tree, there's normally no .config in the kernel tree,
> and it has to be created, either starting from a defconfig, or using one of the
> menuconfig/nconfig/gconfig/xconfig configuration interfaces.
> 
> Could you expand a bit on the use cases? Thanks!

Hi Thomas,

I agree on the first one that it is not neccessarily limited to the ARM section.
Could be used at any time when compiling a kernel in general.

Concerning native config:
When you have a look at the Zedboard or the Raspberry Pi there are already modified kernel sources fitting to the board.
In some cases this is not enough for the requirements of oneself and you start tweaking it. This is the point where you start "branching" the project and saving ( mostly likely ) the config related to your changes. Of course, you host this branch on a server and to make life easier for other developers you provide an out of the box solution. I know I could easily use
"$(LINUX_DIR)/.config" as config file path but I though it was worth a single option.

Comment 4 Thomas Petazzoni 2013-10-30 22:28:55 UTC

The contributor, Philipp Rahns, proposed the addition of a BR2_LINUX_KERNEL_MAKE_FLAGS configuration option, to add custom make flags when building the kernel. However, Philipp hasn't given details on the specific use case for this, so it's hard to understand why we would want to add that.

The second proposal of Philipp is to add BR2_LINUX_KERNEL_NATIVE_CONFIG, which tells the Buildroot kernel building logic to use the .config file present within the kernel tarball as the configuration file. However, this is not a standard practice, and if people want to store a kernel configuration within the kernel tree, they should rather store it into arch/<ARCH>/configs/, as a minimal defconfig. This is the standard practice and is already supported by Buildroot.

Due to those two reasons, I am not convinced the patch is actually needed. Of course Philipp, if you disagree, feel free to reopen the bug and provide additional details about those use cases. It is still possible to convince us! :-)