The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because NEON
hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated
as zero), so the use of NEON instructions may lead to a loss of
precision.
```
-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.
This reverts commit 115ee05214.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This defconfig enables sunxi-mali-mainline-driver so we need to disable
Lima in Linux to prevent Mali to not load.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This package provides a Mali kernel driver for Sunxi Mali Utgard GPUs. The
trailing -mainline is historical and was used at a time when there was
two packages providing this driver. The "non-upstream" package has
been removed some time ago so before adding new packages bringing
support for other ARM Mali GPU versions or implementations, rename
sunxi-mali-mainline-driver into sunxi-mali-utgard-driver.
Add a legacy entry.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Giulio: rebase on master. Add legacy entry instead of substituting the
blob's one]
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This package provides Mali libraries for Sunxi Mali Utgard GPUs. The
trailing -mainline is historical and was used at a time when there was
two packages providing these libraries. The "non-upstream" package has
been removed some time ago so before adding new packages bringing
support for other ARM Mali GPU versions or implementations, rename
sunxi-mali-mainline into sunxi-mali-utgard.
Add a legacy entry.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Giulio: rebase on master. Rename SUNXI_MALI_MAINLINE_REV to
SUNXI_MALI_UTGARD_REV in sunxi-mali-mailine-driver.mk and
BR2_PACKAGE_SUNXI_MALI_MAINLINE to BR2_PACKAGE_SUNXI_UTGARD in
sunxi-mali-mainline-driver/Config.in to respect bisectability]
Tested-by: Luca Ceresoli <luca@lucaceresoli.net>
[Build tested only]
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
[Arnout: also update existing select in Config.in.legacy]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Bump to Linux kernel 5.14.13 and u-boot 2021.10.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
a10_olinuxino is not switched to extlinux.conf, so the broken symlinks
are replaced by the previous content from a20_olinuxino.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
For defconfigs that create a boot script, add the host package
uboot-tools and update the script variable names.
Add BR2_PACKAGE_HOST_UBOOT_TOOLS=y just before the existing
BR2_TARGET_UBOOT_BOOT_SCRIPT option. Note that for the defconfigs that
are not manually formatted (i.e. just the result of 'make
savedefconfig'), this puts them in the wrong place. However, it's easier
this way, and it's more consistent in general to have the definition of
the script close to BR2_TARGET_UBOOT itself.
Special cases:
- nanopi_* had the definition of the _SCRIPT variable in a weird place.
These are moved to close to BR2_TARGET_UBOOT.
- Same for orangepi_plus.
- orangpi_pc_* already had BR2_PACKAGE_HOST_UBOOT_TOOLS=y so it's not
added there.
Related to db2b684126
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Since 2e71b396a1, this defconfig needs
a glibc toolchain to select sunxi-mali-mainline package.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- sunxi mali mainline
- sunxi tools
like in olimex_a20_olinuxino_lime_legacy.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
U-Boot KConfig allows to take care of CONFIG_OLD_SUNXI_KERNEL_COMPAT
in order to properly start the kernel (Error: unrecognized/unsupported machine ID)
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
U-Boot 2016.09.01 is a bugfix release, so bump to this version.
Cc: Francois Perrad <fperrad@gmail.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since quite some time, the kernel and bootloader communities consider
zImage as the default format for kernel images on ARM, replacing
uImage. The load address information in uImage is no longer needed,
since the kernel is position-independent in terms of physical address,
except on a few old platforms. For most people, using zImage is simply
better/simpler, so let's switch to zImage as the default image format
on ARM.
All defconfigs are updated: 46 defconfigs no longer need to select
explicitly zImage because it's the default, and 16 defconfigs now need
to explicitly select uImage because that's no longer the default.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Matt Weber <matt@thewebers.ws>
Acked-by: Julien Boibessot <julien.boibessot@armadeus.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For most defconfigs, it was trivial to deduce the kernel version, by
just reading the version string, which could be:
- a standard upstream version string vX.Y.Z
- a non-standard version string, but still containg the standard X.Y.Z
Those for which it was not so trivial were those hosted on git tree.
Since most were already using a custom linux-headers version, it could
be easily deduced from that. It was confirmed by browsing said git trees
and check the version there.
There are a few cases were there was a mismatch:
- microzed: uses a 3.18 kernel, but 3.8 headers; fixed.
- xilinx_zc706: uses a 3.14 kernel, but 3.8 headers; fixed.
- zedboard: uses a 3.18 kernel, but 3.8 headers; fixed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
