All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] Changing the way the kernel is build from an external layer
@ 2019-05-28  8:24 Ottavio Campana
  2019-05-28 22:04 ` Arnout Vandecappelle
  0 siblings, 1 reply; 2+ messages in thread
From: Ottavio Campana @ 2019-05-28  8:24 UTC (permalink / raw)
  To: buildroot

Hello,

I am porting a BSP to buildroot, to make the full build of the system automatic.

Everything is fine, but I have a problem with the kernel. The kernel
is provided in form of a tarball, but inside the tarball also drivers
are present. The contents of the tarball, once expanded, can be
summarized as:

source folder
* kernel folder
* first folder with a bunch of drivers
* other folder with other drivers

The contents of the content is not compatible with the tarball
mechanism provided by buildroot, which expands the the tarball and
expects to find the kernel sources at the first level. Moreover,
drivers seem to have some hard coded paths to the kernel source.

I would like to avoid patching the build script in buildroot. Is there
a way to change the way the kernel is compiled by using scripts in an
external layer? In chapter 9 of the buildroot I find many tools to
change/add the packages, but I am not able to find a way to change the
way the kernel is compiled.

Thank you for your suggestions,

Ottavio

-- 
Non c'? pi? forza nella normalit?, c'? solo monotonia

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Buildroot] Changing the way the kernel is build from an external layer
  2019-05-28  8:24 [Buildroot] Changing the way the kernel is build from an external layer Ottavio Campana
@ 2019-05-28 22:04 ` Arnout Vandecappelle
  0 siblings, 0 replies; 2+ messages in thread
From: Arnout Vandecappelle @ 2019-05-28 22:04 UTC (permalink / raw)
  To: buildroot



On 28/05/2019 10:24, Ottavio Campana wrote:
> Hello,
> 
> I am porting a BSP to buildroot, to make the full build of the system automatic.
> 
> Everything is fine, but I have a problem with the kernel. The kernel
> is provided in form of a tarball, but inside the tarball also drivers
> are present. The contents of the tarball, once expanded, can be
> summarized as:
> 
> source folder
> * kernel folder
> * first folder with a bunch of drivers
> * other folder with other drivers

 If your suppliers gives you this kind of rubbish, in all likelihood it will not
work very well :-/


> The contents of the content is not compatible with the tarball
> mechanism provided by buildroot, which expands the the tarball and
> expects to find the kernel sources at the first level. Moreover,
> drivers seem to have some hard coded paths to the kernel source.

 And that's even worse!


> I would like to avoid patching the build script in buildroot. Is there
> a way to change the way the kernel is compiled by using scripts in an
> external layer? In chapter 9 of the buildroot I find many tools to
> change/add the packages, but I am not able to find a way to change the
> way the kernel is compiled.

 You have two options, basically:

1. Build the kernel outside of Buildroot, using whatever scripts the supplier
gave you to build the kernel, and adding $HOST_DIR/bin to the PATH. You can
still call this build from the Buildroot post-build script so you still can do
the complete build with one 'make' command.

2. Pick the tarball apart and properly clean it up - preferably, start from a
clone of the linux git repository and import the tarball into it.

 The second approach is a lot more work, obviously, but it's also maintainable
while the first one is a dead end. But if you don't need to maintain this
product for a very long time and you don't need to do bugfixing, it can be a
convenient approach.

 Regards,
 Arnout

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-05-28 22:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-28  8:24 [Buildroot] Changing the way the kernel is build from an external layer Ottavio Campana
2019-05-28 22:04 ` Arnout Vandecappelle

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.