Only a specific type of SPI flash exists on a board, having board
Kconfig to select the SPI flash seems to make more sense. Other
flash types are not necessary except coreboot, which implies all
available flash drivers there.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

QEMU does not support ICH SPI controller yet. It's meaningless to
include SPI flash support.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Imply Qemu-specific drivers in the platform Kconfig.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Imply Quark-specific drivers in the platform Kconfig.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Imply Tangier-specific drivers in the platform Kconfig.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Imply drivers that work with Intel Queensbay platform.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

U-Boot as coreboot payload can run on any x86 hardware ideally.
Let's imply some common drivers that are useful.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Imply Broadwell-specific drivers in the platform Kconfig.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Imply drivers that are working with Ivybridge platform in the
platform Kconfig.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

BayTrail integrates lots of peripherals that have U-Boot drivers.
Imply those in the platform Kconfig.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Now that all x86 boards have been converted to use DM, we can imply
these uclass drivers (DM_ETH, DM_RTC, DM_USB, DM_VIDEO) from the
top level.

Previously DM_GPIO, DM_KEYBOARD, DM_SERIAL, DM_SPI, DM_SPI_FLASH
are selected. Change to use 'imply' to allow them to be removed.

Note with this change, chromebook_link64 build fails:

common/built-in.o:(.data.env_htab+0xc): undefined reference to 'env_flags_validate'
lib/built-in.o: In function `hsearch_r':
lib/hashtable.c:380: undefined reference to 'env_callback_init'
lib/hashtable.c:382: undefined reference to 'env_flags_init'
make[1]: *** [spl/u-boot-spl] Error 1

CONFIG_SPL_ENV_SUPPORT is required for chromebook_link64 to build
again. This is just a workaround as it is not needed at all. See
commit bda40d56 "x86: qemu: Add a config for 64-bit U-Boot" for
the same issue seen on QEMU 64-bit target.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This is a must have for all x86 boards.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Platform knows whether MRC cache is implemented, but using it can
be a choice of a specific board.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This is architecture-dependent early initialization hence should
be put in the platform Kconfig.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

arch_misc_init() is intended to do architecture-dependent stuff.
This is required by each platform.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

CONFIG_BOARD_EARLY_INIT_F literally indicates board-specific codes
and should be not 'default y' for all x86 boards.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Intel Management Engine is required by the platform, however it's
not a must have when building a U-Boot image. For example, during
development normally programming ME firmware is a one-time effort.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

PCI is the de facto interconnect bus in an x86 system.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

x86 is using the built-in libgcc implementation and this cannot be
turned off.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Without a timer, U-Boot just doesn't boot. This is not something
we can turn off.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Some firmwares might have another window for generated tables.

So, introduce two configuration options to select start address and
maximum length for the generated tables.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Rename try_msr_calibrate_tsc() to cpu_mhz_from_msr(), as that
better describes what the routine does.

This keeps in sync with Linux kernel commit:
  02c0cd2: x86/tsc_msr: Remove irqoff around MSR-based TSC enumeration
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Atom processors use a 19.2 MHz crystal oscillator.

Early processors generate 100 MHz via 19.2 MHz * 26 / 5 = 99.84 MHz.

Later processors generate 100 MHz via 19.2 MHz * 125 / 24 = 100 MHz.

Update the Silvermont-based tables accordingly, matching the Software
Developers Manual.

Also, correct a 166 MHz entry that should have been 116 MHz, and add
a missing 80 MHz entry for VLV2.

This keeps in sync with Linux kernel commit:
  05680e7: x86/tsc_msr: Correct Silvermont reference clock values
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Some processor abbreviations in the comments of freq_desc_tables[]
are obscure. This updates part of these to mention processors
that are known to us. Also expand frequency definitions.

This keeps in sync with Linux kernel commit:
  9e0cae9: x86/tsc_msr: Update comments, expand definitions
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

If either ratio or freq is zero, the return value is zero. There
is no need to create a fail branch and return zero there.

This keeps in sync with Linux kernel commit:
  14bb4e3: x86/tsc_msr: Remove debugging messages
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

try_msr_calibrate_tsc() is currently Intel-specific, and should not
execute on any other vendor's parts.

This keeps in sync with Linux kernel commit:
  ba82683: x86/tsc_msr: Identify Intel-specific code
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Currently we read the tsc radio like this:

	ratio = (MSR_PLATFORM_INFO >> 8) & 0x1f;

Thus we get bit 8-12 of MSR_PLATFORM_INFO, however according to the
Intel manual, the ratio bits are bit 8-15.

Fix this problem by masking 0xff instead.

This keeps in sync with Linux kernel commit:
  886123f: x86/tsc: Read all ratio bits from MSR_PLATFORM_INFO
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

64-bit U-Boot image is a combination of 32-bit U-Boot (SPL) plus
64-bit U-Boot (proper). For the U-Boot proper, it has be compiled
to 64-bit object codes. Attempting to use a toolchain to compile
64-bit U-Boot for qemu-x86_64, like kernel.org 4.9 i386-linux-gcc,
fails with the following errors:

  arch/x86/cpu/intel_common/microcode.c:79:2: error: PIC register
  clobbered by 'ebx' in 'asm'

The issue is because toolchain is preconfigured to generate code
for the 32-bit architecture (i386), and currently '-m64' is missing
in the makefile fragment. Using kernel.org 4.9 x86_64-linux-gcc
works out of the box, since it is preconfigured to generate 64-bit
codes.

When compiling U-Boot SPL, '-m32' is passed to the toolchain, no
mater 32-bit (i386-linux-) or 64-bit (x86_64-linux) the toolchain
is preconfigured to generate.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

At present U-Boot x86 build is using -mpreferred-stack-boundary=2
which is 4 bytes stack boundary alignment. With 64-bit U-Boot, the
minimal required stack boundary alignment is 16 bytes.

If -mpreferred-stack-boundary is not specified, the default is 4
(16 bytes). Switch to use the default one.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

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

Rsync all defconfig files using moveconfig.py
Signed-off-by: NTom Rini <trini@konsulko.com>

Migrate all remaining instances of CMD_NAND, CMD_NAND_TRIMFFS
CMD_NAND_LOCK_UNLOCK and CMD_NAND_TORTURE from the headers into the
defconfig files.
Tested-by: NAdam Ford <aford173@gmail.com>
Signed-off-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

With driver model the serial device is often not called "serial". Mark
driver-model stdio devices so that they can be detected and we can look up
the uclass. This is a more reliable way of finding out whether the console
is connected to a serial device or not.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Put the check for whether a console is a serial device in a function so
that we can share the code in the two places that use it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The image address passed to secure_boot_verify_image() may not be
cacheline aligned, round the address down to the nearest cacheline.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>

When we have MMC available we assume that we want to put the env as a
file on FAT.

Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTom Rini <trini@konsulko.com>

The main uses of CONFIG_SPL_ENV_SUPPORT are for network support and for
disabling "Falcon Mode" support at run-time.  As this build enables
neither, remove this feature.

Cc: Andrew F. Davis <afd@ti.com>
Signed-off-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

We rename the various FAT_ENV_xxx options to CONFIG_ENV_FAT_xxx so that
they can be modified via Kconfig.  Migrate all existing users to the new
values.
Signed-off-by: NTom Rini <trini@konsulko.com>

CONFIG_TWL4030_PWM is not being used by any source, so let's remove the #define
and the whitelist entry
Signed-off-by: NAdam Ford <aford173@gmail.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Add CONFIG_STM32X7_SERIAL as a Kconfig option.
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NVikas Manocha <vikas.manocha@st.com>