* [Buildroot] Extending buildroot functionality for creating board support packages (BSP) out of buildroot tree
[not found] <trinity-2fc0f02e-0868-421f-b7b4-637396c65e9e-1365761778735@3capp-gmx-bs44>
@ 2013-04-12 10:39 ` Jeremy Rosen
0 siblings, 0 replies; 6+ messages in thread
From: Jeremy Rosen @ 2013-04-12 10:39 UTC (permalink / raw)
To: buildroot
hmm... yes that's the case. I might have misunderstood your use-case.
having only the modified files in one place and is a strange way of
working... i'm not sure what's the best way of dealing with that in BR
Cordialement
J?r?my Rosen
fight key loggers : write some perl using vim
----- Mail original -----
> If I understand you correctly this means that I have to hold a
> complete copy of the kernel tree where I do the modifications?
> The requirement for me is that I have to store only the modified and
> new files in a different directory tree (under version control). So
> rsync does not work for me and I have to write a small script which
> is invoked by buildroot and copies my local files to the right
> directories in the kernel tree.
>
> Regards,
> Andreas
> ?
> ?
> ?
>
> Gesendet:?Freitag, 12. April 2013 um 11:58 Uhr
> Von:?"Jeremy Rosen" <jeremy.rosen@openwide.fr>
> An:?"universe II" <universeii@gmx.de>
> Cc:?buildroot at busybox.net
> Betreff:?Re: [Buildroot] Extending buildroot functionality for
> creating board support packages (BSP) out of buildroot tree
> hello
>
> I had a similar problem, but more generic. the simplest way is to use
> the OVERRIDE_SRCDIR feature
>
> * create a file called local.mk at the $(TOPDIR) of your buildroot
> install
> * add a single line inside
>
> LINUX_OVERRIDE_SRCDIR=<path to the linux kernel tree>
>
> and you should be good.
>
> Note that this command will rsync the tree into the buildroot tree,
> (which should be fine, rsync is very fast once the initial sync is
> done)
>
>
> Cordialement
>
> J?r?my Rosen
>
> fight key loggers : write some perl using vim
>
> ----- Mail original -----
> > 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
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> >
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Extending buildroot functionality for creating board support packages (BSP) out of buildroot tree
@ 2013-04-12 9:51 universe II
2013-04-12 9:58 ` Jeremy Rosen
2013-04-14 19:42 ` universe II
0 siblings, 2 replies; 6+ messages in thread
From: universe II @ 2013-04-12 9:51 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Extending buildroot functionality for creating board support packages (BSP) out of buildroot tree
2013-04-12 9:51 universe II
@ 2013-04-12 9:58 ` Jeremy Rosen
2013-04-12 10:18 ` universeII at gmx.de
2013-04-14 19:42 ` universe II
1 sibling, 1 reply; 6+ messages in thread
From: Jeremy Rosen @ 2013-04-12 9:58 UTC (permalink / raw)
To: buildroot
hello
I had a similar problem, but more generic. the simplest way is to use
the OVERRIDE_SRCDIR feature
* create a file called local.mk at the $(TOPDIR) of your buildroot install
* add a single line inside
LINUX_OVERRIDE_SRCDIR=<path to the linux kernel tree>
and you should be good.
Note that this command will rsync the tree into the buildroot tree,
(which should be fine, rsync is very fast once the initial sync is done)
Cordialement
J?r?my Rosen
fight key loggers : write some perl using vim
----- Mail original -----
> 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
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
^ permalink raw reply [flat|nested] 6+ messages in thread* [Buildroot] Extending buildroot functionality for creating board support packages (BSP) out of buildroot tree
2013-04-12 9:58 ` Jeremy Rosen
@ 2013-04-12 10:18 ` universeII at gmx.de
2013-04-13 14:25 ` Thomas Petazzoni
0 siblings, 1 reply; 6+ messages in thread
From: universeII at gmx.de @ 2013-04-12 10:18 UTC (permalink / raw)
To: buildroot
Jeremy,
If I understand you correctly this means that I have to hold a complete copy of the kernel tree where I do the modifications?
The requirement for me is that I have to store only the modified and new files in a different directory tree (under version control). So rsync does not work for me and I have to write a small script which is invoked by buildroot and copies my local files to the right directories in the kernel tree.
Regards,
Andreas
?
Gesendet:?Freitag, 12. April 2013 um 11:58 Uhr
Von:?"Jeremy Rosen" <jeremy.rosen@openwide.fr>
An:?"universe II" <universeii@gmx.de>
Cc:?buildroot at busybox.net
Betreff:?Re: [Buildroot] Extending buildroot functionality for creating board support packages (BSP) out of buildroot tree
hello
I had a similar problem, but more generic. the simplest way is to use
the OVERRIDE_SRCDIR feature
* create a file called local.mk at the $(TOPDIR) of your buildroot install
* add a single line inside
LINUX_OVERRIDE_SRCDIR=<path to the linux kernel tree>
and you should be good.
Note that this command will rsync the tree into the buildroot tree,
(which should be fine, rsync is very fast once the initial sync is done)
Cordialement
J?r?my Rosen
fight key loggers : write some perl using vim
----- Mail original -----
> 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
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
?
?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Extending buildroot functionality for creating board support packages (BSP) out of buildroot tree
2013-04-12 10:18 ` universeII at gmx.de
@ 2013-04-13 14:25 ` Thomas Petazzoni
0 siblings, 0 replies; 6+ messages in thread
From: Thomas Petazzoni @ 2013-04-13 14:25 UTC (permalink / raw)
To: buildroot
Hello Andreas,
On Fri, 12 Apr 2013 12:18:49 +0200 (CEST), universeII at gmx.de wrote:
> If I understand you correctly this means that I have to hold a
> complete copy of the kernel tree where I do the modifications? The
> requirement for me is that I have to store only the modified and new
> files in a different directory tree (under version control). So rsync
> does not work for me and I have to write a small script which is
> invoked by buildroot and copies my local files to the right
> directories in the kernel tree.
While we certainly aim at supporting a custom external tree for the
Linux kernel sources to help using Buildroot during kernel development,
we will certainly never support your use case of a partial kernel tree
that contains only the modified and new files. This is just a very
uncommon (and in my opinion completely wrong) way of handling source
code changes. You should instead be using a git tree to do your kernel
developments, and point LINUX_OVERRIDE_SRCDIR to it.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Extending buildroot functionality for creating board support packages (BSP) out of buildroot tree
2013-04-12 9:51 universe II
2013-04-12 9:58 ` Jeremy Rosen
@ 2013-04-14 19:42 ` universe II
1 sibling, 0 replies; 6+ messages in thread
From: universe II @ 2013-04-14 19:42 UTC (permalink / raw)
To: buildroot
Is there interest in incorporating this feature into buildroot?
I prepared a patch for it, please see attachment.
Regards,
Andreas
On 04/12/2013 11:51 AM, universe II wrote:
> 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
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Add_Pre_Compile_Script_Option_to_buildroot.patch
Type: text/x-patch
Size: 1580 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130414/24d59b34/attachment.bin>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-04-14 19:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <trinity-2fc0f02e-0868-421f-b7b4-637396c65e9e-1365761778735@3capp-gmx-bs44>
2013-04-12 10:39 ` [Buildroot] Extending buildroot functionality for creating board support packages (BSP) out of buildroot tree Jeremy Rosen
2013-04-12 9:51 universe II
2013-04-12 9:58 ` 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox