Romain Naour [Thu, 8 Dec 2016 22:24:17 +0000 (23:24 +0100)]
package/efl: add Wayland support
The EFL Wayland support was removed with commit [1] since the dependecy
on libdrm was missing. Also it requires OpenGL ES with EGL, Evas DRM
and Evas GLES DRM support [2].
As stated in configure, Evas GLES DRM engine support (gl_drm) depends
on wayland-client to build (wayland-client >= 1.8.0).
So, enable gl_drm only when wayland support is selected.
The strict unused-const-variable checking was causing autobuilder errors
when trying to build Xen tools/libxl as the migrate_*[] arrays are not
always accessed.
To avoid the error edit the Makefile to stop all general warnings being treated
as errors, by removing the -Werror flag.
[Peter: add local sha256 hash as suggested by Vicente] Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Pass on INSTALL_PROGRAM to configure since starting with version 8.26
when building natively it tries to use the self-built install to
install, and when cross-compiling it expects INSTALL_PROGRAM to point to
a real install, or otherwise fails when recursively trying to expand it.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
rpm: add patches to fix bfd.h related build issues
This commit adds two patches to the rpm package to fix two separate but
related build issues:
- The first patch fixes a build that occurs when rpm is built after
elfutils, but without binutils. In this case, dwarf.h is present, so
rpm enables the build of a number of additional tools. But one of
them uses bfd.h, provided by binutils, without checking for its
existence. So the first patch fixes that by checking for bfd.h
existence before enabling the tool.
- The second patch fixes a build issue that occurs when rpm is built
after both dwarf and binutils. In this case, bfd.h complains because
config.h is not included. That's a weird and silly issue in bfd.h
that the binutils developers don't want to fix, and you have to
define PACKAGE or PACKAGE_VERSION before including bfd.h to use it
outside of binutils.
Frank Hunleth [Wed, 26 Oct 2016 17:18:04 +0000 (13:18 -0400)]
systemd: don't build systemd-firstboot by default
systemd-firstboot is never invoked since systemd's first boot detection
logic checks whether /etc/machine-id exists. Since the file is created
automatically by systemd.mk, systemd will never detect first boot and
therefore the systemd-firstboot.service unit file will never get run.
Additionally, if /etc/machine-id is removed to allow systemd-firstboot
to run, it interactively prompts for the system locale. This makes it
seem unlikely that an embedded system would want to use it.
Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Peter Korsgaard [Wed, 7 Dec 2016 09:25:21 +0000 (10:25 +0100)]
arch/Config.in.arm: only enable BR2_ARM_CPU_HAS_NEON for ARMv8 in 32bit mode
A number of packages use BR2_ARM_CPU_HAS_NEON to know if the target handles
aarch32 neon instructions, which is only true for ARMv8 cores when they are
running in 32bit mode.
Notice: These cores do support neon-like instructions using a different
encoding in 64bit mode (it is a required part of ARMv8, similar to the FPU).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
A number of packages use BR2_ARM_CPU_HAS_ARM to know if the target handles
classic A32 instructions, which is only true for ARMv8 cores when they are
running in 32bit mode.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The math tests are experimental at the moment and require more
adaptions before they can be enabled again.
The locale tests are not compatible with musl toolchains,
so disable them.
Use latest git version from upstream for other bugfixes.
Erico Nunes [Mon, 5 Dec 2016 23:07:18 +0000 (00:07 +0100)]
efibootmgr: depends on wchar
After commit 3ae07b4746 recently, efibootmgr now selects
BR2_PACKAGE_GETTEXT if the toolchain requires it.
gettext depends on wchar, so this dependency should be propagated as
well.
menuconfig currently complains loudly if you select efibootmgr, with an
error such as:
warning: (... && BR2_PACKAGE_EFIBOOTMGR ... && ) selects
BR2_PACKAGE_GETTEXT which has unmet direct dependencies
(BR2_USE_WCHAR)
Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
efivar only makes sense on platforms that support UEFI.
UEFI is only supported by some architectures at the moment, being mostly
employed on platforms such as x86, x86_64 and aarch64. Some other
platforms such as MIPS and PowerPC may have some unofficial UEFI
support. UEFI is also limited to little endian architectures.
efivar was being supported in Buildroot without architecture
restrictions so far, however this has led to the creation of a number of
hacks in the recipes, mostly for architectures that are not supported by
UEFI.
In order to avoid spending more time to debug these failures and
maintaining more hacks for unsupported architectures, efivar can be
restricted to that platforms where it makes sense and where it is more
likely to receive some testing and actual usage.
The existing hacks for the now unsupported architectures are removed,
and the dependency is propagated to efibootmgr as it depends on efivar.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Erico Nunes [Mon, 5 Dec 2016 23:07:15 +0000 (00:07 +0100)]
efivar: fix comment after uClibc compatibility patch
uClibc support was recently added to efivar through a small
compatibility patch.
This commit updates a comment in the efivar recipe to reflect this, as
we no longer have glibc as the only supported C library.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
linux: generate KBUILD_BUILD_TIMESTAMP date whith LC_ALL=C
Fix kernel reproducible build if a non-C locale is used on the host
system.
When building the Linux kernel, scripts/gen_initramfs_list.sh does 'date
-d"$KBUILD_BUILD_TIMESTAMP" +%s'. In linux.mk, Buildroot sets
KBUILD_BUILD_TIMESTAMP to "$(shell date -d @$(SOURCE_DATE_EPOCH))".
For example, if LANG=fr_FR.UTF-8 is defined in the host system, it does
not work:
- LC_ALL=C date -d"$(LC_ALL=C date)" : ok
- LC_ALL=C date -d"$(LC_ALL=fr_FR.UTF-8 date)" : error
LANG/LC_ALL variables exported in the main Makefiles are not passed in
the $(shell ...) sub-shells.
A recent change in uClibc-ng removed the MADV_* definitions for
madvise(), but kept the madvise() function itself. This defeats the
logic used in madplay: it checks if madvise() is available, and if it
is, uses it and assumes the MADV_* definitions exist.
This inconsistency has been reported to upstream uClibc-ng, but in the
mean time, we can simply tell madplay to not use madvise(), which is
anyway useless on noMMU platforms.
Commit 00810e0ea3976c5b26a7fd264870f15e17a2eaa2 still didn't fix the
license information properly, so this is a new commit (properly tested
this time) fixing the license information.
pkg-autotools: search in the entire source directory for ltmain.sh
Fixes static linking of berkeleydb package, where ltmain.sh
is not in the sub-directory that contains configure.
Always search the complete source directory.
Marcin Niestroj [Wed, 7 Dec 2016 14:49:05 +0000 (15:49 +0100)]
package/easydbus: new package
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 1ffcf364b6e9894a876dc581a090f87685945412 updated cmake to 3.7.0,
which requires selecting the libuv package. At the time, the libuv
package only depended on BR2_TOOLCHAIN_HAS_THREADS. However, later on,
it was changed in master to depend on BR2_TOOLCHAIN_HAS_THREADS_NPTL, a
change which was not taken into account in the cmake 3.7.0 bump that was
merged in the next branch.
Due to this, builds of cmake is attempted on architectures that don't
provide NPTL thread support, causing a build failure. This commit fixes
that by adjusting the dependency.
Peter Korsgaard [Tue, 6 Dec 2016 16:42:18 +0000 (17:42 +0100)]
toolchain-external: disallow sourcery codebench ARM toolchain for ARMv8 cores
This toolchain uses GCC 4.8.x, which doesn't support the ARMv8 cores.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Peter Korsgaard [Tue, 6 Dec 2016 16:36:18 +0000 (17:36 +0100)]
gcc: disallow 4.9.x for ARM cortex-a72
a72 support was only added in the 5.1 cycle.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Peter Korsgaard [Tue, 6 Dec 2016 16:36:17 +0000 (17:36 +0100)]
gcc: disallow 4.8.x for ARMv8 cores
Notice: A53/A57 were in fact supported in aarch64 mode in 4.8 (in aarch32
mode only from 4.9), but it doesn't handle --with-abi, and as there is
unlikely to be any aarch64 based legacy projects unwilling to use a newer
GCC version it is simpler to disallow it for all modes.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Makefile: move SED definition into the main Makefile
Since commit f71a621d91ec27f175fc84012962f88b1107305f, we are using the
SED variable in the main Makefile. However, this variable is only
defined in package/Makefile.in, which gets included only when a
configuration is defined.
This means that, if you do:
$ make menuconfig savedefconfig
without a configuration defined, it fails with:
/bin/bash: /BR2_DEFCONFIG=/d: No such file or directory
Makefile:898: recipe for target 'savedefconfig' failed
make[1]: *** [savedefconfig] Error 127
This issue affects users of the "buildroot-submodule" project, which
does menuconfig+savedefconfig automatically. They worked around this
issue in commit
https://github.com/Openwide-Ingenierie/buildroot-submodule/commit/d12676b608a58529c6b551aa176464166a200428,
but really "make menuconfig savedefconfig" should work out of the box.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Phil Eichinger [Tue, 6 Dec 2016 14:32:37 +0000 (15:32 +0100)]
ffmpeg: fix build for ffplay
Upstream has dropped SDL support for ffplay in favor of SDL2.
This results in silently not building ffplay even if it is selected
in Buildroot config.
[Peter: propagate !static dependency from sdl2] Signed-off-by: Phil Eichinger <phil@zankapfel.net> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Mon, 28 Nov 2016 22:20:58 +0000 (23:20 +0100)]
sysklogd: fix build on musl
This commit add a stack of small patches that make sysklogd build fine
with the musl C library. Build with uClibc and glibc has been tested
with those patches applied as well.
The first patch is slightly rework (better description and capital
letter to the title) in preparation for upstream submission.
This new package currently installs the "rpiboot" utility, which is
needed to access via USB mass storage the built-in eMMC of Raspberry Pi
compute modules.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Tom privately notified that he is not able to support the packages he
originally added in Buildroot, so this commit removes him from the
DEVELOPERS file.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
toolchain-external-linaro-{arm,armeb}: allow on ARMv8
The Linaro toolchains are currently only available on ARMv7-A, but can
in fact also be used to generate 32 bits code for ARMv8 platforms. This
commit therefore adjusts their architecture dependency.
Example, a 32 bits ARM build produces a 32 bits busybox binary:
Thomas Petazzoni [Wed, 30 Nov 2016 21:12:11 +0000 (22:12 +0100)]
arch/Config.in.arm: add Cortex-A57 and Cortex-A72
Add two popular ARM64 cores to the list of supported cores: Cortex-A57
and Cortex-A72.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Matt Flax [Wed, 30 Nov 2016 21:12:10 +0000 (22:12 +0100)]
arch/Config.in.arm: Add Cortex-A53 CPU
Adds the Cortex-A53 CPU to the target architecture variant choice. This
sets the toolchain to use Cortex-A53 as the target. The effect is that
various Cortex-A53 tunings are enabled for the compilation of packages.
Signed-off-by: Matt Flax <flatmax@flatmax.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thomas Petazzoni [Wed, 30 Nov 2016 21:12:09 +0000 (22:12 +0100)]
arch/Config.in.arm: specify ABI for ARM64
There's currently only one widely supported ABI for ARM64, called lp64,
so we define BR2_GCC_TARGET_ABI to the appropriate value.
Note that there is another ABI for ARM64 being worked on, ilp32, but its
support is not fully upstream in the kernel, so we're not adding support
for it for the moment.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thomas Petazzoni [Wed, 30 Nov 2016 21:12:08 +0000 (22:12 +0100)]
arch/Config.in.arm: add FPU related options for ARMv8 cores
The ARMv8 cores have a mandatory FPU unit called FP-ARMv8, so we:
- add a new hidden Config.in option for the availability of this
unit (BR2_ARM_CPU_HAS_FP_ARMV8)
- allow the selection of a possible choice in the "Floating point
strategy", and add two new choices: BR2_ARM_FPU_FP_ARMV8 and
BR2_ARM_FPU_NEON_FP_ARMV8.
- specify the -mfpu values for BR2_ARM_FPU_FP_ARMV8 and
BR2_ARM_FPU_NEON_FP_ARMV8 cases, when used on ARM 32 bits (-mfpu
doesn't exist on ARM64, instead -mcpu modifiers are used, so they
will be added on a per-core basis).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[yann.morin.1998@free.fr: drop the FP strategy dependency] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Yann E. MORIN [Wed, 30 Nov 2016 21:12:07 +0000 (22:12 +0100)]
arch/arm: drop legacy dependency for floating point strategy
The floating point strategy currently depends on EABI || EABIHF. The
reason was that, wayback when we also supported OABI, we only exposed FP
for EABI or EABIHF, and hide it for OABI, which did not support FP.
It's been a while now that we do not support OABI, but the dependency
stuck all along.
Remove it as it is no longer needed, and is always true.
However, the choice is empty for AArch64, as we still have no entry for
their floating point strategy yet.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thomas Petazzoni [Wed, 30 Nov 2016 21:12:06 +0000 (22:12 +0100)]
arch/Config.in.arm: add BR2_ARM_CPU_ARMV8
In order to prepare the addition of ARM64 cores, add the blind
BR2_ARM_CPU_ARMV8 option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thomas Petazzoni [Wed, 30 Nov 2016 21:12:05 +0000 (22:12 +0100)]
arch/Config.in.arm: prepare addition of 64 bits cores
Until now the "Target Architecture Variant" choice was not visible on
AArch64. In order to prepare the addition of the 64 bits core to this
choice, this commit adds a "depends on !BR2_ARCH_IS_64" dependency to
all currently supported cores (that are 32 bits only).
Following this commit, the "Target Architecture Variant" choice appears
on AArch64, but is for now empty.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thomas Petazzoni [Wed, 30 Nov 2016 21:12:04 +0000 (22:12 +0100)]
arch: merge Config.in.aarch64 into Config.in.arm
The 64 bits ARM processors are capable of running 32 bits ARM code, and
some platforms are indeed using this capability. Due to this, if we were
to keep the separation between Config.in.aarch64 and Config.in.arm, we
would have to duplicate the definition of all 64-bits capable ARM cores
into both files.
Instead of going down this route, let's take the same route as the x86
one: a single Config.in.x86 file, used for both x86 32 bits and x86 64
bits, with the appropriate logic to only show the relevant cores
depending on which architecture is selected.
In order to do this, we:
- Make the "ARM instruction set" choice only visible on ARM 32 bits,
since we currently don't support ARM vs. Thumb on AArch64.
- Add the relevant values for the BR2_ARCH option.
- Add the relevant values for the BR2_ENDIAN option.
- Make the "aapcs-linux" BR2_GCC_TARGET_ABI value only used on ARM 32
bits, since this ABI doesn't mean anything on AArch64.
- Make the BR2_GCC_TARGET_FPU option depends on ARM 32 bits, since
there is no -mfpu option on AArch64.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
vim: be more careful when removing the documentation
The current VIM_REMOVE_DOCS hook removes all .txt files from
/usr/share/vim. Unfortunately, this also removes the rgb.txt file,
which is needed at runtime for vim, as reported in bug #9466.
This commit changes VIM_REMOVE_DOCS to remove only
/usr/share/vim/vim*/doc/. Size-wise, it's equivalent because:
- We are no longer removing a few README.txt in other directories,
taking more space.
- We are now removing the /usr/share/vim/vim*/doc/ folder entirely,
which contained a few files not named *.txt
So overall, the size of /usr/share/vim/ before and after this patch is
still 11MB.
Fixes bug #9466.
Reported-by: Mateusz Furdyna <sir.ferdek@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Sam bobroff [Mon, 28 Nov 2016 05:11:39 +0000 (16:11 +1100)]
pkg-autotools: generic configure fix for powerpc64
Many (100+) packages supported by buildroot contain old configure
scripts (or build them from old versions of autotools) that are unable
to determine how to link shared libraries on powerpc64 and
powerpc64le. This causes that test to erroneously fail on toolchains
that are not "bi-endian" (which is the case for toolchains built by
buildroot), which causes configure to build static libraries instead
of dynamic ones. Although these builds succeed, they tend to cause
linker failures in binaries later linked against them.
Because affected configure files can be discovered automatically, this
patch introduces a hook (enabled only when building for powerpc64 and
powerpc64le) that uses a script to scan and fix each package.
Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Sam bobroff [Mon, 5 Dec 2016 03:30:57 +0000 (14:30 +1100)]
package/liquid-dsp: fix build failure on powerpc64le
Commit 7d435d8510db69ed2f9108abaa52479bce127b72 fixed building on
powerpc and powerpc64. This extends that fix to cover powerpc64le,
which suffers from the same problem.
Rahul Bedarkar [Mon, 5 Dec 2016 16:08:22 +0000 (21:38 +0530)]
efivar: not available for static builds
efivar uses dlfcn.h which is not available in static builds
configuration. Also propagate dependency to efibootmgr. This commit
also does s/requires/needs/ in comment while at it.
Peter Seiderer [Mon, 5 Dec 2016 20:27:15 +0000 (21:27 +0100)]
gstreamer1: fix compile for microblaze and xtensa architectures
Fix unaligned access support detection introduced to gstreamer
by commit 'gstconfig.h: Detect unaligned access support at compile-time' ([1])
by assuming no unaligned support for unknown architectures.
Fixes [2], [3]:
../gst/gstconfig.h:112:4: error: #error "Could not detect architecture; don't know whether it supports unaligned access! Please file a bug."
# error "Could not detect architecture; don't know whether it supports unaligned access! Please file a bug."
Romain Naour [Thu, 3 Nov 2016 21:05:22 +0000 (22:05 +0100)]
package/openpowerlink: bump to v2.5.0
- Rebase existing patches
- Use a "menu" instead of "choice" to select Ethernet Powerlink
Drivers since we can now build several kernel modules at once.
- Select the Intel 82573 driver by default.
- Disable library with simulation interface.
- Disable zynq/FPGA (PCIe) interface otherwise the kernelpcp library
is always build.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[Thomas: minor Config.in tweaks.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit moves the logic that allows to enable the naxsi external
module below the "external modules" comment, which was already used for
the upload and dav-ext modules.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Johan Oudinet [Tue, 29 Nov 2016 16:47:51 +0000 (17:47 +0100)]
nginx-dav-ext: new package
Nginx built-in support for webdav is missing support for two commands:
PROPFIND and OPTIONS. This commit adds a new package that provides an
external nginx module with improved webdav support.
Signed-off-by: Johan Oudinet <johan.oudinet@gmail.com>
[Thomas:
- Remove the BR2_PACKAGE_NGINX_HTTP_DAV_EXT_MODULE sub-option of the
nginx package. The BR2_PACKAGE_NGINX_DAV_EXT option is sufficient.
- Move the nginx.mk code together with another external module being
enabled, nginx-upload.
- Add LICENSE and LICENSE_FILES variables.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Ash Charles [Fri, 2 Dec 2016 04:22:41 +0000 (23:22 -0500)]
pru-software-support: add library for PRU firmware
TI provides a set of headers files and libraries useful in developing
firmware for real-time (PRU) cores embedded in some processors e.g.
AM3358. This package stages these files for any packages creating
PRU firmware.
Note: As per [1], use commit v4.0.2 to sync with common TI Linux
versions.
Signed-off-by: Ash Charles <ash.charles@savoirfairelinux.com>
[Thomas:
- rename BR2_PACKAGE_PRU_EXAMPLES to BR2_PACKAGE_PRU_SOFTWARE_SUPPORT,
since the package directory name should match the Config.in option
for this package
- use select for BR2_PACKAGE_HOST_TI_CGT_PRU, and therefore add the
appropriate "depends on BR2_PACKAGE_HOST_TI_CGT_PRU_ARCH_SUPPORTS".] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Ash Charles [Fri, 2 Dec 2016 04:22:40 +0000 (23:22 -0500)]
ti-cgt-pru: add package for PRU Host toolchain
TI provides a binary code generation toolchain to develop firmware for
the programmable real-time unit/co-processor found in some SOCs such as
some models in the AM335x line. This toolchain includes C/C++ support
(clpru) rather than just assembler (pasm) supported by the pre-existing
am335x-pru-package [1]. Following the lead of the Yocto meta-ti
layer [2], this package provides a host toolchain suitable for an x86
(or x86_64) Linux targeting an ARM-based PRU core.
Signed-off-by: Ash Charles <ash.charles@savoirfairelinux.com>
[Thomas: add BR2_PACKAGE_HOST_TI_CGT_PRU_ARCH_SUPPORTS boolean option,
so that packages selecting host-ti-cgt-pru can easily inherit its
architecture dependencies.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
projects / coffee / buildroot.git / log