x86: Fix MTRR clear to detect which MTRR to use

Coreboot was always using MTRR 7 for the write-protect
cache entry that covers the ROM and U-boot was removing it.
However with 4GB configs we need mo

x86: Fix MTRR clear to detect which MTRR to use

Coreboot was always using MTRR 7 for the write-protect
cache entry that covers the ROM and U-boot was removing it.
However with 4GB configs we need more MTRRs for the BIOS
and so the WP MTRR needs to move. Instead coreboot will
always use the last available MTRR that is normally set
aside for OS use and U-boot can clear it before the OS.

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

show more ...

x86: Emit port 80 post codes in show_boot_progress()

This helps us monitor boot progress and determine where U-Boot dies if
there are any problems.

Signed-off-by: Stefan Reinauer <reinauer@google.c

x86: Emit port 80 post codes in show_boot_progress()

This helps us monitor boot progress and determine where U-Boot dies if
there are any problems.

Signed-off-by: Stefan Reinauer <reinauer@google.com>

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

show more ...

x86: coreboot: Set CONFIG_ARCH_DEVICE_TREE correctly

We will use coreboot.dtsi as our fdt include file.

Signed-off-by: Gabe Black <gabeblack@chromium.org>

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

x86: coreboot: Set CONFIG_ARCH_DEVICE_TREE correctly

We will use coreboot.dtsi as our fdt include file.

Signed-off-by: Gabe Black <gabeblack@chromium.org>

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

show more ...

x86: Add back cold- and warm-boot flags

These were removed, but actually are useful.

Cold means that we started from a reset/power on.
Warm means that we started from another U-Boot.

We determine

x86: Add back cold- and warm-boot flags

These were removed, but actually are useful.

Cold means that we started from a reset/power on.
Warm means that we started from another U-Boot.

We determine whether u-boot on x86 was warm or cold booted (really if
it started at the beginning of the text segment or at the ELF entry point).
We plumb the result through to the global data structure.

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

show more ...

x86: Override calculate_relocation_address to use the e820 map

Because calculate_relocation_address now uses the e820 map, it will be able
to avoid addresses over 32 bits and regions that are at hig

x86: Override calculate_relocation_address to use the e820 map

Because calculate_relocation_address now uses the e820 map, it will be able
to avoid addresses over 32 bits and regions that are at high addresses but
not big enough for U-Boot. It also means we can remove the hack which
limitted U-Boot's idea of the size of memory to less than 4GB.

Also take into account the space needed for the heap and stack, so we avoid
picking a very small region those areas might overlap with something it
shouldn't.

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

show more ...

x86: Ignore memory >4GB when parsing Coreboot tables

U-boot is unable to actually use that memory and it can
cause problems with relocation if it tries to.

Signed-off-by: Duncan Laurie <dlaurie@chr

x86: Ignore memory >4GB when parsing Coreboot tables

U-boot is unable to actually use that memory and it can
cause problems with relocation if it tries to.

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

show more ...

x86: Clean up MTRR 7 right before jumping to the kernel

This cleans up the rom caching optimization implemented in coreboot (and
needed throughout U-Boot runtime).

Signed-off-by: Stefan Reinauer <r

x86: Clean up MTRR 7 right before jumping to the kernel

This cleans up the rom caching optimization implemented in coreboot (and
needed throughout U-Boot runtime).

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

show more ...

x86: Add basic cache operations

Add functions to enable/disable the data cache.

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

x86: Fill in the dram info using the e820 map on coreboot/x86

This way when that dram "banks" are displayed, there's some useful information
there. The number of "banks" we claim to have needs to be

x86: Fill in the dram info using the e820 map on coreboot/x86

This way when that dram "banks" are displayed, there's some useful information
there. The number of "banks" we claim to have needs to be adjusted so that it
covers the number of RAM e820 regions we expect to have/care about.

This needs to be done after "RAM" initialization even though we always run
from RAM. The bd pointer in the global data structure doesn't automatically
point to anything, and it isn't set up until "RAM" is available since, I
assume, it would take too much space in the very constrained pre-RAM
environment.

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

show more ...

x86: Enable coreboot timestamp facility support in u-boot.

This change turns on the code which allows u-boot to add
timestamps to the timestamp table created by coreboot.

Since u-boot does not use

x86: Enable coreboot timestamp facility support in u-boot.

This change turns on the code which allows u-boot to add
timestamps to the timestamp table created by coreboot.

Since u-boot does not use the tsc_t like structure to represent
HW counter readings, this structure is being replaced by 64 bit
integer.

The timestamp_init() function is now initializing the base timer
value used by u-boot to calculate the HW counter increments.

Timestamp facility is initialized as soon as the timestamp table
pointer is found in the coreboot table. The u-boot generated
timer events' ID will start at 1000 to clearly separate u-boot
events from coreboot events in the timer trace.

Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Add a dummy implementation for timer_get_us

The microsecond timer is not currently implemented, but add a dummy
implementation for now.

Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signe

x86: Add a dummy implementation for timer_get_us

The microsecond timer is not currently implemented, but add a dummy
implementation for now.

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

show more ...

x86: Add a default implementation for cleanup_before_linux()

This function provides an opportunity for some last minute cleanup and
reconfiguration before control is handed over to Linux. It's possi

x86: Add a default implementation for cleanup_before_linux()

This function provides an opportunity for some last minute cleanup and
reconfiguration before control is handed over to Linux. It's possible this
may need to do something in the future, but for now it's left empty. It's set
up as a weak symbol so it can be overridden if necessary on a case by case
basis.

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

show more ...

x86: coreboot: Decode additional coreboot sysinfo tags

Add support for decoding tags for GPIOs, compile/build info, cbmem and
other features.

Signed-off-by: Stefan Reinauer <reinauer@chromium.org>

x86: coreboot: Decode additional coreboot sysinfo tags

Add support for decoding tags for GPIOs, compile/build info, cbmem and
other features.

Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>

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

show more ...

x86: coreboot: Drop sysinfo.c

sysinfo.c only contains the lib_sysinfo data structure which
is used/filled by tables.c. This split was introduced by importing
code from libpayload originally, but to

x86: coreboot: Drop sysinfo.c

sysinfo.c only contains the lib_sysinfo data structure which
is used/filled by tables.c. This split was introduced by importing
code from libpayload originally, but to keep the code simple, add
the single line of actual code to tables.c

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

show more ...

x86: coreboot: Implement recursively scanning PCI busses

A hook is installed to configure PCI bus bridges as they encountered by u-boot.
The hook extracts the secondary bus number from the bridge's

x86: coreboot: Implement recursively scanning PCI busses

A hook is installed to configure PCI bus bridges as they encountered by u-boot.
The hook extracts the secondary bus number from the bridge's config space and
then recursively scans that bus.

On Coreboot, the PCI bus address space has identity mapping with the
physical address space, so declare it as such to ensure that the "pci_map_bar"
function used by some PCI drivers is behaving properly. This fixes the
EHCI PCI driver initialization on Stumpy.

This was tested as follows:

Ran the PCI command on Alex, saw devices on bus 0, the OXPCIe 952 on
bus 1, and empty busses 2 through 5. This matches the bridges
reported on bus 0 and the PCI configuration output from coreboot.

Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

x86: coreboot: Tell u-boot about PCI bus 0 when initializing

U-boot needs a host controller or "hose" to interact with the PCI busses
behind them. This change installs a host controller during initi

x86: coreboot: Tell u-boot about PCI bus 0 when initializing

U-boot needs a host controller or "hose" to interact with the PCI busses
behind them. This change installs a host controller during initialization of
the coreboot "board" which implements some of X86's basic PCI semantics. This
relies on some existing generic code, but also duplicates a little bit of code
from the sc520 implementation. Ideally we'd eliminate that duplication at some
point.

It looks like in order to scan buses beyond bus 0, we'll need to tell u-boot's
generic PCI configuration code what to do if it encounters a bridge,
specifically to scan the bus on the other side of it.

Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Graeme Russ <graeme.russ@gmail.com>

show more ...

x86: coreboot: Move non-board specific files to coreboot arch directory

coreboot.c and coreboot_pci.c don't contain board specific but only
coreboot specific code. Hence move it to the coreboot dire

x86: coreboot: Move non-board specific files to coreboot arch directory

coreboot.c and coreboot_pci.c don't contain board specific but only
coreboot specific code. Hence move it to the coreboot directory in
arch/x86/cpu (which should probably be moved out of cpu/ in another
commit)

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

show more ...

x86: Allow excluding reset vector code from u-boot

When running from coreboot we don't want this code.

This version works by ifdef-ing out all of the code that would go
into those sections and all

x86: Allow excluding reset vector code from u-boot

When running from coreboot we don't want this code.

This version works by ifdef-ing out all of the code that would go
into those sections and all the code that refers to it. The sections are
then empty, and the linker will either leave them empty for the loader
to ignore or remove them entirely.

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

show more ...

x86: Put global data on the stack

Putting global data on the stack simplifies the init process (and makes it
slightly quicker). During the 'flash' stage of the init sequence, global
data is in the C

x86: Put global data on the stack

Putting global data on the stack simplifies the init process (and makes it
slightly quicker). During the 'flash' stage of the init sequence, global
data is in the CAR stack. After SDRAM is initialised, global data is copied
from CAR to the SDRAM stack

Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Forward declare gd_t

So it can be used as a type in struct global_data and remove an ugly typecast

Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.o

x86: Forward declare gd_t

So it can be used as a type in struct global_data and remove an ugly typecast

Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>

show more ...

common: Discard the __u_boot_cmd section

The command declaration now uses the new LG-array method to generate
list of commands. Thus the __u_boot_cmd section is now superseded and
redundant and ther

common: Discard the __u_boot_cmd section

The command declaration now uses the new LG-array method to generate
list of commands. Thus the __u_boot_cmd section is now superseded and
redundant and therefore can be removed. Also, remove externed symbols
associated with this section from include/command.h .

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Joe Hershberger <joe.hershberger@gmail.com>
Cc: Mike Frysinger <vapier@gentoo.org>

show more ...

common: Add .u_boot_list into all linker files

Add section for the linker-generated lists into all possible linker
files, so that everyone can easily use these lists. This is mostly
a mechanical adj

common: Add .u_boot_list into all linker files

Add section for the linker-generated lists into all possible linker
files, so that everyone can easily use these lists. This is mostly
a mechanical adjustment.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Joe Hershberger <joe.hershberger@gmail.com>
Cc: Mike Frysinger <vapier@gentoo.org>

show more ...