Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71 |
|
#
ce697cce |
| 24-Sep-2022 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: remove head-y syntax
Kbuild puts the objects listed in head-y at the head of vmlinux. Conventionally, we do this for head*.S, which contains the kernel entry point.
A counter approach is to
kbuild: remove head-y syntax
Kbuild puts the objects listed in head-y at the head of vmlinux. Conventionally, we do this for head*.S, which contains the kernel entry point.
A counter approach is to control the section order by the linker script. Actually, the code marked as __HEAD goes into the ".head.text" section, which is placed before the normal ".text" section.
I do not know if both of them are needed. From the build system perspective, head-y is not mandatory. If you can achieve the proper code placement by the linker script only, it would be cleaner.
I collected the current head-y objects into head-object-list.txt. It is a whitelist. My hope is it will be reduced in the long run.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
show more ...
|
Revision tags: v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12 |
|
#
c20e1117 |
| 23-Apr-2021 |
Max Filippov <jcmvbkbc@gmail.com> |
xtensa: add kernel ABI selection to Kconfig
Add choice to use default or call0 ABI for the kernel code. If call0 ABI is chosen add '-mabi=call0' to the flags. The toolchain support for this option i
xtensa: add kernel ABI selection to Kconfig
Add choice to use default or call0 ABI for the kernel code. If call0 ABI is chosen add '-mabi=call0' to the flags. The toolchain support for this option is rather new so only enable it when the compiler supports it.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
#
19c5699f |
| 18-Oct-2021 |
Max Filippov <jcmvbkbc@gmail.com> |
xtensa: don't link with libgcc
libgcc may be absent or may have different ABI than the kernel. Don't link with it. Drop declarations and export for helpers that are not implemented. Use generic vers
xtensa: don't link with libgcc
libgcc may be absent or may have different ABI than the kernel. Don't link with it. Drop declarations and export for helpers that are not implemented. Use generic versions of DI mode multiplication and comparisons. Drop register window spilling helper as it should never be used by the compiler-generated code.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
#
129ab0d2 |
| 13-Dec-2021 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: do not quote string values in include/config/auto.conf
The previous commit fixed up all shell scripts to not include include/config/auto.conf.
Now that include/config/auto.conf is only incl
kbuild: do not quote string values in include/config/auto.conf
The previous commit fixed up all shell scripts to not include include/config/auto.conf.
Now that include/config/auto.conf is only included by Makefiles, we can change it into a more Make-friendly form.
Previously, Kconfig output string values enclosed with double-quotes (both in the .config and include/config/auto.conf):
CONFIG_X="foo bar"
Unlike shell, Make handles double-quotes (and single-quotes as well) verbatim. We must rip them off when used.
There are some patterns:
[1] $(patsubst "%",%,$(CONFIG_X)) [2] $(CONFIG_X:"%"=%) [3] $(subst ",,$(CONFIG_X)) [4] $(shell echo $(CONFIG_X))
These are not only ugly, but also fragile.
[1] and [2] do not work if the value contains spaces, like CONFIG_X=" foo bar "
[3] does not work correctly if the value contains double-quotes like CONFIG_X="foo\"bar"
[4] seems to work better, but has a cost of forking a process.
Anyway, quoted strings were always PITA for our Makefiles.
This commit changes Kconfig to stop quoting in include/config/auto.conf.
These are the string type symbols referenced in Makefiles or scripts:
ACPI_CUSTOM_DSDT_FILE ARC_BUILTIN_DTB_NAME ARC_TUNE_MCPU BUILTIN_DTB_SOURCE CC_IMPLICIT_FALLTHROUGH CC_VERSION_TEXT CFG80211_EXTRA_REGDB_KEYDIR EXTRA_FIRMWARE EXTRA_FIRMWARE_DIR EXTRA_TARGETS H8300_BUILTIN_DTB INITRAMFS_SOURCE LOCALVERSION MODULE_SIG_HASH MODULE_SIG_KEY NDS32_BUILTIN_DTB NIOS2_DTB_SOURCE OPENRISC_BUILTIN_DTB SOC_CANAAN_K210_DTB_SOURCE SYSTEM_BLACKLIST_HASH_LIST SYSTEM_REVOCATION_KEYS SYSTEM_TRUSTED_KEYS TARGET_CPU UNUSED_KSYMS_WHITELIST XILINX_MICROBLAZE0_FAMILY XILINX_MICROBLAZE0_HW_VER XTENSA_VARIANT_NAME
I checked them one by one, and fixed up the code where necessary.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
#
8212f898 |
| 13-Oct-2021 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: use more subdir- for visiting subdirectories while cleaning
Documentation/kbuild/makefiles.rst suggests to use "archclean" for cleaning arch/$(SRCARCH)/boot/, but it is not a hard requiremen
kbuild: use more subdir- for visiting subdirectories while cleaning
Documentation/kbuild/makefiles.rst suggests to use "archclean" for cleaning arch/$(SRCARCH)/boot/, but it is not a hard requirement.
Since commit d92cc4d51643 ("kbuild: require all architectures to have arch/$(SRCARCH)/Kbuild"), we can use the "subdir- += boot" trick for all architectures. This can take advantage of the parallel option (-j) for "make clean".
I also cleaned up the comments in arch/$(SRCARCH)/Makefile. The "archdep" target no longer exists.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
show more ...
|
#
7b7cec47 |
| 11-Aug-2021 |
Masahiro Yamada <masahiroy@kernel.org> |
xtensa: move core-y in arch/xtensa/Makefile to arch/xtensa/Kbuild
Use obj-y to clean up Makefile.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Message-Id: <20210811163731.186125-4-masahiro
xtensa: move core-y in arch/xtensa/Makefile to arch/xtensa/Kbuild
Use obj-y to clean up Makefile.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Message-Id: <20210811163731.186125-4-masahiroy@kernel.org> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
#
59210499 |
| 11-Aug-2021 |
Masahiro Yamada <masahiroy@kernel.org> |
xtensa: build platform directories unconditionally
All of arch/xtensa/platforms/*/ have Makefile. You do not need to check the presence of Makefile.
Signed-off-by: Masahiro Yamada <masahiroy@kernel
xtensa: build platform directories unconditionally
All of arch/xtensa/platforms/*/ have Makefile. You do not need to check the presence of Makefile.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Message-Id: <20210811163731.186125-3-masahiroy@kernel.org> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
#
c5485844 |
| 11-Aug-2021 |
Masahiro Yamada <masahiroy@kernel.org> |
xtensa: do not build variants directory
None of arch/xtensa/variants/*/ has Makefile, so 'buildvar' is always empty.
Perhaps, downstream variant code might be dropped in, but given the fact that no
xtensa: do not build variants directory
None of arch/xtensa/variants/*/ has Makefile, so 'buildvar' is always empty.
Perhaps, downstream variant code might be dropped in, but given the fact that none of upstream variants builds anything in their variant directory, I doubt this is needed.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Message-Id: <20210811163731.186125-2-masahiroy@kernel.org> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
#
ef71db48 |
| 11-Aug-2021 |
Masahiro Yamada <masahiroy@kernel.org> |
xtensa: remove unneeded exports
These are not used in any of subdirectories.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Message-Id: <20210811163731.186125-1-masahiroy@kernel.org> Signed-
xtensa: remove unneeded exports
These are not used in any of subdirectories.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Message-Id: <20210811163731.186125-1-masahiroy@kernel.org> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
#
23243c1a |
| 01-May-2021 |
Masahiro Yamada <masahiroy@kernel.org> |
arch: use cross_compiling to check whether it is a cross build or not
'cross_compiling' is defined by the top Makefile and available for arch Makefiles to check whether it is a cross build or not. A
arch: use cross_compiling to check whether it is a cross build or not
'cross_compiling' is defined by the top Makefile and available for arch Makefiles to check whether it is a cross build or not. A good thing is the variable name 'cross_compiling' is self-documenting.
This is a simple replacement for m68k, mips, sh, for which $(ARCH) and $(SRCARCH) always match.
No functional change is intended for xtensa, either.
This is rather a fix for parisc because arch/parisc/Makefile defines UTS_MATCHINE depending on CONFIG_64BIT, therefore cc-cross-prefix is not working in Kconfig time.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Acked-by: Max Filippov <jcmvbkbc@gmail.com> # xtensa
show more ...
|
Revision tags: v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24 |
|
#
c425c546 |
| 13-Mar-2021 |
Masahiro Yamada <masahiroy@kernel.org> |
xtensa: move CONFIG_CPU_*_ENDIAN defines to Kconfig
Move the definition of CONFIG_CPU_*_ENDIAN to Kconfig, the best place for CONFIG options.
I slightly simplified the test code. You can use the -P
xtensa: move CONFIG_CPU_*_ENDIAN defines to Kconfig
Move the definition of CONFIG_CPU_*_ENDIAN to Kconfig, the best place for CONFIG options.
I slightly simplified the test code. You can use the -P option to suppress linemarker generation. The grep command is unneeded.
$ echo __XTENSA_EB__ | xtensa-linux-gcc -E - # 1 "<stdin>" # 1 "<built-in>" # 1 "<command-line>" # 1 "<stdin>" 1
$ echo __XTENSA_EB__ | xtensa-linux-gcc -E -P - 1
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Message-Id: <20210313122342.69995-1-masahiroy@kernel.org> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
Revision tags: v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
a848bf1d |
| 14-Jan-2021 |
Viresh Kumar <viresh.kumar@linaro.org> |
arch: xtensa: Remove CONFIG_OPROFILE support
The "oprofile" user-space tools don't use the kernel OPROFILE support any more, and haven't in a long time. User-space has been converted to the perf int
arch: xtensa: Remove CONFIG_OPROFILE support
The "oprofile" user-space tools don't use the kernel OPROFILE support any more, and haven't in a long time. User-space has been converted to the perf interfaces.
Remove the old oprofile's architecture specific support.
Suggested-by: Christoph Hellwig <hch@infradead.org> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Robert Richter <rric@kernel.org> Acked-by: Max Filippov <jcmvbkbc@gmail.com> Acked-by: William Cohen <wcohen@redhat.com> Acked-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Thomas Gleixner <tglx@linutronix.de>
show more ...
|
Revision tags: v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14, v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10 |
|
#
7af710d9 |
| 03-Jan-2017 |
Max Filippov <jcmvbkbc@gmail.com> |
xtensa: add XIP kernel support
XIP (eXecute In Place) kernel image is the image that can be run directly from ROM, using RAM only for writable data.
XIP xtensa kernel differs from regular xtensa ke
xtensa: add XIP kernel support
XIP (eXecute In Place) kernel image is the image that can be run directly from ROM, using RAM only for writable data.
XIP xtensa kernel differs from regular xtensa kernel in the following ways: - it has exception/IRQ vectors merged into text section. No vectors relocation takes place at kernel startup. - .data/.bss location must be specified in the kernel configuration, its content is copied there in the _startup function. - .init.text is merged with the rest of text and is executed from ROM. - when MMU is used the virtual address where the kernel will be mapped must be specified in the kernel configuration. It may be in the KSEG or in the KIO, __pa macro is adjusted to be able to handle both.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
#
5eacadb5 |
| 13-Nov-2018 |
Firoz Khan <firoz.khan@linaro.org> |
xtensa: generate uapi header and syscall table header files
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 wi
xtensa: generate uapi header and syscall table header files
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 xtensa/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/syscall.c file.
Signed-off-by: Firoz Khan <firoz.khan@linaro.org> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
#
37c8a5fa |
| 10-Jan-2018 |
Rob Herring <robh@kernel.org> |
kbuild: consolidate Devicetree dtb build rules
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dep
kbuild: consolidate Devicetree dtb build rules
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules.
The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc.
This change enables support 'dtbs_install' on some arches which were missing the target.
Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Paul Burton <paul.burton@mips.com> Acked-by: Ley Foon Tan <ley.foon.tan@intel.com> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Michal Simek <monstr@monstr.eu> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Chris Zankel <chris@zankel.net> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: linux-kbuild@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: uclinux-h8-devel@lists.sourceforge.jp Cc: linux-mips@linux-mips.org Cc: nios2-dev@lists.rocketboards.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-xtensa@linux-xtensa.org Signed-off-by: Rob Herring <robh@kernel.org>
show more ...
|
#
8e966fab |
| 11-Sep-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
xtensa: remove unnecessary KBUILD_SRC ifeq conditional
You can always prefix variant/platform header search paths with $(srctree)/ because $(srctree) is '.' for in-tree building.
Signed-off-by: Mas
xtensa: remove unnecessary KBUILD_SRC ifeq conditional
You can always prefix variant/platform header search paths with $(srctree)/ because $(srctree) is '.' for in-tree building.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
#
d503ac53 |
| 23-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kbuild: rename LDFLAGS to KBUILD_LDFLAGS
Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add additional options to CC") renamed CFLAGS to KBUILD_CFLAGS.
Commit 222d394d30e7 ("kbuild: enab
kbuild: rename LDFLAGS to KBUILD_LDFLAGS
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 <yamada.masahiro@socionext.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
show more ...
|
#
f8f02ca7 |
| 03-Dec-2017 |
Max Filippov <jcmvbkbc@gmail.com> |
xtensa: build kernel with text-section-literals
vmlinux.lds.S doesn't do anything special with literals, so instead of keeping them separate put them into the corresponding text sections. Drop expli
xtensa: build kernel with text-section-literals
vmlinux.lds.S doesn't do anything special with literals, so instead of keeping them separate put them into the corresponding text sections. Drop explicit .literal sections from the vmlinux.lds.S, use standard section macros. Mark literal pool locations in the assembly sources. Unfortunately assembler doesn't put literals into .init sections and external libgcc may still have .literal sections, so sed transformation to the linker script is still needed.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
#
7bf5234d |
| 28-Apr-2017 |
Max Filippov <jcmvbkbc@gmail.com> |
xtensa: add -mno-serialize-volatile to CFLAGS
By default xtensa gcc inserts memw for all volatile object accesses. This is too pessimistic for the kernel: there should be no "normal" volatile object
xtensa: add -mno-serialize-volatile to CFLAGS
By default xtensa gcc inserts memw for all volatile object accesses. This is too pessimistic for the kernel: there should be no "normal" volatile objects, and all special objects, like MMIO or objects shared between CPUs should have explicit barriers.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
#
9a736fcb |
| 25-Dec-2016 |
Max Filippov <jcmvbkbc@gmail.com> |
xtensa: clean up bootable image build targets
Currently xtensa uses 'zImage' as a synonym of 'all', but in fact xtensa supports three targets: 'Image' (ELF image with reset vector), 'zImage' (compre
xtensa: clean up bootable image build targets
Currently xtensa uses 'zImage' as a synonym of 'all', but in fact xtensa supports three targets: 'Image' (ELF image with reset vector), 'zImage' (compressed redboot image) and 'uImage' (U-Boot image). Provide separate 'Image', 'zImage' and 'uImage' make targets that only build corresponding image type. Make 'all' build all images appropriate for a platform.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
Revision tags: v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4 |
|
#
4611bf7e |
| 29-Feb-2016 |
Max Filippov <jcmvbkbc@gmail.com> |
xtensa: define CONFIG_CPU_{BIG,LITTLE}_ENDIAN
Query compiler for the CPU endianness and add corresponding definition to KBUILD_CPPFLAGS. This allows using 'native-endian' property in DTS.
Signed-of
xtensa: define CONFIG_CPU_{BIG,LITTLE}_ENDIAN
Query compiler for the CPU endianness and add corresponding definition to KBUILD_CPPFLAGS. This allows using 'native-endian' property in DTS.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
Revision tags: v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1, openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1 |
|
#
99085704 |
| 06-Oct-2015 |
Rob Herring <robh@kernel.org> |
xtensa: enable building of all dtbs
Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs are not really dependent on a platform being enabled or any other kernel config, so for
xtensa: enable building of all dtbs
Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs are not really dependent on a platform being enabled or any other kernel config, so for testing coverage it is convenient to build all of the dtbs. This builds all dts files in the tree, not just targets listed.
Signed-off-by: Rob Herring <robh@kernel.org> Cc: Chris Zankel <chris@zankel.net> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: linux-xtensa@linux-xtensa.org
show more ...
|
Revision tags: v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1 |
|
#
4006e565 |
| 18-Oct-2014 |
Daniel Glöckner <dg@emlix.com> |
xtensa: remove s6000 variant and s6105 platform
The Stretch s6000 family support has been merged into mainline 5 years ago. There appear to be no users of this code since nobody complained that ther
xtensa: remove s6000 variant and s6105 platform
The Stretch s6000 family support has been merged into mainline 5 years ago. There appear to be no users of this code since nobody complained that there is a merge error preventing compilation.
Apart from the s6105 IP camera reference design there are no s6000 devices known to ever have run Linux and as the chips are out of production there probably never will be. The successor s7000 no longer uses an Xtensa core for the OS.
Let's remove the code until someone is found who actually needs it.
Signed-off-by: Daniel Glöckner <dg@emlix.com> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
Revision tags: v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1 |
|
#
420ae951 |
| 15-Jun-2014 |
Max Filippov <jcmvbkbc@gmail.com> |
xtensa: simplify addition of new core variants
Instead of adding new Kconfig options and Makefile rules for each new core variant provide XTENSA_VARIANT_CUSTOM variant and record variant name in the
xtensa: simplify addition of new core variants
Instead of adding new Kconfig options and Makefile rules for each new core variant provide XTENSA_VARIANT_CUSTOM variant and record variant name in the XTENSA_VARIANT_NAME variable. Adding new core variant now means providing directory structure under arch/xtensa/variant and specifying correct name in kernel configuration.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
show more ...
|
Revision tags: v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3, v3.14-rc2, v3.14-rc1, v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1, v3.12, v3.12-rc7, v3.12-rc6, v3.12-rc5, v3.12-rc4, v3.12-rc3, v3.12-rc2, v3.12-rc1, v3.11, v3.11-rc7 |
|
#
123f15e6 |
| 22-Aug-2013 |
Max Filippov <jcmvbkbc@gmail.com> |
xtensa: don't use echo -e needlessly
-e is not needed to output strings without escape sequences. This breaks big endian FSF build when the shell is dash, because its builtin echo doesn't understand
xtensa: don't use echo -e needlessly
-e is not needed to output strings without escape sequences. This breaks big endian FSF build when the shell is dash, because its builtin echo doesn't understand '-e' switch and outputs it in the echoed string.
Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Chris Zankel <chris@zankel.net>
show more ...
|