| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
<common.h> pulls in a lot of bloat. <common.h> is unneeded in most of
places.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
A large number of boards call preloader_console_init unconditionally.
Currently, they fail to build with CONFIG_SPL_SERIAL=n, because the
function is undefined in that case. To fix the build, always define
preloader_console_init, but make it no-op when CONFIG_SPL_SERIAL=n.
For the few boards that did check for CONFIG_SPL_SERIAL before calling
preloader_console_init, remove the checks, since the function can now
be called unconditionally.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
At present panic() is in the vsprintf.h header file. That does not seem
like an obvious choice for hang(), even though it relates to panic(). So
let's put hang() in its own header.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Migrate a few more files]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This SoC is too old. It is difficult to maintain any longer.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
It has been a while since ARM Trusted Firmware supported UniPhier SoC
family. U-Boot SPL was intended as a temporary loader that runs in
secure world. It is a maintenance headache to support two different
boot mechanisms. Secure firmware is realm of ARM Trusted Firmware
and now U-Boot only serves as a non-secure boot loader for UniPhier
ARMv8 SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Commit a8e6300d483d ("ARM: uniphier: refactor spl_init_board()")
accidentally dropped dcache_disable() call. Since then, the SPL of
LD11 and LD20 failed to load U-Boot proper.
Fixes: a8e6300d483d ("ARM: uniphier: refactor spl_init_board()")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
There are similar functions that look up SoC data by the SoC ID.
The new macro UNIPHIER_DEFINE_SOCDATA_FUNC will be helpful to
avoid the code duplication.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Currently, uniphier_get_soc_type() converts the SoC ID (this is
read from the revision register) to an enum symbol to use it for SoC
identification. Come to think of it, there is no need for the
conversion in the first place. Using the SoC ID from the register
as-is a straightforward way.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Initialize SBC and Support Card in U-Boot proper instead of SPL.
We may run different firmware (ex. ARM Trusted Firmware) before
U-Boot, and basic SoC initialization may be done there. In that
case, SPL may not be used.
The motivation for preparing SBC and Support Card in SPL was to use
LED for early debugging, but this is not mandatory to boot SoCs.
With this commit, LED will be unavailable in SPL, but we can use a
debug serial instead. So, this change will not be a big deal.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Merge init-*.c into a single file using a table of callbacks because
the initialization flow is almost common among SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
