25 Sep, 2016
1 commit
-
Enable the drivers on the powerpc arch.
Signed-off-by: Roy Pledge
Signed-off-by: Claudiu Manoil
Signed-off-by: Scott Wood
13 Sep, 2016
3 commits
-
Use the standard Kbuild trick of foo-y to make the construction of
UTC_MACHINE less verbose.Signed-off-by: Michael Ellerman
-
Commit 2578bfae84a7 ("[POWERPC] Create and use CONFIG_WORD_SIZE") added
CONFIG_WORD_SIZE, and suggests that other arches were going to do
likewise.But that never happened, powerpc is the only architecture which uses it.
So switch to using a simple make variable, BITS, like x86, sh, sparc and
tile. It is also easier to spell and simpler, avoiding any confusion
about whether it's defined due to ordering of make vs kconfig.Signed-off-by: Michael Ellerman
-
In fact it makes no sense at all to have this defined on little endian
builds. Since we disabled the 32-bit VDSO on little endian, we don't
build any 32-bit code when building a little endian kernel.Signed-off-by: Michael Ellerman
10 Aug, 2016
1 commit
-
When we introduced the little endian support, we added the endian flags
to CC directly using override. I don't know the history of why we did
that, I suspect no one does.Although this mostly works, it has one bug, which is that CROSS32CC
doesn't get -mbig-endian. That means when the compiler is little endian
by default and the user is building big endian, vdso32 is incorrectly
compiled as little endian and the kernel fails to build.Instead we can add the endian flags to cflags-y/aflags-y, and then
append those to KBUILD_CFLAGS/KBUILD_AFLAGS.This has the advantage of being 1) less ugly, 2) the documented way of
adding flags in the arch Makefile and 3) it fixes building vdso32 with a
LE toolchain.Signed-off-by: Michael Ellerman
14 Jul, 2016
1 commit
-
Explicitly give sparse an endianness in the Makefile, so that it
doesn't get confused.Normally we have #ifdef one and #else the other, so it doesn't usually
matter, but we have been bitten by it before, and indeed this patch
fixes a number of sparse errors.Suggested-by: Arnd Bergmann
Signed-off-by: Daniel Axtens
Signed-off-by: Michael Ellerman
05 Jul, 2016
1 commit
-
Check the assembler supports -maltivec by wrapping it with
call as-option.Signed-off-by: Anton Blanchard
Signed-off-by: Michael Ellerman
14 Mar, 2016
1 commit
-
Freescale updates from Scott:
"Highlights include 8xx optimizations, 32-bit checksum optimizations,
86xx consolidation, e5500/e6500 cpu hotplug, more fman and other dt
bits, and minor fixes/cleanup."
12 Mar, 2016
1 commit
-
Signed-off-by: Alessio Igor Bogani
Signed-off-by: Scott Wood
07 Mar, 2016
1 commit
-
Firstly we add logic to Kconfig to allow a user to choose if they want
mprofile-kernel. This has to be user-selectable because only some
current toolchains support it. If we enabled it unconditionally we would
prevent some users from building the kernel entirely.Arguably it would be nice if we could detect if mprofile-kernel was
available, and use it then. However that would violate the principle of
least surprise because a user having choosen options such as live
patching, would then see them quietly disabled at build time.We also make the user selectable option negative, ie. it disables when
selected, so that allyesconfig continues to build on old toolchains.Once we've decided we do want to use mprofile-kernel, we then add a
script which checks it actually works. That is because there are
versions of gcc that accept the flag but don't generate correct code.Due to the way kconfig works, we can't error out when we detect a
non-working toolchain. If we did a user would never be able to modify
their config and run oldconfig - because the check would block oldconfig
from running. Instead we emit a warning and add a bogus flag to CFLAGS
so that the build will fail.Signed-off-by: Torsten Duwe
Signed-off-by: Michael Ellerman
19 Oct, 2015
1 commit
-
The TUNE_CELL option allows you to build a kernel that runs on multiple
CPUs but is tuned (ie. optimised) to run on Cell CPUs. Now days no one
is building a distro in that fashion, and any users who are building
custom kernels for their Cell machines are better off building with
CONFIG_CELL_CPU, which builds a kernel that only runs on Cell and
therefore can be optimised even more aggresively.Dropping the option also avoids confusing other users, who are presented
with an option to tune for Cell when they are not building for a Cell
CPU at all.Suggested-by: Thomas Huth
Signed-off-by: Michael Ellerman
01 Oct, 2015
1 commit
-
Based directly on ppc64_defconfig using merge_config.
Signed-off-by: Michael Ellerman
09 Sep, 2015
1 commit
-
Pull core kbuild updates from Michal Marek:
- modpost portability fix
- linker script fix
- genksyms segfault fix
- fixdep cleanup
- fix for clang detection* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild: Fix clang detection
kbuild: fixdep: drop meaningless hash table initialization
kbuild: fixdep: optimize code slightly
genksyms: Regenerate parser
genksyms: Duplicate function pointer type definitions segfault
kbuild: Fix .text.unlikely placement
Avoid conflict with host definitions when cross-compiling
04 Sep, 2015
1 commit
-
We cannot detect clang before including the arch Makefile, because that
can set the default cross compiler. We also cannot detect clang after
including the arch Makefile, because powerpc wants to know about clang.
Solve this by using an deferred variable. This costs us a few shell
invocations, but this is only a constant number.Reported-by: Behan Webster
Reported-by: Anton Blanchard
Signed-off-by: Michal Marek
08 Aug, 2015
1 commit
-
Unify mpc85xx and corenet configs using fragments, to ease maintenance
and avoid the sort of drift that the previous patch fixed.Hardware and software options are separated, with the hope that other
embedded platforms could share the software options, and to make it
easier to maintain custom/alternate configs that focus on either
hardware or software options.Due to the previous patch, this patch should not affect the results of
any of the affected defconfigs -- only how those results are achieved.
The resulting config is more or less the union of the options that any
of the configs previously selected. No attempt was made in this (or
the previous) patch to edit out questionable options, but this patch
will make it easier to do so in future patches.Signed-off-by: Scott Wood
11 Jun, 2015
3 commits
-
We have code to choose between several options, eg. -mabi=elfv2 vs
-mcall-aixdesc, and -mcmodel=medium vs -mminimal-toc. But these are all
GCC specific, so use cc-option on all of them.Signed-off-by: Anton Blanchard
Signed-off-by: Michael Ellerman -
We added -mno-strict-align in commit f036b3681962 (powerpc: Work around little
endian gcc bug) to fix gcc bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134Clang doesn't understand it. We need to use a conditional because we can't use the
simpler call cc-option here.Signed-off-by: Anton Blanchard
Signed-off-by: Michael Ellerman -
These options are not recognised on LLVM, so use call cc-option to check
for support.Signed-off-by: Anton Blanchard
Signed-off-by: Michael Ellerman
02 Jun, 2015
1 commit
-
Rather than continuing to maintain a copy of pseries_defconfig with
CONFIG_CPU_LITTLE_ENDIAN enabled, use the generic merge_config script
and use an le.config to enable little endian on top of pseries_defconfig
without the need for a duplicated _defconfig file.This method will require less maintenance in the future and will ensure
that both 'defconfigs' are always in sync.It is worth noting that the seemingly more simple approach of:
pseries_le_defconfig: pseries_defconfig
$(Q)$(MAKE) le.configWill not work when building using O=builddir.
The obvious fix to that:
pseries_le_defconfig:
$(Q)$(MAKE) -f $(srctree)/Makefile pseries_defconfig le.configAlso does not work. This is because if we have for example:
config FOO
depends on CPU_BIG_ENDIAN
select BARThen BAR will be enabled by the first call to kconfig (via
pseries_defconfig), and then will remain enabled after we merge
le.config, even though FOO will have been turned off.The solution is to ensure to only invoke the kconfig logic once, after
we have merged all the config fragments. This ensures nothing is
select'ed on that should then be disabled by the later merged configs.
This is done through the explicit call to make olddefconfigSigned-off-by: Cyril Bur
Reviewed-by: Samuel Mendoza-Jonas
[mpe: Massage change log, fix white space and use ARCH not SRCARCH]
Signed-off-by: Michael Ellerman
11 May, 2015
2 commits
-
There is a bug in binutils 2.24 which causes miscompilation if we're
building little endian and using weak symbols (which the kernel does).It is fixed in binutils commit 57fa7b8c7e59 "Correct elf_merge_st_other
arguments for weak symbols", which is in binutils 2.25 and has been
backported to the binutils 2.24 branch and has been picked up by most
distros it seems.However if we're running stock 2.24 (no extra version) then the bug is
present, so check for that and bail.Signed-off-by: Michael Ellerman
-
We have several checks for bad gcc versions in our Makefile. These don't
apply if we're building with clang, so skip them in that case.The obvious check would be for ${COMPILER} = "gcc", but because of the
way the logic in the top level Makefile conditionally sets COMPILER,
it's possible that we're building with gcc but COMPILER was not set.So instead check for ${COMPILER} != "clang", which we know is currently
the only other possibility.Signed-off-by: Michael Ellerman
23 Mar, 2015
1 commit
-
This runs a bit faster and removes another use of perl from
the kernel build.Signed-off-by: Stephen Rothwell
Acked-By: Tony Breeds
Signed-off-by: Michael Ellerman
10 Jan, 2015
1 commit
-
The macros cc-version, cc-fullversion and ld-version take no argument.
It is not necessary to add $(call ...) to invoke them.Signed-off-by: Masahiro Yamada
Acked-by: Helge Deller [parisc]
Signed-off-by: Michal Marek
25 Sep, 2014
1 commit
-
This allows the user to build a kernel targeted at POWER8
(ie gcc -mcpu=power8).Signed-off-by: Anton Blanchard
Signed-off-by: Michael Ellerman
28 May, 2014
2 commits
-
Merge the binutils and kexec fixes.
-
With binutils 2.24, various 64 bit builds fail with relocation errors
such asarch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
(.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI
against symbol `interrupt_base_book3e' defined in .text section
in arch/powerpc/kernel/built-in.o
arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
(.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI
against symbol `interrupt_end_book3e' defined in .text section
in arch/powerpc/kernel/built-in.oThe assembler maintainer says:
I changed the ABI, something that had to be done but unfortunately
happens to break the booke kernel code. When building up a 64-bit
value with lis, ori, shl, oris, ori or similar sequences, you now
should use @high and @higha in place of @h and @ha. @h and @ha
(and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA)
now report overflow if the value is out of 32-bit signed range.
ie. @h and @ha assume you're building a 32-bit value. This is needed
to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h
and @toc@ha expressions, and for consistency I did the same for all
other @h and @ha relocs.Replacing @h with @high in one strategic location fixes the relocation
errors. This has to be done conditionally since the assembler either
supports @h or @high but not both.Cc:
Signed-off-by: Guenter Roeck
Signed-off-by: Benjamin Herrenschmidt
05 May, 2014
1 commit
-
This series adds support for building the powerpc 64-bit
LE kernel using the new ABI v2. We already supported
running ABI v2 userspace programs but this adds support
for building the kernel itself using the new ABI.
01 May, 2014
1 commit
-
This patch adds an option to enable a work around for an icache bug on
476 that can cause execution of stale instructions when falling
through pages (IBM errata #46). It requires a recent version of
binutils which supports the --ppc476-workaround option.The work around enables the appropriate linker options and ensures
that all module output sections are aligned to 4K page boundaries. The
work around is only required when building modules.Signed-off-by: Alistair Popple
Signed-off-by: Benjamin Herrenschmidt
23 Apr, 2014
2 commits
-
Build the little endian ppc64 kernel with ABIv2 if the toolchain
supports it. We can identify an ABIv2 capable toolchain by the
-mabi=elfv2 compiler flag.Signed-off-by: Anton Blanchard
-
We avoid ABIv2 when building c files since commit b2ca8c89 (powerpc:
Don't use ELFv2 ABI to build the kernel). Do the same for assembly
files.Signed-off-by: Anton Blanchard
09 Apr, 2014
1 commit
-
When building modules with a native le toolchain the linker will
generate R_PPC64_TOCSAVE relocations when it's safe to omit saving r2 on
a plt call. This isn't helpful in the conext of a kernel module and the
kernel will fail to load those modules with an error like:
nf_conntrack: Unknown ADD relocation: 109This patch tells the linker to avoid createing R_PPC64_TOCSAVE
relocations allowing modules to load.Signed-off-by: Tony Breeds
Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt
25 Nov, 2013
1 commit
-
Currently if I cross build TAGS or cscope from x86 I get this:
% make ARCH=powerpc TAGS
gcc-4.8.real: error: unrecognized command line option ‘-mbig-endian’
GEN TAGS
%I'm not setting CROSS_COMPILE= as logically I shouldn't need to and I
haven't needed to in the past when building TAGS or cscope. Also, the
above completess correct as the error is not fatal to the build.This was caused by:
commit d72b08017161ab385d4ae080ea415c9eb7ceef83
Author: Ian Munsie
powerpc: Add ability to build little endian kernelsThe below fixes this by testing for the -mbig-endian option before
adding it.I've not done the same thing in the little endian case as if
-mlittle-endian doesn't exist, we probably want to fail quickly as you
probably have an old big endian compiler.Signed-off-by: Michael Neuling
Signed-off-by: Benjamin Herrenschmidt
23 Nov, 2013
1 commit
-
If CONFIG_ALTIVEC is enabled for CoreNet64, and if we also
select CONFIG_E{5,6}500_CPU this may introduce -mcpu=e500mc64
into $CFLAGS. But Altivec option not allowed with e500mc64,
then some compiling errors occur like this:CC arch/powerpc/lib/xor_vmx.o
arch/powerpc/lib/xor_vmx.c:1:0: error: AltiVec not supported in this target
make[1]: *** [arch/powerpc/lib/xor_vmx.o] Error 1
make: *** [arch/powerpc/lib] Error 2So we should restrict e500mc64 in altivec scenario.
Signed-off-by: Tiejun Chen
Signed-off-by: Scott Wood
21 Nov, 2013
1 commit
-
The kernel doesn't build correctly using the ELFv2 ABI. This patch
ensures that the ELFv1 ABI is used when building a kernel with an
ELFv2 enabled compiler.Signed-off-by: Alistair Popple
Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt
11 Oct, 2013
3 commits
-
Temporarily work around an ICE we are seeing while building
in little endian mode:http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134
Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
This patch allows the kbuild system to successfully compile a kernel
for the little endian PowerPC64 architecture. A subsequent patch
will add the CONFIG_CPU_LITTLE_ENDIAN kernel config option which
must be set to build such a kernel.If cross compiling, CROSS_COMPILE must point to a suitable toolchain
(compiled for the powerpc64le-linux and powerpcle-linux targets).Signed-off-by: Ian Munsie
Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
We need to distinguish between big endian and little endian
environments, so fix uname to return the right thing.Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt
21 Aug, 2013
3 commits
-
Unlike 64-bit, we don't currently support multiplatform between e500
and non-e500, so the -mcpu is not configurable at this time.-msoft-float is specified when testing for -mcpu=8540 because otherwise
some older toolchains will fail with "error: E500 and FPRs not
supported".Signed-off-by: Scott Wood
-
By default use -mcpu=powerpc64 rather than -mtune=power7
Add options for e5500/e6500, with fallbacks for older compilers.
Hide the POWER cpu options in booke configs.
Signed-off-by: Scott Wood
-
This caused lwsync to be converted to sync on 64-bit (on 32-bit lwsync
is generated at runtime, and so wasn't affected). Not using lwsync
caused a significant slowdown on certain workloads.Setting this flag for any e500-enabled build is also not friendly to
multiplatform kernels.Signed-off-by: Scott Wood