[Buildroot] inittab for Busybox

[Buildroot] inittab for Busybox

[Heyendal, Carl]

I have not enabled support for sysvinit in my project. Could someone tell me why Buildroot adds an inittab file that's incompatible with BusyBox? I looked at the mail archives but no one seems to have asked that question before.

Also in the mail archives, some reference is made to documentation about creating your own inittab file. Does that documentation still exist somewhere? I've looked but can't find it.

thanx
/carl h.

[Buildroot] inittab for Busybox

[Thomas Petazzoni]

Hello,

On Tue, 15 Mar 2011 12:37:01 -0400
"Heyendal, Carl" <CHeyendal@stanleyworks.com> wrote:

> I have not enabled support for sysvinit in my project. Could someone
> tell me why Buildroot adds an inittab file that's incompatible with
> BusyBox? I looked at the mail archives but no one seems to have asked
> that question before.

How do you see that the inittab is incompatible with Busybox ? Many of
us use it every day without problem.

When sysvinit is not selected, fs/skeleton/etc/inittab is the inittab
that is used, and it is compatible with Busybox init.

When sysvinit is selected, package/sysvinit/inittab is used instead.

> Also in the mail archives, some reference is made to documentation
> about creating your own inittab file. Does that documentation still
> exist somewhere? I've looked but can't find it.

You should refer to the Busybox documentation, as this is not something
related to Buildroot directly. See examples/inittab in Busybox sources.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] inittab for Busybox

[Charles Krinke]

I want to second what Thomas said. I have been through both the sysvinit
inittab and the busybox inittab and the busybox one works fine. As I recall,
it also has a tiny variation in the location of the RC directory, so you
might look at those differences which I think also depens on the skeleton
base files.
On Mar 15, 2011 10:07 AM, "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Tue, 15 Mar 2011 12:37:01 -0400
> "Heyendal, Carl" <CHeyendal@stanleyworks.com> wrote:
>
>> I have not enabled support for sysvinit in my project. Could someone
>> tell me why Buildroot adds an inittab file that's incompatible with
>> BusyBox? I looked at the mail archives but no one seems to have asked
>> that question before.
>
> How do you see that the inittab is incompatible with Busybox ? Many of
> us use it every day without problem.
>
> When sysvinit is not selected, fs/skeleton/etc/inittab is the inittab
> that is used, and it is compatible with Busybox init.
>
> When sysvinit is selected, package/sysvinit/inittab is used instead.
>
>> Also in the mail archives, some reference is made to documentation
>> about creating your own inittab file. Does that documentation still
>> exist somewhere? I've looked but can't find it.
>
> You should refer to the Busybox documentation, as this is not something
> related to Buildroot directly. See examples/inittab in Busybox sources.
>
> Regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110315/ff3c1830/attachment.html>

[Buildroot] inittab for Busybox

[Heyendal, Carl]

Comments below.....
/carl h.

> -----Original Message-----
> From: buildroot-bounces at busybox.net [mailto:buildroot-
> bounces at busybox.net] On Behalf Of Thomas Petazzoni
> Sent: March 15, 2011 1:08 PM
> To: buildroot at busybox.net
> Subject: Re: [Buildroot] inittab for Busybox
> 
> Hello,
> 
> On Tue, 15 Mar 2011 12:37:01 -0400
> "Heyendal, Carl" <CHeyendal@stanleyworks.com> wrote:
> 
> > I have not enabled support for sysvinit in my project. Could someone
> > tell me why Buildroot adds an inittab file that's incompatible with
> > BusyBox? I looked at the mail archives but no one seems to have asked
> > that question before.
> 
> How do you see that the inittab is incompatible with Busybox ? Many of
> us use it every day without problem.

[Heyendal, Carl] 
Hmmmm....I unselected the sysvinit option in busybox and recompiled from
Buildroot. But there was still an incompatible inittab file being used. I know 
Buildroot picked up my changes in Busybox because I also added support for klogd
which got reflected in the newer inittab file.

Here's my inittab file that Buildroot added to /etc:

	# /etc/inittab
	#
	# This inittab is a basic inittab sample for sysvinit, which mimics
	# Buildroot's default inittab for Busybox.
	id:1:initdefault:

	proc::sysinit:/bin/mount -t proc proc /proc
	rwmo::sysinit:/bin/mount -o remount,rw /
	dpts::sysinit:/bin/mkdir -p /dev/pts
	moun::sysinit:/bin/mount -a
	host::sysinit:/bin/hostname -F /etc/hostname
	init::sysinit:/etc/init.d/rcS

	1:1:respawn:/sbin/getty 38400 tty1
	2:1:respawn:/sbin/getty 38400 tty2

	ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100 # GENERIC_SERIAL

	# Logging junk
	mess::sysinit:/bin/touch /var/log/messages
	sysl:1:respawn:/sbin/syslogd -n -m 0
	klog:1:respawn:/sbin/klogd -n

	# Stuff to do for the 3-finger salute
	rebo::ctrlaltdel:/sbin/reboot

	# Stuff to do before rebooting
	sklo:6:wait:/usr/bin/killall klogd
	ssys:6:wait:/usr/bin/killall syslogd
	umou:6:wait:/bin/umount -a -r
	swap:6:wait:/sbin/swapoff -a

Here's some debug output from running this inittab file:

	Bad inittab entry at line 5
	can't open /dev/proc: No such file or directory
	can't open /dev/rwmo: No such file or directory
	can't open /dev/dpts: No such file or directory
	can't open /dev/moun: No such file or directory
	can't open /dev/host: No such file or directory
	can't open /dev/init: No such file or directory
	can't open /dev/mess: No such file or directory
	can't open /dev/sklo: No such file or directory
	can't open /dev/ssys: No such file or directory
	can't open /dev/umou: No such file or directory
	can't open /dev/swap: No such file or directory
	can't open /dev/1: No such file or directory
	can't open /dev/2: No such file or directory
	can't open /dev/S0: No such file or directory
	can't open /dev/sysl: No such file or directory
	can't open /dev/klog: No such file or directory

Clearly it's not compatible. Note the above file comment:
"This inittab is a basic inittab sample for sysvinit"

> 
> When sysvinit is not selected, fs/skeleton/etc/inittab is the inittab
> that is used, and it is compatible with Busybox init.
> 
> When sysvinit is selected, package/sysvinit/inittab is used instead.
> 

[Heyendal, Carl] 
Do I have to change the inittab file manually? Or should I go a global 
recompile? Or delete the filesystem and recompile?

> > Also in the mail archives, some reference is made to documentation
> > about creating your own inittab file. Does that documentation still
> > exist somewhere? I've looked but can't find it.
> 
> You should refer to the Busybox documentation, as this is not something
> related to Buildroot directly. See examples/inittab in Busybox sources.
> 

[Heyendal, Carl] 
Good to know.

> Regards,
> 
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] inittab for Busybox

[Thomas Petazzoni]

