In commit [1] Peter said he will use BOBCAT for
jaguar cpus. But JAGUAR was used instead.
Use BOBCAT as openblas target for JAGUAR cpus since
it is not listed in openblas's target list [2].
[1] 5e6fa93483
[2] https://github.com/xianyi/OpenBLAS/blob/release-0.3.0/TargetList.txt
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
On Github, a large number of projects name their tag vXYZ (i.e v3.0,
v0.1, etc.). In some packages we do:
<pkg>_VERSION = v0.3
<pkg>_SITE = $(call github foo,bar,$(<pkg>_VERSION))
And in some other packages we do:
<pkg>_VERSION = 0.3
<pkg>_SITE = $(call github foo,bar,v$(<pkg>_VERSION))
I.e in one case we consider the version to be v0.3, in the other case
we consider 0.3 to be the version.
The problem with v0.3 is that when used in conjunction with
release-monitoring.org, it doesn't work very well, because
release-monitoring.org has the concept of "version prefix" and using
that they drop the "v" prefix for the version.
Therefore, a number of packages in Buildroot have a version that
doesn't match with release-monitoring.org because Buildroot has 'v0.3'
and release-monitoring.org has '0.3'.
Since really the version number of 0.3, is makes sense to update our
packages to drop this 'v'.
This commit only addresses the (common) case of github packages where
the prefix is simply 'v'. Other cases will be handled by separate
commits. Also, there are a few cases that couldn't be handled
mechanically that aren't covered by this commit.
Signed-off-by: Victor Huesca <victor.huesca@bootlin.com>
[Arnout: don't change flatbuffers, json-for-modern-cpp, libpagekite,
python-scapy3k, softether]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Nehalem, the predecessor to westmere, is best match for westmere
architecture in current openblas.
Signed-off-by: Esben Haabendal <esben@geanix.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Remove second and third patches (already in version)
- Add an upstream patch to fix build with glibc < 2.5
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Drop 0001-Complete-support-for-MIPS-n32-ABI.patch as it is now upstream and rebase
0002-Makefile.arm-remove-march-flags.patch.
Also add a hash for the license file.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes#10856
The SSE_GENERIC target fails to build with a "sgemm_kernel.o: No such file
or directory" error. Several upstream bug reports exist for this:
https://github.com/xianyi/OpenBLAS/issues/502https://github.com/xianyi/OpenBLAS/issues/685
In both cases, upstream suggests using a different target definition
instead. E.G. from issue 685:
You may use NORTHWOOD on x86: make TARGET=NORTHWOOD that uses SSE2
instructions. It's very hard to find non-SSE2 x86 CPUs today. For x86-64
use the PRESCOTT target
So drop the SSE_GENERIC target. The only x86_64 variant we support not
covered by a more specific openblas target is the default variant, nocona
and jaguar.
Nocona was a Xeon variant of the P4 "Prescott" architecture, so use the
PRESCOTT openblas target:
https://en.wikipedia.org/wiki/Xeon#Nocona_and_Irwindale
Jaguar is from the Bobcat family, so use the BOBCAT openblas target:
https://en.wikipedia.org/wiki/List_of_AMD_microprocessors#Bobcat_core_architecture_(APU)
[Peter: add Jaguar as pointed out by Arnout]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The old Atom target is not really fitting for recent Atom CPUs based
on Silvermont, Airmont or Goldmont. Those have more in common with
older Desktop CPUs than old Atoms.
Signed-off-by: Norbert Lange <norbert.lange@andritz.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Makefile.sparc in the openblas source code passes -mcpu=v9, i.e it
assumes a SPARCv9 CPU. Therefore, this commit adjusts openblas
Config.in file so that SPARC is only used for BR2_sparc_v9.
Fixes:
http://autobuild.buildroot.net/results/805087e87b8bb7d11adb49d9eca3959a37aca3a2/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We want to use SPDX identifier for license string as much as possible.
SPDX short identifier for BSD-3c is BSD-3-Clause.
This change is done using following command.
find . -name "*.mk" | xargs sed -ri '/LICENSE( )?[\+:]?=/s/BSD-3c/BSD-3-Clause/g'
Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For powerpc (and powerpc only), the openblas build system will enable
USE_OPENMP when threads are enabled. But the toolchain wasn't
necessarily built with OpenMP support. So explicitly disable OpenMP -
for all architectures, not just powerpc, just to keep things simple.
We could have autodetected whether OpenMP is available at configure
time, but that would be more of a feature patch, it's up to upstream
to do that.
Fixes:
http://autobuild.buildroot.net/results/423b5e79cd4342d6c160ed478054b294b0826c6ahttp://autobuild.buildroot.net/results/c9e554c8f880b49b3c9203725ac5e6565b7e5c6f
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Older toolchains that use binutils <= 2.23.2 are affected by binutils
bug #14887 (https://sourceware.org/bugzilla/show_bug.cgi?id=14887),
where:
someinstruction [ foo, something ]
is not accepted, due to the whitespace after [ and before ], causing the
following build failures for OpenBLAS:
ARM register expected -- `pld [ r1,#512 ]'
Since we don't have any mechanism to add dependencies on binutils
versions, we work around this problem by patching the code to remove the
problematic whitespaces. As there are many many instances of this in the
ARM assembly code of OpenBLAS, we use a sed expression to make this
modification rather than a patch.
Fixes:
http://autobuild.buildroot.net/results/43e50b480b4aea0fdec745d7875c85377c114cac/
[Peter: use single quotes in sed invocation]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit fixes several build issues of OpenBLAS on ARM:
- The first one occured on ARMv5 platforms, when the ARMV5 OpenBLAS
architecture is used. In this case, OpenBLAS build system forces
-march=armv5, which may not be correct for certain toolchains. As an
example, the Sourcery CodeBench toolchain has an ARMv4 and an ARMv5
sysroot. The ARMv5 sysroot is actually an armv5te sysroot, so when
OpenBLAS forces -march=armv5, gcc thinks it should use the ARMv4
sysroot, causing build failures.
To address this, a patch to completely remove the -march ARM CFLAGS
is added to OpenBLAS.
Fixes:
http://autobuild.buildroot.net/results/991497b12b70f948169e5ad99eebd0fe7f6209a2/
- The second one occured on ARMv7 platforms, when the ARMV7 OpenBLAS
architecture is used. The OpenBLAS code expects an EABIhf build, so a
dependency is added for EABIhf for both ARMv6 and ARMv7.
Fixes:
http://autobuild.buildroot.net/results/0ba0bee48a83367fcefab827e8eaa72f0c8fe90b/
- Once the previous ARMv7 problem has been fixed, it turns out that the
ARMv7 specific code in OpenBLAS contains VFPv3 specific
code. Therefore, the user *must* have choosen either VFPv3 or VFPv4,
or the code will not build. VFPv3-D16/VFPv4-D16 are not sufficient,
as more than 16 registers are used by the OpenBLAS code.
To address this, the ARMV7 platform of OpenBLAS is restricted to the
proper VFPv3/VFPv4 selection, and the ARMV6 platform is restricted to
the proper VFPv2 selection.
This problem was not visible in the autobuilders, as it was hidden by
the previous one.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
OpenBLAS is optimised for specific CPU models, which don't fully match
with the GCC code generation options. Therefore, we can't automatically
select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let
the user select the TARGET name, but offer a sensible default. Other
possible solutions were deemed too complicated: adding choice options in
the ambiguous cases, or only making the option user-visible when there
is ambiguity.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
