Using MSR_PLATFORM_INFO (0xCE) to calibrate TSR will cause #GP on
processors which do not have this MSR. Instead only doing the MSR
calibration for known/supported CPUs.

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

The CPU identification happens in x86_cpu_init_f() and corresponding
fields are saved in the global data for later use.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

The built in self test value is available in register eax on start-up. Save
it so that it can be accessed later. Unfortunately we must wait until the
global_data is available before we can do this, so there is a little bit of
shuffling to keep it around.

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

Some functions are missing prototypes. Fix those that are specific to x86.

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

Instead of an x86-specific cpu_init_f() function, use the normal U-Boot one
for this purpose. Also remove a useless/misleading comment.

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

Instead of having an x86-specific DRAM init function, adjust things so we
can use the normal one.

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

This code is a little muddled, so tidy it up. Make sure that we put the
GDT in the right place and set it up properly.

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

We should invalidate the TLB right at the start to ensure that we don't get
false address translations even though paging is disabled.

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

This allows a board to do very early init, but no boards need to do this.
We may as well drop this feature.

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

This was missed when the real mode support was dropped. Remove it.

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

We should use puts() instead of printf() where possible. Also clarify
the setup.bin message.

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

Detect an x86_64 kernel and boot it in 64-bit mode.

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

The boot_zimage() function is badly named it can also boot a raw kernel.
Rename it, and try to avoid pointers for memory addresses as it involves
lots of casting.

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

Add code to jump to a 64-bit Linux kernel. We need to set up a flat page
table structure, a new GDT and then go through a few hoops in the right
order.

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

Display the type of CPU (x86 or x86_64) when starting up.

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

Update this file to include x86_64 fields.

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

These functions really don't belong in physmem as they relate to the
cpu. Move them.

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

Use the inttypes header file to provide this.

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

There's a definition in stdint.h (provided by gcc) which will be more correct
if available.

Define CONFIG_USE_STDINT to use this feature, or USE_STDINT=1 on the 'make'
commmand.

This adjusts the settings for x86 and sandbox, with both have 64-bit options.

Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@google.com>
Rewritten to be an option, since stdint.h is often available only in glibc.
Changed to preserve a clear boundary between stdint and non-stdint
Signed-off-by: Simon Glass <sjg@chromium.org>

This makes use of the existing device tree node to use driver model
for the serial console.

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

Add more information so that U-Boot can find the address of the serial port.
Also fix the reg-shift value.

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

This code doesn't follow the normal approach of having its arch-specific
definitions in an arch-specific directory. Add a new arch-specific file
and make use of it.

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

Add support for this by reserving a block of memory below global_data.

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

To permit information to be passed from the early U-Boot code to
board_init_f() we cannot zero the global_data in board_init_f(). Instead
zero it in the start-up code.

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

This code generates warnings with recent gcc versions. We really don't need
the clobber specification, so just drop it.

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

The private libgcc is supported only on ARM, MIPS, PowerPC, SH, x86.
Those architectures should "select" HAVE_PRIVATE_LIBGCC and
CONFIG_USE_PRIVATE_LIBGCC should depend on it.

Currently, this option is enabled on Tegra boards and x86 architecture.
Move the definition from header files to Kconfig.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Tested-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Tom Warren <twarren@nvidia.com>

The motivation of this commit is to change CONFIG_USE_PRIVATE_LIBGCC
to a boolean macro so we can move it to Kconfig.

In the current implementation, there are two forms of syntax
for this macro:

  - CONFIG_USE_PRIVATE_LIBGCC=y
  - CONFIG_USE_PRIVATE_LIBGCC=path/to/private/libgcc

The latter is only used by x86 architecture.
With a little bit refactoring, it can be converted to the former.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Tested-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>

Add the required node describing how to find the EC on link.

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

GDT limit should be one less than an integral multiple of eight.

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

When building U-Boot with CONFIG_X86_RESET_VECTOR, the linking
process misses the resetvec.o and start16.o so it cannot generate
the rom version of U-Boot. The arch/x86/cpu/Makefile is updated to
pull them into the final linking process.

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

If we are passing this using the device tree then we may not want to
set this up here.

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

The x86 bootm code is quite special, and geared to zimage. Adjust it
to support device tree and make it more like the ARM code, with
separate bootm stages and functions for each stage.

Create a function announce_and_cleanup() to handle printing the
"Starting kernel ..." message and put it in bootm so it is in one
place and can be used by any loading code. Also move the
board_final_cleanup() function into bootm.

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

These options are used by the image code. To allow us to use the generic
code more easily, define these for x86.

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

The macro MIN, MAX is defined as the aliase of min, max,
respectively.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>

Now the types of CONFIG_SYS_{ARCH, CPU, SOC, VENDOR, BOARD, CONFIG_NAME}
are specified in arch/Kconfig.

We can delete the ones in arch and board Kconfig files.

This commit can be easily reproduced by the following command:

find . -name Kconfig -a ! -path ./arch/Kconfig | xargs sed -i -e '
/config[[:space:]]SYS_\(ARCH\|CPU\|SOC\|\VENDOR\|BOARD\|CONFIG_NAME\)/ {
    N
    s/\n[[:space:]]*string//
}
'

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>

CONFIG_${ARCH} is defined by Kconfig.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

This commit adds:
 - arch/${ARCH}/Kconfig
    provide a menu to select target boards
 - board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig
    set CONFIG macros to the appropriate values for each board
 - configs/${TARGET_BOARD}_defconfig
    default setting of each board

(This commit was automatically generated by a conversion script
based on boards.cfg)

In Linux Kernel, defconfig files are located under
arch/${ARCH}/configs/ directory.
It works in Linux Kernel since ARCH is always given from the
command line for cross compile.

But in U-Boot, ARCH is not given from the command line.
Which means we cannot know ARCH until the board configuration is done.
That is why all the "*_defconfig" files should be gathered into a
single directory ./configs/.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>

At present stdio device functions do not get any clue as to which stdio
device is being acted on. Some implementations go to great lengths to work
around this, such as defining a whole separate set of functions for each
possible device.

For driver model we need to associate a stdio_dev with a device. It doesn't
seem possible to continue with this work-around approach.

Instead, add a stdio_dev pointer to each of the stdio member functions.

Note: The serial drivers have the same problem, but it is not strictly
necessary to fix that to get driver model running. Also, if we convert
serial over to driver model the problem will go away.

Code size increases by 244 bytes for Thumb2 and 428 for PowerPC.

22: stdio: Pass device pointer to stdio methods
       arm: (for 2/2 boards)  all +244.0  bss -4.0  text +248.0
   powerpc: (for 1/1 boards)  all +428.0  text +428.0

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>

There is no point in setting a structure's memory to NULL when it has
already been zeroed with memset().

Also, there is no need to create a stub function for stdio to call - if the
function is NULL it will not be called.

This is a clean-up, with no change in functionality.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>

Until now building the x86 arch boards required 32-bit toolchain. As
many x86_64 toolchains come with 32-bit support (multilib) that's a
good idea to enable build with such toolchains.

The change required was to specify the usage of 32-bit explicitly to
the compiler and the linker (-m32 and -m elf_i386 flags) and locate
the right libgcc path.

Signed-off-by: Vasili Galka <vvv444@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>