Hello,

On Tue, 15 Mar 2011 14:14:09 -0400
"Heyendal, Carl" <CHeyendal@stanleyworks.com> wrote:

> Hmmmm....I unselected the sysvinit option in busybox and recompiled
> from Buildroot.

Yes, but you didn't do "make clean; make", so the etc/inittab in the
target is still the one from sysvinit.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] inittab for Busybox

[Heyendal, Carl]

Really!! 'make clean' from Buildroot directory? That's a complete rebuild!!

How come then it picked up my other Busybox change without having to do a global re-build?

thanx
/carl h.

> -----Original Message-----
> From: Thomas Petazzoni [mailto:thomas.petazzoni at free-electrons.com]
> Sent: March 15, 2011 2:22 PM
> To: Heyendal, Carl
> Cc: buildroot at busybox.net
> Subject: Re: [Buildroot] inittab for Busybox
> 
> Hello,
> 
> On Tue, 15 Mar 2011 14:14:09 -0400
> "Heyendal, Carl" <CHeyendal@stanleyworks.com> wrote:
> 
> > Hmmmm....I unselected the sysvinit option in busybox and recompiled
> > from Buildroot.
> 
> Yes, but you didn't do "make clean; make", so the etc/inittab in the
> target is still the one from sysvinit.
> 
> Regards,
> 
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

[Buildroot] inittab for Busybox

[Thomas Petazzoni]

Hello,

On Tue, 15 Mar 2011 14:32:07 -0400
"Heyendal, Carl" <CHeyendal@stanleyworks.com> wrote:

> Really!! 'make clean' from Buildroot directory? That's a complete
> rebuild!!

Yes, it is. For now, Buildroot is "nothing" more but a tool that
automates the process of building an embedded Linux system. It is not
very smart, so it cannot remove packages that have been installed, or
revert changes that have been made to the target filesystem.

My view on this: Buildroot has been more or less abandonned until late
2008/early 2009, when Peter took over the maintainership of the
project. Since that time, our main goal was to clean up the existing
code base, keeping the existing feature set (in fact, we added a bunch
of features as well, but we didn't fundamentaly changed how Buildroot
works). Now that this cleanup process is mostly over, I'd say that
solving the issue you're facing here is now on the top priorities of
the project. At least it's where it is on my own Buildroot TODO list.
But there a fairly huge and complex amount of work to do here, so it
isn't going to happen overnight.

> How come then it picked up my other Busybox change without having to
> do a global re-build?

Because when you change the Busybox configuration, we have a make
dependency that makes sure that Busybox gets rebuilt/reinstalled.

But that does not happen when you unselect sysvinit.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] inittab for Busybox

[Heyendal, Carl]

Thanks Thomas. Good explanation. Please don't interpret my thoughts 
as complaints. It is a useful and helpful tool.

thanx
/carl


> -----Original Message-----
> From: buildroot-bounces at busybox.net [mailto:buildroot-
> bounces at busybox.net] On Behalf Of Thomas Petazzoni
> Sent: March 15, 2011 4:06 PM
> To: buildroot at busybox.net
> Subject: Re: [Buildroot] inittab for Busybox
> 
> Hello,
> 
> On Tue, 15 Mar 2011 14:32:07 -0400
> "Heyendal, Carl" <CHeyendal@stanleyworks.com> wrote:
> 
> > Really!! 'make clean' from Buildroot directory? That's a complete
> > rebuild!!
> 
> Yes, it is. For now, Buildroot is "nothing" more but a tool that
> automates the process of building an embedded Linux system. It is not
> very smart, so it cannot remove packages that have been installed, or
> revert changes that have been made to the target filesystem.
> 
> My view on this: Buildroot has been more or less abandonned until late
> 2008/early 2009, when Peter took over the maintainership of the
> project. Since that time, our main goal was to clean up the existing
> code base, keeping the existing feature set (in fact, we added a bunch
> of features as well, but we didn't fundamentaly changed how Buildroot
> works). Now that this cleanup process is mostly over, I'd say that
> solving the issue you're facing here is now on the top priorities of
> the project. At least it's where it is on my own Buildroot TODO list.
> But there a fairly huge and complex amount of work to do here, so it
> isn't going to happen overnight.
> 
> > How come then it picked up my other Busybox change without having to
> > do a global re-build?
> 
> Because when you change the Busybox configuration, we have a make
> dependency that makes sure that Busybox gets rebuilt/reinstalled.
> 
> But that does not happen when you unselect sysvinit.
> 
> Regards,
> 
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Buildroot in use

[Steve Calfee]

----- Original Message ----

> From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> 
> Hello,
> 
> On Tue, 15 Mar 2011 14:32:07 -0400
> "Heyendal, Carl" <CHeyendal@stanleyworks.com>  wrote:
> 
> > Really!! 'make clean' from Buildroot directory? That's a  complete
> > rebuild!!
> 
> Yes, it is. For now, Buildroot is "nothing"  more but a tool that
> automates the process of building an embedded Linux  system. It is not
> very smart, so it cannot remove packages that have been  installed, or
> revert changes that have been made to the target  filesystem.
> 
> My view on this: Buildroot has been more or less abandonned  until late
> 2008/early 2009, when Peter took over the maintainership of  the
> project. Since that time, our main goal was to clean up the  existing
> code base, keeping the existing feature set (in fact, we added a  bunch
> of features as well, but we didn't fundamentaly changed how  Buildroot
> works). Now that this cleanup process is mostly over, I'd say  that
> solving the issue you're facing here is now on the top priorities  of
> the project. At least it's where it is on my own Buildroot TODO  list.
> But there a fairly huge and complex amount of work to do here, so  it
> isn't going to happen overnight.
> 

I think a general discussion of how we use buildroot and what we would like to 
see is in order. It seems the framework is stabilizing and useful (thanks guys).

It seems in my use that I am either working on the kernel or configuring a 
system with packages (rootfs). make clean is unbearable where it removes the 
toolchain etc. 


So what I do is I git pull one tree just for my toolchain and compiler. I 
configure and build it without bootstraps, busybox, kernel etc. If I need to 
change a toolchain option I go back to this tree and fix it. This build becomes 
my "external toolchain".

I then git pull another tree which uses that external toolchain. Make clean is 
now much less painful.

During development it is common to want to change stuff in the "skeleton" 
filesystem - add scripts, configure things etc. This is kind of painful from 
within the buildroot framework, with no clear way to force an update to the 
rootfs image etc. So what I do is I create a skeleton directory for my board. In 
the post build script I copy my skeleton on top of the existing buildroot 
constructed skeleton. In this way I only have the files I care about in my board 
skeleton, they are updated every build etc.

