It's really not very useful, all it does is install a target
strace and ldd in a target_utils directory in staging.
While at it clean up the strace makefile a bit.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
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>
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>
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 options to customize the hostname, the banner and the serial port
configuration are now inside a menu named 'System configuration'.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We don't need Config.in and Makefile in target/device: defconfig files
are sufficient to describe the specificities of a board (architecture,
compilation flags, bootloader and kernel details, etc.).
However, a placeholder such as target/device will be kept in order to
host things such as kernel configuration files or various
board-specific patches.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Having Config.in.mirrors (which also to select various download sites)
inside target/device sounds strange. This commit moves the contents of
Config.in.mirrors directly into the main Config.in file.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
In sysvinit inittab the "id" field (first field) must be no longer
than 4 bytes, and is not used by init to determine the output
terminal. Therefore, we adjust the strategy used to modify the inittab
file according to the getty configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Using two '=' for string comparison is a bashism.
Revert to using one, as stated in POSIX 1003.1-2008.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The Alpha, CRIS, IA64 and Sparc64 architectures have been marked as
deprecated during the previous release cycle. They are not widely used
in embedded systems and/or no longer supported by their manufacturers
and/or not properly supported in Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The CRIS architecture support in Buildroot hasn't been updated since a
long time. Even a toolchain with recent kernel headers does not build
due to missing patches.
Moreover, the CRIS architecture has been discontinued by Axis, as
visible at http://www.axis.com/products/dev/index.htm. We will remove
it from Buildroot at the next release cycle.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Supporting multilib is much more than just passing --enable-multilib
to gcc. You have to actually build the C library several times (once
for each multilib variant you want to support in your toolchain), and
to pass MULTILIB_OPTIONS/MULTILIB_EXCEPTIONS values to gcc to let it
know the set of multilib variants you're interested in.
Since we'll probably never support multilib toolchains in Buildroot,
just get rid of this BR2_ENABLE_MULTILIB option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Those architectures don't exist anymore (Alpha, IA64) or aren't widely
used for embedded systems running Linux. Moreover, no clear Buildroot
maintainer has stepped in to maintain these architectures, so it's
better to not pretend that we support them.
The goal is to mark them as deprecated in 2010.08 and remove them in
2010.11.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit solves bug #1051. The problem in this bug in that WebKit
compiles a sample C program, which uses WebKit. As WebKit is written
in C++, even though the program it built with CROSS-gcc, it must be
linked with libstdc++. However, CROSS-gcc can't find the libstdc++ has
it's hidden inside <sysroot>/<tuple>/lib.
Therefore, this commit creates a symbolic link <sysroot>/<tuple>/lib
-> <sysroot>/lib before running the CROSS-gcc installation. While this
may look like a hack, this is the solution used by both Crosstool-NG
and OpenWRT.
Moreover, with this symbolic link in place, I think bug #1741 may also
be solved. The problem in this bug is that the linker tries to link
against /lib/libc.so.0. This is due to the fact that the linker finds
a libc.so script file in the original toolchain location and not
inside the copy of the toolchain sysroot in $(STAGING_DIR). As the
script file is found outside of the current toolchain sysroot, ld
considers the script has non-sysrooted, and therefore doesn't prefix
all paths found in the script file (such as /lib/libc.so.0) with the
sysroot path, leading to the failure.
So, in details, this commit :
* Adds a BR2_ARCH_IS_64 invisible config knob that is used to know if
the arch is a 64 bits architecture or not.
* Creates the <sysroot>/<tuple>/lib -> <sysroot>/lib symbolic link,
and the <sysroot>/<tuple>/lib64 -> <sysroot>/lib64 symbolic link if
needed.
* Fixes the external toolchain sysroot detection code so that the
'sed' replacement is done *after* the readlink -f evaluation.
I have tested this by building ARM, x86 and x86_64 toolchains with
Buildroot, and then use these toolchains as external toolchains to
build a full X.org/Gtk/WebKit/Midori stack. I have also done a
complete ARM Buildroot internal toolchain build with the same full
X.org/Gtk/WebKit/Midori stack.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It's now linux/Config.in that allows to configure the kernel
configuration/compilation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The buildroot/busybox/uClibc VM is running low on disk space, and we've
been asked to move the source mirrors off-site.
A redirect has been setup between the old buildroot.net/downloads/sources/
and sources.buildroot.net, so old .configs continue to work, but we might
as well use the official one now.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
After the rework of the U-Boot configuration/compilation process, we
need to slightly rework how target/linux/Makefile.in.advanced depends
on mkimage on the host to produce an uImage.
target/linux/Makefile.in doesn't need to be fixed as it just doesn't
handle this dependency for the moment.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
A very complicated infrastructure for just a special case, for an
ancient version of U-Boot. Recent versions of U-Boot are reported to
work just fine on Atmel ARM evaluation boards.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
