History log of /openbmc/u-boot/arch/x86/cpu/x86_64/cpu.c (Results 1 – 10 of 10)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v00.04.15, v00.04.14, v00.04.13, v00.04.12, v00.04.11, v00.04.10, v00.04.09, v00.04.08, v00.04.07, v00.04.06, v00.04.05, v00.04.04, v00.04.03, v00.04.02, v00.04.01, v00.04.00, v2021.04, v00.03.03, v2021.01, v2020.10, v2020.07, v00.02.13, v2020.04, v2020.01, v2019.10, v00.02.05, v00.02.04, v00.02.03, v00.02.02, v00.02.01, v2019.07, v00.02.00, v2019.04
# c95c666d 22-Oct-2018 Tom Rini <trini@konsulko.com>

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


# 49d5ff43 13-Oct-2018 Bin Meng <bmeng.cn@gmail.com>

x86: Fix the mystery of printch() during 64-bit boot

At present in arch_setup_gd() it calls printch(' ') at the end which
has been a mystery for a long time as without such call the 64-bit
U-Boot ju

x86: Fix the mystery of printch() during 64-bit boot

At present in arch_setup_gd() it calls printch(' ') at the end which
has been a mystery for a long time as without such call the 64-bit
U-Boot just does not boot at all.

In fact this is due to the bug that board_init_f() was called with
boot_flags not being set. Hence whatever value being there in the
rdi register becomes the boot_flags if without such magic call.
With a printch(' ') call the rdi register is initialized as 0x20
and this value seems to be sane enough for the whole boot process.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

show more ...


# 2c78a79e 13-Oct-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

x86: put global data pointer into the .data section

On x86_64 the field global_data_ptr is assigned before relocation. As
sections for uninitialized global data (.bss) overlap with the relocation
se

x86: put global data pointer into the .data section

On x86_64 the field global_data_ptr is assigned before relocation. As
sections for uninitialized global data (.bss) overlap with the relocation
sections (.rela) this destroys the relocation table and leads to spurious
errors.

Initialization forces the global_data_ptr into a section for initialized
global data (.data) which cannot overlap any .rela section.

Fixes: a160092a610f ("x86: Support global_data on x86_64")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

show more ...


Revision tags: v2018.07
# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

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


# d024236e 18-Apr-2018 Tom Rini <trini@konsulko.com>

Remove unnecessary instances of DECLARE_GLOBAL_DATA_PTR

We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added

Remove unnecessary instances of DECLARE_GLOBAL_DATA_PTR

We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.

Signed-off-by: Tom Rini <trini@konsulko.com>

show more ...


Revision tags: v2018.03, v2018.01, v2017.11
# 76d1d02f 28-Mar-2017 Simon Glass <sjg@chromium.org>

board_f: x86: Use checkcpu() for CPU init

At present we misuse print_cpuinfo() do so CPU init on x86. This is done
because it is the next available call after the console is enabled. But
several arc

board_f: x86: Use checkcpu() for CPU init

At present we misuse print_cpuinfo() do so CPU init on x86. This is done
because it is the next available call after the console is enabled. But
several arches use checkcpu() instead. Despite the horrible name (which
we can fix), it seems a better choice.

Adjust the various x86 CPU implementations to move their init code into
checkcpu() and use print_cpuinfo() only for printing CPU info.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

show more ...


# 020a5d4f 18-Jan-2017 Bin Meng <bmeng.cn@gmail.com>

x86: Wrap print_ch() with config option

print_ch() should not be used if DEBUG_UART is off.

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


# 1b408630 16-Jan-2017 Simon Glass <sjg@chromium.org>

x86: ivybridge: Provide a dummy SDRAM init for 64-bit

We don't support SDRAM init in 64-bit mode since it is essentially
impossible to get into that mode before SDRAM set up. Provide dummy functions

x86: ivybridge: Provide a dummy SDRAM init for 64-bit

We don't support SDRAM init in 64-bit mode since it is essentially
impossible to get into that mode before SDRAM set up. Provide dummy functions
for now. At some point we will need to pass the SDRAM parameters through from
SPL.

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

show more ...


# a160092a 16-Jan-2017 Simon Glass <sjg@chromium.org>

x86: Support global_data on x86_64

At present this is just an ordinary variable. We may consider making it a
fixed register in the future.

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

x86: Support global_data on x86_64

At present this is just an ordinary variable. We may consider making it a
fixed register in the future.

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

show more ...


# 93031595 16-Jan-2017 Simon Glass <sjg@chromium.org>

x86: Add cpu code for x86_64

There is not much needed at present, but set up a separate directory to put
this code as it grows.

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

x86: Add cpu code for x86_64

There is not much needed at present, but set up a separate directory to put
this code as it grows.

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

show more ...