I have not moved my bsp to the new board/company/bsp file system yet, but here 
is my post install script:
#!/bin/bash
#
# script which runs before creating rootfs
#
#
MAINDIR=${1}/../../
SRCDIR=${MAINDIR}"target/device/beagleboard/skeleton/*"
DESTDIR=${1}
echo "***************patching some stuff in " ${DESTDIR} from ${SRCDIR}
#echo "DESTDIR " ${DESTDIR}
#echo "SRCDIR " ${SRCDIR}
#ls -l ${SRCDIR} ${SRCDIR}"/etc"
cp -rv ${SRCDIR} ${DESTDIR}
echo "end of userdefined script before packing rootfs"


I am curious how people do development with cutting edge kernels like 
linux-next? Do you do it completely removed from buildroot and just use the 
external tools? Do you use some kind of sym-link to point to the other kernel 
git tree?

Regards, Steve



      

[Buildroot] Buildroot in use

[Heyendal, Carl]

...at least for the kernel anyways. Maybe not for busybox.

> -----Original Message-----
> From: Heyendal, Carl
> Sent: March 16, 2011 3:22 PM
> To: 'Steve Calfee'
> Subject: RE: [Buildroot] Buildroot in use
> 
> Good advice Steve. Thanks for the tip.
> 
> Another thing I've noticed when I do 'make clean' from Buildroot home
> directory is that the configuration changes back to its defaults for
> both the kernel and busybox. Any changes I made are gone after a make
> clean. Should I need to copy my .config's before a rebuild?
> 
> /carl h.
> 
> 
> 
> > -----Original Message-----
> > From: buildroot-bounces at busybox.net [mailto:buildroot-
> > bounces at busybox.net] On Behalf Of Steve Calfee
> > Sent: March 16, 2011 12:44 PM
> > To: Thomas Petazzoni; buildroot at busybox.net
> > Subject: [Buildroot] Buildroot in use
> >
> > ----- Original Message ----
> >
> > > From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > >
> > > Hello,
> > >
> > > On Tue, 15 Mar 2011 14:32:07 -0400
> > > "Heyendal, Carl" <CHeyendal@stanleyworks.com>  wrote:
> > >
> > > > Really!! 'make clean' from Buildroot directory? That's a
> complete
> > > > rebuild!!
> > >
> > > Yes, it is. For now, Buildroot is "nothing"  more but a tool that
> > > automates the process of building an embedded Linux  system. It is
> > not
> > > very smart, so it cannot remove packages that have been  installed,
> > or
> > > revert changes that have been made to the target  filesystem.
> > >
> > > My view on this: Buildroot has been more or less abandonned  until
> > late
> > > 2008/early 2009, when Peter took over the maintainership of  the
> > > project. Since that time, our main goal was to clean up the
> existing
> > > code base, keeping the existing feature set (in fact, we added a
> > bunch
> > > of features as well, but we didn't fundamentaly changed how
> > Buildroot
> > > works). Now that this cleanup process is mostly over, I'd say  that
> > > solving the issue you're facing here is now on the top priorities
> of
> > > the project. At least it's where it is on my own Buildroot TODO
> > list.
> > > But there a fairly huge and complex amount of work to do here, so
> it
> > > isn't going to happen overnight.
> > >
> >
> > I think a general discussion of how we use buildroot and what we
> would
> > like to
> > see is in order. It seems the framework is stabilizing and useful
> > (thanks guys).
> >
> > It seems in my use that I am either working on the kernel or
> > configuring a
> > system with packages (rootfs). make clean is unbearable where it
> > removes the
> > toolchain etc.
> >
> >
> > So what I do is I git pull one tree just for my toolchain and
> compiler.
> > I
> > configure and build it without bootstraps, busybox, kernel etc. If I
> > need to
> > change a toolchain option I go back to this tree and fix it. This
> build
> > becomes
> > my "external toolchain".
> >
> > I then git pull another tree which uses that external toolchain. Make
> > clean is
> > now much less painful.
> >
> > During development it is common to want to change stuff in the
> > "skeleton"
> > filesystem - add scripts, configure things etc. This is kind of
> painful
> > from
> > within the buildroot framework, with no clear way to force an update
> to
> > the
> > rootfs image etc. So what I do is I create a skeleton directory for
> my
> > board. In
> > the post build script I copy my skeleton on top of the existing
> > buildroot
> > constructed skeleton. In this way I only have the files I care about
> in
> > my board
> > skeleton, they are updated every build etc.
> >
> > I have not moved my bsp to the new board/company/bsp file system yet,
> > but here
> > is my post install script:
> > #!/bin/bash
> > #
> > # script which runs before creating rootfs
> > #
> > #
> > MAINDIR=${1}/../../
> > SRCDIR=${MAINDIR}"target/device/beagleboard/skeleton/*"
> > DESTDIR=${1}
> > echo "***************patching some stuff in " ${DESTDIR} from
> ${SRCDIR}
> > #echo "DESTDIR " ${DESTDIR}
> > #echo "SRCDIR " ${SRCDIR}
> > #ls -l ${SRCDIR} ${SRCDIR}"/etc"
> > cp -rv ${SRCDIR} ${DESTDIR}
> > echo "end of userdefined script before packing rootfs"
> >
> >
> > I am curious how people do development with cutting edge kernels like
> > linux-next? Do you do it completely removed from buildroot and just
> use
> > the
> > external tools? Do you use some kind of sym-link to point to the
> other
> > kernel
> > git tree?
> >
> > Regards, Steve
> >
> >
> >
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Buildroot in use

[William Wagner]

On 16/03/2011 16:44, Steve Calfee wrote:
> ----- Original Message ----
>
>> From: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>>
>> Hello,
>>
>> On Tue, 15 Mar 2011 14:32:07 -0400
>> "Heyendal, Carl"<CHeyendal@stanleyworks.com>   wrote:
>>
>>> Really!! 'make clean' from Buildroot directory? That's a  complete
>>> rebuild!!
>> Yes, it is. For now, Buildroot is "nothing"  more but a tool that
>> automates the process of building an embedded Linux  system. It is not
>> very smart, so it cannot remove packages that have been  installed, or
>> revert changes that have been made to the target  filesystem.
>>
>> My view on this: Buildroot has been more or less abandonned  until late
>> 2008/early 2009, when Peter took over the maintainership of  the
>> project. Since that time, our main goal was to clean up the  existing
>> code base, keeping the existing feature set (in fact, we added a  bunch
>> of features as well, but we didn't fundamentaly changed how  Buildroot
>> works). Now that this cleanup process is mostly over, I'd say  that
>> solving the issue you're facing here is now on the top priorities  of
>> the project. At least it's where it is on my own Buildroot TODO  list.
>> But there a fairly huge and complex amount of work to do here, so  it
>> isn't going to happen overnight.
>>
> I think a general discussion of how we use buildroot and what we would like to
> see is in order. It seems the framework is stabilizing and useful (thanks guys).
>
> It seems in my use that I am either working on the kernel or configuring a
> system with packages (rootfs). make clean is unbearable where it removes the
> toolchain etc.

I agree, this is the only part of the build that takes any time. It 
would be great if there was a way of cleaning back to only the toolchain 
built. I am getting round this at the moment by using an external 
crosstools-NG toolchain in most projects, which gives much the same 
functionality, just would be easier for a beginner to understand if 
buildroot could do this itself.

Given how we support external toolchains would it not be possible to be 
able to clean everything but toolchain (Which I think only gets produced 
if you have an internal toolchain) and then when you build again it does 
the same as for an external toolchain and copies the files into staging etc?

>
> So what I do is I git pull one tree just for my toolchain and compiler. I
> configure and build it without bootstraps, busybox, kernel etc. If I need to
> change a toolchain option I go back to this tree and fix it. This build becomes
> my "external toolchain".
>
> I then git pull another tree which uses that external toolchain. Make clean is
> now much less painful.
>
> During development it is common to want to change stuff in the "skeleton"
> filesystem - add scripts, configure things etc. This is kind of painful from
> within the buildroot framework, with no clear way to force an update to the
> rootfs image etc. So what I do is I create a skeleton directory for my board. In
> the post build script I copy my skeleton on top of the existing buildroot
> constructed skeleton. In this way I only have the files I care about in my board
> skeleton, they are updated every build etc.

I do something very similar. The default skeleton is fine for most 
things, there are just a couple of customisations I want. Recent work in 
this area is already adding config options for some of what I want. A 
custom board script can then make any further modifications.

Would be great to have an example of recommended practice checked in for 
people to see/copy. Also would be great to remove the xtensa bits as 
they are just confusing. Perhaps we should convert that over to the new 
scheme?


Will

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] Buildroot in use

[Heyendal, Carl]

If starting from scratch, downloading and building 2 Buildroots (one for the toolchain, and the other for the rest of the stuff) sounds reasonable. But refining the notion a bit more, if you have already built the entire Buildroot tree like I have done already, is it possible to break off the toolchain leg of the tree and move it somewhere else. Then of course configure the external toolchain option after that. 

/carl

> -----Original Message-----
> From: buildroot-bounces at busybox.net [mailto:buildroot-
> bounces at busybox.net] On Behalf Of William Wagner
> Sent: March 17, 2011 8:15 AM
> To: Steve Calfee
> Cc: Thomas Petazzoni; buildroot at busybox.net
> Subject: Re: [Buildroot] Buildroot in use
> 
> On 16/03/2011 16:44, Steve Calfee wrote:
> > ----- Original Message ----
> >
> >> From: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> >>
> >> Hello,
> >>
> >> On Tue, 15 Mar 2011 14:32:07 -0400
> >> "Heyendal, Carl"<CHeyendal@stanleyworks.com>   wrote:
> >>
> >>> Really!! 'make clean' from Buildroot directory? That's a  complete
> >>> rebuild!!
> >> Yes, it is. For now, Buildroot is "nothing"  more but a tool that
> >> automates the process of building an embedded Linux  system. It is
> not
> >> very smart, so it cannot remove packages that have been  installed,
> or
> >> revert changes that have been made to the target  filesystem.
> >>
> >> My view on this: Buildroot has been more or less abandonned  until
> late
> >> 2008/early 2009, when Peter took over the maintainership of  the
> >> project. Since that time, our main goal was to clean up the
> existing
> >> code base, keeping the existing feature set (in fact, we added a
> bunch
> >> of features as well, but we didn't fundamentaly changed how
> Buildroot
> >> works). Now that this cleanup process is mostly over, I'd say  that
> >> solving the issue you're facing here is now on the top priorities
> of
> >> the project. At least it's where it is on my own Buildroot TODO
> list.
> >> But there a fairly huge and complex amount of work to do here, so
> it
> >> isn't going to happen overnight.
> >>
> > I think a general discussion of how we use buildroot and what we
> would like to
> > see is in order. It seems the framework is stabilizing and useful
> (thanks guys).
> >
> > It seems in my use that I am either working on the kernel or
> configuring a
> > system with packages (rootfs). make clean is unbearable where it
> removes the
> > toolchain etc.
> 
> I agree, this is the only part of the build that takes any time. It
> would be great if there was a way of cleaning back to only the
> toolchain
> built. I am getting round this at the moment by using an external
> crosstools-NG toolchain in most projects, which gives much the same
> functionality, just would be easier for a beginner to understand if
> buildroot could do this itself.
> 
> Given how we support external toolchains would it not be possible to be
> able to clean everything but toolchain (Which I think only gets
> produced
> if you have an internal toolchain) and then when you build again it
> does
> the same as for an external toolchain and copies the files into staging
> etc?
> 
> >
> > So what I do is I git pull one tree just for my toolchain and
> compiler. I
> > configure and build it without bootstraps, busybox, kernel etc. If I
> need to
> > change a toolchain option I go back to this tree and fix it. This
> build becomes
> > my "external toolchain".
> >
> > I then git pull another tree which uses that external toolchain. Make
> clean is
> > now much less painful.
> >
> > During development it is common to want to change stuff in the
> "skeleton"
> > filesystem - add scripts, configure things etc. This is kind of
> painful from
> > within the buildroot framework, with no clear way to force an update
> to the
> > rootfs image etc. So what I do is I create a skeleton directory for
> my board. In
> > the post build script I copy my skeleton on top of the existing
> buildroot
> > constructed skeleton. In this way I only have the files I care about
> in my board
> > skeleton, they are updated every build etc.
> 
> I do something very similar. The default skeleton is fine for most
> things, there are just a couple of customisations I want. Recent work
> in
> this area is already adding config options for some of what I want. A
> custom board script can then make any further modifications.
> 
> Would be great to have an example of recommended practice checked in
> for
> people to see/copy. Also would be great to remove the xtensa bits as
> they are just confusing. Perhaps we should convert that over to the new
> scheme?
> 
> 
> Will
> 
> --
> -----------------------------------------------------------------------
> -
> Will Wagner
> will_wagner at carallon.com
> Development Manager                      Office Tel: +44 (0)20 7371
> 2032
> Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14
> 0DA
> -----------------------------------------------------------------------
> -
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Buildroot in use

[Steve Calfee]

On 03/17/11 06:53, Heyendal, Carl wrote:
> If starting from scratch, downloading and building 2 Buildroots (one for the toolchain, and the other for the rest of the stuff) sounds reasonable. But refining the notion a bit more, if you have already built the entire Buildroot tree like I have done already, is it possible to break off the toolchain leg of the tree and move it somewhere else. Then of course configure the external toolchain option after that.
>
> /carl
>

I believe that the gcc that you have built has a few built-in paths, so 
you cannot just move the compiler stuff to another file tree.

What you can do is the second part of my suggestion, just create another 
buildroot tree and point its external toolchain to the one you now have 
built. It will leave some garbage in the original tree, but disk space 
is pretty cheap. In the new tree you will have faster make clean; 
make.... cycles since the external toolchain will not be deleted.

Regards, Steve

[Buildroot] Buildroot in use

