| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As of now we have 2 flavors of ARC SDP boards:
1) AXS101 - with ARC770 in ASIC
2) AXS103 - with ARC HS38 in FPGA
Both options share exactly the same base-board and only differ with
CPU-tiles in use. That means all peripherals are the same (they are
implemented in FPGA on the base-board) and so generic board could be
used for both.
While at it:
* Recreated defconfigs with savedefconfig
* In include/configs/axs10x.h numerical sizes replaced with
defines from linux/sizes.h for better readability.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARCangel was one of the main development boards back in the day but
now it's gone and replaced by other boards like ARC SDP.
But we also used to have simulation platform very similar to ARCangel4
in terms of CPU settings as well as basic IO like UART. Even though
ARCangel4 is long gone now we have a replacement for simulation which is
a plain or stand-alone nSIM and Free nSIM.
Note Free nSIM is available for download here:
https://www.synopsys.com/cgi-bin/dwarcnsim/req1.cgi
And while at it:
* Finally switch hex numerical values in nsim.h to defines from
include/linux/sizes.h
* Add defconfigs with ARC HS38 cores
* Recreated all defconfigs with savedefconfig
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARC core could be configured with different L1 and L2 (AKA SLC) cache
line lengths. At least these values are possible and were really used:
32, 64 or 128 bytes.
Current implementation requires cache line to be selected upon U-Boot
configuration and then it will only work on matching hardware. Indeed
this is quite efficient because cache line length gets hardcoded during
code compilation. But OTOH it makes binary less portable.
With this commit we allow U-Boot to determine real L1 cache line length
early in runtime and use this value later on. This extends portability
of U-Boot binary a lot.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes building in automated flow that doesn't use defconfigs.
See discussion on that topic here:
http://patchwork.ozlabs.org/patch/502558/
See similar patches for other architectures/platforms here:
[1] http://git.denx.de/?p=u-boot.git;a=commit;h=ff560a13056a565a4e9ce1761bd04276a3cace88
[2] http://git.denx.de/?p=u-boot.git;a=commit;h=589907e2c187ec69b351c38ccda36730d25ab5d6
And while at it add missing shell prompt to axs103.
Cc: Tom Rini <trini@konsulko.com>
Cc: Joe Hershberger <joe.hershberger@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some archs/boards specify their own default by pre-defining the config
which causes the Kconfig system to mix up the order of the configs in
the defconfigs... This will cause merge pain if allowed to proliferate.
Remove the configs that behave this way from the archs.
A few configs still remain, but that is because they only exist as
defaults and do not have a proper Kconfig entry. Those appear to be:
SPIFLASH
DISPLAY_BOARDINFO
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
[trini: rastaban, am43xx_evm_usbhost_boot, am43xx_evm_ethboot updates,
drop DM_USB from MSI_Primo81 as USB_MUSB_SUNXI isn't converted yet to DM]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
TARGET_DUMMY was introduced to resolve the same problem as commit
"arch: Make board selection choices optional"
http://git.denx.de/?p=u-boot.git;a=commit;h=a26cd04920dc069fd6e91abb785426cf6c29f45f
Latter implementation is much cleaner and appropriate.
And anyways TARGET_DUMMY is no longer required.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
By making the board selections optional, every defconfig will include
the board selection when running savedefconfig so if a new board is
added to the top of the list of choices the former top's defconfig will
still be correct.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: Tom Rini <trini@konsulko.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[1] Fix misspeling in ARC_CACHE_LINE_SHIFT dependency, now cache-line
lenth selection is correctly enabled if either I$ or D$ are enabled.
[2] Add dummy entry to target list to make sure target type is always
mentioned in defconfig. Otherwise defconfig for the first target in the
list will not have target name and later on with addition of the new
target on top of the list in Kconfig will lead to corrupted
configuration expanded from defconfig.
Signed-off-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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a preparation to ARCv2 port submission we rename "arc700" folder to
"arcv1" which stands for ARCv1 ISA also known as ARCompact.
This will allow us to add more flavours of binary-compatible ARCv1 CPUs
like ARC600 if needed later on and all required ARCv2 CPUs (which are
binary incompatible with ARCv1) in "arcv2" folder in subsequent commits.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Igor Guryanov <guryanov@synopsys.com>
|
|
|
|
|
|
|
|
| |
Both ARCangel4 and AXS10x are FPGA-based boards so they may have
different CPUs. For now we have only 1 option (ARC700) and we define
this as default in arch Kconfig.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now the types of CONFIG_SYS_{ARCH, CPU, SOC, VENDOR, BOARD, CONFIG_NAME}
are specified in arch/Kconfig.
We can delete the ones in arch and board Kconfig files.
This commit can be easily reproduced by the following command:
find . -name Kconfig -a ! -path ./arch/Kconfig | xargs sed -i -e '
/config[[:space:]]SYS_\(ARCH\|CPU\|SOC\|\VENDOR\|BOARD\|CONFIG_NAME\)/ {
N
s/\n[[:space:]]*string//
}
'
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
|
|
This commit adds:
- arch/${ARCH}/Kconfig
provide a menu to select target boards
- board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig
set CONFIG macros to the appropriate values for each board
- configs/${TARGET_BOARD}_defconfig
default setting of each board
(This commit was automatically generated by a conversion script
based on boards.cfg)
In Linux Kernel, defconfig files are located under
arch/${ARCH}/configs/ directory.
It works in Linux Kernel since ARCH is always given from the
command line for cross compile.
But in U-Boot, ARCH is not given from the command line.
Which means we cannot know ARCH until the board configuration is done.
That is why all the "*_defconfig" files should be gathered into a
single directory ./configs/.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
|