aboutsummaryrefslogtreecommitdiff
path: root/include/cpu_func.h
AgeCommit message (Collapse)Author
2021-07-28arm64: Update memcpy_{from, to}io() helpersPatrice Chotard
At early U-Boot stage, before relocation, MMU is not yet configured and disabled. DDR may not be configured with the correct memory attributes (can be configured in MT_DEVICE instead of MT_MEMORY). In this case, usage of memcpy_{from, to}io() may leads to synchronous abort in AARCH64 in case the normal memory address is not 64Bits aligned. To avoid such situation, forbid usage of normal memory cast to (u64 *) in case MMU is not enabled. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: mark.kettenis@xs4all.nl Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-03-02reset: Remove addr parameter from reset_cpu()Harald Seiler
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>
2020-05-18command: Remove the cmd_tbl_t typedefSimon Glass
We should not use typedefs in U-Boot. They cannot be used as forward declarations which means that header files must include the full header to access them. Drop the typedef and rename the struct to remove the _s suffix which is now not useful. This requires quite a few header-file additions. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-01-17common: Move reset_cpu() to the CPU headerSimon Glass
Move this function out of common.h and into a relevant header file. Signed-off-by: Simon Glass <sjg@chromium.org>
2019-12-02common: Move ARM cache operations out of common.hSimon Glass
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-02common: Move some cache and MMU functions out of common.hSimon Glass
These functions belong in cpu_func.h. Another option would be cache.h but that code uses driver model and we have not moved these cache functions to use driver model. Since they are CPU-related it seems reasonable to put them here. Move them over. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-12-02common: Move some SMP functions out of common.hSimon Glass
These functions belong in cpu_func.h so move them over. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-12-02common: Move checkcpu() out of common.hSimon Glass
This function belongs in cpu_func.h so move it over. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-12-02common: Move older CPU functions to their own headerSimon Glass
These should be moved to driver model, but in the meantime, move them out of the common header to help reduce its size. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>