[Heyendal, Carl]

Makes sense.

Another thing I have noticed that is frustrating is that a 'make clean' acts more like 'make distclean' and therefore you lose any configuration changes you have previously made. 

As a work around, can I copy the relevant .configs before the 'make clean' and add them back once the rebuild is complete (assumed that I need to delete the .stamp_compiled files as well)?

/carl h. 

> -----Original Message-----
> From: buildroot-bounces at busybox.net [mailto:buildroot-
> bounces at busybox.net] On Behalf Of Steve Calfee
> Sent: March 17, 2011 1:17 PM
> To: buildroot at busybox.net
> Subject: Re: [Buildroot] Buildroot in use
> 
> On 03/17/11 06:53, Heyendal, Carl wrote:
> > If starting from scratch, downloading and building 2 Buildroots (one
> for the toolchain, and the other for the rest of the stuff) sounds
> reasonable. But refining the notion a bit more, if you have already
> built the entire Buildroot tree like I have done already, is it
> possible to break off the toolchain leg of the tree and move it
> somewhere else. Then of course configure the external toolchain option
> after that.
> >
> > /carl
> >
> 
> I believe that the gcc that you have built has a few built-in paths, so
> you cannot just move the compiler stuff to another file tree.
> 
> What you can do is the second part of my suggestion, just create
> another
> buildroot tree and point its external toolchain to the one you now have
> built. It will leave some garbage in the original tree, but disk space
> is pretty cheap. In the new tree you will have faster make clean;
> make.... cycles since the external toolchain will not be deleted.
> 
> Regards, Steve
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Buildroot in use

[Steve Calfee]

On 03/17/11 12:42, Heyendal, Carl wrote:
> Makes sense.
>
> Another thing I have noticed that is frustrating is that a 'make clean' acts more like 'make distclean' and therefore you lose any configuration changes you have previously made.
>
> As a work around, can I copy the relevant .configs before the 'make clean' and add them back once the rebuild is complete (assumed that I need to delete the .stamp_compiled files as well)?
>
> /carl h.
>
Hi Carl,

Please don't top post and trim stuff after your message.

Yes, "make clean" destroys buildroot's .config. I have a "bsp" type 
directory with stuff specifically for the project I am working on. I do 
a sym-link from configs/beagleboard_defconfig to my bsp config. Then 
after a make clean I do a "make beagleboard_defconfig" to copy in my 
saved configuration. I also put the linux and u-boot and whatever 
configs in my bsp and point to the appropriate config in the buildroot 
.config. Dont forget to update your bsp config whenever you change 
buildroot with a make menuconfig.

Regards, Steve

[Buildroot] Buildroot in use

[Thomas Petazzoni]

On Thu, 17 Mar 2011 14:50:03 -0700
Steve Calfee <stevecalfee@gmail.com> wrote:

> Yes, "make clean" destroys buildroot's .config. 

No, it doesn't.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Buildroot in use

[Thomas Petazzoni]

Hello,

On Thu, 17 Mar 2011 15:42:58 -0400
"Heyendal, Carl" <CHeyendal@stanleyworks.com> wrote:

> Another thing I have noticed that is frustrating is that a 'make
> clean' acts more like 'make distclean' and therefore you lose any
> configuration changes you have previously made. 

Not really correct: "make clean" keeps the Buildroot configuration. But
it's true it removes the kernel, Busybox and uClibc configuration files
from their respective build directories.

There has been some proposal to add some sort of "saveconfigs" target,
but the semantic wasn't that all clear.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Buildroot in use

[Thomas Petazzoni]

On Thu, 17 Mar 2011 10:17:16 -0700
Steve Calfee <stevecalfee@gmail.com> wrote:

> I believe that the gcc that you have built has a few built-in paths,
> so you cannot just move the compiler stuff to another file tree.

As long as the sysroot remains at the same relative location compared
to the compiler, you're fine with a toolchain based on gcc 4.x : you
can move it around if you wish. If think Yann E. Morin could give a few
more details here.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Buildroot in use

[Grant Edwards]

On 2011-03-17, Heyendal, Carl <CHeyendal@stanleyworks.com> wrote:

> If starting from scratch, downloading and building 2 Buildroots (one
> for the toolchain, and the other for the rest of the stuff) sounds
> reasonable. But refining the notion a bit more, if you have already
> built the entire Buildroot tree like I have done already, is it
> possible to break off the toolchain leg of the tree and move it
> somewhere else. Then of course configure the external toolchain
> option after that.

I used to try to do that with a complicated shell script that had one
option to use buildroot to build the toolchain, move it somewhere else
and fix it up. Another option would use buildroot to build the kernel
and a third would build the rootfs using that external toolchain.

After fighting with that for a month or two, I finally gave up.  Now I
use crosstool-ng to build the external toolchain; I build the kernel
separately; and I use buildroot to build only the rootfs.

It takes a little extra time to set up the three seperate build
scripts, but those three scripts are dead-simple and way easier to
maintain and use.

-- 
Grant Edwards               grant.b.edwards        Yow! I know things about
                                  at               TROY DONAHUE that can't
                              gmail.com            even be PRINTED!!

[Buildroot] Xtensa support

[Thomas Petazzoni]

Hello,

On Thu, 17 Mar 2011 12:14:54 +0000
William Wagner <will_wagner@carallon.com> wrote:

> Would be great to have an example of recommended practice checked in
> for people to see/copy.

Yeah, I could document how I build the latest system I've done.

> Also would be great to remove the xtensa bits as they are just
> confusing. Perhaps we should convert that over to the new scheme?

Well, the Xtensa bits are a bit complicated, because Xtensa supports
configurable CPU cores, so they have some strange Perl scripts that are
needed when building the toolchain. But this Xtensa support has never
been updated since it has been merged quite some time ago, and no
active contributor has any Xtensa hardware platform to test the changes
on, so maybe we could drop the support for Xtensa altogether.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Xtensa support

[Piet Delaney]

Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 17 Mar 2011 12:14:54 +0000
> William Wagner <will_wagner@carallon.com> wrote:
> 
>> Would be great to have an example of recommended practice checked in
>> for people to see/copy.
> 
> Yeah, I could document how I build the latest system I've done.
> 
>> Also would be great to remove the xtensa bits as they are just
>> confusing. Perhaps we should convert that over to the new scheme?
> 
> Well, the Xtensa bits are a bit complicated, because Xtensa supports
> configurable CPU cores, so they have some strange Perl scripts that are
> needed when building the toolchain. But this Xtensa support has never
> been updated since it has been merged quite some time ago, and no
> active contributor has any Xtensa hardware platform to test the changes
> on, so maybe we could drop the support for Xtensa altogether.

Hi Thomas:

We appeared to have had some git import problems during our last merge and I had to
revert back to an older snapshot until we re-syncing with the central git repo again.

