This commit adds support of USB 1.1 storage media on AXS103 board.
For some yet unknown reason USB 2.0 doesn't work on AXS103 board issuing
messages like this:
------------------------>8-------------------
AXS# usb start
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
unable to get device descriptor (error=-1)
1 USB Device(s) found
------------------------>8-------------------
As a work-around we're falling back to USB 1.1.
Indeed it is much slower but at least USB storage devices are usable on
AXS103.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
This commit adds support of USB 2.0 storage media on AXS10x boards.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
With this change Synopsys DesignWare SDP board is switched to driver
model for both serial port (serial_dw) and Ethernet (Designware GMAC).
This simplifies include/configs/axs101.h and allows for reuse of Linux's
Device Tree description.
For simplicity Linux's .dts files are not blindly copied but only very
few extracts of them are really used (those that are supported in U-Boot
at the moment).
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
common/usb.c unconditionally includes <asm/processor.h>
And now to allow USB support on ARC boards we have to have that header.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Up until now there was no need in those stubs.
But since following commit compilation of U-Boot on ARC is broken:
------------------------>8----------------------
commit 7861204c9a
Author: Stephen Warren <swarren@wwwdotorg.org>
Date: Sat Oct 3 13:56:46 2015 -0600
itest: make memory access work under sandbox
itest accesses memory, and hence must map/unmap it. Without doing so, it
accesses invalid addresses and crashes.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
------------------------>8----------------------
That's because CMD_ITEST is enabled by default in common/Kconfig and now
map_physmem()/unmap_physmem() is used there.
So this patch adds missing stubs for ARC.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Stephen Warren <swarren@wwwdotorg.org>
After consulting with some of the SPDX team, the conclusion is that
Makefiles are worth adding SPDX-License-Identifier tags too, and most of
ours have one. This adds tags to ones that lack them and converts a few
that had full (or in one case, very partial) license blobs into the
equivalent tag.
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
The generic bitops headers are required when calling logarithmic
functions, such as ilog2().
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
[1] Align cache management functions to those in Linux kernel. I.e.:
a) Use the same functions for all cache ops (D$ Inv/Flush)
b) Split cache ops in 3 sub-functions: "before", "lineloop" and
"after". That way we may re-use "before" and "after" functions for
region and full cache ops.
[2] Implement full-functional L2 (SLC) management. Before SLC was
simply disabled early on boot. It's also possible to enable or disable
L2 cache from config utility.
[3] Disable/enable corresponding caches early on boot. So if U-Boot is
configured to use caches they will be used at all times (this is useful
in partucular for speed-up of relocation).
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
With new SMP-enabled CPUs with ARC HS38 cores and corresponding support
in Linux kernel it's required to add basic SMP support in U-Boot.
Currently we assume the one and only core starts execution after
power-on. So most of things in U-Boot is handled in UP mode.
But when U-Boot is used for loading and starting Linux kernel right
before jumping to kernel's entry point U-Boot:
[1] Sets all slave cores to jump to the same address [kernel's entry
point]
[2] Really starts all slav cores
In ARC's implemetation of SMP in Linux kernel all cores are supposed to
run the same start-up code. But only core with ID 0 (master core)
processes further while others are looping waiting for master core to
complete some initialization.
That means it's safe to un-pause slave cores and let them execute kernel
- they will wait for master anyway.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Vineet Gupta <vgupta@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>
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>
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>
While testing "arc: make sure _start is in the beginning of .text
section" I haven't done proper clean-up of built binaries and so missed
another tiny bit that lead to the following error:
--->8---
LD u-boot
arc-linux-ld.bfd: cannot find arch/arc/lib/start.o
Makefile:1107: recipe for target 'u-boot' failed
make: *** [u-boot] Error 1
--->8---
Fix is trivial: put "start.o" in "extra-y".
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This is important to have entry point in the beginning of .text section
because it allows simple loading and execution of U-Boot.
For example pre-bootloader loads U-Boot in memory starting from offset
0x81000000 and then just jumps to the same address.
Otherwise pre-bootloader would need to find-out where entry-point is. In
its turn if it deals with binary image of U-Boot there's no way for
pre-bootloader to get required value.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
ARCv2 cores may have built-in SLC (System Level Cache, AKA L2-cache).
This change adds functions required for controlling SLC:
* slc_enable/disable
* slc_flush/invalidate
For now we just disable SLC to escape DMA coherency issues until either:
* SLC flush/invalidate is supported in DMA APIin U-Boot
* hardware DMA coherency is implemented (that might be board specific
so probably we'll need to have a separate Kconfig option for
controlling SLC explicitly)
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Now when all infrastructure in ARC is ready for it let's switch ARC UART
to driver model.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Simon Glass <sjg@chromium.org>
[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>
As discussed on mailing list we're drifting away from
CONFIG_SYS_GENERIC_GLOBAL_DATA in favour to use of board_init_f_mem()
for global data.
So do this for ARC architecture.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Intention behind this work was elimination of as much assembly-written
code as it is possible.
In case of ARC we already have relocation fix-up implemented in C so why
don't we use C for U-Boot copying, .bss zeroing etc.
It turned out x86 uses pretty similar approach so we re-used parts of
code in "board_f.c" initially implemented for x86.
Now assembly usage during init is limited to stack- and frame-pointer
setup before and after relocation.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
This separation makes maintenance of code easier because those low-level
interrupt- or exception handling routines are pretty static and usually
require not much care while start-up code is a subject of modifications
and enhancements.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Even though ARCompact and ARCv2 are not binary compatible most of
assembly instructions are used in both. With this change we'll get rid
of duplicate code.
Still IVTs are implemented differently so we're keeping them in separate
files.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
always
Make both invalidate_icache_all() and invalidate_dcache_all() available
even if U-Boot is configured with CONFIG_SYS_DCACHE_OFF and/or
CONFIG_SYS_ICACHE_OFF.
This is useful because configuration of U-Boot may not match actual
hardware features. Real board may have cache(s) but for some reason we
may want to run U-Boot with cache(s) disabled (for example if some
peripherals work improperly with existing drivers if data cache is
enabled). So board may start with cache(s) enabled (that's the case for
ARC cores with built-in caches) but early in U-Boot we disable cache(s)
and make sure all contents of data cache gets flushed in RAM.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
We have done with the generic board conversion for all the boards
of ARC, Blackfin, M68000, MicroBlaze, MIPS, NIOS2, Sandbox, X86.
Let's select SYS_GENERIC_BOARD for those architectures, so we can
tell which architecture has finished the conversion at a glance.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexey Brodkin <abrodkin@synopsys.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>
For some assemblers, they use another character as newline in a macro
(e.g. arc uses '`'), so for generic assembly code, need use ASM_NL (a
macro) instead of ';' for it.
Basically this is the same patch as applied to Linux kernel -
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/include/linux/linkage.h?id=9df62f054406992ce41ec4558fca6a0fa56fffeb
but modified a bit to fit in U-Boot.
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@ti.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>
Common arch_early_init_r() is used in "arc/lib/cpu.c" for all ARC boards
so there's no sense in separate per-board definitions.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
There're no other options for ARC except "generic board" so ther's no
point to define CONFIG_SYS_GENERIC_BOARD per board.
We now have it set fo all ARC 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>
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>
It's prohibited to put branch instruction in the very end of zero-delay
loop. On execution this causes "Illegal instruction" exception.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Igor Guryanov <guryanov@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>
"reset.c" and "cpu.c" have no architecture-specific code at all.
Others are applicable to either ARC CPU.
This change is a preparation to submission of ARCv2 architecture port.
Even though ARCv1 and ARCv2 ISAs are not binary compatible most of
built-in modules still have the same programming model - AUX registers
are mapped in the same addresses and hold the same data (new featues
extend existing ones).
So only low-level assembly code (start-up, interrupt handlers) is left
as CPU(actually ISA)-specific. This significantyl simplifies maintenance
of multiple CPUs/ISAs.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Igor Guryanov <guryanov@synopsys.com>
* use better symbols for relocatable region boundaries
("__image_copy_start" instead of "CONFIG_SYS_TEXT_BASE")
* remove useless debug messages because they will only show up in case
of both problem (when normal "if" branch won't be taken) and DEBUG take
place which is pretty rare situation.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Even though existing implementation works fine in preparation to
submission of ARCv2 architecture we need this change.
In case of ARCv2 interrupt vector table consists of just addresses
of corresponding handlers. And if those addresses will be in .text
section then assembler will encode them as everything in .text section
as middle-endian and then on real execution CPU will read swapped
addresses and will jump into the wild.
Once introduced new section is situated so .text section remains the
first which allows us to use common linker option for linking everything
to a specified CONFIG_SYS_TEXT_BASE.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Igor Guryanov <guryanov@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>
To disable interrupts we need to reset corresponding flags in STATUS32
register. For this we need to OR flags for interrupts level1 and level2
and then AND with current value in STATUS32.
Before that implementation was incorrect.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Igor Guryanov <guryanov@synopsys.com>
Exception cause register (ECR) contains value that describes a reason
for exception that has happened. This helps a lot to figure-out what
went wrong.
Now we print this register contents when dumping registers.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Igor Guryanov <guryanov@synopsys.com>
Some cache operations ({i|d}cache_{enable|disable|status} or
flush_dcache_all) are built and used even if CONFIG_SYS_{I|D}CACHE_OFF
is set.
This is required for force disable of caches on early boot.
What if something was executed before U-boot and enabled caches
(low-level bootloaders, previously run kernel etc.)?
But if CPU doesn't really have caches any attempt to access
cache-related AUX registers triggers instruction error exception.
So for convenience we'll try to avoid exceptions by checking if CPU
actually has caches (we check separately data and instruction cache
existence) at all.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Igor Guryanov <guryanov@synopsys.com>
MetaWare debugger (MDB) is still used as a primary tool for interaction
with target via JTAG. Moreover some very advanced features are not yet
implemented in GDB for ARC (and not sure if they will be implemnted
sometime soon given complexity and rare need for those features for
common user).
So if we're talking about development process when U-Boot is loaded in
target memory not by low-level boot-loader but manually through JTAG
chances are high developer uses MDB for it.
But MDB doesn't support PIE (position-independent executable) - it will
refuse to even start - that means no chance to load elf contents on
target.
Then the only way to load U-Boot in MDB is to fake it by:
1. Reset PIE flag in ELF header
This is simpe - on attempt to open elf MDB checks header and if it
doesn't match its expectation refuces to use provided elf.
2. Strip all debug information from elf
If (1) is done then MDB will open elf but on parsing of elf's debug
info it will refuse to process due to debug info it cannot understand
(symbols with PIE relocation).
Even though it could be done manually (I got it documented quite a while
ago here http://www.denx.de/wiki/U-Boot/ARCNotes) having this automated
way is very convenient. User may build U-Boot that will be loaded on
target via MDB saying "make mdbtrick".
Then if we now apply the manipulation MDB will happily start and will
load all required sections into the target.
Indeed there will be no source-level debug info available. But still MDB
will do its work on showing disassembly, global symbols, registers,
accessing low-level debug facilities etc.
As a summary - this is a pretty dirty hack but it simplifies life a lot
for us ARc developers.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Tom Rini <trini@ti.com>
Cc: Wolfgang Denk <wd@denx.de>
