driver: net: keystone_net: fix phy mode configuration

Phy mode is a board property and it can be different between
multiple board and ports, so it should not be hardcoded in
driver to one specific mode. So adding a field in eth_priv_t
structure to pass phy mode to driver.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: k2g: update keystone nav rx queue numbers

update K2G nav rx queue number

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: k2g: Correct base addresses

Coreect base addresses for SPI, Queue Manager, Ethernet, GPIO,
and MSMC segments.

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: k2g: Add pin mux data

Add pin mux data for k2g-evm

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: k2g: Add support for pin mux configuration

Add api for configuring pin mux.

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: k2g: Add ddr3 info

Add ddr3 related info

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: k2g: Add PSC info

Add psc information for k2g

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: k2g: Add clock information

Add clock information for Galileo

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>

ARM: k2g: Add pll data

Add pll data for k2g

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: k2g: Add kconfig support

Add Kconfig support

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: k2g: Add support for CPU detection

Adding CPU detection support for Keystone2 Galileo.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: keystone2: Use dtb images by default

Now that OF_CONTROL is enabled on all keystone2 platforms,
build the default images with DT.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: dts: k2e: Enable OF_CONTROL and DM

Import k2e specific DT files from Linux Kernel and enable
OF_CONTROL, DM, DM_SERIAL.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: dts: k2l: Enable OF_CONTROL and DM

Import k2l specific DT files from Linux Kernel and enable
OF_CONTROL, DM, DM_SERIAL.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: dts: k2hk: Enable OF_CONTROL and DM

Import k2hk specific DT files from Linux Kernel and enable
OF_CONTROL, DM, DM_SERIAL.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: dts: keystone2: Do not use LPAE addresses in U-Boot

Keystone dts files assumes that LPAE is enabled and top level root
node uses 64bit addresses. This breaks the keystone boot with
CONFIG_OF_CONTROL enabled. So do not use 64 bit addresse in U-Boot DT.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: dts: Keystone2: Import generic dt files from Linux Kernel

Import various generic dts files from Linux kernel so that
all keystone2 platforms can be DT in U-boot.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: keystone2: spl: Fix stack allocation with CONFIG_SYS_MALLOC_F_LEN

If CONFIG_SYS_MALLOC_F_LEN is enabled, the stack is moved down to the
specified size to make the malloc function available before relocation.
But on keystone platforms SYS_SPL_MALLOC is immediately preceding stack,
which is causing an overlap with this config enabled.
So leave a gap between malloc space and stack space.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ARM: keystone2: Fix serial port init

With CONFIG_DM_SERIAL is enabled NS16550_init() cannot be
called directly. Driver probe should be taking care of this.
So call this function only when DM_SERIAL is not enabled.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

dra72_evm: Switch to DM_SERIAL

Tested on J6Eco EVM.
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Lokesh Vutla <lokeshvutla@ti.com>

ti_omap5_common.h: Switch to CONFIG_OMAP_SERIAL for non-SPL DM_SERIAL

Tested on J6Eco EVM
Signed-off-by: Tom Rini <trini@konsulko.com>

ti_omap4_common.h: Switch to CONFIG_OMAP_SERIAL for non-SPL DM_SERIAL

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

test: Add basic tests for remoteproc

Use the sandbox environment for the basic tests.

Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>

sandbox: Introduce dummy remoteproc nodes

Introduce dummy devices for sandbox remoteproc device and enable it by
default

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>

remoteproc: Introduce a sandbox dummy driver

Introduce a dummy driver for sandbox that allows us to verify basic
functionality. This is not meant to do anything functional - but is
more or less meant as a framework plumbing debug helper.

The sandbox remoteproc driver maintains absolutey no states and is a
simple driver which just is filled with empty hooks. Idea being to give
an approximate idea to implement own remoteproc driver using this as a
template.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>

drivers: Introduce a simplified remoteproc framework

Many System on Chip(SoC) solutions are complex with multiple processors
on the same die dedicated to either general purpose of specialized
functions. Many examples do exist in today's SoCs from various vendors.
Typical examples are micro controllers such as an ARM M3/M0 doing a
offload of specific function such as event integration or power
management or controlling camera etc.

Traditionally, the responsibility of loading up such a processor with a
firmware and communication has been with a High Level Operating
System(HLOS) such as Linux. However, there exists classes of products
where Linux would need to expect services from such a processor or the
delay of Linux and operating system being able to load up such a
firmware is unacceptable.

To address these needs, we need some minimal capability to load such a
system and ensure it is started prior to an Operating System(Linux or
any other) is started up.

NOTE: This is NOT meant to be a solve-all solution, instead, it tries to
address certain class of SoCs and products that need such a solution.

A very simple model is introduced here as part of the initial support
that supports microcontrollers with internal memory (no MMU, no
execution from external memory, or specific image format needs). This
basic framework can then (hopefully) be extensible to other complex SoC
processor support as need be.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>

defconfig: am335x: gp_evm: enable ethernet driver model

enable ethernet driver model for am335x gp evm as cpsw supports
driver model

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

defconfig: am335x: bbb: enable ethernet driver model

enable ethernet driver model for am335x beagle bone black as cpsw
supports driver model

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

drivers: net: cpsw: convert driver to adopt device driver model

adopt cpsw driver to device driver model

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

drivers: net: cpsw: prepare driver for device model migration

prepare driver for device model migration

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

am335x_evm: do not define usb ether gadget when Eth DM is defined

Since usb ether gadget doesn't have support for driver model, so
not defining usb ether gadget when ethernet driver model is
defined.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

am335x_evm: prepare for eth driver model support

Prepare board file so that ethernet registration are
commented for DM conversion

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

configs: am335x_evm: Support distro bootcmds

Add support for distro bootcmds and network booting while retaining
backwards compatibility with the current "legacy" setup. With these
changes the default boot sequence becomes:

* SD card (standard distro boot)
* SD card (legacy boot)
* EMMC (standard distro boot)
* EMMC (legacy boot)
* Nand (legacy boot)
* PXE (standard distro boot)
* DHCP (standard distro boot)

The older boot scripts have some overlap with what the distro
bootcommands to however i've left them unchanged to prevent introduction
of subtle bugs.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

configs: ti_armv7_common.h: Add default addresses for pxe and scripts

Add mandatory address variables for loading scripts and pxe configuration as
per README.distro

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

config_distro_bootcmd.h: Use a private variable for bootpart

Hush has an oddity where using ${var} causes var to resolved in the the global
address space (iotw the environment) first and only afterwards will the local
variable space be searched.

This causes odd side-effects when iterating over the boot partitions
using ${bootpart} if the environment also has a bootpart variable (e.g. for
the various TI boards). Fix this by using the hopefully more unique
${distro_bootpart} instead of ${bootpart}.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>

omap-common: Common get_board_serial function to pass serial through ATAG

Since there is a common function to grab the serial number from the die id bits,
it makes sense have one to parse that serial number and feed it to the serial
ATAG.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>

omap-common: Common function to display die id, replacing omap3-specific version

This introduces omap_die_id_display to display the full die id.
There is no need to store it in an environment variable, that no boot script
is using anyway.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>

omap-common: Common serial and usbethaddr functions based on die id

Now that we have a common prototype to grab the omap die id, functions to figure
out a serial number and usb ethernet address can use it directly.
Those also get an omap_die_id prefix for better consistency.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>

omap5: omap_die_id support

This introduces omap5 support for omap_die_id, which matches the common
omap_die_id definition. It replaces board-specific code to grab the die id bits.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>

omap4: omap_die_id support

This introduces omap4 support for omap_die_id, which matches the common
omap_die_id definition. It replaces board-specific code to grab the die id bits.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>

omap3: omap_die_id support

This replaces the previous get_dieid definition with omap_die_id, that matches
the common omap_die_id definition.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>

omap-common: Common omap_die_id definition

This introduces a common definition for omap_die_id, that aims at providing a
common interface for accessing omap platform's die id bits.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>

ARM Fix pandaboard es and a4 revision ID

