All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.