Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: universe II <universeii@gmx.de>
To: buildroot@busybox.net
Subject: [Buildroot] Extending buildroot functionality for creating board support packages (BSP) out of buildroot tree
Date: Fri, 12 Apr 2013 11:51:07 +0200	[thread overview]
Message-ID: <5167D90B.3020601@gmx.de> (raw)

Dear all,
we are using buildroot for porting an existing embedded PowerPC board to 
linux. For this purpose we have to make modifications to the kernel 
(adding and changing files to support custom hardware). This can easily 
be done by enabling custom patches in the menuconfig.
This is a wonderful solution when the development of the kernel 
modifications is done and the patches are existing but during 
development this could be time consuming. The reason is that we can not 
do the kernel modifcations in the kernel tree itself but in a completely 
separated directory structure. This is caused by our existing version 
control system and by project development requirements.

Imagine that you made a small modification to one of the custom files  
(e.g. changing a printk() statement) and you want to re-build the 
kernel. You have to develop a script which takes a virgin kernel, 
extracts the gz file, makes a copy of the tree, modifies the files in 
the copy and then creates the patch and copies this patch to the 
buildroot tree. Even on a fast hardware this takes some time and you 
have to do it for every change.

I spent some time this morning to evaluate if there could be a more 
elegant solution. Here is what I've done:
1) In linux/Config.in: Add a new entry to the kernel menuconfig which 
allows to enter a script name or a directory name (similar to the custom 
patch option)
2) In linux/linux.mk: After unpacking the kernel and applying the 
patches (if any) the given script or all scripts in the given directory 
are executed.

This allows me to make modification to the unpacked kernel tree without 
the need to create patch files but also opens up flexibility for other 
functionality which may arise in the future.

Let me know what you think about this. If you are interested in 
incorporating these changes into the official buildroot suite, l can 
provide the changes I made.

Regards,
Andreas

             reply	other threads:[~2013-04-12  9:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-12  9:51 universe II [this message]
2013-04-12  9:58 ` [Buildroot] Extending buildroot functionality for creating board support packages (BSP) out of buildroot tree Jeremy Rosen
2013-04-12 10:18   ` universeII at gmx.de
2013-04-13 14:25     ` Thomas Petazzoni
2013-04-14 19:42 ` universe II
     [not found] <trinity-2fc0f02e-0868-421f-b7b4-637396c65e9e-1365761778735@3capp-gmx-bs44>
2013-04-12 10:39 ` Jeremy Rosen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5167D90B.3020601@gmx.de \
    --to=universeii@gmx.de \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox