summaryrefslogtreecommitdiff
path: root/arch/riscv/cpu/start.S
AgeCommit message (Collapse)Author
2025-10-16Revert "riscv: Add a Zalrsc-only alternative for synchronization in start.S"Yao Zi
This reverts commit a681cfecb4346107212f377e2075f6eb1bdc6a2b. It has been reported that the commit causes boot regression for SPL on StarFive VisionFive 2 or compatible boards. Inspecting the code, I did spot one logic error for deciding whether Zaamo or Zalrsc is used, and it's still unclear what exactly causes the regression, let's revert it for now. Reported-by: E Shattow <[email protected]> Link: https://lore.kernel.org/u-boot/[email protected]/ Signed-off-by: Yao Zi <[email protected]> Acked-by: E Shattow <[email protected]> Acked-by: Leo Yu-Chi Liang <[email protected]>
2025-09-19riscv: Add a Zalrsc-only alternative for synchronization in start.SYao Zi
Add an alternative implementation that use Zalrsc extension only for HART lottery and SMP locking to support SMP on cores without "Zaamo" extension available. The Zaamo implementation is still prioritized if both of them are available, since it takes fewer instructions. Signed-off-by: Yao Zi <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2025-03-13spl: Use CONFIG_VAL() to obtain the SPL stackSimon Glass
Now that we have the same option for SPL and TPL, simplify the logic for determining the initial stack. Note that this changes behaviour as current SPL_STACK is a fallback for TPL. However, that was likely unintended and can be handled with Kconfig defaults if needed. Signed-off-by: Simon Glass <[email protected]> Reviewed-by: Tom Rini <[email protected]> Suggested-by: Tom Rini <[email protected]>
2025-03-13spl: Add an SPL_HAVE_INIT_STACK optionSimon Glass
At present there is a hex value SPL_STACK which both determines whether SPL has its own initial stack and the hex value of that stack. Split off the former into SPL_HAVE_INIT_STACK with SPL_STACK depending on that and only providing the latter. Signed-off-by: Simon Glass <[email protected]> [trini: Resync defconfig files]
2024-10-11arch: Use CONFIG_XPL_BUILD instead of CONFIG_SPL_BUILDSimon Glass
Use the new symbol to refer to any 'SPL' build, including TPL and VPL Signed-off-by: Simon Glass <[email protected]>
2024-05-30riscv: remove cache enablement in start.SLeo Yu-Chi Liang
Cache could be enabled in harts_early_init board-specific hook, so remove cache enablement in start.S Signed-off-by: Leo Yu-Chi Liang <[email protected]>
2024-04-09riscv: add backtrace supportBen Dooks
When debugging, it is useful to have a backtrace to find out what is in the call stack as the previous function (RA) may not have been the culprit. Since this adds size to the build, do not add it by default and avoid putting it in the SPL build if not needed. Signed-off-by: Ben Dooks <[email protected]> Tested-by: Leo Yu-Chi Liang <[email protected]>
2023-10-24riscv: Remove common.h usageTom Rini
We can remove common.h from most cases of the code here, and only a few places need an additional header instead. Signed-off-by: Tom Rini <[email protected]> Reviewed-by: Rick Chen <[email protected]>
2023-08-10riscv: Add SPL_ZERO_MEM_BEFORE_USE implementationShengyu Qu
Add the actual support code for SPL_ZERO_MEM_BEFORE_USE and remove existing Starfive JH7110's L2 LIM clean code, since existing code has following issues: 1. Each hart (in the middle of a function call) overwriting its own stack and other harts' stacks. (data-race and data-corruption) 2. Lottery winner hart can be doing "board_init_f_init_reserve", while other harts are in the middle of zeroing L2 LIM. (data-race) Signed-off-by: Bo Gan <[email protected]> Signed-off-by: Shengyu Qu <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2023-07-24riscv: setup per-hart stack earlierBo Gan
Harts need to use per-hart stack before any function call, even if that function is a simple one. When the callee uses stack for register save/ restore, especially RA, if nested call, concurrent access by multiple harts on the same stack will cause data-race. This patch sets up SP before `board_init_f_alloc_reserve`. A side effect of this is that the memory layout has changed as the following: +----------------+ +----------------+ <----- SPL_STACK/ | ...... | | hart 0 stack | SYS_INIT_SP_ADDR | malloc_base | +----------------+ +----------------+ | hart 1 stack | | GD | +----------------+ If not SMP, N=1 +----------------+ | ...... | | hart 0 stack | +----------------+ +----------------+ ==> | hart N-1 stack| | hart 1 stack | +----------------+ +----------------+ | ...... | | ...... | | malloc_base | +----------------+ +----------------+ | hart N-1 stack| | GD | +----------------+ +----------------+ | | | | Signed-off-by: Bo Gan <[email protected]> Cc: Rick Chen <[email protected]> Cc: Leo <[email protected]> Cc: Sean Anderson <[email protected]> Cc: Bin Meng <[email protected]> Cc: Lukas Auer <[email protected]> Reviewed-by: Rick Chen <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2023-04-20riscv: spl: Remove relocation sectionsBin Meng
U-Boot SPL is not relocable. Drop these relocation sections. Signed-off-by: Bin Meng <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2023-04-20riscv: Avoid updating the link registerBin Meng
board_init_r does not return for U-Boot SPL hence there is no need to update the link register when jumping to board_init_r. Signed-off-by: Bin Meng <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2023-04-20riscv: Change to use positive offset to access relocation entriesBin Meng
The codes currently skip the very first relocation entry, and have an inaccurate comment "skip first reserved entry" indicating that the first entry is reserved, but later it references the elements in the first relocation entry using a minus offset. Change to use a positive offset so that there is no need to skip the first relocation entry. Signed-off-by: Bin Meng <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2023-04-20riscv: Optimize loading relocation typeBin Meng
't5' already contains relocation type so don't bother reloading it. Signed-off-by: Bin Meng <[email protected]> Reviewed-by: Rick Chen <[email protected]>
2023-04-20riscv: Optimize source end address calculation in start.SBin Meng
The __bss_start is the source end address hence load its address directly into register 't2' for optimization. Signed-off-by: Bin Meng <[email protected]> Reviewed-by: Rick Chen <[email protected]>
2022-09-26riscv: Introduce AVAILABLE_HARTSRick Chen
In SMP all harts will register themself in available_hart during start up. Then main hart will send IPI to other harts according to this variables. But this mechanism may not guarantee that all other harts can jump to next stage. When main hart is sending IPI to other hart according to available_harts, but other harts maybe still not finish the registration. Then the SMP booting will miss some harts finally. So let it become an option and it will be enabled by default. Please refer to the discussion: https://www.mail-archive.com/[email protected]/msg449997.html Signed-off-by: Rick Chen <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2022-09-26spl: introduce SPL_XIP to configNikita Shubin
U-Boot and SPL don't necessary share the same location, so we might end with U-Boot SPL in read-only memory (XIP) and U-Boot in read-write memory. In case of non XIP boot mode, we rely on such variables as "hart_lottery" and "available_harts_lock" which we use as atomics. The problem is that CONFIG_XIP also propagate to main U-Boot, not only SPL, so we need CONFIG_SPL_XIP to distinguish SPL XIP from other XIP modes. This adds an option special for SPL to behave it in XIP manner and we don't use hart_lottery and available_harts_lock, during start proccess. Signed-off-by: Nikita Shubin <[email protected]> Reviewed-by: Rick Chen <[email protected]>
2022-08-11riscv: ae350: Fix XIP config boot failureLeo Yu-Chi Liang
The booting flow is SPL -> OpenSBI -> U-Boot. The boot hart may change after OpenSBI and may not always be hart0, so wrap the related branch instruction with M-MODE. Current DTB setup for XIP is not valid. There is no chance for CONFIG_SYS_FDT_BASE, the DTB address used in XIP mode, to be returned. Fix this. Fixes: 2e8d2f88439d ("riscv: Remove OF_PRIOR_STAGE from RISC-V boards") Signed-off-by: Rick Chen <[email protected]> Signed-off-by: Leo Yu-Chi Liang <[email protected]>
2022-08-11riscv: cpu: set gp before board_init_f_init_reserveNikita Shubin
Restore global pointer before board_init_f_init_reserve call, as "a0" can be set in harts_early_init call and we end up with invalid global pointer. Signed-off-by: Nikita Shubin <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2022-06-06Migrate CUSTOM_SYS_INIT_SP_ADDR to Kconfig using system-constants.hTom Rini
- Make all users of CUSTOM_SYS_INIT_SP_ADDR reference SYS_INIT_SP_ADDR - Introduce HAS_CUSTOM_SYS_INIT_SP_ADDR to allow for setting the stack pointer directly, otherwise we use the common calculation. - On some platforms that were using the standard calculation but did not set CONFIG_SYS_INIT_RAM_SIZE / CONFIG_SYS_INIT_RAM_ADDR, set them. - On a small number of platforms that were not subtracting GENERATED_GBL_DATA_SIZE do so now via the standard calculation. - CONFIG_SYS_INIT_SP_OFFSET is now widely unused, so remove it from most board config header files. Signed-off-by: Tom Rini <[email protected]>
2021-10-18riscv: Remove OF_PRIOR_STAGE from RISC-V boardsIlias Apalodimas
At some point back in 2018 prior_stage_fdt_address and OF_PRIOR_STAGE got introduced, in order to support a DTB handed over by an earlier stage boo loader. However we have another option in the Kconfig (OF_BOARD) which has identical semantics. On RISC-V some of the boards pick up the DTB from a1 and copy it in their private gd_t. Apart from that they copy it to prior_stage_fdt_address, if the Kconfig option is selected, which is unnecessary. So let's switch the config option for those boards to OF_BOARD and define the required board_fdt_blob_setup() for them. Signed-off-by: Ilias Apalodimas <[email protected]> Reviewed-by: Simon Glass <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2021-05-05riscv: cpu: Add callback to init each coreGreen Wan
Add a callback harts_early_init() to start.S to allow different riscv hart perform setup code for each hart as early as possible. Since all the harts enter the callback, they must be able to run the same setup. Signed-off-by: Green Wan <[email protected]> Reviewed-by: Rick Chen <[email protected]> Reviewed-by: Bin Meng <[email protected]>
2020-12-14riscv: fix the wrong swap value registerBrad Kim
Not s2 register, t1 register is correct Fortunately, it works because t1 register has a garbage value Signed-off-by: Brad Kim <[email protected]> Reviewed-by: Lukas Auer <[email protected]> Reviewed-by: Leo Liang <[email protected]>
2020-09-30riscv: Add some comments to start.SSean Anderson
This adds comments regarding the ordering and purpose of certain instructions as I understand them. Signed-off-by: Sean Anderson <[email protected]> Reviewed-by: Bin Meng <[email protected]> Reviewed-by: Rick Chen <[email protected]> Reviewed-by: Leo Liang <[email protected]>
2020-09-30riscv: Ensure gp is NULL or points to valid dataSean Anderson
This ensures constructs like `if (gd & gd->...) { ... }` work when accessing the global data pointer. Without this change, it was possible for a very early trap to cause _exit_trap to directly or indirectly (through printf) to read arbitrary memory. This could cause a second trap, preventing show_regs from being printed. printf (and specifically puts) uses gd to determine what function to print with. These functions in turn use gd to find the serial device, etc. However, before accessing gd, puts first checks to see if it is non-NULL. This indicates an existing (perhaps undocumented) assumption that either gd is NULL or it is completely valid. Before this patch, gd either points to unexpected data (because it retains the value it did from the prior-stage) or points to uninitialized data (because it has not yet been initialized by board_init_f_init_reserve) until the hart has acquired available_harts_lock. This can cause two problems, depending on the value of gd->flags. If GD_FLG_SERIAL_READY is unset, then some garbage data will be printed to stdout, but there will not be a second trap. However, if GD_FLG_SERIAL_READY is set, then puts will try to print with serial_puts, which will likely cause a second trap. After this patch, gd is zero up until either a hart has set it in wait_for_gd_init, or until it is set by arch_init_gd. This prevents its usage before its data is initialized because both handle_trap and puts ensure that gd is nonzero before using it. After gd has been set, it is OK to access it because its data has been cleared (and so flags is valid). XIP cannot use locks because flash is not writable. This leaves it vulnerable to the same class of bugs regarding already-pending IPIs as before this series. Fixing that would require finding another method of synchronization, which is outside the scope of this series. Fixes: 7c6ca03eae ("riscv: additional crash information") Signed-off-by: Sean Anderson <[email protected]> Reviewed-by: Bin Meng <[email protected]> Reviewed-by: Rick Chen <[email protected]>
2020-09-30riscv: Consolidate fences into AMOs for available_harts_lockSean Anderson
We can reduce the number of instructions needed to use available_harts_lock by using the aq and rl suffixes for AMOs. Signed-off-by: Sean Anderson <[email protected]> Reviewed-by: Bin Meng <[email protected]> Reviewed-by: Rick Chen <[email protected]>
2020-09-30Revert "riscv: Clear pending interrupts before enabling IPIs"Sean Anderson
Clearing MIP.MSIP is not guaranteed to do anything by the spec. In addition, most existing RISC-V hardware does nothing when this bit is set. The following commits "riscv: Use a valid bit to ignore already-pending IPIs" and "riscv: Clear pending IPIs on initialization" should implement the original intent of the reverted commit in a more robust manner. This reverts commit 9472630337e7c4ac442066b5a752aaa8c3b4d4a6. Signed-off-by: Sean Anderson <[email protected]> Reviewed-by: Bin Meng <[email protected]> Reviewed-by: Rick Chen <[email protected]>
2020-07-24riscv: Fix linking error when building u-boot-spl with no SMP supportLeo Yu-Chi Liang
Switch off SMP support when building u-boot-spl would cause linking error as follow: undefined reference to 'secondary hart relocate' and 'smp_call_function'. Add macro to wrap up proper code region that needs SMP configuration on. Signed-off by: Leo Liang <[email protected]> Cc: [email protected] Reviewed-by: Bin Meng <[email protected]>
2020-07-01riscv: Clear pending interrupts before enabling IPIsSean Anderson
On some platforms (k210), the previous stage bootloader may have not cleared pending IPIs before transferring control to U-Boot. This can cause race conditions, as multiple harts all attempt to initialize the IPI controller at once. This patch clears IPIs before enabling them, ensuring that only one hart modifies shared memory at once. Signed-off-by: Sean Anderson <[email protected]> Reviewed-by: Rick Chen <[email protected]>
2020-04-23riscv: Provide a mechanism to fix DT for reserved memoryAtish Patra
In RISC-V, M-mode software can reserve physical memory regions by setting appropriate physical memory protection (PMP) csr. As the PMP csr are accessible only in M-mode, S-mode U-Boot can not read this configuration directly. However, M-mode software can pass this information via reserved-memory node in device tree so that S-mode software can access this information. This patch provides a framework to copy to the reserved-memory node from one DT to another. This will be used to update the DT used by U-Boot and the DT passed to the next stage OS. Signed-off-by: Atish Patra <[email protected]> Reviewed-by: Bin Meng <[email protected]> Tested-by: Bin Meng <[email protected]>
2020-04-23riscv: Introduce SPL_SMP Kconfig option for U-Boot SPLBin Meng
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 <[email protected]> Reviewed-by: Atish Patra <[email protected]>
2020-04-23riscv: Merge unnecessary SMP ifdefs in start.SBin Meng
Two consecutive SMP ifdefs blocks can be combined into one. Signed-off-by: Bin Meng <[email protected]> Reviewed-by: Atish Patra <[email protected]>
2020-02-10riscv: Remove unnecessary instructionSean Anderson
The add instruction on risc-v can have any three sources and targets, so there is no need for an intermediate mov. Signed-off-by: Sean Anderson <[email protected]> Reviewed-by: Rick Chen <[email protected]> Reviewed-by: Bin Meng <[email protected]>
2020-01-17common: Move relocate_code() to init.hSimon Glass
This is an init function so move it out of the common header. Avoid using the typedef so that we don't have to include the global_data header file. Also tidy up the function style in comments while we are here. Signed-off-by: Simon Glass <[email protected]>
2019-12-10riscv: add option to wait for ack from secondary harts in smp functionsLukas Auer
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 <[email protected]> Reviewed-by: Rick Chen <[email protected]> Tested-by: Rick Chen <[email protected]> Reviewed-by: Anup Patel <[email protected]>
2019-12-10riscv: Fix clear bss loop in the start-up codeRick Chen
For RV64, it will use sd instruction to clear t0 register, and the increament will be 8 bytes. So if the difference between__bss_strat and __bss_end was not 8 bytes aligned, the clear bss loop will overflow and acks like system hang. Signed-off-by: Rick Chen <[email protected]> Cc: KC Lin <[email protected]> Cc: Alan Kao <[email protected]>
2019-09-03riscv: update fix_rela_dynMarcus Comstedt
The addend is now added for RELOC_TYPE relocs. Also, changed the loop structure so that all the R_RISCV_RELATIVE relocs are not required to be at the beginning of the list. Signed-off-by: Marcus Comstedt <[email protected]> Cc: Rick Chen <[email protected]>
2019-08-26riscv: support SPL stack and global data relocationLukas Auer
To support relocation of the stack and global data on RISC-V, the secondary harts must be notified of the change using IPIs. We can reuse the hart relocation code for this purpose. It uses global data to store the new stack pointer and global data pointer for the secondary harts. This means that we cannot update the global data pointer of the main hart in spl_relocate_stack_gd(), because the secondary harts have not yet been relocated at this point. It is updated after the secondary harts have been notified. Signed-off-by: Lukas Auer <[email protected]> Reviewed-by: Bin Meng <[email protected]> Tested-by: Bin Meng <[email protected]> Reviewed-by: Anup Patel <[email protected]>
2019-08-26riscv: add SPL supportLukas Auer
U-Boot SPL on the generic RISC-V CPU supports two boot flows, directly jumping to the image and via OpenSBI firmware. In the first case, both U-Boot SPL and proper must be compiled to run in the same privilege mode. Using OpenSBI firmware, U-Boot SPL must be compiled for machine mode and U-Boot proper for supervisor mode. To be able to use SPL, boards have to provide a supported SPL boot device. Signed-off-by: Lukas Auer <[email protected]> Reviewed-by: Bin Meng <[email protected]> Tested-by: Bin Meng <[email protected]> Reviewed-by: Anup Patel <[email protected]>
2019-08-26riscv: add run mode configuration for SPLLukas Auer
U-Boot SPL can be run in a different privilege mode from U-Boot proper. Add new configuration entries for SPL to allow the run mode to be configured independently of U-Boot proper. Extend all uses of the CONFIG_RISCV_SMODE and CONFIG_RISCV_MMODE configuration symbols to also cover the SPL equivalents. Ensure that files compatible with only one privilege mode are not included in builds targeting an incompatible privilege mode. Signed-off-by: Lukas Auer <[email protected]> Reviewed-by: Bin Meng <[email protected]> Tested-by: Bin Meng <[email protected]> Reviewed-by: Anup Patel <[email protected]>
2019-08-15riscv: Access CSRs using CSR numbersBin Meng
We should prefer accessing CSRs using their CSR numbers because: 1. It compiles fine with older toolchains. 2. We can use latest CSR names in #define macro names of CSR numbers as-per RISC-V spec. 3. We can access newly added CSRs even if toolchain does not recognize newly added CSRs by name. This commit is inspired from Linux kernel commit a3182c91ef4e ("RISC-V: Access CSRs using CSR numbers"). Signed-off-by: Bin Meng <[email protected]> Reviewed-by: Rick Chen <[email protected]> Reviewed-by: Anup Patel <[email protected]> Reviewed-by: Lukas Auer <[email protected]>
2019-05-09riscv: prior_stage_fdt_address should only be used when OF_PRIOR_STAGE is ↵Rick Chen
enabled This patch will fix prior_stage_fdt_address write failure problem, when AE350 boots from flash. When AE350 boots from flash, prior_stage_fdt_address will be flash address, we shall avoid it to be written. Signed-off-by: Rick Chen <[email protected]> Cc: Greentime Hu <[email protected]> Reviewed-by: Bin Meng <[email protected]> Reviewed-by: Lukas Auer <[email protected]>
2019-05-09riscv: Introduce CONFIG_XIP to support booting from flashRick Chen
When U-Boot boots from flash, during the boot process, hart_lottery and available_harts_lock variable addresses point to flash which is not writable. This causes boot failures on AE350. Introduce a config option CONFIG_XIP to support such configuration. Signed-off-by: Rick Chen <[email protected]> Cc: Greentime Hu <[email protected]> Reviewed-by: Lukas Auer <[email protected]> Reviewed-by: Bin Meng <[email protected]>
2019-04-08riscv: hang if relocation of secondary harts failsLukas Auer
Print an error message and hang if smp_call_function() returns an error, indicating that relocation of the secondary harts has failed. Signed-off-by: Lukas Auer <[email protected]> Reviewed-by: Bin Meng <[email protected]> Tested-by: Bin Meng <[email protected]> Reviewed-by: Anup Patel <[email protected]>
2019-04-08riscv: do not rely on hart ID passed by previous boot stageLukas Auer
RISC-V U-Boot expects the hart ID to be passed to it via register a0 by the previous boot stage. Machine mode firmware such as BBL and OpenSBI do this when starting their payload (U-Boot) in supervisor mode. If U-Boot is running in machine mode, this task must be handled by the boot ROM. Explicitly populate register a0 with the hart ID from the mhartid CSR to avoid possible problems on RISC-V processors with a boot ROM that does not handle this task. Suggested-by: Rick Chen <[email protected]> Signed-off-by: Lukas Auer <[email protected]> Reviewed-by: Anup Patel <[email protected]> Reviewed-by: Atish Patra <[email protected]> Reviewed-by: Bin Meng <[email protected]> Tested-by: Bin Meng <[email protected]> Reviewed-by: Rick Chen <[email protected]> Tested-by: Rick Chen <[email protected]>
2019-04-08riscv: add support for multi-hart systemsLukas Auer
On RISC-V, all harts boot independently. To be able to run on a multi-hart system, U-Boot must be extended with the functionality to manage all harts in the system. All harts entering U-Boot are registered in the available_harts mask stored in global data. A hart lottery system as used in the Linux kernel selects the hart U-Boot runs on. All other harts are halted. U-Boot can delegate functions to them using smp_call_function(). Every hart has a valid pointer to the global data structure and a 8KiB stack by default. The stack size is set with CONFIG_STACK_SIZE_SHIFT. Signed-off-by: Lukas Auer <[email protected]> Reviewed-by: Anup Patel <[email protected]> Reviewed-by: Bin Meng <[email protected]> Tested-by: Bin Meng <[email protected]>
2019-04-08riscv: save hart ID in register tp instead of s0Lukas Auer
The hart ID passed by the previous boot stage is currently stored in register s0. If we divert the control flow inside a function, which is required as part of multi-hart support, the function epilog may not be called, clobbering register s0. Save the hart ID in the unallocatable register tp instead to protect the hart ID. Signed-off-by: Lukas Auer <[email protected]> Reviewed-by: Bin Meng <[email protected]> Reviewed-by: Rick Chen <[email protected]> Reviewed-by: Anup Patel <[email protected]>
2019-04-08riscv: delay initialization of caches and debug UARTLukas Auer
Move the initialization of the caches and the debug UART until after board_init_f_init_reserve. This is in preparation for SMP support, where code prior to this point will be executed by all harts. This ensures that initialization will only be performed once on the main hart running U-Boot. Signed-off-by: Lukas Auer <[email protected]> Reviewed-by: Anup Patel <[email protected]> Reviewed-by: Bin Meng <[email protected]>
2018-12-18riscv: Save boot hart id to the global dataBin Meng
At present the hart id passed via a0 in the U-Boot entry is saved to s0 at the beginning but does not preserve later. Save it to the global data structure so that it can be used later. Signed-off-by: Bin Meng <[email protected]> Reviewed-by: Lukas Auer <[email protected]> Reviewed-by: Anup Patel <[email protected]>
2018-12-18riscv: Move trap handler codes to mtrap.SBin Meng
Currently the M-mode trap handler codes are in start.S. For future extension, move them to a separate file mtrap.S. Signed-off-by: Bin Meng <[email protected]> Reviewed-by: Lukas Auer <[email protected]> Reviewed-by: Anup Patel <[email protected]>