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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.