This code currently requires CONFIG_SYS_TEXT_BASE but this should be
unnecessary. As a first step, remove the build-time limitation and report an
error instead.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

When running as an EFI application we must skip relocation. Add support for
this in the x86 relocation code.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

This is now handled by generic U-Boot code so we do not need an x86 version.
It is no-longer called, so remove it.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

This normally indicates a problem which will prevent relocation from
functioning, resulting in a hang. Panic in this case to make it easier
to debug.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Use the inttypes header file to provide this.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Signed-off-by: NWolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: NTom Rini <trini@ti.com>

Several files use the global_data pointer without declaring it. This works
because the declaration is currently a NOP. But still it is better to
fix this so that x86 lines up with other archs.
Signed-off-by: NSimon Glass <sjg@chromium.org>

These are defined in asm-generic/sections.h, so remove them from
architecture-specific files.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This file handles common pre-relocation init for boards which use
the generic framework.

It starts up the console, DRAM, performs relocation and then jumps
to post-relocation init.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Tested-by: NWolfgang Denk <wd@denx.de>
Acked-by: NWolfgang Denk <wd@denx.de>

This does not actually change normal behaviour, but adds a check that
should detect corruption of relocation data (e.g. by using BSS data
prior to relocation).

Also add additional debugging output when enabled.

During this investigation, two situations have been seen:
1. calculate_relocation_address():
	uintptr_t size = (uintptr_t)&__bss_end - (uintptr_t)&__text_start;

turns into
     111166f:	b8 83 c4 17 01       	mov    $0x117c483,%eax

whih is beyond the end of bss:

0117b484 g       .bss	00000000 __bss_end

Somehow the __bss_end here is 255 bytes ahead.

2. do_elf_reloc_fixups():

	uintptr_t size = (uintptr_t)&__bss_end - (uintptr_t)&__text_start;

Here the __text_start is 0 in the file:

 1111d9f:	bb a0 e0 13 01       	mov    $0x113e0a0,%ebx
1111da4:	81 ef 00 00 00 00    	sub    $0x0,%edi

As it happens, both of these are in pre-relocation code.

For these reasons we silent check and ignore bad relocations.
Signed-off-by: NSimon Glass <sjg@chromium.org>

With CONFIG_OF_CONTROL we may have an FDT in the BSS region. Relocate
it up with the rest of U-Boot to keep the rest of memory free.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This seems to be a bug.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The use of post-increment with a do-while loop results in
the loop going one step too far when handling relocation fixups.

In about 1/100 cases this would cause it to hang.
Signed-off-by: NDuncan Laurie <dlaurie@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Create an init function array for board_init_f_r - This finalises the
migration to a purely array based initialisation mechanism

Also tweak a few comments while we are at it so everything is 'correct'

--
Changes for v2:
 - Renamed to a more apt name
 - Fix bug in set_reloc_flag_r
 - Re-instate gd->flags = boot_flags; in board_init_f
 - Added commit message