I've been maintain bug fixes for binutils and gcc there until we have a chance to
try a new merge.

	http://git.linux-xtensa.org/cgi-bin/git.cgi?p=buildroot/buildroot-xtensa-HiFi2-Snapshot.git;a=shortlog;h=snapshot_2%2BSMP


While maintaining our 2nd buildroot snapshot I kept wiki notes on issues I was having with buildroot:

	http://wiki.linux-xtensa.org/index.php/HiFi-2_snapshot_2_SMP_Snapshot_menuconfig
	http://wiki.linux-xtensa.org/index.php/HiFi-2_snapshot_2_SMP_uclibc-menuconfig


as part of a support blog for building a kernel and root file system that supported target
development of Codec's for our Audio cores.

	http://wiki.linux-xtensa.org/index.php/SMP_HiFi_2_Development_Board

I tried to get our last buildroot merge to work but had bizarre problems when trying to
get the new X code and the development  environment building together. We use the Buildroot
development environment (compiler, debugger, ...) to sort out kernel bugs.

Chris Zankel, Marc Gauthier, and I have recently been discussing cleaning up some
the the Xtensa eccentricity's needed for extensibility. We have quite a few
buildroot git tress and branches and we would also love to get back in sync with
the buildroot central repository. We have a similar story with the kernel git repo,
we are horribly behind in getting in sync with kernel.org.

Christian Zankel recently proposed a few changes in the 'xtensa' branch:

	http://git.linux-xtensa.org/cgi-bin/git.cgi?p=buildroot/buildroot-next.git;a=shortlog;h=xtensa

to address the 'strange' stuff being done to support extensibility.

I've been working about 60 hours a week on a new kernel feature and it's finally working great on our FPGA board.
I expect to have more cycles available in the not to distant future to look more closely at Christian's
change and try merging and/or cherry picking patches from our other git repos to establish a Buildroot with
a working development environment that's in sync with the current buildroot source code.

Perhaps in the next week or two I can start to put some time into getting our buildroot up-to-date.
We would like to upgrade our Pthreads implementation to support NPT and take advantage of the TLS
work that Bob Wilson did here a couple years ago. The current signal based approach is bit crazy
and likely killing performance for our customers heavily using pthreads.

In the mean time perhaps you could provide some guidance on how you would like us to clean
up the approach we are taking. I would appreciate it greatly, while we sort out the problems
bringing up a complete set of packages necessary for development, if the community could
provide their two cents on issues that come up when we discuss them.

Marc, Christian, and I agreed a few weeks ago to upgrade buildroot in a git repo at linux-xtensa.org.
We will be adjusting it with our Xtensa tools and testing it in local a local git repo as a
staging ground for submission upstream.

Reading over this thread it wasn't clear how Xtensa came up. I also didn't know what
Steve was referring to when he ask Carl not to 'top post'; hope I'm not doing that now.
Hopefully we can minimize the problems with the 'strange' perl scripts by documenting it
well and keeping it as simple as possible. Any suggestions you have would be greatly appreciated.

In summary, we are just getting back to getting buildroot up-to-date and
would appropriate your support when trying to pull this off.

Sorry for the last posting, our IT department changed my outgoing email addresses
and messed up my mailman access.

-piet

> 
> Regards,
> 
> Thomas

[Buildroot] Xtensa support

[Thomas Petazzoni]

Hello Piet,

Le Mon, 21 Mar 2011 14:18:45 -0700,
Piet Delaney <pdelaney@tensilica.com> a ?crit :

> In summary, we are just getting back to getting buildroot up-to-date
> and would appropriate your support when trying to pull this off.

Do you have any news about the Xtensa support in Buildroot ? Are you
still interested in having this support in the mainline Buildroot ?

I am remain concerned by the fact that we carry some special stuff to
support Xtensa, but he Xtensa architecture support has never been
updated since it was merged in Buildroot. Of course, it is our goal to
support configurable architectures such as Xtensa, but the support for
those architectures needs to be actively maintained in Buildroot
upstream. Unfortunately, none of the main Buildroot developers have
Xtensa-capable hardware, so it's a bit hard to contribute to this
effort.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Xtensa support

[Marc Gauthier]

Hi Thomas,

Thomas Petazzoni wrote:
> Hello Piet,
>
> Le Mon, 21 Mar 2011 14:18:45 -0700,
> Piet Delaney <pdelaney@tensilica.com> a ?crit :
>
>> In summary, we are just getting back to getting buildroot up-to-date
>> and would appropriate your support when trying to pull this off.
>
> Do you have any news about the Xtensa support in Buildroot ? Are you
> still interested in having this support in the mainline Buildroot ?


We're certainly still interested.  And have been maintaining buildroot
in our own trees.  However, we're temporarily short on people in that
area at the moment, so although we and our customers have been more
active lately on buildroot for Xtensa, submitting patches back has been
embarassingly slow.  (Btw, if you have expertise and interest in
toolchains or OS, we have openings in California ;-)

If you're curious, some of it is here, but far from cleaned up!!:

http://git.linux-xtensa.org/cgi-bin/git.cgi?p=buildroot/buildroot-new.git;a=shortlog;h=Xtensa-Patches

and an earlier version in buildroot-next.


> I am remain concerned by the fact that we carry some special stuff to
> support Xtensa, but he Xtensa architecture support has never been
> updated since it was merged in Buildroot. Of course, it is our goal to
> support configurable architectures such as Xtensa, but the support for
> those architectures needs to be actively maintained in Buildroot
> upstream.

Yes.  For example, some of the xtensa files under /target/ need to be
moved and/or refactored.  And a defconfig added in /configs/.
(Hopefully you now take pull requests?  easier than patches)


> Unfortunately, none of the main Buildroot developers have
> Xtensa-capable hardware, so it's a bit hard to contribute to this
> effort.


Do I hear volunteers? :-)  We've discussed sending out boards in the
past, but that turned out to be a bit more sideline effort than hoped.
Looks like an easier approach is to use an instruction set simulator.
It can boot Linux, so should be fine.  If you're interested I'll be
very happy to share the details.  Helping hands are most appreciated.


Merci!
-Marc



> Best regards,
>
> Thomas

[Buildroot] Xtensa support

[Thomas Petazzoni]

Hello Marc,

Le Tue, 20 Sep 2011 21:01:35 -0700,
Marc Gauthier <marc@tensilica.com> a ?crit :

> If you're curious, some of it is here, but far from cleaned up!!:
> 
> http://git.linux-xtensa.org/cgi-bin/git.cgi?p=buildroot/buildroot-new.git;a=shortlog;h=Xtensa-Patches

Sounds like most of those patches are patches against uClibc, binutils
or gdb. It'd be better to have those patches merged in their respective
upstreams rather than integrating those patches into Buildroot.

