- Dec 21, 2010
-
-
Peter Korsgaard authored
As discussed on IRC, this only needs to be disabled for very specific configurations, and it can nowadays be done with a custom busybox .config (CONFIG_INSTALL_APPLET_DONT), so get rid of the option. Signed-off-by:Peter Korsgaard <jacmet@sunsite.dk>
-
Peter Korsgaard authored
Explicitly explain what the (default) install target does, so people who don't know busybox details understands what the option does. Notice: Busybox can be configured to create hard links or shell wrappers instead, but by default symlinks are used. Signed-off-by: -
Thomas Petazzoni authored
As reported by Miroslav Ignjatovic in bug #2983, our hack in xlib_libX11 to build makekeys for the host does not work, for several reasons: * As we are building a tool for the host, we shouldn't pass -I$(STAGING_DIR)/usr/include, since the $(STAGING_DIR) contains headers of packages for the target. * Instead, we should use the headers in $(HOST_DIR)/usr/include. They were not used due to a typo: $(HOST_CFLAGS) must be used instead of $(HOSTCFLAGS). * Finally, in order for makekeys to find the required headers in $(HOST_DIR)/usr/include, we must depend on host-xproto_xproto. This fixes bug #2983. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
-
Thomas Petazzoni authored
ARCH_SUBDIR is a shell variable, so it should be referenced with $${ARCH_SUBDIR}. Without this, no symbolic link is created, and the external toolchain fails to work if the non-default multilib variant is used. Signed-off-by: -
Peter Korsgaard authored
Signed-off-by:
-
- Dec 20, 2010
-
-
Peter Korsgaard authored
Signed-off-by: -
Peter Korsgaard authored
Otherwise configure errors out with 'Phonon enabled, but GUI disabled'. Signed-off-by:
-
- Dec 19, 2010
-
-
Bjørn Forsman authored
linux-% shortcut targets (short for linux26-%) ignores the ouput dir $(O) so that 'make O=output.arm linux-menuconfig' is actually run in the default $(O) directory output/ and not in output.arm/. Fix by passing on $(O) if set. [Peter: Use EXTRAMAKEARGS] Signed-off-by:
Bjørn Forsman <bjorn.forsman@gmail.com> Signed-off-by:
-
Bjørn Forsman authored
Signed-off-by:
-
Peter Korsgaard authored
Signed-off-by:
-
- Dec 17, 2010
-
-
Thomas Petazzoni authored
Both i386 and x86_64 architectures are supported by the arch/x86 directory in the kernel. So, when we copy the kernel configuration file to arch/$(KERNEL_ARCH)/configs/, it does not work because arch/i386 and arch/x86_64 do not exist. So, we introduce KERNEL_ARCH_PATH, which is the path to the architecture specific directory in the kernel source tree. Signed-off-by:
-
Thomas Petazzoni authored
Signed-off-by:
-
Thomas Petazzoni authored
Signed-off-by:
-
Thomas Petazzoni authored
The ELF vmlinux image found at the root of the kernel source tree is the format that Qemu needs when emulating mips(el) or ppc targets, so add support for it. Signed-off-by:
-
Philippe Reynes authored
[ Thomas: * renamed sh4_defconfig to qemu_sh4_r2d_defconfig, for consistency with other Qemu platforms supported * renamed board/qemu/sh4 to board/qemu/sh4-r2d * minor fixes in the readme.txt * remove useless statements in the minimal defconfig * switch to a fixed kernel version instead of "same as headers" ] Signed-off-by:Philippe Reynes <tremyfr@yahoo.fr> Signed-off-by:
-
Thomas Petazzoni authored
Signed-off-by:
-
- Dec 16, 2010
-
-
Thomas Petazzoni authored
The kernel being a component that often needs a fairly important set of changes to be adapted to a particular hardware platform, having maximum flexibility on the patching process is a nice thing. Therefore, as per the discussions from the Buildroot Developer Day, we add a mechanism to apply a list of patches (that could come either from URLs, local files or local directories). Signed-off-by:
-
Thomas Petazzoni authored
Now that minimal kernel defconfigs are used in Buildroot, the problem is that copying those minimal configuration files to .config in the kernel source tree does not work, as kconfig will ask interactively what should be the value for all unspecified options. On suggestion on Sam Ravnborg, the easiest way to solve this is to import the minimal defconfig file as a defconfig inside the kernel tree (in arch/$(ARCH)/configs) and configure the kernel with it. Signed-off-by:
-
Yegor Yefremov authored
Those folders are currently created using makedevs according to the specifications in device_table.txt. However, as makedevs is no longer executed when dynamic device creation methods are selected (devtmpfs, udev, mdev), those folders must be created differently. We choose to put them directly into the default filesystem skeleton. Signed-off-by:
Yegor Yefremov <yegor_sub1@visionsystems.de> Signed-off-by:
-
Yegor Yefremov authored
BR2_TARGET_GENERIC_GETTY_PORT has now a string type instead of choice. This makes port configuration flexible and compact. Signed-off-by:
Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by:
-
Thomas Petazzoni authored
Even when building the host tools, for some reason U-Boot tries to execute the cross-compiler, so tell it which cross-compiler to use in order to avoid failure such as: /usr/bin/make -j12 -C /home/test/outputs/test-253-mini2440_defconfig/build/u-boot-custom tools make[1]: arm-linux-gcc: Command not found make[1]: Entering directory `/home/test/outputs/test-253-mini2440_defconfig/build/u-boot-custom' for dir in tools examples api_examples ; do /usr/bin/make -C $dir _depend ; done Generating include/autoconf.mk /bin/sh: line 3: arm-linux-gcc: command not found Signed-off-by:
-
Thomas Petazzoni authored
Signed-off-by:
-
Thomas Petazzoni authored
Paul Jones documented at http://pauljones.id.au/blog/2010/07/using-buildroot-on-a-mini2440/ how to use Buildroot to generate a system for the FriendlyARM Mini2440 platform. This patch integrates Paul's work into Buildroot. Unfortunately, the kernel being 2.6.32, we can't easily use a minimal defconfig here. The mini2440 support has been merged into more recent kernels, but I don't have the hardware to test. Signed-off-by:
-
Thomas Petazzoni authored
Signed-off-by:
-
Thomas Petazzoni authored
Signed-off-by:
-
Thomas Petazzoni authored
This default configuration did not even build a kernel image, which is the main point of having board default configuration. So remove it. Signed-off-by:
-
Thomas Petazzoni authored
Neither the kernel nor U-Boot have support for a 1005 board, so let's get rid of this board configuration, the corresponding target skeleton, kernel and busybox configuration and device table. Signed-off-by:
-
Thomas Petazzoni authored
Use recent U-Boot and kernel version, remove target skeleton and use the default one instead, remove useless kernel configuration, busybox configuration and device table. Signed-off-by:
-
Thomas Petazzoni authored
It was supposed to be the support for AT91SAM9260 using a parallel flash (instead of the usual dataflash). But the provided U-Boot configuration at91sam9260pf.h was not used anywhere, and it was unsufficient to add correct support in U-Boot (some changes in U-Boot Makefile would also be needed). Additionnally, this configuration has not been merged into U-Boot upstream since 2007 (when it was added to Buildroot). Therefore, let's get rid of this configuration. If some users are interested, we can re-introduce it properly with their help. Signed-off-by:
-
Thomas Petazzoni authored
Use recent U-Boot and kernel versions, remove useless kernel configuration file. Signed-off-by:
-
Thomas Petazzoni authored
Use recent U-Boot and kernel versions, remove useless kernel configuration file. Signed-off-by:
-
Thomas Petazzoni authored
Minimize the board defconfig, remove custom busybox configuration, custom kernel configuration (use the kernel defconfig instead), custom device table and target skeleton. The only difference in the target skeleton was the support of mdev and the usage of an automount script. Instead of adding this in a board-specific way, we should provide board-independent configuration options. There are already patches contributed to add support for mdev. Signed-off-by:
-
Thomas Petazzoni authored
Minimize atngw100_defconfig, remove atngw100-base_defconfig, and remove the target skeleton and device table. Instead of having complete copies of new target skeletons (making them hard to maintain), we should just have a post-build script that adds/removes/tweaks the existing target skeleton. Moreover, most of the tweaks in this target skeleton were for specific packages, but the policy now is that board defconfig should just build a basic root filesystem with Busybox, and let the user select whichever set of packages (s)he wants. Signed-off-by:
-
Thomas Petazzoni authored
Signed-off-by:
-
Thomas Petazzoni authored
Signed-off-by:
-
Thomas Petazzoni authored
Those are not associated with any specific hardware system (PC or another i386 system). Moreover, the fact that those configurations require the build of a JFFS2 filesystem, very uncommon on PC systems, seems to indicate that those configurations are not really being used today. It would make more sense to have a qemu_i388_defconfig (building a kernel with just the device drivers for Qemu) and possibly a pc_i386_defconfig (building a kernel with many device drivers, and a bootloader such as Grub or Grub 2). We also remove the corresponding kernel configuration files. Signed-off-by:
-
Thomas Petazzoni authored
Signed-off-by:
-
Thomas Petazzoni authored
One config per board is enough. Signed-off-by:
-
Thomas Petazzoni authored
Signed-off-by:
-
Thomas Petazzoni authored
Signed-off-by:
-
