From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Storing board configuration ?
Date: Sun, 20 Jun 2010 14:35:35 +0200 [thread overview]
Message-ID: <20100620143535.38416ef6@surf> (raw)
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
next reply other threads:[~2010-06-20 12:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-20 12:35 Thomas Petazzoni [this message]
2010-06-20 13:10 ` [Buildroot] Storing board configuration ? Paul Jones
2010-06-20 13:34 ` Michael S. Zick
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=20100620143535.38416ef6@surf \
--to=thomas.petazzoni@free-electrons.com \
--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.