The last user of the NEEDS_MANUAL_RELOC has been removed in commit
26af162ac8f8 ("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>

Move this into a function and do it once, not each time around the loop.

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 47870afab92fca6e672c03d0dea802a55e200675.

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>