24 Sep, 2020
1 commit
-
There was a request to preprocess the module linker script like we
do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512)The difference between vmlinux.lds and module.lds is that the latter
is needed for external module builds, thus must be cleaned up by
'make mrproper' instead of 'make clean'. Also, it must be created
by 'make modules_prepare'.You cannot put it in arch/$(SRCARCH)/kernel/, which is cleaned up by
'make clean'. I moved arch/$(SRCARCH)/kernel/module.lds to
arch/$(SRCARCH)/include/asm/module.lds.h, which is included from
scripts/module.lds.S.scripts/module.lds is fine because 'make clean' keeps all the
build artifacts under scripts/.You can add arch-specific sections in .
Signed-off-by: Masahiro Yamada
Tested-by: Jessica Yu
Acked-by: Will Deacon
Acked-by: Geert Uytterhoeven
Acked-by: Palmer Dabbelt
Reviewed-by: Kees Cook
Acked-by: Jessica Yu
13 Jul, 2020
4 commits
-
The log of 'make ARCH=m68k clean' does not look nice.
$ make ARCH=m68k clean
CLEAN arch/m68k/kernel
[ snip ]
CLEAN usr
rm -f vmlinux.gz vmlinux.bz2
CLEAN vmlinux.symvers modules.builtin modules.builtin.modinfoUse CLEAN_FILES to simplify the code, and beautify the log.
Signed-off-by: Masahiro Yamada
Link: https://lore.kernel.org/r/20200617031153.85858-1-masahiroy@kernel.org
Signed-off-by: Geert Uytterhoeven -
Precisely, -D is a preprocessor option.
KBUILD_CPPFLAGS is passed for compiling .c and .S files too.
Signed-off-by: Masahiro Yamada
Acked-by: Greg Ungerer
Link: https://lore.kernel.org/r/20200526123810.301667-4-masahiroy@kernel.org
Signed-off-by: Geert Uytterhoeven -
arch/m68k/Makefile computes lots of unneeded cc-option calls.
For example, if CONFIG_M5441x is not defined, there is not point in
evaluating the following compiler flag.cpuflags-$(CONFIG_M5441x) := $(call cc-option,-mcpu=54455,-mcfv4e)
The result is set to cpuflags-, then thrown away.
The right hand side of ':=' is immediately expanded. Hence, all of the
16 calls for cc-option are evaluated. This is expensive since cc-option
invokes the compiler. This occurs even if you are not attempting to
build anything, like 'make ARCH=m68k help'.Use '=' to expand the value _lazily_. The evaluation for cc-option is
delayed until $(cpuflags-y) is expanded. So, the cc-option test happens
just once at most.This commit mimics tune-y of arch/arm/Makefile.
Signed-off-by: Masahiro Yamada
Acked-by: Greg Ungerer
Link: https://lore.kernel.org/r/20200526123810.301667-3-masahiroy@kernel.org
Signed-off-by: Geert Uytterhoeven -
Use the standard obj-y form to specify the sub-directories under
arch/m68k/. No functional change intended.Signed-off-by: Masahiro Yamada
Acked-by: Greg Ungerer
Link: https://lore.kernel.org/r/20200526123810.301667-1-masahiroy@kernel.org
Signed-off-by: Geert Uytterhoeven
11 Jun, 2020
1 commit
-
Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp.
GZIP, BZIP2, LZOP env variables are reserved by the tools. The original
attempt to redefine them internally doesn't work in makefiles/scripts
intercall scenarios, e.g., "make GZIP=gzip bindeb-pkg" and results in
broken builds. There can be other broken build commands because of this,
so the universal solution is to use non-reserved env variables for the
compression tools.Fixes: 8dfb61dcbace ("kbuild: add variables for compression tools")
Signed-off-by: Denis Efremov
Tested-by: Guenter Roeck
Signed-off-by: Masahiro Yamada
06 Jun, 2020
1 commit
-
Allow user to use alternative implementations of compression tools,
such as pigz, pbzip2, pxz. For example, multi-threaded tools to
speed up the build:
$ make GZIP=pigz BZIP2=pbzip2Variables _GZIP, _BZIP2, _LZOP are used internally because original env
vars are reserved by the tools. The use of GZIP in gzip tool is obsolete
since 2015. However, alternative implementations (e.g., pigz) still rely
on it. BZIP2, BZIP, LZOP vars are not obsolescent.The credit goes to @grsecurity.
As a sidenote, for multi-threaded lzma, xz compression one can use:
$ export XZ_OPT="--threads=0"Signed-off-by: Denis Efremov
Signed-off-by: Masahiro Yamada
21 Aug, 2019
1 commit
-
Currently, the timestamp of module linker scripts are not checked.
Add them to the dependency of modules so they are correctly rebuilt.Signed-off-by: Masahiro Yamada
21 Jan, 2019
1 commit
-
This patch fixes a build failure when using GCC 8.1:
/usr/bin/ld: block/partitions/ldm.o: in function `ldm_parse_tocblock':
block/partitions/ldm.c:153: undefined reference to `strcmp'This is caused by a new optimization which effectively replaces a
strncmp() call with a strcmp() call. This affects a number of strncmp()
call sites in the kernel.The entire class of optimizations is avoided with -fno-builtin, which
gets enabled by -ffreestanding. This may avoid possible future build
failures in case new optimizations appear in future compilers.I haven't done any performance measurements with this patch but I did
count the function calls in a defconfig build. For example, there are now
23 more sprintf() calls and 39 fewer strcpy() calls. The effect on the
other libc functions is smaller.If this harms performance we can tackle that regression by optimizing
the call sites, ideally using semantic patches. That way, clang and ICC
builds might benfit too.Cc: stable@vger.kernel.org
Reference: https://marc.info/?l=linux-m68k&m=154514816222244&w=2
Signed-off-by: Finn Thain
Signed-off-by: Geert Uytterhoeven
04 Dec, 2018
1 commit
-
System call table generation script must be run to gener-
ate unistd_32.h and syscall_table.h files. This patch will
have changes which will invokes the script.This patch will generate unistd_32.h and syscall_table.h
files by the syscall table generation script invoked by
m68k/Makefile and the generated files against the removed
files must be identical.The generated uapi header file will be included in uapi/-
asm/unistd.h and generated system call table header file
will be included by kernel/syscalltable.S file.Signed-off-by: Firoz Khan
Signed-off-by: Geert Uytterhoeven
24 Aug, 2018
1 commit
-
Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add
additional options to CC") renamed CFLAGS to KBUILD_CFLAGS.Commit 222d394d30e7 ("kbuild: enable 'make AFLAGS=...' to add
additional options to AS") renamed AFLAGS to KBUILD_AFLAGS.Commit 06c5040cdb13 ("kbuild: enable 'make CPPFLAGS=...' to add
additional options to CPP") renamed CPPFLAGS to KBUILD_CPPFLAGS.For some reason, LDFLAGS was not renamed.
Using a well-known variable like LDFLAGS may result in accidental
override of the variable.Kbuild generally uses KBUILD_ prefixed variables for the internally
appended options, so here is one more conversion to sanitize the
naming convention.I did not touch Makefiles under tools/ since the tools build system
is a different world.Signed-off-by: Masahiro Yamada
Acked-by: Kirill A. Shutemov
Reviewed-by: Palmer Dabbelt
07 Mar, 2016
1 commit
-
Remove the obsolete Motorola/Freescale 68360 SoC support. It has been
bit rotting for many years with little active use in mainlne. There has
been no serial driver support for many years, so it is largely not
useful in its current state.Signed-off-by: Greg Ungerer
29 Sep, 2014
3 commits
-
The non-mmu 68360 specific code is inconsistently placed under a directory
named "platform". Move it to arch/m68k/ along with the other platform and
board directories.Signed-off-by: Greg Ungerer
Acked-by: Geert Uytterhoeven -
The non-mmu 68000 specific code is inconsistently placed under a directory
named "platform". Move it to arch/m68k/ along with the other platform and
machine directories.Signed-off-by: Greg Ungerer
Acked-by: Geert Uytterhoeven -
Move the m68k ColdFire platform support code directory to be with the
existing m68k platforms. Although the ColdFire is not a platform as such,
we have always kept all its support together. No reason to change that
as this time.Signed-off-by: Greg Ungerer
Acked-by: Geert Uytterhoeven
29 Apr, 2013
1 commit
-
The ColdFire 537x family is very similar internally to the ColdFire 532x
family. So with just a little extra configuration we can configure and
target them as well.Signed-off-by: Greg Ungerer
05 Dec, 2012
1 commit
-
This patch merges all 68000 core cpus into one directory.
There is a lot of common code in the 68328, 68EZ328 and 68VZ328 directories.This will also facilitate easy development of support for original stand
alone MC68000 CPU machines.Signed-off-by: Luis Alves
Signed-off-by: Greg Ungerer
16 Jul, 2012
2 commits
-
Add support for the Coldfire 5441x (54410/54415/54416/54417/54418). Currently
we only support noMMU mode. It requires the PIT patch posted previously as it
uses the PIT instead of the dma timer as a clock source so we can get all that
GENERIC_CLOCKEVENTS goodness. It also adds some simple clk definitions and
very simple minded power management. The gpio code is tweeked and some
additional devices are added to devices.c. The Makefile uses -mv4e as
apparently, the only difference a v4m (m5441x) and a v4e is the later has a
FPU, which I don't think should matter to us in the kernel.Signed-off-by: Steven King
Signed-off-by: Greg Ungerer -
Basic support for the Coldfire 5251/5253.
Signed-off-by: Steven king
Signed-off-by: Greg Ungerer
22 May, 2012
1 commit
-
Pull m68knommu tree from Greg Ungerer:
"More merge and clean up of MMU and non-MMU common files, namely
signal.c and dma.c. There is also a simplification of the ColdFire
GPIO setup tables. Using a couple of simple macros we make the init
tables really small and easy to read, and save a couple of thousand
lines of code. Also a move of all the ColdFire subarch support files
into the existing coldfire directory. The sub-directories just ended
up duplicating Makefiles and now only contain really simple pieces of
code. This saves quite a few lines of code too.As always a couple of bugs fixes thrown in too. Oh and a new
defconfig for the ColdFire platforms that support having the MMU
enabled."* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: (39 commits)
m68k: add a defconfig for the M5475EVB ColdFire with MMU board
m68knommu: unaligned.h fix for M68000 core
m68k: merge the MMU and non-MMU versions of the arch dma code
m68knommu: reorganize the no-MMU cache flushing to match m68k
m68knommu: move the 54xx platform code into the common ColdFire code directory
m68knommu: move the 532x platform code into the common ColdFire code directory
m68knommu: move the 5407 platform code into the common ColdFire code directory
m68knommu: move the 5307 platform code into the common ColdFire code directory
m68knommu: move the 528x platform code into the common ColdFire code directory
m68knommu: move the 527x platform code into the common ColdFire code directory
m68knommu: move the 5272 platform code into the common ColdFire code directory
m68knommu: move the 5249 platform code into the common ColdFire code directory
m68knommu: move the 523x platform code into the common ColdFire code directory
m68knommu: move the 520x platform code into the common ColdFire code directory
m68knommu: move the 5206 platform code into the common ColdFire code directory
m68knommu: simplify the ColdFire 5407 GPIO struct setup
m68knommu: simplify the ColdFire 532x GPIO struct setup
m68knommu: simplify the ColdFire 5307 GPIO struct setup
m68knommu: simplify the ColdFire 528x GPIO struct setup
m68knommu: simplify the ColdFire 527x GPIO struct setup
...
20 May, 2012
11 commits
-
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.Signed-off-by: Greg Ungerer
-
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.Signed-off-by: Greg Ungerer
-
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.Signed-off-by: Greg Ungerer
-
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.Signed-off-by: Greg Ungerer
-
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.Signed-off-by: Greg Ungerer
-
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.Signed-off-by: Greg Ungerer
-
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.Signed-off-by: Greg Ungerer
-
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.Signed-off-by: Greg Ungerer
-
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.Signed-off-by: Greg Ungerer
-
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.Signed-off-by: Greg Ungerer
-
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.Signed-off-by: Greg Ungerer
16 May, 2012
1 commit
-
CROSS_COMPILE must be setup before using e.g. cc-option (and a few other
as-*, cc-*, ld-* macros), else they will check against the wrong compiler
when cross-compiling, and may invoke the cross compiler with wrong or
suboptimal compiler options.Signed-off-by: Geert Uytterhoeven
Acked-by: Greg Ungerer
18 Oct, 2011
1 commit
-
Most of the build logic is the same for the mmu and non-mmu m68k targets.
Merge the top level architecture Makefiles back into a single Makefile.For the most part this is just adding the non-mmu processor types and
their specific cflags and other options into the mmu Makefile.Note that all the BOARD setting logic that was in the non-mmu Makefile
is completely removed. It was no longer being used at all.This has been build and run tested on ColdFire targets and ARAnyM.
It has been build tested on all the m68k defconfig targets using a
gcc-4.5.1 based toolchain.Signed-off-by: Greg Ungerer
Acked-by: Sam Ravnborg
25 Mar, 2011
1 commit
-
There is a lot of common code that could be shared between the m68k
and m68knommu arch branches. It makes sense to merge the two branches
into a single directory structure so that we can more easily share
that common code.This is a brute force merge, based on a script from Stephen King
, which was originally written by Arnd Bergmann
.> The script was inspired by the script Sam Ravnborg used to merge the
> includes from m68knommu. For those files common to both arches but
> differing in content, the m68k version of the file is renamed to
> _mm. and the m68knommu version of the file is moved into the
> corresponding m68k directory and renamed _no. and a small
> wrapper file . is used to select between the two version. Files
> that are common to both but don't differ are removed from the m68knommu
> tree and files and directories that are unique to the m68knommu tree are
> moved to the m68k tree. Finally, the arch/m68knommu tree is removed.
>
> To select between the the versions of the files, the wrapper uses
>
> #ifdef CONFIG_MMU
> #include _mm.
> #else
> #include _no.
> #endifOn top of this file merge I have done a simplistic merge of m68k and
m68knommu Kconfig, which primarily attempts to keep existing options and
menus in place. Other than a handful of options being moved it produces
identical .config outputs on m68k and m68knommu targets I tested it on.With this in place there is now quite a bit of scope for merge cleanups
in future patches.Signed-off-by: Greg Ungerer
17 Mar, 2011
1 commit
-
Add improved support for running under the ARAnyM emulator
(Atari Running on Any Machine - http://aranym.org/).[michael, geert: Cleanups and updates]
Signed-off-by: Petr Stehlik
Signed-off-by: Michael Schmitz
Signed-off-by: Geert Uytterhoeven
03 Aug, 2010
1 commit
-
It is now possible to assign options to AS, CC and LD
on the command line - which is only used when building modules.{A,C,LD}FLAGS_MODULE was all used both in the top-level Makefile
in the arch makefiles, thus users had no way to specify
additional options to AS, CC, LD when building modules
without overriding the original value.Introduce a new set of variables KBUILD_{A,C,LD}FLAGS_MODULE
that is used by arch specific files and free up
{A,C,LD}FLAGS_MODULE so they can be assigned on
the command line.All arch Makefiles that used the old variables has been updated.
Note: Previously we had a MODFLAGS variable for both
AS and CC. But in favour of consistency this was dropped.
So in some cases arch Makefile has one assignmnet replaced by
two assignmnets.Note2: MODFLAGS was not documented and is dropped
without any notice. I do not expect much/any breakage
from this.Signed-off-by: Sam Ravnborg
Cc: Denys Vlasenko
Cc: Haavard Skinnemoen
Cc: Mike Frysinger
Cc: Tony Luck
Cc: Geert Uytterhoeven
Cc: Ralf Baechle
Cc: Benjamin Herrenschmidt
Cc: Martin Schwidefsky
Cc: Chen Liqin
Acked-by: Mike Frysinger [blackfin]
Acked-by: Haavard Skinnemoen [avr32]
Signed-off-by: Michal Marek
27 Mar, 2009
1 commit
-
This patch enables the use of "make install" on m68k architecture
to copy kernel to /boot.Signed-off-by: Laurent Vivier
Signed-off-by: Geert Uytterhoeven
21 Jul, 2008
1 commit
-
It seems to match the intention behind multi_defconfig to make it the
default defconfig.Signed-off-by: Adrian Bunk
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Linus Torvalds
05 Apr, 2008
1 commit
-
The default defconfig should be one from arch/m68k/configs/
arch/m68k/defconfig was not exactly identical to amiga_defconfig but
also considering how long they have been without any update that doesn't
seem to have been on purpose.Signed-off-by: Adrian Bunk
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Linus Torvalds
06 Feb, 2008
1 commit
-
The cc-cross-prefix is new and developed on request from Geert Uytterhoeven.
With cc-cross-prefix it is now much easier to have a few default cross compile
prefixes and defaulting to none - if none of them were present. ARCH
maintainers are expected to pick up this feature soon.Signed-off-by: Geert Uytterhoeven
Cc: Andreas Schwab
Cc: Sam Ravnborg
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds