After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
The last user of the NEEDS_MANUAL_RELOC has been removed in commit
26af162ac8 ("arch: m68k: Implement relocation")
Remove now unused NEEDS_MANUAL_RELOC code.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Move the manual-relocation code to the initcall file. Make sure to avoid
manually relocating event types. Only true function pointers should be
relocated.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the initcall list consists of a list of function pointers. Over
time the initcall lists will likely change to mostly emitting events,
since most of the calls are board- or arch-specific.
As a first step, allow an initcall to be an event type instead of a
function pointer. Add the required macro and update initcall_run_list() to
emit an event in that case, or ignore it if events are not enabled.
The bottom 8 bits of the function pointer are used to hold the event type,
with the rest being all ones. This should avoid any collision, since
initcalls should not be above 0xffffff00 in memory.
Convert misc_init_f over to use this mechanism.
Add comments to the initcall header file while we are here. Also fix up
the trace test to handle the change.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move the failure message outside the loop, so it is easier to follow the
code. Avoid swallowing the error code - just pass it along.
Drop the initcall-list address from the output. This is confusing since
we show two addresses. Really it is only the function address which is
useful, since it can be looked up in the map, e.g. with:
grep -A1 -B1 serial_init u-boot.map
Signed-off-by: Simon Glass <sjg@chromium.org>
Use a variable to hold the function, so we don't need to repeat the
pointer access each time. Rename the init pointer to 'ptr' since we only
refer to it in the for() statement now.
Signed-off-by: Simon Glass <sjg@chromium.org>
Somehow I do not see any inlining with initcalls now. I was sure I saw
it when this commit went in, but now it seems to make things worse.
This reverts commit 47870afab9.
Signed-off-by: Simon Glass <sjg@chromium.org>
The board_r init function was complaining that we are looping through
an array, calling all our tiny init stubs sequentially via indirect
function calls (which can't be speculated, so they are slow).
The solution to that is pretty easy though. All we need to do is inline
the function that loops through the functions and the compiler will
automatically convert almost all indirect calls into direct inlined code.
With this patch, the overall code size drops (by 40 bytes on riscv64)
and boot time should become measurably faster for every target.
Signed-off-by: Alexander Graf <agraf@suse.de>
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>
With EFI the start address of U-Boot is specified differently. We could
consider just setting GD_FLG_RELOC and then setting up reloc_off. But that
flag has other implementations and we are not able to use U-Boot relocation
which this flag implies.
Instead, just add a special case for EFI.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Commit "initcall: Improve debugging support" makes sense and indeed
simplifies process of matching initcalls executed with static
disassembly.
Until you are debugging relocation functionality.
Existign output may make you think that at some point execution somehow
returned back to non-relocated area. And there're many reasons/problems
that may provoke this behavior.
In order to make things clear let's add explicit mention in case initall
was actually relocated like this:
--->---
initcall: 810015f8
Relocation Offset is: 0efcf000
Relocating to 8ffcf000, new gd at 8fdced3c, sp at 8fdced20
initcall: 810015b8
initcall: 8ffd093c
initcall: 8ffd0a14
initcall: 81001940 (relocated to 8ffd0940)
initcall: 81001958 (relocated to 8ffd0958)
--->---
Note "unexpected" jump from 0x8f... area to 0x81... area.
Without explanation this raises many questions: execution jumped in
relocated area right as expected and then for some reason returned back?
But I hope comment in brackets will save some time for those curious
developers who are careful enough to catch "unexpected jump to pre-reloc
area" or those unlucky ones who'll have to deal with relocation
debugging.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Now that some initcall functions return a useful error number, display it
when something goes wrong.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Add the ability to display the code offset of an initcall even after it
is relocated. This makes it much easier to relate initcalls back to the
U-Boot System.map file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
This library supports calling a list of functions one after the
other.
It is intended that we move to a more powerful initcall implementation
as proposed by Graeme Russ <graeme.russ@gmail.com>. For now, this allows
us to do the basics.
Signed-off-by: Simon Glass <sjg@chromium.org>
