| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically, the reset_cpu() function had an `addr` parameter which was
meant to pass in an address of the reset vector location, where the CPU
should reset to. This feature is no longer used anywhere in U-Boot as
all reset_cpu() implementations now ignore the passed value. Generic
code has been added which always calls reset_cpu() with `0` which means
this feature can no longer be used easily anyway.
Over time, many implementations seem to have "misunderstood" the
existence of this parameter as a way to customize/parameterize the reset
(e.g. COLD vs WARM resets). As this is not properly supported, the
code will almost always not do what it is intended to (because all
call-sites just call reset_cpu() with 0).
To avoid confusion and to clean up the codebase from unused left-overs
of the past, remove the `addr` parameter entirely. Code which intends
to support different kinds of resets should be rewritten as a sysreset
driver instead.
This transformation was done with the following coccinelle patch:
@@
expression argvalue;
@@
- reset_cpu(argvalue)
+ reset_cpu()
@@
identifier argname;
type argtype;
@@
- reset_cpu(argtype argname)
+ reset_cpu(void)
{ ... }
Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
| |
|
|
|
|
| |
Move this uncommon header out of the common header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
| |
Move this uncommon header out of the common header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It's a very rare if at all existing occasion when ARC CPU template
is used as is w/o any changes - in the end it's a beauty and competitive
advantage of ARC cores to be tailored for a particular use-case - and
so it doesn't make a lot of sense to offer template-based "-mcpu" selection.
Given for each and every platform we end-up adding quite a few more flags
it's logical to move "-mcpu" selection to platform's definition as well
which we exactly do here.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
| |
|
|
|
|
| |
Move this function out of common.h and into a relevant header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
|
| |
Somehow EMSDP & IoT DK boards were skipped on ARC boads conversion
to DM MMC. So doing it now.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
| |
|
|
|
|
|
|
| |
Since we now do advanced CPU identification in
generic ARC code there's no need to have per-board
hardcoded data.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
| |
|
|
| |
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So now we may detect MMC/SD-card existence and
instead of completely misleading message on missing card:
------------------------>8-----------------------
Loading Environment from FAT... Card did not respond to voltage select!
------------------------>8-----------------------
we now get very clear one:
------------------------>8-----------------------
Loading Environment from FAT... MMC: no card present
------------------------>8-----------------------
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
| |
|
|
|
|
|
| |
Since gd->cpu_clk is a global item we may once populate it from .dtb
ans use it then in other places like for printing CPU info etc.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
| |
|
|
| |
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
| |
|
|
|
|
| |
It is done by writing some magic sequence in a special register.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
| |
|
|
|
|
|
|
|
| |
ARC IDENTITY register only encodes major architecture
type and version while for a particular board/silicon we
may know better which template was used and so we may identify
CPU more precise, which exactly we do here.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
|
|
The DesignWare ARC IoT Development Kit is a versatile platform
that includes the necessary hardware and software to accelerate
software development and debugging of sensor fusion,
voice recognition and face detection designs.
More information is avaialble here [1] and here [2].
The board is based on real silicon with
ARC EM9D-based Data Fusion IP Subsystem.
It sports a rich set of I/O including
* DW USB OTG
* DW MobileStorage (used for micro SD-card)
* GPIO
* multiple serial interface including DW APB UART
* ADC, PWM and eFlash, SRAM and SPI Flash memory
* Real-Time Clock (RTC)
* Bluetooth module with worldwide regulatory compliance
(FCC, IC, CE, ETSI, TELEC)
* On-board 9-axis sensor (gyro, accelerometer and compass)
Extensible with Arduino, Pmod, mikroBUS connectors and a 2x18
extension header.
One of the most interesting features for developers is built-in
Digilent USB JTAG probe so only micro-USB cable is needed!
[1] https://www.synopsys.com/dw/ipdir.php?ds=arc_iot_development_kit
[2] https://www.synopsys.com/dw/doc.php/ds/cc/iot_dev_kit.pdf
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