board_name environment variable was not getting set correctly for Pandaboard A4 and ES

Signed-off-by: David Batzle <dbatzle@dcbcyber.com>
CC: Albert Aribaud <albert.u.boot@aribaud.net>; Tom Rini <trini@ti.com>; Peter Robinson <pbrobinson@gmail.com>

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

x86: Add support for Advantech SOM-6896

Advantech SOM-6896 is a Broadwell U based COM Express Compact Module
Type 6. This patch adds support for it as a coreboot payload.

On board SATA and SPI are functional. On board Ethernet isn't functional
but since it's optional and ties up a PCIe x4 that is otherwise brought
out, this isn't a concern at the moment. USB doesn't work since the
xHCI driver appears to be broken.

Signed-off-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

x86: ivybridge: Enable the MRC cache

This works correctly now, so enable it.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Dropped malloc() and adjusted commit message:
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: ivybridge: Measure the MRC code execution time

This code takes about 450ms without the MRC cache and about 27ms with the
cache. Add a debug timer so that this time can be displayed.

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

x86: ivybridge: Fix car_uninit() to correctly set run state

At present a missing $ causes this code to hang when using the MRC cache/
Fix it.

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

x86: ivybridge: Check the RTC return value

The RTC can fail, so check the return value for reads.

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

x86: ivybridge: Use 'ret' instead of 'rcode'

For consistency, use 'ret' to handle a return value.

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

dm: rtc: Correct rtc_read32() return value

The current check is incorrect and will fail when any non-zero byte is read.
Fix it.

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

rtc: mc146818: Use probe() to set up the device

At present this driver uses bind() to set up the device. The bind() method
should not touch the hardware, so move the init code to probe().

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

rtc: mc146818: Add a comment to the #endif

Add a comment to make it clear to which block the #endif relates.

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

x86: chromebook_link: Enable the debug UART

Add support for the debug UART on link. This is useful for early debugging.

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

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>

debug_uart: Add an option to announce the debug UART

It is useful to see a message from the debug UART early during boot so that
you know things are working. Add an option to enable this. The message will
be displayed as soon as debug_uart_init() is called.

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

debug_uart: Support board-specific UART initialisation

Some boards need to set things up before the debug UART can be used. On
these boards a call to debug_uart_init() is insufficient. When this option
is enabled, the function board_debug_uart_init() will be called when
debug_uart_init() is called. You can put any code here that is needed to
set up the UART ready for use, such as set pin multiplexing or enable
clocks.

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

debug_uart: Adjust the declaration of debug_uart_init()

We want to be able to add other common code to this function. So change the
driver's version to have an underscore before it, just like
_debug_uart_putc(). Define debug_uart_init() to call this version.

Update all drivers to this new method.

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

x86: spi: Add support for Wildcat Point

Add the Wildcat Point ID so Broadwell U based boards can use SPI.

Signed-off-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: pci: Add PCI IDs for Wildcat Point

Add Wildcat Point AHCI and LPC PCI IDs which are present on Broadwell U
based (and possibly other) boards.

Signed-off-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: Pass correct cpu_index to ap_init()

In sipi_vector.S, cpu_index (passed as %eax) is wrongly overwritten
by the ap_init() function address. Correct it.

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

x86: galileo: Enable mrc cache

Now that we have added MRC cache on quark support codes,
enable it on Intel Galileo board.

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

x86: quark: Implement mrc cache

Using existing mrccache library to implement mrc cache support
for Intel Quark.

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

x86: ivybridge: Correct two typos for MRC

It should be MRC, not MCR.

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

x86: Remove unused rw-mrc-cache properties in the link and panther dts files

"type" and "wipe-value" are never used by the mrccache codes.
Remove them to avoid confusion. This also removes the alignment
comment in the panther dts file.

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

x86: baytrail: Issue full system reset in reset_cpu()

With MRC cache enabled, when typing 'reset' in the U-Boot shell,
BayTrail FSP initialization hangs at "Configuring Memory Start":

  Setting BootMode to 0
  Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56
  Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE
  About to call MrcInit();
  BayleyBay Platform Type
  CurrentMrcData.BootMode = 4
  Taking Fastboot path!
  Configuring Memory Start...