> > I am remain concerned by the fact that we carry some special stuff
> > to support Xtensa, but he Xtensa architecture support has never been
> > updated since it was merged in Buildroot. Of course, it is our goal
> > to support configurable architectures such as Xtensa, but the
> > support for those architectures needs to be actively maintained in
> > Buildroot upstream.
> 
> Yes.  For example, some of the xtensa files under /target/ need to be
> moved and/or refactored.  And a defconfig added in /configs/.
> (Hopefully you now take pull requests?  easier than patches)

We do take pull requests, but we like when patches are posted on the
mailing list as well. This is easy to do with a combination of git
pull-request + git send-email. I can share my little script to do that
if you're interested.

> > Unfortunately, none of the main Buildroot developers have
> > Xtensa-capable hardware, so it's a bit hard to contribute to this
> > effort.
> 
> Do I hear volunteers? :-)  We've discussed sending out boards in the
> past, but that turned out to be a bit more sideline effort than hoped.
> Looks like an easier approach is to use an instruction set simulator.
> It can boot Linux, so should be fine.  If you're interested I'll be
> very happy to share the details.  Helping hands are most appreciated.

Having a working emulator setup would definitely be nice. However, to
get volunteers working on something freely, one needs to put some
incentive on the table. And usually, in the embedded space, this
incentive is a nice hardware platform, that the open-source developer
is so happy to receive that he will be interested in contributing. The
charm of having a real hardware platform is a lot higher than the charm
of the emulator, as is the incentive to contribute things :-)

Of course, regardless of whether boards are made available or not, we
will gladly take patches, review them, comment them, and help you
merging as much as possible of the Xtensa support into the mainline
Buildroot.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Xtensa support

[Piet Delaney]

Thomas Petazzoni wrote:

Hi Thomas:

> Hello Marc,
>
> Le Tue, 20 Sep 2011 21:01:35 -0700,
> Marc Gauthier <marc@tensilica.com> a ?crit :
>
>   
>> If you're curious, some of it is here, but far from cleaned up!!:
>>
>> http://git.linux-xtensa.org/cgi-bin/git.cgi?p=buildroot/buildroot-new.git;a=shortlog;h=Xtensa-Patches
>>     
>
> Sounds like most of those patches are patches against uClibc, binutils
> or gdb. It'd be better to have those patches merged in their respective
> upstreams rather than integrating those patches into Buildroot.
>
>   
>>> I am remain concerned by the fact that we carry some special stuff
>>> to support Xtensa, but he Xtensa architecture support has never been
>>> updated since it was merged in Buildroot. Of course, it is our goal
>>> to support configurable architectures such as Xtensa, but the
>>> support for those architectures needs to be actively maintained in
>>> Buildroot upstream.
>>>       
>> Yes.  For example, some of the xtensa files under /target/ need to be
>> moved and/or refactored.  And a defconfig added in /configs/.
>> (Hopefully you now take pull requests?  easier than patches)
>>     
>
> We do take pull requests, but we like when patches are posted on the
> mailing list as well. This is easy to do with a combination of git
> pull-request + git send-email. I can share my little script to do that
> if you're interested.
>
>   
>>> Unfortunately, none of the main Buildroot developers have
>>> Xtensa-capable hardware, so it's a bit hard to contribute to this
>>> effort.
>>>       
>> Do I hear volunteers? :-)  We've discussed sending out boards in the
>> past, but that turned out to be a bit more sideline effort than hoped.
>> Looks like an easier approach is to use an instruction set simulator.
>> It can boot Linux, so should be fine.  If you're interested I'll be
>> very happy to share the details.  Helping hands are most appreciated.
>>     
>
> Having a working emulator setup would definitely be nice. However, to
> get volunteers working on something freely, one needs to put some
> incentive on the table. And usually, in the embedded space, this
> incentive is a nice hardware platform, that the open-source developer
> is so happy to receive that he will be interested in contributing. The
> charm of having a real hardware platform is a lot higher than the charm
> of the emulator, as is the incentive to contribute things :-)
>   
*I also thought having access to "a nice hardware platform' was helpful
for open Buildroot development. My thoughts were that you would be best 
off with
a ML605 that we are currently preparing. They cost about $2,000.00  and can
be configured "concurrently" with multiple VARIANTS. A small set of bit 
streams for
various VARIANT can be stored in the 2GB Flash. We have designed an add 
on daughter
card that has a JTAG connector as well as a high speed FT2232H and support
in our Xtensa Tools environment in the next release.
*
    *  http://www.xilinx.com/products/boards/ml605/reference_designs.htm

This board has an FPGA which I believe is a bit larger that our older LX200
board which supports up to three cores running SMP linux. There boards
cost $8,000 and are is very short supply. I'll send you a jpeg of the ML605
at my desk which I've just set up for FT2232 JTAG development. I'm getting
download speeds of 17MBytes/sec and hope to be at 40Mbytes/sec shortly.
I suspect unlike our linux-xtensa.org mailing list that the buildroot mailer
will reject attachments.
*
*We also have some older development boards that aren't as sexy but might be
of interest. The oldest is a XT2000 which we are discarding but my last 
attempt
at installing a bit stream on wasn't successful. We also have LX60 and 
LX110 boards
that are a bit cheaper than the ML605.  My preference is to beef up the 
ML605
to support 1Gb of memory for customer Linux development and it also makes
it an attractive board for Open Source development.
*
> Of course, regardless of whether boards are made available or not, we
> will gladly take patches, review them, comment them, and help you
> merging as much as possible of the Xtensa support into the mainline
> Buildroot.
>   
* We are having gdb problems that we are currently trying to sort out; 
particularly with
pthreads. I currently suspect changes introduce between binutils-2.20 
and binutils-2.21.

I'll make a uClibc git repo available on linux-xtensa.org with details 
on what's
being done on that front. We need to fix an unresolved symbol that has 
surfaced
recently and perhaps a bit more.

I've recently updated the strace patch but haven't tried it. Your 
current Buildroot
uses a new strace release and needed heavy patching. Once I've got it 
tested I'll
try to get the changes upstream to the strace maintainers and interim 
patches to
your buildroot git repo.

The newer buildroot environment isn't as good for debugging with gdb yet 
and is a bit
less stable. It's a bit rough and needs work. However it's much better 
that our snapshot
from two years ago, that the C development environment is now compatible 
with X11
and large software packages like DDD are easily built for the target.

We need to resolve if the current VARIANT patching mechanism is 
acceptable for the
Buildroot community. It's still in place in the uClibc and gdb 
sub-systems but was removed
from the binutils subsystem when it was moved from the toolchain to 
package directories.
It seems fine to me, do you have any objection to our updating the 
binutils package makefiles
to support Variant patching like we currently to for uClibc and gdb?

I suppose I should keep this relatively short and stop here.

I'll send you the jpeg of the ML605 I'm working on at my desk. I'll Cc 
the buildroot
mailing list but don't expect it to get through. If any developers are 
interested in a copy
write to me or Thomas for a copy.

-piet
*
> Regards,
>
> Thomas
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110921/ed6f5c2c/attachment-0001.html>

[Buildroot] Buildroot in use

