* [Buildroot] Storing board configuration ?
@ 2010-06-20 12:35 Thomas Petazzoni
2010-06-20 13:10 ` Paul Jones
2010-06-23 21:02 ` Peter Korsgaard
0 siblings, 2 replies; 5+ messages in thread
From: Thomas Petazzoni @ 2010-06-20 12:35 UTC (permalink / raw)
To: buildroot
Hello,
The work on cleaning up the target/ directory has been making some
progress lately: bootloaders-cleanup has been merged, linux-cleanup has
been through a first review phase and Dmytro Milinevskyy has
contributed the cleanup of the filesystem skeleton.
The last big part is the "board support", i.e what allows to configure
Buildroot to build a system for a particular hardware board, without
the user having to worry about kernel/bootloader/toolchain details.
Instead of having configuration details defined in makefiles in
target/device, I'd like to use defconfigs instead.
However, defconfigs are not perfect : they are large and they get
out-dated pretty quickly because they must store the value of *every*
existing option.
For that reason, I'm wondering whether we should limit the defconfigs
to the important options for a particular board and remove all other
option values. This would leave ~30 lines to a human-written defconfig
instead of ~1000 lines of automatically-generated defconfigs.
A "mini-defconfig" could look like :
======================================================================
# General
BR2_HAVE_DOT_CONFIG=y
BR2_arm=y
BR2_arm926t=y
BR2_ARM_EABI=y
BR2_PROJECT="at91sam9263ek"
BR2_HOSTNAME="AT91SAM9263EK"
# Root filesystem
BR2_TARGET_ROOTFS_JFFS2=y
BR2_TARGET_ROOTFS_JFFS2_NANDFLASH_2K_128K=y
BR2_TARGET_ROOTFS_JFFS2_PAGESIZE=0x800
BR2_TARGET_ROOTFS_JFFS2_EBSIZE=0x20000
BR2_TARGET_ROOTFS_JFFS2_NOCLEANMARKER=y
BR2_TARGET_ROOTFS_JFFS2_PAD=y
BR2_TARGET_ROOTFS_JFFS2_PADSIZE=0x02000000
BR2_TARGET_ROOTFS_JFFS2_LE=y
# Boot
BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BOARDNAME="at91sam9263ek"
BR2_TARGET_UBOOT_2009_01=y
BR2_TARGET_AT91BOOTSTRAP=y
BR2_TARGET_AT91BOOTSTRAP_BOARD="at91sam9263ek"
BR2_TARGET_AT91BOOT_DATAFLASHCARD=y
BR2_AT91BOOTSTRAP_JUMP_TO_DEFAULT=y
BR2_AT91BOOTSTRAP_JUMP_ADDR="0x23F00000"
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_2_6_34=y
BR2_LINUX_KERNEL_USE_DEFCONFIG=y
BR2_LINUX_KERNEL_DEFCONFIG="at91sam9263ek"
======================================================================
But if we do that, we would have to modify the main Makefile so that
when an user does "make foobar_defconfig", configs/foobar_defconfig is
used and for all options non-specified in the defconfig, the default
options would be choosen. So something like :
%_defconfig: $(TOPDIR)/configs/%_defconfig
cp $^ .config
@yes "" | $(MAKE) oldconfig
What do you think about this ?
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] 5+ messages in thread* [Buildroot] Storing board configuration ?
2010-06-20 12:35 [Buildroot] Storing board configuration ? Thomas Petazzoni
@ 2010-06-20 13:10 ` Paul Jones
2010-06-20 13:34 ` Michael S. Zick
2010-06-23 21:02 ` Peter Korsgaard
1 sibling, 1 reply; 5+ messages in thread
From: Paul Jones @ 2010-06-20 13:10 UTC (permalink / raw)
To: buildroot
> -----Original Message-----
> From: buildroot-bounces at busybox.net [mailto:buildroot-
> bounces at busybox.net] On Behalf Of Thomas Petazzoni
> Sent: Sunday, 20 June 2010 10:36 PM
> To: buildroot at busybox.net
> Subject: [Buildroot] Storing board configuration ?
>
> Hello,
>
> The work on cleaning up the target/ directory has been making some
> progress lately: bootloaders-cleanup has been merged, linux-cleanup has
> been through a first review phase and Dmytro Milinevskyy has contributed
> the cleanup of the filesystem skeleton.
>
> The last big part is the "board support", i.e what allows to configure
Buildroot
> to build a system for a particular hardware board, without the user having
to
> worry about kernel/bootloader/toolchain details.
>
> Instead of having configuration details defined in makefiles in
target/device,
> I'd like to use defconfigs instead.
>
> However, defconfigs are not perfect : they are large and they get
out-dated
> pretty quickly because they must store the value of *every* existing
option.
>
> For that reason, I'm wondering whether we should limit the defconfigs to
the
> important options for a particular board and remove all other option
values.
> This would leave ~30 lines to a human-written defconfig instead of ~1000
> lines of automatically-generated defconfigs.
>
> A "mini-defconfig" could look like :
>
> ==========================================================
> ============
> # General
> BR2_HAVE_DOT_CONFIG=y
> BR2_arm=y
> BR2_arm926t=y
> BR2_ARM_EABI=y
> BR2_PROJECT="at91sam9263ek"
> BR2_HOSTNAME="AT91SAM9263EK"
>
> # Root filesystem
> BR2_TARGET_ROOTFS_JFFS2=y
> BR2_TARGET_ROOTFS_JFFS2_NANDFLASH_2K_128K=y
> BR2_TARGET_ROOTFS_JFFS2_PAGESIZE=0x800
> BR2_TARGET_ROOTFS_JFFS2_EBSIZE=0x20000
> BR2_TARGET_ROOTFS_JFFS2_NOCLEANMARKER=y
> BR2_TARGET_ROOTFS_JFFS2_PAD=y
> BR2_TARGET_ROOTFS_JFFS2_PADSIZE=0x02000000
> BR2_TARGET_ROOTFS_JFFS2_LE=y
>
> # Boot
> BR2_TARGET_UBOOT=y
> BR2_TARGET_UBOOT_BOARDNAME="at91sam9263ek"
> BR2_TARGET_UBOOT_2009_01=y
> BR2_TARGET_AT91BOOTSTRAP=y
> BR2_TARGET_AT91BOOTSTRAP_BOARD="at91sam9263ek"
> BR2_TARGET_AT91BOOT_DATAFLASHCARD=y
> BR2_AT91BOOTSTRAP_JUMP_TO_DEFAULT=y
> BR2_AT91BOOTSTRAP_JUMP_ADDR="0x23F00000"
>
> # Kernel
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_2_6_34=y
> BR2_LINUX_KERNEL_USE_DEFCONFIG=y
> BR2_LINUX_KERNEL_DEFCONFIG="at91sam9263ek"
> ==========================================================
> ============
>
> But if we do that, we would have to modify the main Makefile so that when
> an user does "make foobar_defconfig", configs/foobar_defconfig is used
> and for all options non-specified in the defconfig, the default options
would
> be choosen. So something like :
>
> %_defconfig: $(TOPDIR)/configs/%_defconfig
> cp $^ .config
> @yes "" | $(MAKE) oldconfig
>
> What do you think about this ?
Sounds good to me - I actually had the same idea the other day, but I don't
know enough to do anything about it.
Paul.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] Storing board configuration ?
2010-06-20 13:10 ` Paul Jones
@ 2010-06-20 13:34 ` Michael S. Zick
0 siblings, 0 replies; 5+ messages in thread
From: Michael S. Zick @ 2010-06-20 13:34 UTC (permalink / raw)
To: buildroot
On Sun June 20 2010, Paul Jones wrote:
> > -----Original Message-----
> > From: buildroot-bounces at busybox.net [mailto:buildroot-
> > bounces at busybox.net] On Behalf Of Thomas Petazzoni
> > Sent: Sunday, 20 June 2010 10:36 PM
> > To: buildroot at busybox.net
> > Subject: [Buildroot] Storing board configuration ?
> >
> > Hello,
> >
> > The work on cleaning up the target/ directory has been making some
> > progress lately: bootloaders-cleanup has been merged, linux-cleanup has
> > been through a first review phase and Dmytro Milinevskyy has contributed
> > the cleanup of the filesystem skeleton.
> >
> > The last big part is the "board support", i.e what allows to configure
> Buildroot
> > to build a system for a particular hardware board, without the user having
> to
> > worry about kernel/bootloader/toolchain details.
> >
> > Instead of having configuration details defined in makefiles in
> target/device,
> > I'd like to use defconfigs instead.
> >
> > However, defconfigs are not perfect : they are large and they get
> out-dated
> > pretty quickly because they must store the value of *every* existing
> option.
> >
> > For that reason, I'm wondering whether we should limit the defconfigs to
> the
> > important options for a particular board and remove all other option
> values.
> > This would leave ~30 lines to a human-written defconfig instead of ~1000
> > lines of automatically-generated defconfigs.
> >
> > A "mini-defconfig" could look like :
> >
> > ==========================================================
> > ============
> > # General
> > BR2_HAVE_DOT_CONFIG=y
> > BR2_arm=y
> > BR2_arm926t=y
> > BR2_ARM_EABI=y
> > BR2_PROJECT="at91sam9263ek"
> > BR2_HOSTNAME="AT91SAM9263EK"
> >
> > # Root filesystem
> > BR2_TARGET_ROOTFS_JFFS2=y
> > BR2_TARGET_ROOTFS_JFFS2_NANDFLASH_2K_128K=y
> > BR2_TARGET_ROOTFS_JFFS2_PAGESIZE=0x800
> > BR2_TARGET_ROOTFS_JFFS2_EBSIZE=0x20000
> > BR2_TARGET_ROOTFS_JFFS2_NOCLEANMARKER=y
> > BR2_TARGET_ROOTFS_JFFS2_PAD=y
> > BR2_TARGET_ROOTFS_JFFS2_PADSIZE=0x02000000
> > BR2_TARGET_ROOTFS_JFFS2_LE=y
> >
> > # Boot
> > BR2_TARGET_UBOOT=y
> > BR2_TARGET_UBOOT_BOARDNAME="at91sam9263ek"
> > BR2_TARGET_UBOOT_2009_01=y
> > BR2_TARGET_AT91BOOTSTRAP=y
> > BR2_TARGET_AT91BOOTSTRAP_BOARD="at91sam9263ek"
> > BR2_TARGET_AT91BOOT_DATAFLASHCARD=y
> > BR2_AT91BOOTSTRAP_JUMP_TO_DEFAULT=y
> > BR2_AT91BOOTSTRAP_JUMP_ADDR="0x23F00000"
> >
> > # Kernel
> > BR2_LINUX_KERNEL=y
> > BR2_LINUX_KERNEL_2_6_34=y
> > BR2_LINUX_KERNEL_USE_DEFCONFIG=y
> > BR2_LINUX_KERNEL_DEFCONFIG="at91sam9263ek"
> > ==========================================================
> > ============
> >
> > But if we do that, we would have to modify the main Makefile so that when
> > an user does "make foobar_defconfig", configs/foobar_defconfig is used
> > and for all options non-specified in the defconfig, the default options
> would
> > be choosen. So something like :
> >
> > %_defconfig: $(TOPDIR)/configs/%_defconfig
> > cp $^ .config
> > @yes "" | $(MAKE) oldconfig
> >
> > What do you think about this ?
>
> Sounds good to me - I actually had the same idea the other day, but I don't
> know enough to do anything about it.
>
Already been done, see Aboriginal Linux build system which uses mini-configs
and for the scripts to handle them. Previously known as Firmware Linux.
http://aboriginal.impactlinux.com/
Mike
>
>
> Paul.
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] Storing board configuration ?
2010-06-20 12:35 [Buildroot] Storing board configuration ? Thomas Petazzoni
2010-06-20 13:10 ` Paul Jones
@ 2010-06-23 21:02 ` Peter Korsgaard
2010-06-23 22:09 ` Paul Jones
1 sibling, 1 reply; 5+ messages in thread
From: Peter Korsgaard @ 2010-06-23 21:02 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
Thomas> But if we do that, we would have to modify the main Makefile so that
Thomas> when an user does "make foobar_defconfig", configs/foobar_defconfig is
Thomas> used and for all options non-specified in the defconfig, the default
Thomas> options would be choosen. So something like :
Thomas> %_defconfig: $(TOPDIR)/configs/%_defconfig
Thomas> cp $^ .config
Thomas> @yes "" | $(MAKE) oldconfig
Thomas> What do you think about this ?
I like it. It will ofcourse hide any new questions you might have wanted
to get asked about, but that's not so bad.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] Storing board configuration ?
2010-06-23 21:02 ` Peter Korsgaard
@ 2010-06-23 22:09 ` Paul Jones
0 siblings, 0 replies; 5+ messages in thread
From: Paul Jones @ 2010-06-23 22:09 UTC (permalink / raw)
To: buildroot
> -----Original Message-----
> From: buildroot-bounces at busybox.net [mailto:buildroot-
> bounces at busybox.net] On Behalf Of Peter Korsgaard
> Sent: Thursday, 24 June 2010 7:03 AM
> To: Thomas Petazzoni
> Cc: buildroot at busybox.net
> Subject: Re: [Buildroot] Storing board configuration ?
>
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-
> electrons.com> writes:
>
> Hi,
>
> Thomas> But if we do that, we would have to modify the main Makefile so
> that Thomas> when an user does "make foobar_defconfig",
> configs/foobar_defconfig is Thomas> used and for all options
non-specified
> in the defconfig, the default Thomas> options would be choosen. So
> something like :
>
> Thomas> %_defconfig: $(TOPDIR)/configs/%_defconfig
> Thomas> cp $^ .config
> Thomas> @yes "" | $(MAKE) oldconfig
>
> Thomas> What do you think about this ?
>
> I like it. It will ofcourse hide any new questions you might have wanted
to get
> asked about, but that's not so bad.
We could add another command like make foobar_defconfig_ask to cover both
cases.
Paul.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-06-23 22:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-20 12:35 [Buildroot] Storing board configuration ? Thomas Petazzoni
2010-06-20 13:10 ` Paul Jones
2010-06-20 13:34 ` Michael S. Zick
2010-06-23 21:02 ` Peter Korsgaard
2010-06-23 22:09 ` Paul Jones
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox