From: Michael S. Zick <minimod@morethan.org>
To: buildroot@busybox.net
Subject: [Buildroot] Storing board configuration ?
Date: Sun, 20 Jun 2010 08:34:57 -0500 [thread overview]
Message-ID: <201006200834.59189.minimod@morethan.org> (raw)
In-Reply-To: <000c01cb1079$ed7276a0$c85763e0$@pauljones.id.au>
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
>
>
next prev parent reply other threads:[~2010-06-20 13:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2010-06-23 21:02 ` Peter Korsgaard
2010-06-23 22:09 ` Paul Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201006200834.59189.minimod@morethan.org \
--to=minimod@morethan.org \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox