powerpc: Remove IBM_CELL_BLADE & SPIDER_NET references

The symbols are no longer selectable so remove references to them.

Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Madhava

powerpc: Remove IBM_CELL_BLADE & SPIDER_NET references

The symbols are no longer selectable so remove references to them.

Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Madhavan Srinivasan <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

powerpc/64: Remove maple platform

The maple platform was added in 2004 [1], to support the "Maple" 970FX
evaluation board.

It was later used for IBM JS20/JS21 machines, as well as the Bimini
machin

powerpc/64: Remove maple platform

The maple platform was added in 2004 [1], to support the "Maple" 970FX
evaluation board.

It was later used for IBM JS20/JS21 machines, as well as the Bimini
machine, aka "Yellow Dog Powerstation".

Sadly all those machines have passed into memory, and there's been no
evidence for years that anyone is still using any of them.

Remove the platform and related code. It can always be reinstated if
there's interest.

Note that this has no impact on support for 970FX based Power Macs.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux-fullhistory.git/commit/?id=f0d068d65c5e555ffcfbc189de32598f6f00770c

Signed-off-by: Michael Ellerman <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

powerpc/boot: Remove all 40x platforms from boot

Remove 40x platforms from the boot directory.

Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <mpe@ell

powerpc/boot: Remove all 40x platforms from boot

Remove 40x platforms from the boot directory.

Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

kbuild: use $(src) instead of $(srctree)/$(src) for source directory

Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention withou

kbuild: use $(src) instead of $(srctree)/$(src) for source directory

Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention without any functional
difference. In fact, $(obj) and $(src) are exactly the same, as defined
in scripts/Makefile.build:

src := $(obj)

When the kernel is built in a separate output directory, $(src) does
not accurately reflect the source directory location. While Kbuild
resolves this discrepancy by specifying VPATH=$(srctree) to search for
source files, it does not cover all cases. For example, when adding a
header search path for local headers, -I$(srctree)/$(src) is typically
passed to the compiler.

This introduces inconsistency between upstream and downstream Makefiles
because $(src) is used instead of $(srctree)/$(src) for the latter.

To address this inconsistency, this commit changes the semantics of
$(src) so that it always points to the directory in the source tree.

Going forward, the variables used in Makefiles will have the following
meanings:

$(obj) - directory in the object tree
$(src) - directory in the source tree (changed by this commit)
$(objtree) - the top of the kernel object tree
$(srctree) - the top of the kernel source tree

Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced
with $(src).

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>

show more ...

powerpc: Fix typos

Fix typos, most reported by "codespell arch/powerpc". Only touches
comments, no code changes.

Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Michael Ellerman

powerpc: Fix typos

Fix typos, most reported by "codespell arch/powerpc". Only touches
comments, no code changes.

Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc: drop MPC85xx_CDS platform support

The MPC8541/8548/8555 Configurable Development System (CDS) were the
vehicle used to provide evaluation of the 1st e500-v2 CPUs around 2007.

Similar to th

powerpc: drop MPC85xx_CDS platform support

The MPC8541/8548/8555 Configurable Development System (CDS) were the
vehicle used to provide evaluation of the 1st e500-v2 CPUs around 2007.

Similar to the earlier MPC83xx-MDS systems we removed, the "brains"
exist on a PCI-X card, but additional connectors exist to the right of
the PCI-X slot, two structural metal pins are used to provide stability
in a vertical ATX mounting, and the CPU is now on a daughter-card vs. a
clamped down BGA.

Given the extra complexity and risk of connector damage, the 8548CDS
I had access to came pre-assembled in a basic white Antec case common
for that era, and I'm inclined to assume that was the default.

Power was typical "Pentium4" 2005 ATX - the main 20 pin connector went
to the PCI ATX form factor backplane, and the 4 pin black/yellow went
to the CPU card.

Like previous evaluation boards, they attempted to provide break-out
connectors for as many features as possible, and that made for a fairly
complex looking system.

In any case, these are over 15 years old, and fairly complex systems,
originally made for a small group of industry related people, and made
for use where quiet fan operation wasn't important. Given that, it
makes sense to remove support from them in 2023.

Signed-off-by: Paul Gortmaker <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc: drop MPC8540_ADS and MPC8560_ADS platform support

Based on the revision history in the manual(s), these e500-v1
platforms were first available around 2002.

Like a lot of evaluation boards,

powerpc: drop MPC8540_ADS and MPC8560_ADS platform support

Based on the revision history in the manual(s), these e500-v1
platforms were first available around 2002.

Like a lot of evaluation boards, they attempted to provide break-out
connectors for all possible features, and that combined with four
PCI-X slots (and the age/era) meant for a considerably large board.

As I recall it, from a Linux point of view, the biggest difference
between 8540 and 8560 was in the UART implementation, and that is
reflected in a diff of the defconfigs.

In any case, these are over 20 years old, and by today's standards
only have a small amount of DDR1 memory, and were not widely available.

Given that, it makes sense to remove support from them in 2023.

Signed-off-by: Paul Gortmaker <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc/build: Remove -pipe from compilation flags

x86 removed -pipe in commit 437e88ab8f9e2 ("x86/build: Remove -pipe from
KBUILD_CFLAGS") and the newer arm64 and riscv seem to have never used it,

powerpc/build: Remove -pipe from compilation flags

x86 removed -pipe in commit 437e88ab8f9e2 ("x86/build: Remove -pipe from
KBUILD_CFLAGS") and the newer arm64 and riscv seem to have never used it,
so that seems to be the way the world's going.

Compile performance building defconfig on a POWER10 PowerNV system
was in the noise after 10 builds each. No point in adding options unless
they help something, so remove it.

Signed-off-by: Nicholas Piggin <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc/boot: Clean up Makefile after cflags and asflags separation

Tidy pass over boot Makefile. Move variables together where possible.

Signed-off-by: Nicholas Piggin <[email protected]>
Signed-o

powerpc/boot: Clean up Makefile after cflags and asflags separation

Tidy pass over boot Makefile. Move variables together where possible.

Signed-off-by: Nicholas Piggin <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc/boot: Separate BOOTCFLAGS from BOOTASFLAGS

BOOTCFLAGS no longer contains anything that BOOTASFLAGS needs (except
-pipe). Separate them to avoid fragility with cross-contamination of
flags wh

powerpc/boot: Separate BOOTCFLAGS from BOOTASFLAGS

BOOTCFLAGS no longer contains anything that BOOTASFLAGS needs (except
-pipe). Separate them to avoid fragility with cross-contamination of
flags which has caused several build problems.

Suggested-by: Linus Torvalds <[email protected]>
Link: https://lore.kernel.org/lkml/CAHk-=whyWUdJDeOBN1hRWYSkQkvzYiQ5RbSW5rJjExgnbSNX9Q@mail.gmail.com/
Signed-off-by: Nicholas Piggin <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc/boot: Separate CPP flags from BOOTCFLAGS

Add BOOTCPPFLAGS variable for the CPP options required by C and AS.

Signed-off-by: Nicholas Piggin <[email protected]>
Signed-off-by: Michael Ellerm

powerpc/boot: Separate CPP flags from BOOTCFLAGS

Add BOOTCPPFLAGS variable for the CPP options required by C and AS.

Signed-off-by: Nicholas Piggin <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc/boot: Separate target flags from BOOTCFLAGS

Add BOOTTARGETFLAGS variable with target / ABI options common to
CFLAGS and AFLAGS.

Signed-off-by: Nicholas Piggin <[email protected]>
Signed-off

powerpc/boot: Separate target flags from BOOTCFLAGS

Add BOOTTARGETFLAGS variable with target / ABI options common to
CFLAGS and AFLAGS.

Signed-off-by: Nicholas Piggin <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc/boot: Disable power10 features after BOOTAFLAGS assignment

When building the boot wrapper assembly files with clang after
commit 648a1783fe25 ("powerpc/boot: Fix boot wrapper code generation

powerpc/boot: Disable power10 features after BOOTAFLAGS assignment

When building the boot wrapper assembly files with clang after
commit 648a1783fe25 ("powerpc/boot: Fix boot wrapper code generation
with CONFIG_POWER10_CPU"), the following warnings appear for each file
built:

'-prefixed' is not a recognized feature for this target (ignoring feature)
'-pcrel' is not a recognized feature for this target (ignoring feature)

While it is questionable whether or not LLVM should be emitting a
warning when passed negative versions of code generation flags when
building assembly files (since it does not emit a warning for the
altivec and vsx flags), it is easy enough to work around this by just
moving the disabled flags to BOOTCFLAGS after the assignment of
BOOTAFLAGS, so that they are not added when building assembly files.
Do so to silence the warnings.

Fixes: 648a1783fe25 ("powerpc/boot: Fix boot wrapper code generation with CONFIG_POWER10_CPU")
Link: https://github.com/ClangBuiltLinux/linux/issues/1839
Reviewed-by: Nicholas Piggin <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/20230427-remove-power10-args-from-boot-aflags-clang-v1-1-9107f7c943bc@kernel.org

show more ...

powerpc: drop PowerQUICC II Family ADS platform support

Based on documentation revision dates, this MPC82xx pq2fads system
predates the MPC8272-ADS variant by about a year and only has 1/2
the amoun

powerpc: drop PowerQUICC II Family ADS platform support

Based on documentation revision dates, this MPC82xx pq2fads system
predates the MPC8272-ADS variant by about a year and only has 1/2
the amount of RAM (32MB) -- largely making it useless with a modern
v6.x kernel from today.

Similar to the MPC8272-ADS the pq2fads also supported other 82xx CPU
variants, had 8MB flash, and like the 8272 ADS platform, was on a fairly
large PCB in order to have space for breakout connectors for all features.

These 82xx platforms are two decades old, and originally made for a
small group of industry related people in order to assist in new OEM
board designs. Given that, it makes sense to remove support today.

Signed-off-by: Paul Gortmaker <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc: drop MPC8272_ADS platform support

The MPC8272-ADS also supported other 82xx CPU variants, had 64MB RAM,
8MB flash, and like the 85xx ADS platforms, was on a fairly large PCB
in order to hav

powerpc: drop MPC8272_ADS platform support

The MPC8272-ADS also supported other 82xx CPU variants, had 64MB RAM,
8MB flash, and like the 85xx ADS platforms, was on a fairly large PCB
in order to have space for breakout connectors for all the features.

These 82xx platforms are two decades old, and originally made for a
small group of industry related people in order to assist in new OEM
board designs. Given that, it makes sense to remove support today.

Signed-off-by: Paul Gortmaker <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc: drop HPC II (MPC7448) evaluation platform support.

This was an interesting platform - it was the 1st instance of a
respin of earlier 130nm 74xx CPUs on 90nm and systems using MPC7448
were p

powerpc: drop HPC II (MPC7448) evaluation platform support.

This was an interesting platform - it was the 1st instance of a
respin of earlier 130nm 74xx CPUs on 90nm and systems using MPC7448
were positioned as a rack server platform solution.

Given that, the evaluation platform (at least the one I had) was shipped
in a horizontal 1/2 height Antec desktop case with retro styling and
colours, despite the fact the docs explicitly stated that the HPC II is
not a desktop machine (noting it had no gfx or legacy PC I/O support).

Historic trivia aside, this was the 1st introduction of the e600
procfam as an evolution from the earlier G4.

However even with the claim to being "1st e600" it seems the 2005+
era was turning its attention to multicore support and from my memory
this poor guy was quickly overshadowed by the dual core MPC8641D.

All that aside, we are once again looking at 15+ year old evaluation
platforms that were not widely distributed, so 2023 removal makes sense.

Signed-off-by: Paul Gortmaker <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc: drop MPC832x_MDS platform support

This final variant in the e300 family of Modular Development System
(MDS) in this series was actually aimed at feature reduction - things
like floating poi

powerpc: drop MPC832x_MDS platform support

This final variant in the e300 family of Modular Development System
(MDS) in this series was actually aimed at feature reduction - things
like floating point and ethernet were removed in order to make for a
lower power and lower cost system.

Like all the MDS systems, it was meant as a vehicle to get the CPU out
early to hardware OEMs so software and board development could take place
in parallel.

These were made in limited numbers and availability preference was given
to partners who were planning to make their own boards.

Given that the whole reason for existence was to assist in enabling new
board designs [not happening for 10+ years], and that they weren't
generally available, and that the hardware wasn't really hobbyist friendly
even for retro computing, it makes sense to retire the support for this
particular platform.

Signed-off-by: Paul Gortmaker <[email protected]>
Acked-by: Li Yang <[email protected]>
[mpe: Drop stale reference to MPC832x_MDS in arch/powerpc/boot/Makefile]
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc: drop MPC836x_MDS platform support

This 2006 era Modular Development System (MDS) has, at its core component,
a full length card with a PCI edge. No case. Serial and network
connectors wer

powerpc: drop MPC836x_MDS platform support

This 2006 era Modular Development System (MDS) has, at its core component,
a full length card with a PCI edge. No case. Serial and network
connectors were on card, so it could optionally be fitted with plastic
stand-offs and run stand-alone off a power brick.

This is very similar to the MPC834x_MDS removed in the prior commit, but
with this board variant as an evolutionary step. DDR2 was now an option,
and the card edge was revised down to PCI-32 as PCI-64 never got traction.
But overall the form factor and design goals were unchanged.

Like all the MDS systems, it was meant as a vehicle to get the CPU out
early to hardware OEMs so software and board development could take place
in parallel.

To that end, the BGA CPU was held in place with a mechanical spring loaded
pressure assembly (vs. solder) so that early rev silicon could be replaced
in the field. Not for COTS deployment!

These were made in limited numbers and availability preference was given
to partners who were planning to make their own boards.

Given that the whole reason for existence was to assist in enabling new
board designs [not happening for 10+ years], and that they weren't
generally available, and that the hardware wasn't really hobbyist friendly
even for retro computing, it makes sense to retire the support for this
particular platform.

Signed-off-by: Paul Gortmaker <[email protected]>
Acked-by: Li Yang <[email protected]>
[mpe: Drop stale reference to MPC836x_MDS in arch/powerpc/boot/Makefile]
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc: drop MPC834x_MDS platform support

This 2006 era Modular Development System (MDS) has, at its core
component, a full length card with a PCI-64 edge. No case. Serial
and network connectors

powerpc: drop MPC834x_MDS platform support

This 2006 era Modular Development System (MDS) has, at its core
component, a full length card with a PCI-64 edge. No case. Serial
and network connectors were on card, so it could optionally be fitted
with plastic stand-offs and run stand-alone off a power brick.

Like all the MDS systems, it was meant as a vehicle to get the CPU
out early to hardware OEMs so software and board development could
take place in parallel.

To that end, the BGA CPU was held in place with a mechanical spring
loaded pressure assembly (vs. solder) so that early rev silicon could
be replaced in the field. Not for COTS deployment!

These were made in limited numbers and availability preference was
given to partners who were planning to make their own boards, like
our WR SBC8349 [since retired in v4.18 (2017, commit 3bc6cf5a86e5)]

Given that the whole reason for existence was to assist in enabling
new board designs [not happening for 10+ years], and that they weren't
generally available, and that the hardware wasn't really hobbyist
friendly even for retro computing, it makes sense to retire the
support for this platform.

Signed-off-by: Paul Gortmaker <[email protected]>
Acked-by: Li Yang <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc/boot: Fix boot wrapper code generation with CONFIG_POWER10_CPU

-mcpu=power10 will generate prefixed and pcrel code by default, which
we do not support. The general kernel disables these with

powerpc/boot: Fix boot wrapper code generation with CONFIG_POWER10_CPU

-mcpu=power10 will generate prefixed and pcrel code by default, which
we do not support. The general kernel disables these with cflags, but
those were missed for the boot wrapper.

Fixes: 4b2a9315f20d ("powerpc/64s: POWER10 CPU Kconfig build option")
Cc: [email protected] # v6.1+
Reported-by: Danny Tsen <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc/boot: Only use '-mabi=elfv2' with CONFIG_PPC64_BOOT_WRAPPER

When CONFIG_PPC64_ELF_ABI_V2 is enabled with clang through
CONFIG_PPC64_BIG_ENDIAN_ELF_ABI_V2, building the powerpc boot wrapper
i

powerpc/boot: Only use '-mabi=elfv2' with CONFIG_PPC64_BOOT_WRAPPER

When CONFIG_PPC64_ELF_ABI_V2 is enabled with clang through
CONFIG_PPC64_BIG_ENDIAN_ELF_ABI_V2, building the powerpc boot wrapper
in 32-bit mode (i.e. with CONFIG_PPC64_BOOT_WRAPPER=n) fails with:

error: unknown target ABI 'elfv2'

The ABI cannot be changed with '-m32'; GCC silently accepts it but clang
errors out. Only provide '-mabi=elfv2' when CONFIG_PPC64_BOOT_WRAPPER is
enabled, which is the only way '-mabi=elfv2' will be useful.

Tested-by: "Erhard F." <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]

show more ...

powerpc/boot: Don't always pass -mcpu=powerpc when building 32-bit uImage

When CONFIG_TARGET_CPU is specified then pass its value to the compiler
-mcpu option. This fixes following build error when

powerpc/boot: Don't always pass -mcpu=powerpc when building 32-bit uImage

When CONFIG_TARGET_CPU is specified then pass its value to the compiler
-mcpu option. This fixes following build error when building kernel with
powerpc e500 SPE capable cross compilers:

BOOTAS arch/powerpc/boot/crt0.o
powerpc-linux-gnuspe-gcc: error: unrecognized argument in option ‘-mcpu=powerpc’
powerpc-linux-gnuspe-gcc: note: valid arguments to ‘-mcpu=’ are: 8540 8548 native
make[1]: *** [arch/powerpc/boot/Makefile:231: arch/powerpc/boot/crt0.o] Error 1

Similar change was already introduced for the main powerpc Makefile in
commit 446cda1b21d9 ("powerpc/32: Don't always pass -mcpu=powerpc to the
compiler").

Fixes: 40a75584e526 ("powerpc/boot: Build wrapper for an appropriate CPU")
Cc: [email protected] # v5.19+
Signed-off-by: Pali Rohár <[email protected]>
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/2ae3ae5887babfdacc34435bff0944b3f336100a.1674632329.git.christophe.leroy@csgroup.eu

show more ...

powerpc/boot: Explicitly disable usage of SPE instructions

uImage boot wrapper should not use SPE instructions, like kernel itself.
Boot wrapper has already disabled Altivec and VSX instructions but

powerpc/boot: Explicitly disable usage of SPE instructions

uImage boot wrapper should not use SPE instructions, like kernel itself.
Boot wrapper has already disabled Altivec and VSX instructions but not SPE.
Options -mno-spe and -mspe=no already set when compilation of kernel, but
not when compiling uImage wrapper yet. Fix it.

Cc: [email protected]
Signed-off-by: Pali Rohár <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

powerpc: Add CONFIG_PPC64_ELF_ABI_V1 and CONFIG_PPC64_ELF_ABI_V2

At the time being, we use CONFIG_CPU_LITTLE_ENDIAN and
CONFIG_CPU_BIG_ENDIAN to pass -mabi=elfv1 or elfv2 to
compiler, then define a

powerpc: Add CONFIG_PPC64_ELF_ABI_V1 and CONFIG_PPC64_ELF_ABI_V2

At the time being, we use CONFIG_CPU_LITTLE_ENDIAN and
CONFIG_CPU_BIG_ENDIAN to pass -mabi=elfv1 or elfv2 to
compiler, then define a PPC64_ELF_ABI_v1 or PPC64_ELF_ABI_v2
macro in asm/types.h based on _CALL_ELF define set by the compiler.

Make it more straight forward with a CONFIG option that
is directly usable.

Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/1eca1addbc550167da9841c7340a010d0c4b2200.1652074503.git.christophe.leroy@csgroup.eu

show more ...

kbuild: drop $(objtree)/ prefix support for clean-files

I think this hack is a bad idea. arch/powerpc/boot/Makefile is the
only and last user. Let's stop doing this.

Signed-off-by: Masahiro Yamada

kbuild: drop $(objtree)/ prefix support for clean-files

I think this hack is a bad idea. arch/powerpc/boot/Makefile is the
only and last user. Let's stop doing this.

Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Michael Ellerman <[email protected]> (powerpc)

show more ...