Merge git://git.denx.de/u-boot-x86

x86: Fix car_uninit weak symbol definition

Since commit 80df194f0165 ("x86: detect unsupported relocation types"),
an error message is seen on QEMU x86 target during boot:

do_elf_reloc_fixups32: un

x86: Fix car_uninit weak symbol definition

Since commit 80df194f0165 ("x86: detect unsupported relocation types"),
an error message is seen on QEMU x86 target during boot:

do_elf_reloc_fixups32: unsupported relocation type 0x1 at fff841f0, offset = 0xfff00087
do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff841f8, offset = 0xfff00091

Check offset 0xfff00087 and 0xfff00091 in the u-boot ELF image,

fff00087 000df401 R_386_32 00000000 car_uninit
fff00091 000df402 R_386_PC32 00000000 car_uninit

we see R_386_32 and R_386_PC32 relocation type is generated for
symbol car_uninit, which is declared as a weak symbol in start.S.

However the actual weak symbol implementation ends up nowhere. As
we can see below, it's *UND*.

$ objdump -t u-boot | grep car_uninit
00000000 w *UND* 00000000 car_uninit

With this fix, it is normal now.

$ objdump -t u-boot | grep car_uninit
fff00094 w F .text.start 00000001 car_uninit

Reported-by: Hannes Schmelzer <hannes@schmelzer.or.at>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>

show more ...

Merge tag 'signed-efi-next' of git://github.com/agraf/u-boot

Patch queue for efi - 2018-07-25

Highlights this time:

- Many small fixes to improve spec compatibility (found by SCT)
- Almost eno

Merge tag 'signed-efi-next' of git://github.com/agraf/u-boot

Patch queue for efi - 2018-07-25

Highlights this time:

- Many small fixes to improve spec compatibility (found by SCT)
- Almost enough to run with sandbox target
- GetTime() improvements
- Enable EFI_LOADER and HYP entry on ARMv7 with NONSEC=y

show more ...

efi_loader: Rename sections to allow for implicit data

Some times gcc may generate data that is then used within code that may
be part of an efi runtime section. That data could be jump tables,
cons

efi_loader: Rename sections to allow for implicit data

Some times gcc may generate data that is then used within code that may
be part of an efi runtime section. That data could be jump tables,
constants or strings.

In order to make sure we catch these, we need to ensure that gcc emits
them into a section that we can relocate together with all the other
efi runtime bits. This only works if the -ffunction-sections and
-fdata-sections flags are passed and the efi runtime functions are
in a section that starts with ".text".

Up to now we had all efi runtime bits in sections that did not
interfere with the normal section naming scheme, but this forces
us to do so. Hence we need to move the efi_loader text/data/rodata
sections before the global *(.text*) catch-all section.

With this patch in place, we should hopefully have an easier time
to extend the efi runtime functionality in the future.

Signed-off-by: Alexander Graf <agraf@suse.de>
[agraf: Fix x86_64 breakage]

show more ...

SPDX: Convert all of our single license tags to Linux Kernel style

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

SPDX: Convert all of our single license tags to Linux Kernel style

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>

show more ...

x86: make LOAD_FROM_32_BIT visible for platforms

This option is useful not only for development, but for the platforms
where U-Boot is run from custom ROM bootloader. For example, Intel
Edison is th

x86: make LOAD_FROM_32_BIT visible for platforms

This option is useful not only for development, but for the platforms
where U-Boot is run from custom ROM bootloader. For example, Intel
Edison is that board.

Make this option visible that platforms can select it if needed.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

x86: Support a chained-boot development flow

Sometimes it is useful to jump into U-Boot directly from coreboot or UEFI
without any 16-bit init. This can help during development by allowing U-Boot
to

x86: Support a chained-boot development flow

Sometimes it is useful to jump into U-Boot directly from coreboot or UEFI
without any 16-bit init. This can help during development by allowing U-Boot
to avoid doing all the init required by the platform.

U-Boot expects its GDT to be set up correctly by its 16-bit code. If
coreboot doesn't do this (because it hasn't run the payload setup code yet)
then this won't happen.

In this case we cannot rely on the GDT settings. U-Boot will hang or crash
if these are wrong. Provide a development-only option to set up the GDT
correctly. This is just a hack so you can jump to U-Boot from any stage of
coreboot, not just at the end.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

Fix board init code to respect the C runtime environment

board_init_f_mem() alters the C runtime environment's
stack it is actually already using. This is not a valid
behaviour within a C runtime en

Fix board init code to respect the C runtime environment

board_init_f_mem() alters the C runtime environment's
stack it is actually already using. This is not a valid
behaviour within a C runtime environment.

Split board_init_f_mem into C functions which do not alter
their own stack and always behave properly with respect to
their C runtime environment.

Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Acked-by: Thomas Chou <thomas@wytron.com.tw>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot

Merge git://git.denx.de/u-boot-x86

x86: Init the debug UART if enabled

If the debug UART is enabled, get it ready for use at the earliest possible
opportunity. This is not actually very early, but until we have a stack it
is difficul

x86: Init the debug UART if enabled

If the debug UART is enabled, get it ready for use at the earliest possible
opportunity. This is not actually very early, but until we have a stack it
is difficult to make it work.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

Merge git://git.denx.de/u-boot-x86

x86: fsp: Add comments about U-Boot entering start.S twice

Add some comments in start.S for the fact that with FSP U-Boot
actually enters the code twice. Also change to use fsp_init()
and fsp_contin

x86: fsp: Add comments about U-Boot entering start.S twice

Add some comments in start.S for the fact that with FSP U-Boot
actually enters the code twice. Also change to use fsp_init()
and fsp_continue for accuracy.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

x86: fsp: Enlarge the size of malloc() pool before relocation

After fsp_init() returns, the stack has already been switched to a
place within system memory as defined by CONFIG_FSP_TEMP_RAM_ADDR.
En

x86: fsp: Enlarge the size of malloc() pool before relocation

After fsp_init() returns, the stack has already been switched to a
place within system memory as defined by CONFIG_FSP_TEMP_RAM_ADDR.
Enlarge the size of malloc() pool before relocation since we have
plenty of memory now.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

Merge git://git.denx.de/u-boot-x86

x86: Switch to using generic global_data setup

There is quite a bit of assembler code that can be removed if we use the
generic global_data setup. Less arch-specific code makes it easier to add
new

x86: Switch to using generic global_data setup

There is quite a bit of assembler code that can be removed if we use the
generic global_data setup. Less arch-specific code makes it easier to add
new features and maintain the start-up code.

Drop the unneeded code and adjust the hooks in board_f.c to cope.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

Merge git://git.denx.de/u-boot-dm

x86: Enable debug UART for Minnowmax

Enable the debug UART and emit a single 'a' early in the init sequence to
show that it is working.

Unfortunately the debug UART implementation needs a stack to

x86: Enable debug UART for Minnowmax

Enable the debug UART and emit a single 'a' early in the init sequence to
show that it is working.

Unfortunately the debug UART implementation needs a stack to work. I cannot
seem to remove this limitation as the absolute 'jmp %eax' instruction goes
off into the weeds.

So this means that the character output cannot be any earlier than
car_init_ret, where memory is available for a stack.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>

show more ...

Merge git://git.denx.de/u-boot-x86

x86: Add support for passing tables into U-Boot

The EFI stub provides information to U-Boot in a table. This includes the
memory map which is needed to decide where to relocate U-Boot. Collect this

x86: Add support for passing tables into U-Boot

The EFI stub provides information to U-Boot in a table. This includes the
memory map which is needed to decide where to relocate U-Boot. Collect this
information in the early init code and store it in global_data.

Fix up the BIST code at the same time since we don't have it when booting
from EFI and can assume it is 0.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

x86: Tidy up global_data flags

These flags now overlap some global ones. Adjust the x86-specific flags to
avoid this. Since this requires a change to the start.S code, add a way for
tools to find th

x86: Tidy up global_data flags

These flags now overlap some global ones. Adjust the x86-specific flags to
avoid this. Since this requires a change to the start.S code, add a way for
tools to find the 32-bit cold reset entry point. Previously this was at a
fixed offset.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

x86: Add various minor tidy-ups to the 32-bit startup code

Fix a typo, improve some comments and add a little more detail in some
cases.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: B

x86: Add various minor tidy-ups to the 32-bit startup code

Fix a typo, improve some comments and add a little more detail in some
cases.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot

Merge git://git.denx.de/u-boot-x86

x86: fsp: Move FspInitEntry call to board_init_f()

The call to FspInitEntry is done in arch/x86/lib/fsp/fsp_car.S so far.
It worked pretty well but looks not that good. Apart from doing too
much wor

x86: fsp: Move FspInitEntry call to board_init_f()

The call to FspInitEntry is done in arch/x86/lib/fsp/fsp_car.S so far.
It worked pretty well but looks not that good. Apart from doing too
much work than just enabling CAR, it cannot read the configuration
data from device tree at that time. Now we want to move it a little
bit later as part of init_sequence_f[] being called by board_init_f().
This way it looks and works better in the U-Boot initialization path.

Due to FSP's design, after calling FspInitEntry it will not return to
its caller, instead it jumps to a continuation function which is given
by bootloader with a new stack in system memory. The original stack in
the CAR is gone, but its content is perserved by FSP and described by
a bootloader temporary memory HOB. Technically we can recover anything
we had before in the previous stack, but that is way too complicated.
To make life much easier, in the FSP continuation routine we just
simply call fsp_init_done() and jump back to car_init_ret() to redo
the whole board_init_f() initialization, but this time with a non-zero
HOB list pointer saved in U-Boot's global data so that we can bypass
the FspInitEntry for the second time.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
Tested-by: Simon Glass <sjg@chromium.org>

show more ...