Changing reset_cpu() to do a full system reset fixes this issue.

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

x86: Enable mrc cache for bayleybay and minnowmax

Now that we have added MRC cache for Intel FSP and BayTrail codes,
enable it for all BayTrail boards (Bayley Bay and Minnow Max).

Note it turns out that FSP for Intel Atom E6xx does not produce
the HOB for NV storage, so we don't have such functionality on
Intel Crown Bay board.

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

x86: baytrail: Save mrc cache to spi flash

Save MRC cache to SPI flash in arch_misc_init().

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

x86: fsp: Pass mrc cache to fsp_init() and save it to gd after fsp_init()

fsp_init() call has a parameter nvs_buf which is used by FSP as the
MRC cache but currently is blindly set to NULL. Retreive the MRC
cache from SPI flash and pass it to fsp_init() call. After the call,
save FSP produced MRC cache to SPI flash too.

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

x86: Use struct mrc_region to describe a mrc region

Currently struct fmap_entry is used to describe a mrc region.
However this structure contains some other fields that are not
related to mrc cache and causes confusion. Besides, it does not
include a base address field to store SPI flash's base address.
Instead in the mrccache.c it tries to use CONFIG_ROM_SIZE to
calculate the SPI flash base address, which unfortunately is
not 100% correct as CONFIG_ROM_SIZE may not match the whole
SPI flash size.

Define a new struct mrc_region and use it instead.

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

x86: ivybridge: Use APIs provided in the mrccache lib

Remove the call to custom mrc cache APIs, and use the ones
provided in the mrccache lib.

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

x86: Add more common routines to manipulate mrc cache

This adds mrccache_reserve(), mrccache_get_region() and
mrccache_save() APIs to the mrccache codes. They are ported
from the ivybridge implementation, but with some changes.
For example, in the mrccache_reserve(), ivybridge version
only reserves the pure MRC data, which causes additional
malloc() when saving the cache as the save API needs some
meta data. Now we change it to save the whole MRC date plus
the meta data to elinimate the need for the malloc() later.

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

x86: Add various minor tidy-ups in mrccache codes

Fix some nits, improve some comments and reorder some codes
a little bit.

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

x86: Do sanity test on the cache record in mrccache_update()

For the cache record to write in mrccache_update(), we should
perform a sanity test to see if it is a valid one.

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

x86: Move mrccache.[c|h] to a common place

mrccache implementation can be common for all boards. Move it
from ivybridge cpu directory to the common lib directory.

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

x86: Add ENABLE_MRC_CACHE Kconfig option

Create a Kconfig option for enabling MRC cache.

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

x86: fsp: Add a hdr sub-command to show header information

It would be helpful to have a command to show FSP header. So far
it only supports FSP header which conforms to FSP spec 1.0.

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

x86: fsp: Make hob command a sub-command to fsp

Introduce a new fsp command and make the existing hob command a
sub-command to fsp for future extension. Also move cmd_hob.c to
the dedicated fsp sub-directory in arch/x86/lib.

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

x86: fsp: Print GUID whenever applicable in the hob command output

When examining a HOB, it's useful to see which GUID this HOB
belongs to. Add GUID output in the hob command to aid this.

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

x86: fsp: Compact the output of hob command

Compact hob command output, especially by making hob type string a
little bit shorter so that we can leave room for future extension.

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

x86: Add SMBIOS table support

System Management BIOS (SMBIOS) is a specification for how
motherboard and system vendors present management information
about their products in a standard format by extending the BIOS
interface on Intel architecture systems. As of today the latest
spec is 3.0 and can be downloaded from DMTF website. This commit
adds a simple and minimum required implementation.

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

Makefile: Generate U_BOOT_DMI_DATE for SMBIOS

Add U_BOOT_DMI_DATE (format mm/dd/yyyy) generation to be used by
SMBIOS tables, as required by SMBIOS spec 3.0 [1]. See chapter 7.1,
BIOS information structure offset 08h for details.

