Newer ARC toolchains don't support "-marchs" option any longer.
Instead "-mcpu=archs" should be used. What's also important older
toiolchains that support ARC HS cores will also happily accept
"-mcpu=archs" so that's a very safe move.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
As doc/README.ARC says, pre-build ARC toolchains are available at
the Synopsys GitHub page.
The bin files are prefixed with arc(eb)-buildroot-linux- for earlier
releases, but with arc(eb)-snps-linux- for the latest releases.
The symbolic links prefixed with arc(eb)-linux- are also available
for all the release, so those prefixes can be used as the default
CROSS_COMPILE regardless of the toolchains version/variants.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Move the option to Kconfig renaming it to CONFIG_HAVE_GENERIC_BOARD.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexey Brodkin <abrodkin@synopsys.com>
ARC HS and ARC EM are new cores based on ARCv2 ISA which is binary
incompatible with ISAv1 (AKA ARCompact).
Significant difference between ISAv2 and v1 is implementation of
interrupt vector table.
In v1 it is implemented in the same way as on many other architectures -
as a special location where user may put whether code executed in place
(if machine word of space is enough) or jump to a full-scale interrupt
handler.
In v2 interrupt table is just an array of adresses of real interrupt
handlers. That requires a separate section for IVT that is not encoded
as code by assembler.
This change adds support for following cores:
* ARC EM6 (simple 32-bit microcontroller without MMU)
* ARC HS36 (advanced 32-bit microcontroller without MMU)
* ARC HS38 (advanced 32-bit microcontroller with MMU)
As a part of ARC HS38 new version of MMU (v4) was introduced.
Also this change adds AXS131 board which is the same DW ARC SDP base board but
with ARC HS38 CPU tile.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This way we may have very limited set of functions implemented so we
save some space.
Also it allows us to build U-Boot for any ARC core with the same one
toolchain because we don't rely on pre-built libgcc.
For example:
* we may use little-endian toolchain but build U-Boot for ether
endianess
* we may use non-multilibbed uClibc toolchain but build U-Boot for
whatever ARC CPU flavour that current GCC supports
Private libgcc built from generic C implementation contributes only 144
bytes to .text section so we don't see significant degradation of size:
--->8---
$ arc-linux-size u-boot.libgcc-prebuilt
text data bss dec hex filename
222217 24912 214820 461949 70c7d u-boot.libgcc-prebuilt
$ arc-linux-size u-boot.libgcc-private
text data bss dec hex filename
222361 24912 214820 462093 70d0d u-boot.libgcc-private
--->8---
Also I don't notice visible performance degradation compared to
pre-built libgcc (where at least "*div*" functions are had-written in
assembly) on typical operations of downloading 10Mb uImage over TFTP and
bootm.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
As a preparation to ARCv2 port submission we're moving CPU slection
flags to a common location.
Also it will allow us to have more flexible CPU specification, not only
ISA version but CPU family as well checking CONFIG_ARC_CPU_xxx.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This change allows to keep board description clean and minimalistic.
This is especially helpful if one board may house different CPUs with
different features.
It is applicable to both FPGA-based boards or those that have CPUs
mounted on interchnagable daughter-boards.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Now we may select a particular version of ARC700:
* ARC750D or
* ARC770D
It allows more flexible (or more fine tuned) configuration of U-Boot.
Before that change we relied on minimal configuration but now we may
use specific features of each CPU.
Moreover allows us to escape manual selection of options that
exist in both CPUs but may have say different version like MMUv2 in
ARC750D vs MMUv3 in ARC770D.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Depending on MMU presence in CPU there're differences in HW behavior.
For example address of instruction that caused exception is put in
ECR register if MMU exists and in ERET register otherwise.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Igor Guryanov <guryanov@synopsys.com>
The syntax
CROSS_COMIPLE ?= <cross_compiler_prefix>
does not work because config.mk is parsed after
exporting CROSS_COMPILE.
Like Linux Kernel's arch/$(ARCH)/Makefile,
we must write as follows:
ifeq ($(CROSS_COMPILE),)
CROSS_COMPILE := <cross_compiler_prefix>
endif
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
