Commit graph

12 commits

Author SHA1 Message Date
Bin Meng
a0018fc820 riscv: Make SiFive HiFive Unleashed board boot again
Commit 40686c394e ("riscv: Clean up IPI initialization code")
caused U-Boot failed to boot on SiFive HiFive Unleashed board.

The codes inside arch_cpu_init_dm() may call U-Boot timer APIs
before the call to riscv_init_ipi(). At that time the timer register
base (e.g.: the SiFive CLINT device in this case) is unknown yet.

It might be the name riscv_init_ipi() that misleads people to only
consider it is related to IPI, but in fact the timer capability is
provided by the same SiFive CLINT device that provides the IPI.
Timer capability is needed for both UP and SMP.

Considering that the original refactor does have benefits, that it
makes the IPI code more similar to U-Boot initialization idioms.
It also removes some quite ugly macros. Let's do the minimal revert
instead of a complete revert, plus a fixes to arch_cpu_init_dm() to
consider the SPL case.

Fixes: 40686c394e ("riscv: Clean up IPI initialization code")
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Tested-by: Leo Liang <ycliang@andestech.com>
2020-07-24 14:55:04 +08:00
Tom Rini
6e7d7aa2e2 Merge branch 'next'
Merge all outstanding changes from the current next branch in now that
we have released.
2020-07-06 15:46:38 -04:00
Sean Anderson
7984922fb2 riscv: sbi: Add newline to error message
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Bin Meng <bin.meng@windriver.com>
2020-07-02 10:02:57 +08:00
Sean Anderson
40686c394e riscv: Clean up IPI initialization code
The previous IPI code initialized the device whenever the first call was
made to a riscv_*_ipi function. This made it difficult to determine when
the IPI device was initialized. This patch introduces a new function
riscv_init_ipi. It is called once during arch_cpu_init_dm. In SPL, it is
called in spl_invoke_opensbi. Before this point, no riscv_*_ipi functions
should be called.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Rick Chen <rick@andestech.com>
2020-07-01 15:01:22 +08:00
Simon Glass
4d72caa5b9 common: Drop image.h from common header
Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 17:33:33 -04:00
Bin Meng
191636e448 riscv: Introduce SPL_SMP Kconfig option for U-Boot SPL
With SBI v0.2 HSM extension, only a single hart need to boot and
enter operating system. The booting hart can bring up secondary
harts one by one afterwards.

For U-Boot running in SPL, SMP can be turned on, while in U-Boot
proper, SMP can be optionally turned off if using SBI v0.2 HSM.

Introduce a new SPL_SMP Kconfig option to support this.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
2020-04-23 10:14:06 +08:00
Simon Glass
db41d65a97 common: Move hang() to the same header as panic()
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>
2020-01-17 17:53:40 -05:00
Lukas Auer
0e1233ce90 spl: opensbi: wait for ack from secondary harts before entering OpenSBI
At the start, OpenSBI relocates itself to its link address. If the link
address ranges of U-Boot SPL and OpenSBI overlap, the relocation can
lead to code corruption if a hart is still running U-Boot SPL during
relocation. To avoid this problem, the main hart is specified as the
preferred boot hart to perform the relocation. This fixes the code
corruption problems based on the assumption that since the main hart
schedules the secondary harts to enter OpenSBI, it will be the last to
enter OpenSBI. However it was reported that this assumption is not
always correct.

To make sure the assumption always holds true, wait for all secondary
harts to acknowledge the call-function request before entering OpenSBI
on the main hart.

Reported-by: Rick Chen <rick@andestech.com>
Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Rick Chen <rick@andestech.com>
Tested-by: Rick Chen <rick@andestech.com>
Reviewed-by: Anup Patel <anup.patel@wdc.com>
2019-12-10 08:23:10 +08:00
Lukas Auer
90ae281437 riscv: add option to wait for ack from secondary harts in smp functions
Add a wait option to smp_call_function() to wait for the secondary harts
to acknowledge the call-function request. The request is considered to
be acknowledged once each secondary hart has cleared the corresponding
IPI.

As part of the call-function request, the secondary harts invalidate the
instruction cache after clearing the IPI. This adds a delay between
acknowledgment (clear IPI) and fulfillment (call function) of the
request. We want to use the acknowledgment to be able to judge when the
request has been completed. Remove the delay by clearing the IPI after
cache invalidation and just before calling the function from the
request.

Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Rick Chen <rick@andestech.com>
Tested-by: Rick Chen <rick@andestech.com>
Reviewed-by: Anup Patel <anup.patel@wdc.com>
2019-12-10 08:23:10 +08:00
Lukas Auer
b86f6d1e64 spl: opensbi: specify main hart as preferred boot hart
OpenSBI uses a relocation lottery to determine the hart to relocate
OpenSBI to its link address. In the U-Boot SPL boot flow, the main hart
schedules the secondary harts to enter OpenSBI before doing so itself.
One of the secondary harts will therefore always be the winner of the
relocation lottery. This is problematic if the link address ranges of
OpenSBI and U-Boot SPL overlap. OpenSBI will be relocated and therefore
overwrite U-Boot SPL while some harts may still run it, leading to code
corruption.

Avoid this problem by specifying the main hart as the preferred boot
hart to perform the OpenSBI relocation. The main hart will be the last
hart to enter OpenSBI, relocation can therefore occur safely.

The boot hart field was added to version 2 of the OpenSBI FW_DYNAMIC
info structure. The header file include/opensbi.h is synchronized with
include/sbi/fw_dynamic.h from the OpenSBI project to update the info
structure. The header file is recent as of commit
7a13beb21326 ("firmware: Add preferred boot HART field in struct
fw_dynamic_info").

Reported-by: Rick Chen <rick@andestech.com>
Suggested-by: Anup Patel <Anup.Patel@wdc.com>
Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Rick Chen <rick@andestech.com>
Tested-by: Rick Chen <rick@andestech.com>
Reviewed-by: Anup Patel <anup.patel@wdc.com>
2019-12-10 08:23:10 +08:00
Simon Glass
1eb69ae498 common: Move ARM cache operations out of common.h
These functions are CPU-related and do not use driver model. Move them to
cpu_func.h

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2019-12-02 18:24:58 -05:00
Lukas Auer
5e30e45c83 spl: support booting via RISC-V OpenSBI
RISC-V OpenSBI is an open-source implementation of the RISC-V Supervisor
Binary Interface (SBI) specification. It is required by Linux and U-Boot
running in supervisor mode. This patch adds support for booting via the
OpenSBI FW_DYNAMIC firmware. It supports OpenSBI version 0.4 and higher.

In this configuration, U-Boot SPL starts in machine mode. After loading
OpenSBI and U-Boot proper, it will start OpenSBI. All necessary
parameters are generated by U-Boot SPL and are passed to OpenSBI. U-Boot
proper is started in supervisor mode by OpenSBI. Support for OpenSBI is
enabled with CONFIG_SPL_OPENSBI. An additional configuration entry,
CONFIG_SPL_OPENSBI_LOAD_ADDR, is used to specify the load address of the
OpenSBI firmware binary. It is not used directly in U-Boot and instead
is intended to make the value available to scripts such as FIT
configuration generators.

The header file include/opensbi.h is based on header files from the
OpenSBI project. They are recent, as of commit bae54f764570 ("firmware:
Add fw_dynamic firmware").

Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Anup Patel <anup.patel@wdc.com>
2019-08-26 16:07:42 +08:00