buildroot-novena/target, branch master

Split target/Config.in.arch into multiple Config.in.* in arch/

2012-11-04T11:51:38+00:00

target/Config.in.arch had become too long, and we want to remove the target/ directory. So let's move it to arch/ and split it this way: * An initial Config.in that lists the top-level architecture, and sources the arch-specific Config.in. files, as well as Config.in.common (see below) * One Config.in. per architecture, listing the CPU families, ABI choices, etc. * One Config.in.common that defines the gcc mtune, march, mcpu values and other hidden options. [Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout] Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

New top-level directory: system

2012-11-04T11:51:08+00:00

This directory groups the following elements: * the default root filesystem skeleton * the default device tables * the Config.in options for system configuration (UART port for getty, system hostname, etc.) * the make rules to apply the system configuration options Even though the skeleton and device tables could have lived in fs/, it would have been strange to have the UART, system hostname and other related options into fs/. A new system/ directory makes more sense. As a consequence, this patch also removes target/Makefile.in, which has become useless in the process. [Peter: fixup TARGET_SKELETON settings / documentation to match] Signed-off-by: Thomas Petazzoni Acked-by: Yann E. MORIN Acked-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Peter Korsgaard

Add AArch64 to the list of architectures

2012-11-02T20:06:02+00:00

Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

Remove the Xtensa architecture

2012-09-20T20:31:08+00:00

As stated in commit 555c2585bf28c3ef71f6d2dcdd983d17a19892af, the Xtensa architecture has been introduced in 2009 and never changed since its initial introduction. It requires some special handling that is a bit annoying, and despite our call to the initial developers, and the announcement of the deprecation of the architecture during the 2012.05, nothing has happened. Therefore, drop support for this architecture. Signed-off-by: Thomas Petazzoni Acked-by: me Signed-off-by: Peter Korsgaard

Move BR2_SPARC_TYPE to an uClibc specific place

2012-09-20T20:24:16+00:00

BR2_SPARC_TYPE is a hidden configuration option that is only used for the configuration of uClibc, therefore, we move it from target/Config.arch.in to toolchain/uClibc/Config.in. Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

Move BR2_ARM_TYPE to an uClibc specific place

2012-09-20T20:24:13+00:00

BR2_ARM_TYPE is a hidden configuration option that is only used for the configuration of uClibc, therefore, we move it from target/Config.arch.in to toolchain/uClibc/Config.in. We also add a comment that explains that this stuff is only useful for uClibc <= 0.9.32. Starting from 0.9.33, uClibc build process simply uses the compiler flags to find the ARM processor that should be used. So, someday, we'll be able to remove this. Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

Clarify MIPS ABIs support

2012-09-04T20:03:55+00:00

Practically speaking, MIPS has three useful ABIs: * o32 is for 32-bits CPUs, or 64-bit CPUs running only a 32-bit subset of the instruction set. * n32 is for 64-bits CPUs only. It has 32-bits pointers and long integers. * n64 is for 64-bits CPUs only. It has 64-bits pointers and long integers. See http://www.linux-mips.org/wiki/MIPS_ABI_History and http://www.linux-mips.org/wiki/WhatsWrongWithO32N32N64 for more details. So, this commit reworks the Buildroot MIPS support by: * Add separate mips64/mips64el top-level architectures. * Renaming the n32 ABI option to BR2_MIPS_NABI32, for consistency with BR2_MIPS_OABI32. * Renaming the n64 ABI option to BR2_MIPS_NABI64, for consistency with BR2_MIPS_OABI32. * Make the n32 and n64 ABI selections select the BR2_ARCH_IS_64, since those ABIs are valid on 64-bits CPUs only. * Removing the o64 ABI, which is practicaly never used. * Removing the "none" ABI, which really doesn't make sense. * Introduce the mips64 and mips64el architecture names when a 64-bits MIPS ABI is choosen. This will fix build issue like http://autobuild.buildroot.org/results/9b8c5ea86c953a89e85e7b67e9221de41773f652/build-end.log where gmp was confused by the fact of having a 32 bits architecture (detected by the mips- architecture part of the tuple) but 64 bits integer size when compiling. * Adjust the uclibc.mk logic to support the new mips64/mips64el architecture names, and take into account the renaming of the ABI options. This has been build tested by generating Buildroot toolchains and compiling a few packages for MIPS o32, MIPS n32 and MIPS n64. This work is originally based on prior work done by Gustavo Zacarias. Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

system/init: add option for no init system

2012-08-24T22:05:22+00:00

Can be usefull if a local package provides an init procedure. Signed-off-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

Simplify x86 target architecture variant handling

2012-07-30T22:00:29+00:00

Instead of having two separate list of choices for select the target architecture variant for i386 and x86_64, with many CPU choices duplicated (because all modern x86 CPUs can be both used as i386 or x86_64), merge them into a single list. In the x86_64 case, all the x86 CPUs that do not support the 64 bits instruction set are hidden. Signed-off-by: Thomas Petazzoni

Rework of the init system

2012-07-30T21:12:17+00:00

Since we have now two uncompatible init systems, and we want only one of them at the same time in use in the rootfs, we need to select a particular init system. This patch also adds $(PKG)_INSTALL_INIT_SYSTEMD and $(PKG)_INSTALL_INIT_SYSV hooks that are called when the matching init systems are selected to install properly the init scripts of the package. Signed-off-by: Maxime Ripard Acked-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni