We no longer need these globally. Guard them so we get to declare
static replacements at few locations until complete removal.
Change-Id: Ie33e2a680fc9bbb7e28c8fbe17e5181e626736a5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5718
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Problem with UMA region allocation was fixed when MTRRs changed to use
memrange implementation.
Change-Id: I420dac30de2836a91596d81f88bb45b46f248532
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5719
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The memory reference code doesn't maintain some of
the registers which contain valuable information in order
to log correct reset and wake events in the eventlog. Therefore
snapshot the registers which matter in this area so that
they can be consumed by ramstage.
BUG=chrome-os-partner:24907
BRANCH=rambi,squawks
TEST=Did various resets/wakes with logging patch which
consumes this structure. Eventlog can pick up reset
events and power failures.
Change-Id: Id8d2d782dd4e1133113f5308c4ccfe79bc6d3e03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181982
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5032
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This is a empty struct that has propagated through the superio's & ec's
but really does nothing. Time to get rid of it before it adds yet more
cruft. However, since this touches many superio's at once we do this in
stages by first changing the function type to be a pure procedure.
Change-Id: Ibc732e676a9d4f0269114acabc92b15771d27ef2
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5617
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
Allow ramstage cache to be used from ramstage proper. Also
add a helper function for checking validity of ramstage
cache structure.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=Built and booted. S3 resumed.
Change-Id: If1f2ad1bcf64504b42e315be243a12432b50e3d5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179775
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5011
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The reg_script library has proven to be useful. It's
also shown that many scripts operate on devices. However,
certain code paths run the same script on multiple,
but different, devices. In order to make that easier
introduce reg_script_run_on_dev() which takes a device
as a parameter. That way, chained reg_scripts are not
scrictly needed to run the same script on multiple devices.
BUG=None
BRANCH=None
TEST=Built.
Change-Id: I273499af4d303ebd7dc19e9b635ca23cf9bb2225
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179540
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5005
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
- Move the non chipset-specific fsp pieces out of the chipset into a
shared area. This is used by northbridge / southbrige / SOC code. It
pulls in pieces from Kconfig, Makefile and FSP specific code.
- Enabled in the CPU code with a Kconfig "select PLATFORM_USES_FSP"
Change-Id: I7ffa934c1df09b71d48a876a56e3b888685870b8
Signed-off-by: Martin Roth <gaumless@gmail.com>
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/5635
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This feature is no longer specific to ChromeOS builds.
Change-Id: If27d4dc7caff8a551b5b325cdebdd05c079ec921
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5641
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Aaron Durbin <adurbin@google.com>
ITE Super I/O's make use of this method to enter and exit in and out of
their PNP configuration. Provide functions for use in ram stage
component.
Change-Id: I2b546c2b17eefc89aaab4982192f5e9a15a16c2f
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5666
Tested-by: build bot (Jenkins)
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER
as they do not make any sense for coreboot as a whole. All these attributes are
associated with each of the stages.
Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5577
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
This required changing value/mask types to uint64_t.
Another option would be to use id field to select low or high
32 bits of the MSR and set them independently.
BUG=chrome-os-partner:23505
BRANCH=none
TEST=build and boot on rambi
Change-Id: Ied9998058a8035bf3f003185236f3be3e0df7fc9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176304
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4951
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
In the signature of the function `hexdump32()` it does not make sense to
represent a length, assumed to be positive, as a signed integer.
With this change, it is no longer necessary to cast a pointer to
unsigned long when passing it to `hexdump32()`.
The same change for the function `hexdump()` was done in commit
3dd0e72d [1].
lib/hexdump: Take const void * and size_t as arguments
[1] http://review.coreboot.org/4575
Change-Id: Id97f5daff95f94e862ee8b5be896a6629b125a13
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/5646
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
A global flag oprom_is_loaded was used to indicate to
U-boot that VGA option ROM was loaded and run, or that
native VGA init was completed on GMA device.
Implement this feature without dependency to CHROMEOS option
and replace use of global variable oprom_is_loaded with call
to gfx_get_init_done().
Change-Id: I7e1afd752f18e5346dabdee62e4f7ea08ada5faf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4309
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We have means to easily disable a specific console in romstage if
necessary, so this global option makes little sense.
The option was initially introduced as a work-around for build issues
around CACHE_AS_RAM, ROMCC and ARCH_ARMV7 dependencies for UARTs.
Change-Id: I797bdd11a48ddd813d3ee7ccef9a0c050f16f669
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5607
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The port for console remains to be a compile time constant.
The Kconfig option is changed to select an UART port with index
to avoid putting map of UART base addresses in Kconfigs.
With this change it is possible to have other than debug console
on different UART port.
Change-Id: Ie1845a946f8d3b2604ef5404edb31b2e811f3ccd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5342
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There is redundancy in terms of use of init_timer. We have a Kconfig option to
decide whether a board has init_timer as well as we use a stub for init_timer in
places where we do not have any init_timer defined. Thus, remove the Kconfig
option. Henceforth, all boards that do not have init_timer functionality can
include a stub_timer if required.
Change-Id: I35d38ec686f4dc92861cf9248f9b540323cd98ae
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5569
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Fix compilation. Relying on the pre-processor to condition an if
statement will lead to warnings of implicitly defined functions. To
solve this dilemma add symbols to resolve to at compile time.
Change-Id: Id0117528c5579cc1dec750a8a17a76fab4314b3f
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5504
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Consoles on CBMEM and USB have somewhat complex rules and dependencies
when they can be active. Use simple variables to test which stage
of boot is being built for each console.
Change-Id: I2489e7731d07ca7d5dd2ea8b6501c73f05d6edd8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5341
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Provide simple environment variables telling which stage of boot is
being built. Also move this to arch-agnostic location.
Change-Id: I8cbb5cf91f53e01c06e7d672b5be3f5c235f911d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5410
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
These are potentially useful with GDB or SerialICE too.
Also it reduces the amount of actual code we put in romcc_console.
Change-Id: Id8c56e979660ad9f4eef39c648f68c7ec60edfba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5339
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Console is arch-agnostic and there is no need for separate
implementations for romstage and ramstage.
For SMM there is console only if DEBUG_SMI is selected.
Change-Id: I7028eeeff8bfbb9c8552972436b29a7508834d87
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5338
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This framework was only available in ramstage. So we had to define
console output functions separately for bootblock, romstage and SMM.
Follow-up patches will re-enable all the consoles removed here,
in a more flexible fashion, and with less lines-of-code and copy-paste.
Also the driver list is not in a well-defined order and some of the
loops could exit without visiting all drivers.
NOTE: This build has no console in ramstage.
Change-Id: Iaddc495aaca37e2a6c2c3f802a0dba27bf227a3e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5337
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This is the minimal setup needed to be able to execute SMI handlers.
Only support for ASEG handlers is added, which should be sufficient
for Trinity (up to 4 cores).
There are a few hacks which need to be introduced in generic code in
order to make this work properly, but these hacks are self-contained.
They are a not a result of any special needs of this CPU, but rather
from a poorly designed infrastructure. Comments are added to explain
how such code could be refactored in the future.
Change-Id: Iefd4ae17cf0206cae8848cadba3a12cbe3b2f8b6
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5493
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
Do this for symmetry with romstage_console.c.
Change-Id: If17acfc3da07b1dbefa87162c3c7168deb7b354a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5330
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
We do not need ROMCC support here and using wrappers for
console_tx_byte we can simplify this code.
Change-Id: I7f3b5acdfd0bde1d832b16418339dd5e232627e7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5334
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This gives us completely transparent low-level function to transmit
data.
Change-Id: I706791ff43d80a36a7252a4da0e6f3af92520db7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5336
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Do not expose console_tx_flush() to ChromeOS as that function
is part of lower-level implementation.
Change-Id: I1e31662da88a60e83f8e5d307a4b53441c130aab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5347
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Splitting the version prompt satisfies some requirements ROMCC
sets for the order in which we include source files. Also GDB
stub will need console hardware before entering main().
Change-Id: Ibb445a2f8cfb440d9dd69cade5f0ea41fb606f50
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5331
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
None of the PCI bridge management here is specific to the PCI UART
device/function. Also the Kconfig variable defaults are not globally
valid, fill samsung/lumpy with working values.
Change-Id: Id22631412379af1d6bf62c996357d36d7ec47ca3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5237
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Also fixes the reported baudrate to take get_option() into account.
Change-Id: Ieadad70b00df02a530b0ccb6fa4e1b51526089f3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5310
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Prepare low-level register access to take UART base address as a
parameter. This is done to support a list of base addresses defined
in the platform.
Change-Id: Ie630e55f2562f099b0ba9eb94b08c92d26dfdf2e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5309
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Start using the rmodtool for generating rmodules.
rmodule_link() has been changed to create 2 rules:
one for the passed in <name>, the other for creating
<name>.rmod which is an ELF file in the format of
an rmodule.
Since the header is not compiled and linked together
with an rmodule there needs to be a way of marking
which symbol is the entry point. __rmodule_entry is
the symbol used for knowing the entry point. There
was a little churn in SMM modules to ensure an
rmodule entry point symbol takes a single argument.
Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5379
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Fixing the location of the ram oops buffer can lead to certain
kernel and boot loaders being confused when there is a ram
reservation low in the address space. Alternatively provide
a mechanism to allocate the ram oops buffer in cbmem. As cbmem
is usually high in the address space it avoids low reservation
confusion.
The patch uncondtionally provides a GOOG9999 ACPI device with
a single memory resource describing the memory region used for
the ramoops region.
BUG=None
BRANCH=baytrail,haswell
TEST=Built and booted with and w/o dynamic ram oops. With
the corresponding kernel change things behave correctly.
Change-Id: Ide2bb4434768c9f9b90e125adae4324cb1d2d073
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5257
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order for userland to create rmodules the common code should be
shareable. Therefore, convert the short u<width> name types to the
posix uint<width>_t types. Additionally, move the definition of the
header structure to a new rmodule-defs.h header file so that userland
can include that without pulling in the coreboot state.
Change-Id: I54acd3bfd8c207b9efd50a3b6d89efd5fcbfc1d9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5363
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This preprocessor guard was used to disable CBMEM console from
romstage of ROMCC boards. It unintentionally disabled it for ARM
too as they do not have CACHE_AS_RAM selected.
Option EARLY_CBMEM_INIT implies CAR migration which is required
to have CBMEM console in romstage. This change should have been
done in commit f8bf5a10 already, but we missed it.
Change-Id: I03e95183be0e78bc7dd439d5fef5b10e54966dc3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5356
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Information really contained in it is mostly the same as in type 1 tag.
However Linux uses type 2 to match hardware. Duplicate the info.
Change-Id: I75e13d764464053ecab4a833fbb83836cedf26e6
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5322
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Boot speeds can be sped up by mirroring the payload into
main memory before doing the actual loading. Systems that
would benefit from this are typically Intel ones whose SPI
are memory mapped. Without the SPI being cached all accesses
to the payload in SPI while being loaded result in uncacheable
accesses. Instead take advantage of the on-board SPI controller
which has an internal cache and prefetcher by copying 64-byte
cachelines using 32-bit word copies.
Change-Id: I4aac856b1b5130fa2d68a6c45a96cfeead472a52
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5305
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This is based on the RCBA configuration setup from haswell.
It handles PCI, BARs, IO, MMIO, and baytrail-specific IOSF.
I did not extend it to handle MSR yet but that would be another
potential register type.
There are a number of approaches to this kind of thing, but in the
end they have a lot of switch statements and a mass of #defines.
I'm not particularly set on any of the details so comments welcome.
BUG=chrome-os-partner:23635
BRANCH=rambi
TEST=emerge-rambi chromeos-coreboot-rambi
Change-Id: Ib873936ecf20fc996a8feeb72b9d04ddb523211f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175206
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4923
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
UARTs now have unified prototypes and can use a single entry
in the list of drivers for ramstage.
Change-Id: I315daaf9a83cfa60f1a270146c729907a1d6d45b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5308
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Existing code compiled serial communication and printk() for SMM
even when DEBUG_SMI was not selected.
Change-Id: Ic5e25cd7453cb2243f7ac592b093fba752a299f7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5142
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
NOTE: UART base for SMM continues to be broken, as it does not use
the address resource allocator has assigned.
Change-Id: I79f2ca8427a33a3c719adfe277c24dab79a33ef3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5235
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Do not pull in console hw-specific prototypes everywhere
with console.h as those are not needed for higher levels.
Move prototypes for UARTs next to other consoles.
Change-Id: Icbc9cd3e5bdfdab85d7dccd7c3827bba35248fb8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5232
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We should not have pc80/ includes in console/.
Change-Id: Id7da732b1ea094be01f45f9dbb49142f4e78f095
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5157
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Divisor is a function of requested baudrate, platform-specific
reference clock and amount of oversampling done on the UART reference.
Calculate this parameter with divisor rounded to nearest integer.
When building without option_table or when there is no entry for
baud_rate, CONFIG_TTYS0_BAUD is used for default baudrate.
For OxPCIe use of 4 MHz for reference was arbitrary giving correct
divisor for 115200 but somewhat inaccurate for lower baudrates.
Actual hardware is 62500000 with 16 times oversampling.
FIXME: Field for baudrate in lb_tables is still incorrect.
Change-Id: I68539738469af780fadd3392263dd9b3d5964d2d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5229
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Do not guard the file by CONFIG_CONSOLE_SERIAL8250 or
CONFIG_CONSOLE_SERIAL8250MEM or CONFIG_CONSOLE_SERIAL.
Don't do indirect includes for <uart8250.h>.
The config-specific options are already properly guarded, and there
is no need to guard the register and bit definitions.
Change-Id: I7528b18cdc62bc5c22486f037e14002838a2176e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4585
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
No one is interrogating the write_tables() return value. Therefore,
drop it.
Change-Id: I97e707f071942239c9a0fa0914af3679ee7a9c3c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5301
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
The get_lb_mem() is no longer used. Therefore, remove it.
Change-Id: I2d8427c460cfbb2b7a9870dfd54f4a75738cfb88
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5304
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Instead of packing and unpacking entries in lb_mem use
the bootmem infrastructure for performing sanity checks
during payload loading.
Change-Id: Ica2bee7ebb0f6bf9ded31deac8cb700aa387bc7a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5303
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The write_coreboot_table() in coreboot_table.c was already using
struct memrange for managing and building up the entries that
eventually go into the lb_memory table. Abstract that concept
out to a bootmem memory map. The bootmem concept can then be
used as a basis for loading payloads, for example.
Change-Id: I7edbbca6bbd0568f658fde39ca93b126cab88367
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5302
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The selfboot() function relied on global variables
within the selfboot.c compilation unit. Now that the
bounce buffer is a part of struct payload use a new
architecture-specific arch_payload_run() function
for jumping to the payload. selfboot() can then be
removed.
Change-Id: Icec74942e94599542148561b3311ce5096ac5ea5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5300
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order to break the dependency on selfboot for jumping to
payload the bounce buffer location needs to be communicated.
Therefore, add the bounce buffer to struct payload.
Change-Id: I9d9396e5c5bfba7a63940227ee0bdce6cba39578
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5299
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order to encapsulate more data for self loading use struct
payload as the type. That way modifications to what is needed
for payload loading does not introduce more global variables.
Change-Id: I5b8facd7881e397ca7de1c04cec747fc1dce2d5f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5298
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
A payload can be loaded either from a vboot region or from cbfs.
Provide a common place for choosing where the payload is loaded
from. Additionally, place the logic in the 'loaders' directory
similarly to the ramstage loader infrastructure.
Change-Id: I6b0034ea5ebd04a3d058151819ac77a126a6bfe2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5296
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
With the recent improvement 3d6ffe76f8,
speedup by CACHE_ROM is reduced a lot.
On the other hand this makes coreboot run out of MTRRs depending on
system configuration, hence screwing up I/O access and cache
coherency in worst cases.
CACHE_ROM requires the user to sanity check their boot output because
the feature is brittle. The working configuration is dependent on I/O
hole size, ram size, and chipset. Because of this the current
implementation can leave a system configured in an inconsistent state
leading to unexpected results such as poor performance and/or
inconsistent cache-coherency
Remove this as a buggy feature until we figure out how to do it properly
if necessary.
Change-Id: I858d78a907bf042fcc21fdf7a2bf899e9f6b591d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5146
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Struct dbgp_pipe would not be suitable for use with xHCI.
Just use an index, it is easy to setup in Kconfig if our
future debug setup has separate pipes for console
output and debugging/traceings.
Change-Id: Icbbd28f03113b208016f80217ab801d598d443a8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5227
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Certain CPUs require the default SMM region to be backed up
on resume after a suspend. The reason is that in order to
relocate the SMM region the default SMM region has to be used.
As coreboot is unaware of how that memory is used it needs to
be backed up. Therefore provide a common method for doing this.
Change-Id: I65fe1317dc0b2203cb29118564fdba995770ffea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5216
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
There are 2 methods currently available in coreboot to load
ramstage from romstage: cbfs and vboot. The vboot path had
to be explicitly enabled and code needed to be added to
each chipset to support both. Additionally, many of the paths
were duplicated between the two. An additional complication
is the presence of having a relocatable ramstage which creates
another path with duplication.
To rectify this situation provide a common API through the
use of a callback to load the ramstage. The rest of the
existing logic to handle all the various cases is put in
a common place.
Change-Id: I5268ce70686cc0d121161a775c3a86ea38a4d8ae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5087
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
These are almost one-to-one copies from pci_device.c. However,
devicetree has not been enumerated yet and we have no console.
Change-Id: Ic80c781626521d03adde05bdb1916acce31290ea
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5196
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Adding PCI functions for romstage in pci.h breaks ARMv7 build without
this. Also fix two related includes to use pci_def.h instead.
Change-Id: I5291eaf6ddf5a584f50af29cf791d2ca4d9caa71
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5199
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
We should not have x86 specific includes in lib/.
Change-Id: I18fa9c8017d65c166ffd465038d71f35b30d6f3d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5156
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Needs printk and is not a console core function.
Change-Id: Id90a363eca133af4469663c1e8b504baa70471e0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5155
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
There are EHCI compatible host controllers on ARM without PCI bus
architecture. Currently we have not come across one with the debug
capability though.
Change-Id: I8775c9814f6fdf8754f97265118a7186369d721d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5175
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Read from USB endpoint_in 8 bytes at a time, the maximum what
EHCI debug port capability has to offer.
Change-Id: I3d012d758a24b24f894e587b301f620933331407
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4700
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
LDN is 8-bit but coreboot squeezes unrelated info: VLDN in this field.
Increase to 16-bit to handle this.
Change-Id: I97af1b32dcfaed84980fa3aa4c317dfab6fad6d8
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5165
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Be more conservative and only add VGA devices' prefetchable
resources as write-combining in the address space. Previously
all prefetchable memory was added as a write-combining memory
type. Some hardware incorrectly advertises its BAR as
prefetchable when it shouldn't be.
A new memranges_add_resources_filter() function is added
to provide additional filtering on device and resource.
Change-Id: I3fc55b90d8c5b694c5aa9e2f34db1b4ef845ce10
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5169
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
Also prepare this console for use in romstage.
Change-Id: I26a4d4b5db1e44a261396a21bb0f0574d72aa86d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5136
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Also relocate and split header files, there is some interest
for EHCI debug support without PCI.
Change-Id: Ibe91730eb72dfe0634fb38bdd184043495e2fb08
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5129
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The memranges_update_tag() function replaces all instances
that are tagged with old_tag and update to new_tag. This
can be helpful in the MTRR code by adjusting the address
space if certain memory types cause the MTRR usage to
become too large.
Change-Id: Ie5c405204de2fdd9fd1dd5d6190b223925d6d318
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5150
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
In order for the cpu code to start SMM relocation 2 new
functions are added to be shared:
- void smm_initiate_relocation_parallel()
- void smm_initiate_relocation()
The both initiate an SMI on the currently running cpu.
The 2 variants allow for parallel relocation or serialized
relocation.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted rambi using these functions.
Change-Id: I325777bac27e9a0efc3f54f7223c38310604c5a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173982
Reviewed-on: http://review.coreboot.org/4891
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The Bay Trail SMM save state revision is 0x0100.
Add support for this save state area using the
type named em64t100_smm_state_save_area_t.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted using this structure with forthcoming CLs.
Change-Id: Iddd9498ab9fffcd865dae062526bda2ffcdccbce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173981
Reviewed-on: http://review.coreboot.org/4890
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Provide a common entry point for bringing up the APs
in parallel. This work is based off of the Haswell one
which can be moved over to this in the future. The APs
are brought up and have the BSP's MTRRs duplicated in
their own MTRRs. Additionally, Microcode is loaded before
enabling caching. However, the current microcode loading
support assumes Intel's mechanism.
The infrastructure provides a notion of a flight plan
for the BSP and APs. This allows for flexibility in the
order of operations for a given architecture/chip without
providing any specific policy. Therefore, the chipset
caller can provide the order that is required.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted on rambi with baytrail specific patches.
Change-Id: I0539047a1b24c13ef278695737cdba3b9344c820
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173703
Reviewed-on: http://review.coreboot.org/4888
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Haswell was the original chipset to store the cache
in another area besides CBMEM. However, it was specific
to the implementation. Instead, provide a generic way
to obtain the location of the ramstage cache. This option
is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
Kconfig option.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with baytrail support. Also built for
falco successfully.
Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172602
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4876
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This will make it possible for payloads to find the ACPI
NVS region which is needed to get base addresses for devices
that are in ACPI mode.
BUG=chrome-os-partner:24380
BRANCH=none
TEST=build and boot rambi with emmc in ACPI mode
Change-Id: Ia67b66ee8bd45ab8270444bbb2802080d31d14eb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179849
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5015
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The access to control registers were scattered about.
Provide a single header file to provide the correct
access function and definitions.
BUG=chrome-os-partner:22991
BRANCH=None
TEST=Built and booted using this infrastructure. Also objdump'd the
assembly to ensure consistency (objdump -d -r -S | grep xmm).
Change-Id: Iff7a043e4e5ba930a6a77f968f1fcc14784214e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172641
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4873
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
There are 3 places rmodule stages are loaded in the
existing code: cbfs and 2 in vboot_wrapper. Much of the
code is the same except for a few different cbmem entry
ids. Instead provide a common implementation in the
rmodule library itself.
A structure named rmod_stage_load is introduced to manage
the inputs and outputs from the new API.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted successfully.
Change-Id: I146055005557e04164e95de4aae8a2bde8713131
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174425
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4897
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
In order to identify the ram used in cbmem for
reference code blobs add common ids to be consumed
by downstream users.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted with ref code support. Noted reference
code entries in cbmem.
Change-Id: Iae3f0c2c1ffdb2eb0e82a52ee459d25db44c1904
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174424
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4896
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Romstage and ramstage can use 2 different values for the
amount of ROM to cache just under 4GiB in the address
space. Don't assume a cpu's romstage caching policy
for the ROM.
Change-Id: I689fdf4d1f78e9556b0bc258e05c7b9bb99c48e1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4846
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The tsc header is using u32 w/o including the file
with defines it.
Change-Id: I9fcad882d25e93b4c0032b32abd2432b0169a068
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4843
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
On Asus A8N-E this test fails but if failure is ignored keyboard works.
Change-Id: Ifeeff2f41537b35bc90a679f956fea830b94292c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4816
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
GRUB2-as-payload doesn't use them. Libpayload can live with just coreboot tables
if loaded as payload. memtest86+ can use them but is buggy with them. Solaris
needs a huge boot archive not supported by coreboot and too big to fit in
flash (dozens of megabytes). All-in-all looks like no users are left for this.
Change-Id: Id92f73be5a397db80f5b0132ee57c37ee6eeb563
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4628
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This function does not really initialize anything, but only
checks for the TOC.
Change-Id: I9d100d1823a0b630f5d1175e42a6a15f45266de4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4669
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The replacement function confirms CBMEM TOC is wiped clean on power
cycles and resets. It also introduces compatibility interface to ease
up transition to DYNAMIC_CBMEM.
Change-Id: Ic5445c5bff4aff22a43821f3064f2df458b9f250
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4668
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
The sequence to inject microcode updates is virtually the same for all
Intel CPUs. The same function is used to inject the update in both CBFS
and hardcoded cases, and in both of these cases, the microcode resides in
the ROM. This should be a safe change across the board.
The function which loaded compiled-in microcode is also removed here in
order to prevent it from being used in the future.
The dummy terminators from microcode need to be removed if this change is
to work when generating microcode from several microcode_blob.c files, as
is the case for older socketed CPUs. Removal of dummy terminators is done
in a subsequent patch.
Change-Id: I2cc8220cc4cd4a87aa7fc750e6c60ccdfa9986e9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4495
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
This change allows Kconfig options ROM_SIZE and CBFS_SIZE to be
set with values that are not power of 2. The region programmed
as WB cacheable will include all of ROM_SIZE.
Side-effects to consider:
Memory region below flash may be tagged WRPROT cacheable. As an
example, with ROM_SIZE of 12 MB, CACHE_ROM_SIZE would be 16 MB.
Since this can overlap CAR, we add an explicit test and fail
on compile should this happen. To work around this problem, one
needs to use CACHE_ROM_SIZE_OVERRIDE in the mainboard Kconfig and
define a smaller region for WB cache.
With this change flash regions outside CBFS are also tagged WRPROT
cacheable. This covers IFD and ME and sections ChromeOS may use.
Change-Id: I5e577900ff7e91606bef6d80033caaed721ce4bf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4625
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Representing a memory location as an unsigned long is specific to
32-bit architectures. It also doesn't make sense to represent a length
assumed to be positive as a signed integer. With this change, it is no
longer necessary to cast a pointer to unsigned long when passing it to
hexdump.
Change-Id: I641777d940ceac6f37c363051f1e9c1b3ec3ed95
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4575
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On x86, log2() is defined as an inline function in arch/io.h. This is
a remnant of ROMCC, and forced us to not include clog2.c in romstage.
As a result, romstage on ARM has no log2().
Use the inline log2 only with ROMCC, but otherwise, use the one in
clog2.c.
Change-Id: Ifef2aa0a7b5a1db071a66f2eec0be421b8b2a56d
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4681
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Remove sprintf as if you can't easily use snprintf then you probably
have buffer overflow.
Change-Id: Ic4570e099a52d743aca938a2bfadb95981adc503
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4280
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
snprintf is a safe variant of sprintf. To avoid buffer overflows
we shouldn't use sprintf at all. But for now let's start by
implementing snprintf in first place.
Change-Id: Ic17d94b8cd91b72f66b84b0589a06b8abef5e5c9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4278
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
CBMEM console buffer size is adjustable in menuconfig, but this would
not correctly adjust the overall allocation made for CBMEM.
HIGH_MEMORY_SIZE is aligned to 64kB and definitions are moved down in
the header file as HIGH_MEMORY_SIZE is not used with DYNAMIC_CBMEM.
Try to continue boot even if CBMEM cannot be created. This error would
only occur during development of new ports anyways and more log output
is better.
Change-Id: I4ee2df601b12ab6532ffcae8897775ecaa2fc05f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4621
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This function was for logging only, but we have both base and size
already logged elsewhere.
Change-Id: Ie6ac71fc859b8fd42fcf851c316a5f888f828dc2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4620
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Handler is ACPI/x86 specific so move details out of cbmem code.
With static CBMEM initialisation, ramstage will need to test for
S3 wakeup condition so publish also acpi_is_wakeup().
Change-Id: If591535448cdd24a54262b534c1a828fc13da759
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4619
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
This commit adds a new Kconfig option for the LynxPoint
southbridge that will have coreboot route all of the USB
ports to the XHCI controller in the finalize step (i.e.
after the bootloader) and disable the EHCI controller(s).
Additionally when doing this the XHCI USB3 ports need
to be put into an expected state on resume in order to make
the kernel state machine happy.
Part of this could also be done in depthcharge but there
are also some resume-time steps required so it makes sense
to keep it all together in coreboot.
This can theoretically save ~100mW at runtime.
Verify that the EHCI controller is not found in Linux and
that booting from USB still works.
Change-Id: I3ddfecc0ab12a4302e6034ea8d13ccd8ea2a655d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63802
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4407
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
If the firwmare is flashed and the MRC cache is blown away
then it is not possible to resume.
Right now this can be inferred from the event log but it can
be made very clear by adding a unique post code for this event.
1) boot falco
2) flash firmware
3) suspend and then resume
4) check for post code 0xef in log
0 | 2013-08-08 16:27:47 | Log area cleared | 4096
1 | 2013-08-08 16:27:47 | ACPI Enter | S3
2 | 2013-08-08 16:27:55 | System boot | 48
3 | 2013-08-08 16:27:55 | Last post code in previous boot | 0xef | Resume Failure
4 | 2013-08-08 16:27:55 | System Reset
5 | 2013-08-08 16:27:55 | ACPI Wake | S5
Change-Id: I7602d9eef85d3b764781990249ae32b84fe84134
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65259
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4458
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
- prints hex and ascii
- detects duplicate all zero lines
Change-Id: I557fed34f0f50ae256a019cf893004a0d6cbff7c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62655
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4392
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
... based on the EDID detailed timing values for
pixel_clock and link_clock.
Two undocumented registers 0x6f040 and 0x6f044 correspond to link_m and link_n
respectively. Other two undocumented registers 0x6f030 and 0x6f034 correspond
to data_m and data_n respectively.
Calculations are based on the intel_link_compute_m_n from linux kernel.
Currently, the value for 0x6f030 does not come up right with our calculations.
Hence, set to hard-coded value.
Change-Id: I40ff411729d0a61759164c3c1098504973f9cf5e
Reviewed-on: https://gerrit.chromium.org/gerrit/62915
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/4381
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Calculating the CRC of a SPD may be useful by itself, so split that
part of the code in a separate function.
Change-Id: I6c20d3db380551865126fd890e89de6b06359207
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4537
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
CPU_MICROCODE_IN_CBFS was designed to mean that loading microcode updates
from a CBFS file is supported, however, the name implies that microcode is
present in CBFS. This has recently caused confusion both with contributions
from Google, as well as SAGE. Rename this option to
SUPPORT_CPU_UCODE_IN_CBFS in order to make it clearer that what is meant is
"hey, the code we have for this CPU supports loading microcode updates from
CBFS", and prevent further confusion.
Change-Id: I394555f690b5ab4cac6fbd3ddbcb740ab1138339
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4482
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
Now that we have horizontal display areas that are not multiples of 32 bytes,
things are more complex. We add three struct members (x, y resolution and
bytes per line) which are to be filled in by the mainboard as it sets the mode.
In future, the EDID code may take a stab at initializing these but the values are
context-dependent.
Change-Id: Ib9102d6bbf8c66931f5adb1029a04b881a982cfe
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60514
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4336
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
No ROMCC involved, no need to include .c files in romstage.c.
Change-Id: I8a2aaf84276f2931d0a0557ba29e359fa06e2fba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4501
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
walkcbfs() is used only with ROMCC. Besides finding stages during the
bootblock, it's also used when applying microcode updates during the
bootblock phase. The function used to return only a pointer to the data of
the CBFS file, while making the header completely inaccessible. Since the
header contains the length of the CBFS file, the caller did not have a way
to know how long the data was. Then, other conventions had to be used to
determine the EOF, which might present problems if the user replaces the
CBFS file. This is not an issue when jumping to a stage (romstage), but can
present problems when accessing a microcode file which has not been
NULL-terminated.
Refactor walkcbfs_asm to return a pointer to the CBFS file header rather
than the data. Rename walkcbfs() to walkcbfs_head(), and reimplement a new
walkcbfs() based on walkcbfs_head(). Thus current usage of walkcbfs()
remains unaffected.
The code has been verified to run successfully under qemu.
Subsequent patches will change usage of walkcbfs() to walkcbfs_head where
knowing the length of the data is needed.
Change-Id: I21cbf19e130e1480e2749754e5d5130d36036f8e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4504
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It was suggested to eliminate the lock for sprintf. One way to do it is
to make the fake tx_byte into a closure. This patch allows it.
It's a bit tricky since we need to preserve compatibility with romcc.
Change-Id: I877ef0cef54dcbb0589fe858c485f76f3dd27ece
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4287
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add support for Sandybridge and Ivybridge using the Intel FSP.
The FSP is different enough to warrant its own source files.
This source handle the majority of FSP interaction.
"Intel® Firmware Support Package (Intel® FSP) provides key
programming information for initializing Intel® silicon and can be
easily integrated into a boot loader of the developer’s choice.
It is easy to adopt, scalable to design, reduces time-to-market, and
is economical to build."
http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
Change-Id: Ib879c6b0fbf2eb1cbf929a87f592df29ac48bcc5
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4015
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This was used by Ron 13ys ago and was never used again
ever since.
Change-Id: I8ae8a570d67fa0b34b17c9e3709845687f73c724
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59320
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4256
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Now that there is a clearly defined boot state machine
we can add some useful post codes to indicate the current
point in the state machine by having it log a post code
before the execution of each state.
This removes the currently defined POST codes that were
used by hardwaremain in favor of a new contiguous range
that are defined for each boot state.
The reason for this is that the existing codes are mostly
used to indicate when something is done, which is confusing
for actual debug because POST code debugging relies on knowing
what is about to happen (to know what may be at fault) rather
than what has just finished.
One additonal change is added during device init step as this
step often does the bulk of the work, and frequently logs POST
codes itself. Therefore in order to keep better track of what
device is being initialized POST_BS_DEV_INIT is logged before
each device is initialized.
interrupted boot with reset button and
gathered the eventlog. Mosys has been extended to
decode the well-known POST codes:
26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset
Change-Id: Ida1e1129d274d28cbe8e49e4a01483e335a03d96
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58106
Reviewed-on: http://review.coreboot.org/4231
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
One of the most common hangs during coreboot execution
is during ramstage device init steps. Currently there
are a set of (somewhat misleading) post codes during this
phase which give some indication as to where execution
stopped, but it provides no information on what device
was actually being initialized at that point.
This uses the new CMOS "extra" log banks to store the
encoded device path of the device that is about to be
touched by coreboot. This way if the system hangs when
talking to the device there will be some indication where
to investigate next.
interrupted boot with reset button and
gathered the eventlog after several test runs:
26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset
Change-Id: I6045bd4c384358b8a4e464eb03ccad639283939c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58105
Reviewed-on: http://review.coreboot.org/4230
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This can be used to indicate sub-state within a POST
code range which can assist in debugging BIOS hangs.
For example this can be used to indicate which device
is about to be initialized so if the system hangs
while talking to that device it can be identified.
Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58104
Reviewed-on: http://review.coreboot.org/4229
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Change-Id: Ida98f81b1ac1f6b3ba16c0b98e5c64756606fd58
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48318
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4126
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This function will encode the device path into 3
bytes of a dword which can be saved for debug.
It will be used by subsequent commit to store the
current device into CMOS for debugging BIOS hangs.
Change-Id: I3a5155ea53c8d280806e610a0f8998dbabe15f3c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58103
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4228
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Do not return hardcoded numerical values to communicate succes/failure, but
instead use an enumeration.
Change-Id: I742b08796adf136dce5984b702533f91640846dd
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4265
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The idea is that instead of:
if (do_something()) do_something_else();
It is more readable to write:
if (do_something() != CB_SUCCESS) handle_error();
Change-Id: I4fa5a6f2d2960cd747fda6602bdfff6aef08f8e2
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4264
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Mainboards were defining their own SMBIOS type41
write function. Instead pull this into the generic
SMBIOS code and change the existing mainboards to
make use of it.
Change-Id: I3c8a95ca51fe2a3118dc8d1154011ccfed5fbcbc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56619
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4187
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In the process of getting rid of compiler includes during in coreboot
and libpayload, we defined size_t and ssize_t ourselves, using a GCC
macro for size_t: __SIZE_TYPE__. Unfortunately, there is no
__SSIZE_TYPE__, so we temporarily redefine unsigned to signed to make
__SIZE_TYPE__ __SSIZE_TYPE__.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I4cf4eb0fdaa4db64277c2585fe2c1bdc0acdf02b
Reviewed-on: https://gerrit.chromium.org/gerrit/49947
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4156
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The EC saves its last "shutdown reason" for the system in EC RAM
that we can read back and log on boot.
The decode for the "reason" field will be added to mosys.
Change-Id: I834d39122e45262ef8e7ba59201accbee5857aac
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48323
Reviewed-by: David James <davidjames@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4127
Tested-by: build bot (Jenkins)
the part !CAR && PRE_RAM is obviously meant as dummies. Unfortunately
cbmemc_tx_byte has wrong number of arguments and hence causes compilation
failure.
Found out when compiling for vexpress-a9.
Change-Id: Ic84d142bac5c455c2371fbc9439c898de04a974e
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4267
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
With the LynxPoint chipset there are more than 16
possible GPIOs that can trigger an SMI so we need
a mainboard handler that can support this.
There are only a handful of users of this function
so just change them all to use the new prototype.
Change-Id: I3d96da0397d6584f713fcf6003054b25c1c92939
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49530
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4145
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The code is wrong (it's calling ntohl on an entry point that is actually
already le due to an old cbfs bug) and nothing calls it any more anyway.
Change-Id: Ief2c33faf99e3d2fc410524a5aae7bde378f088b
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/4090
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Make manufacturer, product_name and uuid smbios fields (type 1)
configurable at runtime, simliar to version and serial number.
Change-Id: Ibc826225e31fa42aa944fa43632dd6a406d5c85d
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/4085
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add a function to display memory locations in the console
logfile.
Change-Id: Iddb8d2e7a24357075f32c2fdf7916ae7a732247d
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4013
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Many chipset devices require additional configuration after
device init. It is not uncommmon for a device early in the devicetree
list to need to change a setting after a device later in the tree does
PCI init. A final function call has been added to device ops to handle
this case. It is called prior to coreboot table setup.
Another problem that is often seen is that the chipset or mainboard
need to do some final cleanup just before loading the OS. The chip
finalize has been added for this case. It is call after all coreboot
tables are setup and the payload is ready to be called.
Similar functionality could be implemented with the hardwaremain
states, but those don't fit well in the device tree function pointer
structure and should be used sparingly.
Change-Id: Ib37cce104ae41ec225a8502942d85e54d99ea75f
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4012
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Header file is not compatible with romcc, just drop it as a romstage
built with romcc cannot use usbdebug anyway.
Change-Id: If7f8f22d6a8fa1f02157df281f82f02b72b6a609
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4006
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
As boards without EARLY_CBMEM_INIT do not initialize CBMEM in romstage,
and have no CAR migration, these features are available for ramstage only.
Change-Id: Ic3f77ccdedd4e71ba693619c02c9b98b328a0882
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3970
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
If romstage does not make cbmem_initialize() call, linker should
optimize the code for CAR migration away.
This simplifies design of CBMEM console by a considerable amount.
As console buffer is now migrated within cbmem_initialize() call there
is no longer need for cbmemc_reinit() call made at end of romstage.
Change-Id: I8675ecaafb641fa02675e9ba3f374caa8e240f1d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3916
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
These features depend on CAR_GLOBAL region, which is not available
when romstage is built with ROMCC. Exclude these from romstage, keep
them available for ramstage.
A follow-up patch will fix the dependencies and allows enabling these
features in menuconfig.
Change-Id: I9de5ad41ea733655a3fbdc734646f818e39cc471
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3919
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
This retrieves back the value stored with store_initial_timestamp()
in the bootblock for southbridge.
Change-Id: I377c823706c33ed65af023d20d2e4323edd31199
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3908
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Old name was too much x86.
All external references have been removed.
Change-Id: I982b9abfcee57a7ea421c245dadb84342949efae
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3906
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The parameters can be dropped as initialisation always happens for
the region resolved with cbmem_locate_table().
This is no longer referenced externally, make it static.
Change-Id: Ia40350a5232dcbf30aca7b5998e7995114c44551
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3565
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Function is always called with get_top_of_ram() - HIGH_MEMORY_SIZE
which equals cbmem_base, thus no need to pass it as a parameter.
Change-Id: If026cb567ff534716cd9200cdffa08b21ac0c162
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3564
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Kyösti Mälkki