Closes#2965
For some odd reason, xkeyboard-config < 1.8 was creating a symbolic
link from /usr/share/X11/xkb/xkbcomp to the xkbcomp binary. But in
cross-compilation mode, this is absurd as the xkbcomp binary to which
the link is pointing is the one in $(HOST_DIR).
This symbolic link thing has been removed completely starting from
xkeyboard-config 1.9. See
http://cgit.freedesktop.org/xkeyboard-config/commit/?id=f413dff57e77e7b01461508f74b4e92d1dc8defd.
Therefore, we simply bump xkeyboard-config to the latest available
version, 2.0.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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>
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: Peter Korsgaard <jacmet@sunsite.dk>
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: Peter Korsgaard <jacmet@sunsite.dk>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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: Peter Korsgaard <jacmet@sunsite.dk>
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
[ 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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Use recent U-Boot and kernel versions, remove useless kernel
configuration file.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Use recent U-Boot and kernel versions, remove useless kernel
configuration file.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
One config per board is enough.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
unzip is needed to uncompress at91bootstrap, so let's add it as a
dependency. This can be discussed, and if we think it shouldn't be a
new dependency, we can also build a host-unzip.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Use modern U-Boot and kernel versions, get rid of the now unused
kernel configuration file since we use the kernel defconfig instead.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Use modern U-Boot and kernel versions, and get rid of the useless
kernel configuration file, since we now use the kernel defconfig.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Use modern kernel and U-Boot versions, and get rid of the now useless
kernel configuration file since we use the kernel defconfig file
instead.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The Buildroot makefile was fetching and building the special
AT91Bootstrap of Ulf, which is not the Atmel official version. While
Ulf's variant has a better configuration/build system, the Atmel
version, as officially supported, is probably a better choice for the
future.
The Atmel version only needed a small tweak to work with EABI
toolchains.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