[Michael J. Hammel]

On Wed, 2011-03-16 at 09:44 -0700, Steve Calfee wrote:
> I think a general discussion of how we use buildroot and what we would like to 
> see is in order. It seems the framework is stabilizing and useful (thanks guys).

This thread got me thinking about how and why I created BeagleBox, which
is a metabuild that wraps other metabuilds like Buildroot and
Crosstool-NG.  The structure is based on experience from a number of
previous projects I did at work and heavily on what I learned trying to
track down the bits and pieces that work for BeagleBoard.

So I thought it might be of some value to write up a paper on the how's
and why's of it all for metabuilds.  I've placed the paper online for
critique.  

http://www.graphics-muse.org/wiki/pmwiki.php?n=Papers.MetabuildsForEmbeddedDevelopment

I'm open to updates, clarifications, omissions, extensions, etc.  I
expect some to disagree with my analysis and welcome corrections.  I'd
like this to be useful for those new to the field.  I'm also open to
moving this to a more useful site such as elinux.org or Buildroot's web
site if anyone thinks it would be appropriate.

Some of it is very basic if you've been doing this for very long.  The
interesting stuff for the more experienced is in "The Build Workflow"
section and below.
-- 
Michael J. Hammel <buildroot@graphics-muse.org>

[Buildroot] Buildroot in use

[Steve Calfee]

On 03/27/11 12:19, Michael J. Hammel wrote:
> On Wed, 2011-03-16 at 09:44 -0700, Steve Calfee wrote:
>> I think a general discussion of how we use buildroot and what we would like to
>> see is in order. It seems the framework is stabilizing and useful (thanks guys).
>
> This thread got me thinking about how and why I created BeagleBox, which
> is a metabuild that wraps other metabuilds like Buildroot and
> Crosstool-NG.  The structure is based on experience from a number of
> previous projects I did at work and heavily on what I learned trying to
> track down the bits and pieces that work for BeagleBoard.
>
> So I thought it might be of some value to write up a paper on the how's
> and why's of it all for metabuilds.  I've placed the paper online for
> critique.
>
> http://www.graphics-muse.org/wiki/pmwiki.php?n=Papers.MetabuildsForEmbeddedDevelopment
>
Interesting and well formatted document.

I do kernel driver work and find using small, but powerful platforms 
very convenient. Buildroot has evolved to the point where it is "good 
enough". I have seen (and appreciate) all the pain people have gone 
through to get the make system working and easily extended.

I personally don't like the concept of a one-button build scheme for 
actual development. Magic stuff hidden in python scripts just slows 
understanding. However it is very desirable to have a stable platform 
where known things work and I can start customizing from there.

I did a modification for the Dockstar hardware BSP someone else 
submitted and did a half-hearted submittal to the buildroot maintainers. 
I have switched to gmail so I can more easily submit using 
git-send-mail. Someday I will get back to the Dockstar and try again.

I am working on a beagleboardxm right now, and I finally have a decent 
environment for kernel hacking. I will eventually package that up and 
submit it too.

Currently, there are a few sample _defconfigs for actual hardware. They 
are understandably very bare configurations that demonstrate building a 
minimal system. This is good and I wish there were more platforms.

However, most platforms like the Dockstar and beagleboardxm have H/W 
quirks that really require customization and patches to even begin 
reliably/efficiently using them. BBXM has H/W that has really out-run 
the u-boot capabilities - it is getting very bloated supporting things 
like usb, but it needs more, for usbnet support and using mmc instead of 
nand for stuff like saveenv. Then the BBXM has what seems to be a recent 
kernel wide problem where kexec is broken. So supporting fast nfs and 
kernel updates is possible, but tricky.

I would like to ask Peter and Thomas what they think of changing the way 
board support packages are handled. I think that buildroot also needs to 
support more complete BSP packages which have common desires (booting 
for USB or booting from NFS) available as options. But this is not great 
for buildroot because it adds more downloads in a default git pull, it 
adds bit-rotting code for BSPs, and puts a bigger burden on the core 
buildroot maintainers.

What I propose is that BSPs be added just like any other package. A few 
changes to the buildroot config would allow linking in the new_defconfig 
for selected packages. The current buildroot config supports selecting 
toolchain, kernel, u-boot, busybox etc, configs, locations of patches 
for each, location of external placement of each, etc. As well as handy 
skeleton updates or additions.  It would be nice if there was a way to 
add some BSP configuration options - I think the config.in was removed 
when the bsps were moved from target/device/* to board/manu/*.

Handling BSPs as packages would enable someone like me to have a github 
git tree for a bsp, or put in the buildroot download a tar file which 
can be selected, etc just like any other package. This way when a 
developer pulls a new version of buildroot he is not also pulling in 
lots of uninteresting (and possibly quite large) BSPs. But he can select 
one that is very close to what he wants to use and get a more functional 
initial package.

Since a complete set of configurations would be part of the package, bit 
rot could be slowed. The package would select the latest version of each 
major component that it was tested and built against. In the future if 
someone wants to use an unsupported package, he may be able to build it 
with old configurations and have a stable platform to bring the BSP up 
to date.

Regards, Steve

[Buildroot] Buildroot in use

[Steve Calfee]

Hi Thomas and Peter,

I would like to know if you will accept a patch to implement the following.

On 03/27/11 16:58, Steve Calfee wrote:
> 
> I would like to ask Peter and Thomas what they think of changing the way 
> board support packages are handled. I think that buildroot also needs to 
> support more complete BSP packages which have common desires (booting 
> for USB or booting from NFS) available as options. But this is not great 
> for buildroot because it adds more downloads in a default git pull, it 
> adds bit-rotting code for BSPs, and puts a bigger burden on the core 
> buildroot maintainers.
> 
> What I propose is that BSPs be added just like any other package. A few 
> changes to the buildroot config would allow linking in the new_defconfig 
> for selected packages. The current buildroot config supports selecting 
> toolchain, kernel, u-boot, busybox etc, configs, locations of patches 
> for each, location of external placement of each, etc. As well as handy 
> skeleton updates or additions.  It would be nice if there was a way to 
> add some BSP configuration options - I think the config.in was removed 
> when the bsps were moved from target/device/* to board/manu/*.
> 
> Handling BSPs as packages would enable someone like me to have a github 
> git tree for a bsp, or put in the buildroot download a tar file which 
> can be selected, etc just like any other package. This way when a 
> developer pulls a new version of buildroot he is not also pulling in 
> lots of uninteresting (and possibly quite large) BSPs. But he can select 
> one that is very close to what he wants to use and get a more functional 
> initial package.
> 
> Since a complete set of configurations would be part of the package, bit 
> rot could be slowed. The package would select the latest version of each 
> major component that it was tested and built against. In the future if 
> someone wants to use an unsupported package, he may be able to build it 
> with old configurations and have a stable platform to bring the BSP up 
> to date.
> 
Regards, Steve