20 Jan, 2021
4 commits
-
[ Upstream commit c5e6ae563c802c4d828d42e134af64004db2e58c ]
If you run 'make uImage uImage.gz' with the parallel option, uImage.gz
will be created by two threads simultaneously.This is because arch/arc/Makefile does not specify the dependency
between uImage and uImage.gz. Hence, GNU Make assumes they can be
built in parallel. One thread descends into arch/arc/boot/ to create
uImage, and another to create uImage.gz.Please notice the same log is displayed twice in the following steps:
$ export CROSS_COMPILE=
$ make -s ARCH=arc defconfig
$ make -j$(nproc) ARCH=arc uImage uImage.gz
[ snip ]
LD vmlinux
SORTTAB vmlinux
SYSMAP System.map
OBJCOPY arch/arc/boot/vmlinux.bin
OBJCOPY arch/arc/boot/vmlinux.bin
GZIP arch/arc/boot/vmlinux.bin.gz
GZIP arch/arc/boot/vmlinux.bin.gz
UIMAGE arch/arc/boot/uImage.gz
UIMAGE arch/arc/boot/uImage.gz
Image Name: Linux-5.10.0-rc4-00003-g62f23044
Created: Sun Nov 22 02:52:26 2020
Image Type: ARC Linux Kernel Image (gzip compressed)
Data Size: 2109376 Bytes = 2059.94 KiB = 2.01 MiB
Load Address: 80000000
Entry Point: 80004000
Image arch/arc/boot/uImage is ready
Image Name: Linux-5.10.0-rc4-00003-g62f23044
Created: Sun Nov 22 02:52:26 2020
Image Type: ARC Linux Kernel Image (gzip compressed)
Data Size: 2815455 Bytes = 2749.47 KiB = 2.69 MiB
Load Address: 80000000
Entry Point: 80004000This is a race between the two threads trying to write to the same file
arch/arc/boot/uImage.gz. This is a potential problem that can generate
a broken file.I fixed a similar problem for ARM by commit 3939f3345050 ("ARM: 8418/1:
add boot image dependencies to not generate invalid images").I highly recommend to avoid such build rules that cause a race condition.
Move the uImage rule to arch/arc/Makefile.
Another strangeness is that arch/arc/boot/Makefile compares the
timestamps between $(obj)/uImage and $(obj)/uImage.*:$(obj)/uImage: $(obj)/uImage.$(suffix-y)
@ln -sf $(notdir $
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin -
[ Upstream commit 0cfccb3c04934cdef42ae26042139f16e805b5f7 ]
The top-level boot_targets (uImage and uImage.*) should be phony
targets. They just let Kbuild descend into arch/arc/boot/ and create
files there.If a file exists in the top directory with the same name, the boot
image will not be created.You can confirm it by the following steps:
$ export CROSS_COMPILE=
$ make -s ARCH=arc defconfig all # vmlinux will be built
$ touch uImage.gz
$ make ARCH=arc uImage.gz
CALL scripts/atomic/check-atomics.sh
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
# arch/arc/boot/uImage.gz is not createdSpecify the targets as PHONY to fix this.
Signed-off-by: Masahiro Yamada
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin -
[ Upstream commit f2712ec76a5433e5ec9def2bd52a95df1f96d050 ]
arch/arc/boot/Makefile supports uImage.lzma, but you cannot do
'make uImage.lzma' because the corresponding target is missing
in arch/arc/Makefile. Add it.I also changed the assignment operator '+=' to ':=' since this is the
only place where we expect this variable to be set.Signed-off-by: Masahiro Yamada
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin -
[ Upstream commit 9836720911cfec25d3fbdead1c438bf87e0f2841 ]
The deb-pkg builds for ARCH=arc fail.
$ export CROSS_COMPILE=
$ make -s ARCH=arc defconfig
$ make ARCH=arc bindeb-pkg
SORTTAB vmlinux
SYSMAP System.map
MODPOST Module.symvers
make KERNELRELEASE=5.10.0-rc4 ARCH=arc KBUILD_BUILD_VERSION=2 -f ./Makefile intdeb-pkg
sh ./scripts/package/builddeb
cp: cannot stat 'arch/arc/boot/bootpImage': No such file or directory
make[4]: *** [scripts/Makefile.package:87: intdeb-pkg] Error 1
make[3]: *** [Makefile:1527: intdeb-pkg] Error 2
make[2]: *** [debian/rules:13: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
make[1]: *** [scripts/Makefile.package:83: bindeb-pkg] Error 2
make: *** [Makefile:1527: bindeb-pkg] Error 2The reason is obvious; arch/arc/Makefile sets $(boot)/bootpImage as
the default image, but there is no rule to build it.Remove the meaningless KBUILD_IMAGE assignment so it will fallback
to the default vmlinux. With this change, you can build the deb package.I removed the 'bootpImage' target as well. At best, it provides
'make bootpImage' as an alias of 'make vmlinux', but I do not see
much sense in doing so.Signed-off-by: Masahiro Yamada
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
06 Oct, 2020
1 commit
-
NPS customers are no longer doing active development, as evident from
rand config build failures reported in recent times, so drop support
for NPS platform.Tested-by: kernel test robot
Signed-off-by: Vineet Gupta
17 Jun, 2020
2 commits
-
Signed-off-by: Vineet Gupta
-
kernel build system used to add -mcpu for each ARC ISA as default.
These days there are versions and varaints of ARC HS cores some of which
have specific -mcpu options to fine tune / optimize generated code.So allow users/external build systems to specify their own -mcpu
This will be used in future patches for HSDK-4xD board support which
uses specific -mcpu to utilize dual issue scheduling of the core.Signed-off-by: Eugeniy Paltsev
Signed-off-by: Vineet Gupta
[abrodkin/vgupta: rewrote changelog]
29 Oct, 2019
1 commit
-
Starting from nSIM 2019.06 is possible to use DW UART
instead of ARC UART. That allows us to merge
"nsim_hs" with "haps_hs" and "nsim_hs_smp" with "haps_hs_smp"
with minor changes which were done in previous commits.We eliminate nsim_hs_defconfig and nsim_hs_smp_defconfig
and leave haps_hs_defconfig and haps_hs_smp_defconfig
which can be used on HAPS / nSIM / ZEBU / QEMU platforms
without additional changes in Linux kernel.For nSIM we should now use UART property values
"-prop=nsim_mem-dev=uart0,kind=dwuart,base=0xf0000000"
instead of previously used
"-prop=nsim_mem-dev=uart0,base=0xc0fc1000"
"use_connect" and "irq" values of UART property remains untouched.Signed-off-by: Eugeniy Paltsev
Signed-off-by: Vineet Gupta
04 Sep, 2019
1 commit
-
arch/arc/Makefile overrides -O2 with -O3. This is the only user of
ARCH_CFLAGS. There is no user of ARCH_CPPFLAGS or ARCH_AFLAGS.
My plan is to remove ARCH_{CPP,A,C}FLAGS after refactoring the ARC
Makefile.Currently, ARC has no way to enable -Wmaybe-uninitialized because both
-O3 and -Os disable it. Enabling it will be useful for compile-testing.
This commit allows allmodconfig (, which defaults to -O2) to enable it.Add CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3=y to all the defconfig files
in arch/arc/configs/ in order to keep the current config settings.Signed-off-by: Masahiro Yamada
Acked-by: Vineet Gupta
13 Jul, 2019
1 commit
-
Pull Kbuild updates from Masahiro Yamada:
- remove headers_{install,check}_all targets
- remove unreasonable 'depends on !UML' from CONFIG_SAMPLES
- re-implement 'make headers_install' more cleanly
- add new header-test-y syntax to compile-test headers
- compile-test exported headers to ensure they are compilable in
user-space- compile-test headers under include/ to ensure they are self-contained
- remove -Waggregate-return, -Wno-uninitialized, -Wno-unused-value
flags- add -Werror=unknown-warning-option for Clang
- add 128-bit built-in types support to genksyms
- fix missed rebuild of modules.builtin
- propagate 'No space left on device' error in fixdep to Make
- allow Clang to use its integrated assembler
- improve some coccinelle scripts
- add a new flag KBUILD_ABS_SRCTREE to request Kbuild to use absolute
path for $(srctree).- do not ignore errors when compression utility is missing
- misc cleanups
* tag 'kbuild-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (49 commits)
kbuild: use -- separater intead of $(filter-out ...) for cc-cross-prefix
kbuild: Inform user to pass ARCH= for make mrproper
kbuild: fix compression errors getting ignored
kbuild: add a flag to force absolute path for srctree
kbuild: replace KBUILD_SRCTREE with boolean building_out_of_srctree
kbuild: remove src and obj from the top Makefile
scripts/tags.sh: remove unused environment variables from comments
scripts/tags.sh: drop SUBARCH support for ARM
kbuild: compile-test kernel headers to ensure they are self-contained
kheaders: include only headers into kheaders_data.tar.xz
kheaders: remove meaningless -R option of 'ls'
kbuild: support header-test-pattern-y
kbuild: do not create wrappers for header-test-y
kbuild: compile-test exported headers to ensure they are self-contained
init/Kconfig: add CONFIG_CC_CAN_LINK
kallsyms: exclude kasan local symbols on s390
kbuild: add more hints about SUBDIRS replacement
coccinelle: api/stream_open: treat all wait_.*() calls as blocking
coccinelle: put_device: Add a cast to an expression for an assignment
coccinelle: put_device: Adjust a message construction
...
10 Jul, 2019
1 commit
-
Replace $(src) and $(obj) with $(srctree) and $(objtree), respectively.
Signed-off-by: Masahiro Yamada
29 Jun, 2019
1 commit
-
Pull ARC fixes from Vineet Gupta:
- hsdk platform unifying apertures
- build system CROSS_COMPILE prefix
* tag 'arc-5.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARC: [plat-hsdk]: unify memory apertures configuration
ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix
19 Jun, 2019
1 commit
-
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundationthis program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Enrico Weigelt
Reviewed-by: Kate Stewart
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman
12 Jun, 2019
1 commit
-
For a long time we used to hard-code CROSS_COMPILE prefix
for ARC until it started to cause problems, so we decided to
solely rely on CROSS_COMPILE externally set by a user:
commit 40660f1fcee8 ("ARC: build: Don't set CROSS_COMPILE in arch's Makefile").While it works perfectly fine for build-systems where the prefix
gets defined anyways for us human beings it's quite an annoying
requirement especially given most of time the same one prefix
"arc-linux-" is all what we need.It looks like finally we're getting the best of both worlds:
1. W/o cross-toolchain we still may install headers, build .dtb etc
2. W/ cross-toolchain get the kerne built with only ARCH=arcInspired by [1] & [2].
[1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-May/005788.html
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc2b47b55f17A side note: even though "cc-cross-prefix" does its job it pollutes
console with output of "which" for all the prefixes it didn't manage to find
a matching cross-compiler for like that:
| # ARCH=arc make defconfig
| which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin)
| *** Default configuration is based on 'nsim_hs_defconfig'Suggested-by: Vineet Gupta
Reviewed-by: Masahiro Yamada
Signed-off-by: Alexey Brodkin
Signed-off-by: Vineet Gupta
26 Feb, 2019
1 commit
-
As of today we enable unaligned access unconditionally on ARCv2.
Do this under a Kconfig option to allow disable it for test, benchmarking
etc. Also while at it- Select HAVE_EFFICIENT_UNALIGNED_ACCESS
- Although gcc defaults to unaligned access (since GNU 2018.03), add the
right toggles for enabling or disabling as appropriate
- update bootlog to prints both HW feature status (exists, enabled/disabled)
and SW status (used / not used).
- wire up the relaxed memcpy for unaligned accessSigned-off-by: Eugeniy Paltsev
Signed-off-by: Vineet Gupta
[vgupta: squashed patches, handle gcc -mno-unaligned-access quick]
01 Dec, 2018
1 commit
-
Change the default defconfig (used with 'make defconfig') to the ARCv2
nsim_hs_defconfig, and also switch the default Kconfig ISA selection to
ARCv2.This allows several default defconfigs (e.g. make defconfig, make
allnoconfig, make tinyconfig) to all work with ARCv2 by default.Note since we change default architecture from ARCompact to ARCv2
it's required to explicitly mention architecture type in ARCompact
defconfigs otherwise ARCv2 will be implied and binaries will be
generated for ARCv2.Cc: # 4.4.x
Signed-off-by: Kevin Hilman
Signed-off-by: Alexey Brodkin
Signed-off-by: Vineet Gupta
27 Oct, 2018
1 commit
-
Pull Devicetree updates from Rob Herring:
"A bit bigger than normal as I've been busy this cycle.There's a few things with dependencies and a few things subsystem
maintainers didn't pick up, so I'm taking them thru my tree.The fixes from Johan didn't get into linux-next, but they've been
waiting for some time now and they are what's left of what subsystem
maintainers didn't pick up.Summary:
- Sync dtc with upstream version v1.4.7-14-gc86da84d30e4
- Work to get rid of direct accesses to struct device_node name and
type pointers in preparation for removing them. New helpers for
parsing DT cpu nodes and conversions to use the helpers. printk
conversions to %pOFn for printing DT node names. Most went thru
subystem trees, so this is the remainder.- Fixes to DT child node lookups to actually be restricted to child
nodes instead of treewide.- Refactoring of dtb targets out of arch code. This makes the support
more uniform and enables building all dtbs on c6x, microblaze, and
powerpc.- Various DT binding updates for Renesas r8a7744 SoC
- Vendor prefixes for Facebook, OLPC
- Restructuring of some ARM binding docs moving some peripheral
bindings out of board/SoC binding files- New "secure-chosen" binding for secure world settings on ARM
- Dual licensing of 2 DT IRQ binding headers"
* tag 'devicetree-for-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (78 commits)
ARM: dt: relicense two DT binding IRQ headers
power: supply: twl4030-charger: fix OF sibling-node lookup
NFC: nfcmrvl_uart: fix OF child-node lookup
net: stmmac: dwmac-sun8i: fix OF child-node lookup
net: bcmgenet: fix OF child-node lookup
drm/msm: fix OF child-node lookup
drm/mediatek: fix OF sibling-node lookup
of: Add missing exports of node name compare functions
dt-bindings: Add OLPC vendor prefix
dt-bindings: misc: bk4: Add device tree binding for Liebherr's BK4 SPI bus
dt-bindings: thermal: samsung: Add SPDX license identifier
dt-bindings: clock: samsung: Add SPDX license identifiers
dt-bindings: timer: ostm: Add R7S9210 support
dt-bindings: phy: rcar-gen2: Add r8a7744 support
dt-bindings: can: rcar_can: Add r8a7744 support
dt-bindings: timer: renesas, cmt: Document r8a7744 CMT support
dt-bindings: watchdog: renesas-wdt: Document r8a7744 support
dt-bindings: thermal: rcar: Add device tree support for r8a7744
Documentation: dt: Add binding for /secure-chosen/stdout-path
dt-bindings: arm: zte: Move sysctrl bindings to their own doc
...
02 Oct, 2018
1 commit
-
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
Acked-by: Paul Burton
Acked-by: Ley Foon Tan
Acked-by: Masahiro Yamada
Cc: Michal Marek
Cc: Vineet Gupta
Cc: Russell King
Cc: Catalin Marinas
Cc: Yoshinori Sato
Cc: Michal Simek
Cc: Ralf Baechle
Cc: James Hogan
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Chris Zankel
Cc: Max Filippov
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
19 Sep, 2018
1 commit
-
There's not much sense in doing that because if user or
his build-system didn't set CROSS_COMPILE we still may
very well make incorrect guess.But as it turned out setting CROSS_COMPILE is not as harmless
as one may think: with recent changes that implemented automatic
discovery of __host__ gcc features unconditional setup of
CROSS_COMPILE leads to failures on execution of "make xxx_defconfig"
with absent cross-compiler, for more info see [1].Set CROSS_COMPILE as well gets in the way if we want only to build
.dtb's (again with absent cross-compiler which is not really needed
for building .dtb's), see [2].Note, we had to change LIBGCC assignment type from ":=" to "="
so that is is resolved on its usage, otherwise if it is resolved
at declaration time with missing CROSS_COMPILE we're getting this
error message from host GCC:| gcc: error: unrecognized command line option -mmedium-calls
| gcc: error: unrecognized command line option -mno-sdata[1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-September/004308.html
[2] http://lists.infradead.org/pipermail/linux-snps-arc/2018-September/004320.htmlSigned-off-by: Alexey Brodkin
Cc: Masahiro Yamada
Cc: Rob Herring
Signed-off-by: Vineet Gupta
14 Sep, 2018
1 commit
-
This check is very naive: we simply test if GCC invoked without
"-mcpu=XXX" has ARC700 define set. In that case we think that GCC
was built with "--with-cpu=arc700" and has libgcc built for ARC700.Otherwise if ARC700 is not defined we think that everythng was built
for ARCv2.But in reality our life is much more interesting.
1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu"
it may generate code for any ARC core).2. libgcc might be built with explicitly specified "--mcpu=YYY"
That's exactly what happens in case of multilibbed toolchains:
- GCC is configured with default settings
- All the libs built for many different CPU flavorsI.e. that check gets in the way of usage of multilibbed
toolchains. And even non-multilibbed toolchains are affected.
OpenEmbedded also builds GCC without "--with-cpu" because
each and every target component later is compiled with explicitly
set "-mcpu=ZZZ".Acked-by: Rob Herring
Signed-off-by: Alexey Brodkin
Signed-off-by: Vineet Gupta
11 Sep, 2018
1 commit
-
helps gcc with better instruction selections such as 64-bit multiply MPYD
before
------
82c34b58 :
82c34b58: ld r2,[0x83068d00]
82c34b60: add_s r2,r2,0x7530
82c34b66: mov_s r0,0x989680
82c34b6c: mpymu r5,r2,r0
82c34b70: mpy r4,r2,r0
82c34b74: mov_s r0,r4
82c34b76: j_s.d [blink]
82c34b78: mov_s r1,r5
82c34b7a: nop_safter
------
82c34b7c :
82c34b7c: ld r0,[0x83064d00]
82c34b84: add_s r0,r0,0x7530
82c34b8a: mpydu r0,r0,0x989680
82c34b92: j_s [blink]Signed-off-by: Vineet Gupta
31 Aug, 2018
1 commit
-
Commit cafa0010cd51 ("Raise the minimum required gcc version to 4.6")
bumped the minimum GCC version to 4.6 for all architectures.With GCC >= 4.6 assumed, 'upto_gcc44' is empty, 'atleast_gcc44' is y.
Signed-off-by: Masahiro Yamada
Signed-off-by: Vineet Gupta
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
14 Jun, 2018
1 commit
-
GCC built for arc*-*-linux has "-mmedium-calls" implicitly enabled by default
thus we don't see any problems during Linux kernel compilation.
----------------------------->8------------------------
arc-linux-gcc -mcpu=arc700 -Q --help=target | grep calls
-mlong-calls [disabled]
-mmedium-calls [enabled]
----------------------------->8------------------------But if we try to use so-called Elf32 toolchain with GCC configured for
arc*-*-elf* then we'd see the following failure:
----------------------------->8------------------------
init/do_mounts.o: In function 'init_rootfs':
do_mounts.c:(.init.text+0x108): relocation truncated to fit: R_ARC_S21W_PCREL
against symbol 'unregister_filesystem' defined in .text section in fs/filesystems.oarc-elf32-ld: final link failed: Symbol needs debug section which does not exist
make: *** [vmlinux] Error 1
----------------------------->8------------------------That happens because neither "-mmedium-calls" nor "-mlong-calls" are enabled in
Elf32 GCC:
----------------------------->8------------------------
arc-elf32-gcc -mcpu=arc700 -Q --help=target | grep calls
-mlong-calls [disabled]
-mmedium-calls [disabled]
----------------------------->8------------------------Now to make it possible to use Elf32 toolchain for building Linux kernel
we're explicitly add "-mmedium-calls" to CFLAGS.And since we add "-mmedium-calls" to the global CFLAGS there's no point in
having per-file copies thus removing them.Signed-off-by: Alexey Brodkin
Signed-off-by: Vineet Gupta
04 Oct, 2017
1 commit
-
The top-level Makefile sets the default of UTS_MACHINE to $(ARCH).
If ARCH and UTS_MACHINE match, arch/$(ARCH)/Makefile need not specify
UTS_MACHINE explicitly.Signed-off-by: Masahiro Yamada
Signed-off-by: Vineet Gupta
02 Sep, 2017
1 commit
-
This initial port adds support of ARC HS Development Kit board with some
basic features such serial port, USB, SD/MMC and Ethernet.Essentially we run Linux kernel on all 4 cores (i.e. utilize SMP) and
heavily use IO Coherency for speeding-up DMA-aware peripherals.Note as opposed to other ARC boards we link Linux kernel to
0x9000_0000 intentionally because cores 1 and 3 configured with DCCM
situated at our more usual link base 0x8000_0000. We still can use
memory region starting at 0x8000_0000 as we reallocate DCCM in our
platform code.Note that PAE remapping for DMA clients does not work due to an RTL bug,
so CREG_PAE register must be programmed to all zeroes, otherwise it will
cause problems with DMA to/from peripherals even if PAE40 is not used.Acked-by: Rob Herring
Signed-off-by: Alexey Brodkin
Signed-off-by: Eugeniy Paltsev
Signed-off-by: Vineet Gupta
04 Aug, 2017
1 commit
-
Essentially remove CONFIG_ARC_PLAT_SIM
There is no need for any platform specific code, just the board DTS
match strings which we can include unconditionallySigned-off-by: Vineet Gupta
20 Mar, 2017
1 commit
-
The KBUILD_IMAGE variable is used by the rpm and deb-pkg targets, which
expect it to point to the image file in the build directory. The
builddeb script has a workaround for architectures which only provide
the basename, but let's provide a clean interface for packaging tools.Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Michal Marek
Signed-off-by: Masahiro Yamada
12 Nov, 2016
2 commits
-
Pull ARC fixes from Vineet Gupta:
- mmap handler for dma ops as generic handler no longer works for us
[Alexey]- Fixes for EZChip platform [Noam]
- Fix RTC clocksource driver build issue
- ARC IRQ handling fixes [Yuriy]
- Revert a recent makefile change which doesn't go well with oldish
tools out in the wild* tag 'arc-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARCv2: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core
ARC: IRQ: Do not use hwirq as virq and vice versa
ARC: [plat-eznps] set default baud for early console
ARC: [plat-eznps] remove IPI clear from SMP operations
Revert "ARC: build: retire old toggles"
ARC: timer: rtc: implement read loop in "C" vs. inline asm
ARC: change return value of userspace cmpxchg assist syscall
arc: Implement arch-specific dma_map_ops.mmap
ARC: [SMP] avoid overriding present cpumask
ARC: Enable PERF_EVENTS in nSIM driven platforms -
Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE. This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that I had
not addressed until then. This caused a lot of actual bugs to get
merged into mainline, and I sent several dozen patches for these during
the v4.9 development cycle. Most of these are actual bugs, some are for
correct code that is safe because it is only called under external
constraints that make it impossible to run into the case that gcc sees,
and in a few cases gcc is just stupid and finds something that can
obviously never happen.I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got (I can
provide the combined patch for the other warnings if anyone is
interested), so I hope we can get the warning back and let people catch
the actual bugs earlier.This reverts the change to disable the warning completely and for now
brings it back at the "make W=1" level, so we can get it merged into
mainline without introducing false positives. A follow-up patch enables
it on all levels unless some configuration option turns it off because
of false-positives.Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann
Signed-off-by: Linus Torvalds
09 Nov, 2016
1 commit
-
This has caused a bunch of build failures at a few sites, with GNU
2015.12 and older as the assembler seems to need -mlock to be able to
grok llock/scond instructions for ARC700 builds.
different places since the
older tools still seem to release
of tools which most people are using seem to trip with the -mlock flag
not being passed.This reverts commit c3005475889c7c730638f95d13be3360f0b33e98.
29 Oct, 2016
1 commit
-
These are really ancient toggles and tools no longer require them to be
passed. This paves way for deprecating them in long run.Signed-off-by: Vineet Gupta
01 Oct, 2016
3 commits
-
1. detect whether binutils supports the cfi pseudo ops
2. define conditional macros to generate the ops
3. define new ENTRY_CFI/END_CFI to annotate hand asm code.
- Needed because we don't want to emit dwarf info in general ENTRY/END
used by lowest level trap/exception/interrutp handlers as unwinder
gets confused trying to unwind out of them. We want unwinder to
instead stop when it hits onfo those routines
- These provide minimal start/end cfi ops assuming routine doesn't
touch stack memory/regsSigned-off-by: Vineet Gupta
-
In .debug_frame based unwinding regime, we used to force -gdwarf-2 since
kernel unwinder only claimed to handle dwarf 2. This changed since commit
6d0d506012c93d ("ARC: dw2 unwind: Don't bail for CIE.version != 1")
which added some support beyond dwarf 2, atleast to handle CIE != 1The ill-effect of -gdwarf-2 is that it forces generation of .debug_*
sections, which bloats loadable modules .ko files. For the curious, this
doesn't affect vmlinx binary since linker script discards .debug_* but
same discard is not yet implemented for modules.So it seems we can drop the -gdwarf-2 toggle, which should not be needed
anyways given that we now use .eh_frame based unwinding.I've verified using GNU 2016.09-engo10 that the actual unwind info is
not different with or w/o this toggle - but the debug_* sections are
gone for good.before
-----
arc-linux-readelf -S q_proc.ko-unwinding-1-eh_frame-switch | grep debug
[15] .debug_info PROGBITS 00000000 000300 00d08d 00 0 0 1
[16] .rela.debug_info RELA 00000000 0162a0 008844 0c I 29 15 4
[17] .debug_abbrev PROGBITS 00000000 00d38d 0005f8 00 0 0 1
[18] .debug_loc PROGBITS 00000000 00d985 000070 00 0 0 1
[19] .rela.debug_loc RELA 00000000 01eae4 0000c0 0c I 29 18 4
[20] .debug_aranges PROGBITS 00000000 00d9f5 000040 00 0 0 1
[21] .rela.debug_arang RELA 00000000 01eba4 000030 0c I 29 20 4
[22] .debug_ranges PROGBITS 00000000 00da35 000018 00 0 0 1
[23] .rela.debug_range RELA 00000000 01ebd4 000030 0c I 29 22 4
[24] .debug_line PROGBITS 00000000 00da4d 000b5b 00 0 0 1
[25] .rela.debug_line RELA 00000000 01ec04 0000cc 0c I 29 24 4
[26] .debug_str PROGBITS 00000000 00e5a8 007831 01 MS 0 0 1after
----Signed-off-by: Vineet Gupta
-
So finally after almost 8 years of dealing with .debug_frame, we are
finally switching to .eh_frame. The reason being stripped kernel
binaries had non-functional unwinder as .debug_frame was gone.
Also, in general .eh_frame seems more common way of doing unwinding.This also folds a revert of f52e126cc747 ("ARC: unwind: ensure that
.debug_frame is generated (vs. .eh_frame)") to ensure that we start
getting .eh_frameReported-by: Daniel Mentz
Signed-off-by: Vineet Gupta
28 Jul, 2016
1 commit
-
Several build configurations had already disabled this warning because
it generates a lot of false positives. But some had not, and it was
still enabled for "allmodconfig" builds, for example.Looking at the warnings produced, every single one I looked at was a
false positive, and the warnings are frequent enough (and big enough)
that they can easily hide real problems that you don't notice in the
noise generated by -Wmaybe-uninitialized.The warning is good in theory, but this is a classic case of a warning
that causes more problems than the warning can solve.If gcc gets better at avoiding false positives, we may be able to
re-enable this warning. But as is, we're better off without it, and I
want to be able to see the *real* warnings.Signed-off-by: Linus Torvalds
28 Jun, 2016
1 commit
-
With recent binutils update to support dwarf CFI pseudo-ops in gas, we
now get .eh_frame vs. .debug_frame. Although the call frame info is
exactly the same in both, the CIE differs, which the current kernel
unwinder can't cope with.This broke both the kernel unwinder as well as loadable modules (latter
because of a new unhandled relo R_ARC_32_PCREL from .rela.eh_frame in
the module loader)The ideal solution would be to switch unwinder to .eh_frame.
For now however we can make do by just ensureing .debug_frame is
generated by removing -fasynchronous-unwind-tables.eh_frame generated with -gdwarf-2 -fasynchronous-unwind-tables
.debug_frame generated with -gdwarf-2Fixes STAR 9001058196
Cc: stable@vger.kernel.org
Signed-off-by: Vineet Gupta
30 May, 2016
1 commit
-
Signed-off-by: Andrea Gelmini
Signed-off-by: Vineet Gupta
09 May, 2016
1 commit
-
This commit should be left last since only now eznps platform
is in state which one can actually use.
Signed-off-by: Noam Camus
18 Mar, 2016
1 commit
-
linux-next has been reporting gazillion warnings for ARC build and
I finally decided to take a bite:http://kisskb.ellerman.id.au/kisskb/buildresult/12638735/
Most of the them are due to -Wmaybe-uninitialized
| ../kernel/sysctl.c: In function '__do_proc_doulongvec_minmax':
| ../kernel/sysctl.c:1928:12: warning: 'p' may be used uninitialized in this function [-Wmaybe-uninitialized]
| ret = tmp - *buf;
| ^
| ../kernel/sysctl.c:2342:29: note: 'p' was declared here
| char *kbuf = NULL, *p;
| ^
| ...
| ...Cursory look at code seemed fine and a definite gcc false positive in say
kernel/sysctl.cMystery was why only for ARC (and not with ARM linaro toolchain based
off same gcc 4.8). Turns out that -O3 (default for ARC) triggers these
and if I enable -O3 for ARM kernel build, I see the same splat.I initially wanted to disable this only for gcc 4.8, but Arnd reported
it is seen even on gcc 6.0 for ARM with -O3. Thus better to disable
this independent of gcc version.Cc: Claudiu Zissulescu
Cc: Arnd Bergmann
Cc: Michal Marek
Cc: Geert Uytterhoeven
Cc: linux-kbuild@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Vineet Gupta