[1] http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.0.0.pdf

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

doc: Complement document about booting VxWorks

Current document about how to boot VxWorks is limited.
Add several chapters in README.vxworks to document this.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

cmd: bootvx: Add asmlinkage to the VxWorks x86 entry

VxWorks on x86 uses stack to pass parameters.

Reported-by: Jian Luo <jian.luo4@boschrexroth.de>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

cmd: bootvx: Pass E820 information to an x86 VxWorks kernel

E820 is critical to the kernel as it provides system memory map
information. Pass it to an x86 VxWorks kernel.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Jian Luo <jian.luo4@boschrexroth.de>

cmd: bootvx: Always get VxWorks bootline from env

So far VxWorks bootline can be contructed from various environment
variables, but when these variables do not exist we get these from
corresponding config macros. This is not helpful as it requires
rebuilding U-Boot, and to make sure these config macros take effect
we should not have these environment variables. This is a little
bit complex and confusing.

Now we change the logic to always contruct the bootline from
environments (the only single source), by adding two new variables
"bootdev" and "othbootargs", and adding some comments about network
related settings mentioning they are optional. The doc about the
bootline handling is also updated.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>

cmd: bootvx: Pass netmask and gatewayip to VxWorks bootline

There are fields in VxWorks bootline for netmask and gatewayip.
We can get these from U-Boot environment variables and pass them
to VxWorks, just like ipaddr and serverip.

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

cmd: bootvx: Avoid strlen() calls when constructing VxWorks bootline

Remember the position in the VxWorks bootline buffer to avoid the call
to strlen() each time.

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

cmd: elf: Reorder load_elf_image_phdr() and load_elf_image_shdr()

Move load_elf_image_phdr() and load_elf_image_shdr() to the beginning
of the cmd_elf.c so that forward declaration is not needed.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

cmd: Clean up cmd_elf a little bit

This commit cleans up cmd_elf.c per U-Boot coding convention,
and removes the unnecessary DECLARE_GLOBAL_DATA_PTR and out-of-date
powerpc comments (it actually supports not only powerpc targets).

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

cmd: Convert CONFIG_CMD_ELF to Kconfig

Convert CONFIG_CMD_ELF to Kconfig and tidy up affected boards.

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

x86: Remove quotation mark in CONFIG_HOSTNAME

CONFIG_HOSTNAME is an environment varible, so that quotation mark
is not needed.

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

x86: Move install_e820_map() out of zimage.c

install_e820_map() has nothing to do with zimage related codes.
Move it to a dedicated place.

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

x86: Initialize GDT entry 1 to be the 32-bit CS as well

Some OS (like VxWorks) requires GDT entry 1 to be the 32-bit CS.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Jian Luo <jian.luo4@boschrexroth.de>

x86: Allow disabling IGD on Intel Queensbay

Add a Kconfig option to disable the Integrated Graphics Device (IGD)
so that it does not show in the PCI configuration space as a VGA
disaplay controller. This gives a chance for U-Boot to run PCI/PCIe
based graphics card's VGA BIOS and use that for the graphics console.

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

x86: ivybridge: Remove the dead codes that programs pci bridge

Remove bd82x6x_pci_bus_enable_resources() that is not called anywhere.

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

dm: pci: Enable VGA address forwarding on bridges

To support graphics card behind a PCI bridge, the bridge control
register (offset 0x3e) in the configuration space must turn on
VGA address forwarding.

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

dm: pci: Fix pci_last_busno() to return the real last bus no

Currently pci_last_busno() only checks the last bridge device
under the first UCLASS_PCI device. This is not the case when
there are multiple bridge devices.

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

video: vesa_fb: Fix wrong return value check of pci_find_class()

When pci_find_class() fails to find a device, it returns -ENODEV.
But now we check the return value against -1. Fix it.

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

pci: Set PCI_COMMAND_IO bit for VGA device

PCI_COMMAND_IO bit must be set for VGA device as it needs to respond
to legacy VGA IO address.

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