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>
AMD northbridges have a complex way to resolve top_of_ram.
Once it is resolved, it is stored in NVRAM to be used on resume.
TODO: Redesign these get_top_of_ram() functions from scratch.
Change-Id: I3cceb7e9b8b07620dacf138e99f98dc818c65341
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3557
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
For both romstage and ramstage, this calls an arch-specific function
get_cbmem_table() to resolve the base and size of CBMEM region. In ramstage,
the result is cached as the query may be relatively slow involving multiple PCI
configuration reads.
For x86 CBMEM tables are located right below top of low ram and
have fixed size of HIGH_MEMORY_SIZE in EARLY_CBMEM_INIT implementation.
Change-Id: Ie8d16eb30cd5c3860fff243f36bd4e7d8827a782
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3558
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This helper function is for compatibility only for chipsets that do
not implement get_top_of_ram() to support early CBMEM.
Also remove references to globals high_tables_base and _size under
arch/ and from two ARMv7 boards.
Change-Id: I17eee30635a0368b2ada06e0698425c5ef0ecc53
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3902
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
We can postpone the call to set_top_of_ram_once() outside the
loops and make just one call instead.
As set_top_of_ram() is now only called once, it is no longer
necessary to check if high_tables_base was already set.
Change-Id: I302d9af52ac40c7fa8c7c7e65f82e00b031cd397
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3895
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Prepare for removal of globals high_tables_base and _size
by replacing the references with a helper function.
Added set_top_of_ram_once() may be called several times,
but only the first call (with non-zero argument) takes effect.
Change-Id: I5b5f71630f03b6a01e9c8ff96cb78e9da03e5cc3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3894
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
If we already initialized EHCI controller and USB device in romstage,
locate active configuration from salvaged CAR_GLOBAL and avoid doing
the hardware initialisation again.
Change-Id: I7cb3a359488b25abc9de49c96c0197f6563a4a2c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3476
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Nowadays, chipsets or boards do not only have one USB port with the
capabilities of a debug port but several ones. Some of these ports are
easier accessible than others, so making them configurable is also necessary.
This change adds infrastructure to switch between EHCI controllers,
but does not implement it for any chipset.
Change-Id: I079643870104fbc64091a54e1bfd56ad24422c9f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3438
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Add a function to test if pci_devfn_t matches with a device
instance of struct device, by comparing bus:dev.fn.
Change-Id: Ic6c3148ac62c7183246d83302ee504b17064c794
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3474
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Declare the functions that may be used in both romstage and ramstage
with simple device model. This will later allow to define PNP access
functions for ramstage using the inlined functions from romstage.
Change-Id: I2a0bd8194acaf9c4c7252a29376eec363397e3a6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3871
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Declare the functions that may be used in both romstage and ramstage
with simple device model. This will later allow to define PCI access
functions for ramstage using the inlined functions from romstage.
Change-Id: I32ff622883ceee4628e6b1b01023b970e379113f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3508
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Instead of returning 0 on success and -1 on error, return the decompressed
size of the data on success and 0 on error. The decompressed size is useful
information to have that was being thrown away in that function.
Change-Id: If787201aa61456b1e47feaf3a0071c753fa299a3
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3578
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This module uses cim_verb_data to detect and initialize HD audio
codecs.
The module source code is based on southbridge/intel/sch/audio.c and
southbridge/nvidia/mcp55/azalia.c.
Change-Id: I810fef6fdcf55d66f62da58c3d7d99f006559d6e
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3844
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
src/arch/x86/boot/tables.c and src/include/device/pci_ids.h are also
changed because these two files depend on F16kb northbridge macros
Change-Id: Iedc842f0b230826675703fc78ed8001a978319c5
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Bruce Griffith <bruce.griffith@se-eng.com>
Tested-by: Bruce Griffith <bruce.griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3782
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Change-Id: I4a1d2118aeb2895f3c2acea5e792fbd69c855156
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Mike Loptien <mike.loptien@se-eng.com>
Tested-by: Bruce Griffith <bruce.griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3781
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
The tests for __PRE_RAM__ or __SMM__ were repeatedly used
for detection if dev->ops in the devicetree are not available
and simple device model functions need be used.
If a source file build for ramstage had __PRE_RAM__ inserted
at the beginning, the struct device would no longer match the
allocation the object had taken. This problem is fixed by
replacing such cases with explicit __SIMPLE_DEVICE__.
Change-Id: Ib74c9b2d8753e6e37e1a23fcfaa2f3657790d4c0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3555
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Taking device_t as a parameter, this allows to alter the PCI config
access handlers. This is useful to add tracing of PCI config writes
for devices having problems to initialise correctly.
On older AMD platform PCI MMIO may not be able to fully configure all
PCI devices/nodes, while MMIO_SUPPORT_DEFAULT would be preferred due
to its atomic nature. So those can be forced to IO config instead.
Change-Id: I2162884185bbfe461b036caf737980b45a51e522
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3608
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Refactor the structure to better support receive and another
set of endpoints over usbdebug.
Change-Id: Ib0f76afdf4e638363ff30c67010920142c58f250
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3726
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Move ehci_debug_info allocation from console to lib, as console code
was only built for ramstage.
Implement dbgp_ehci_info() to return the EHCI context. Alread alias this
as dbgp_console_input() and _output() to return the console stream context
later on.
Change-Id: Id6cc07d62953f0466df61eeb159e22b0e3287d4e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3625
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Output to usbdebug console needs to be disabled until hardware is
initialized and while EHCI BAR is relocated. Add separate field
ehci_info to point to back to EHCI context when hardware is ready
to transfer data.
Change-Id: If7d441b561819ab8ae23ed9f3f320f7742ed231e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3624
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Data is intended to be a byte array, so it should be described by a type which
has a fixed size equal to an 8 bit byte. Also, the data passed to write
shouldn't be modified and can be const.
Change-Id: I6466303d962998f6c37c2d4006a39c2d79a235c1
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3721
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
Change-Id: I68ae3fcb4d828fa8a328a30001c23c81a4423bb8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3671
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This stuff is not used, so let's drop it.
Change-Id: I671a5e87855b4c59622cafacdefe466ab3d70143
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3660
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When starting the Exynos5250 port, a lot of unneeded u-boot code
was imported. This is an attempt to get rid of a lot of unneeded
code before the port is used as a basis for further ARM ports.
There is a lot more that can be done, including cleaning up the
5250's Kconfig file.
Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3642
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
... and drop the wrapper on ARMv7
Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3639
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We've got enough of a handle on this to realize some things:
drm_dp_helper.h is by design device and architecture independent
i915.h is common to most intel graphics chipsets going back several years
i915_reg.h is as well
Move these files to src/include/device, and adjust the .c files accordingly.
Change-Id: I07512b3695fea0b22949074b467986420783d62a
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3637
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add three functions to edid.c:
void set_vbe_mode_info_valid(struct edid *edid, uintptr_t fb_addr)
takes an edid and uintptr_t, and fills in a static lb_framebuffer struct
as well as setting the static vbe_valid to 1 unless some problem
is found in the edid. The intent here is that this could be called from
the native graphics setup code on both ARM and x86.
int vbe_mode_info_valid(void)
returns value of the static vbe_valid.
void fill_lb_framebuffer(struct lb_framebuffer *framebuffer)
copies the static edid_fb to lb_framebuffer.
There is now a common vbe.h in src/include, removed the two special ones.
In general, graphics in coreboot is a mess, but graphics is always a
mess. We don't have a clean way to try two different ways to turn on
a device and use the one that works. One battle at a time. Overall,
things are much better.
The best part: this code would also work for ARM, which also uses EDID.
Change-Id: Id23eb61498b331d44ab064b8fb4cb10f07cff7f3
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3636
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
All the additional work that needs to be done in EHCI BAR relocation
is independent of the hardware platform and was functionally identical
in all the copies removed.
When USBDEBUG is not selected, PCI EHCI controllers use standard
pci_dev_read_resources() call.
With USBDEBUG selected, PCI EHCI controller's device_operations
.read_resources is replaced with pci_ehci_read_resources() call,
which in turn will replace the device_operations .set_resources call.
The replacement for .set_resources reconfigures usbdebug driver side,
and calls the original .set_resources to configure hardware side.
Change-Id: I8e136a5da4efedf60b6dd7068c0488153efaaf8e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3412
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The IOMMU AGESA needs a reserved scratch space and it wants
to allocate the stuff for runtime. So provide a simple
allocator for 4 KB CBMEM page.
Change-Id: I53bdfcd2cd69f84fbfbc6edea53a051f516c05cc
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/3315
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
For IOMMU we need to allocate a 512 KB BAR in a non-standard
location. Use the standard allocator for that and limit the BAR
to 32-bits to be compatible with older systems.
Change-Id: I44414ce6b264b7f1c086a9b1c7ea275a0830205e
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3314
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Many super i/o chips only answer to PnP requests if they are in a
configuration state (sometimes also called ext func mode). To cope with
that, the code of many chips implements its own version of our default
PnP functions like pnp_set_resource(), pnp_enable_resource() etc.
To avoid this code duplication, this patch extends our PnP device
interface with optional functions to enter and exit configuration mode.
Change-Id: I9b7662a0db70ede93276764fa15020f251eb46bd
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3481
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The current default implementation of pnp_enable() only disables devices
- if set so in the devicetree - but does not enable them. Enablement takes
place in pnp_enable_resources(). Yet, many PnP chips implement their own
version of pnp_enable() which also enables devices if set in the devicetree.
It's arguable, if enabling those devices makes sense, before they get
resources assigned. Maybe we can't write the resource registers if not,
who knows? The least we can do is providing a common implementation for
this behavior, and get rid of some code duplication.
Used the following cocci:
@@
expression e;
@@
+pnp_alt_enable(e);
-pnp_set_logical_device(e);
(
-pnp_set_enable(e, !!e->enabled);
|
-(e->enabled) ? pnp_set_enable(e, 1) : pnp_set_enable(e, 0);
|
-if (e->enabled) { pnp_set_enable(e, 1); }
-else { pnp_set_enable(e, 0); }
)
Change-Id: I8d695e8fcd3cf8b847b1aa99326b51a554700bc4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3480
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch provides the correct SD controller timings for
the Family16 device. It also will remove the SD controller
from PCI space when device 0:14.7 is set to off in devicetree.
This was tested on a AMD Parmer board and a AMD G-series SOC
reference board. The settings were found in the AMD
Hudson2 RRG and family16 BKGD.
Change-Id: I6d7e7997ddc39802ab75dc8a211ed29f028c0471
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3348
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In some cases, we want a ram_check that does not die and does not
clobber the terminal with useless output that slows us down a lot.
Usage examples include Checking if the RAM is up at the start of
raminit, or checking if each rank is accessible as it is being
initialized.
As with all other ram_checks, this is more of a "Is my DRAM properly
configured?" test, which is exactly what we want for something to use
during memory initialization.
Change-Id: I95d8d9a2ce1e29c74ef97b90aba0773f88ae832c
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3416
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When I've first written this macro in 2011, the correct define for
verbose SMBus message was CONFIG_DEBUG_SMBUS_SETUP. This has since
been changed to CONFIG_DEBUG_SMBUS. I didn't catch that, and this made
the printsmbus macro always evaluate to an empty statement.
Use the proper CONFIG_DEBUG_SMBUS define. This makes printsmbus
functional again.
Change-Id: Iaf03354b179cc4a061e0b65f5b746af10f5d2b88
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3379
Tested-by: build bot (Jenkins)
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Early SMBUS code with similar functionality is duplicated for all
southbridges. Add a generic SMBus API (function declarations) designed to
unify the early SMBus structure.
This patch only adds the API. It does not implement any hardware-specific
bits.
Change-Id: I0861b7a3f098115182ae6de9f016dd671c500bad
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/143
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
MRS commands are used to tell the DRAM chip what timing and what
termination and drive strength to use, along with other parameters.
The MRS commands are defined by the DDR3 specification [1]. This
makes MRS commands hardware-independent.
MRS command creation is duplicated in various shapes and forms in any
chipset that does DDR3. This is an effort to create a generic MRS API
that can be used with any chipset.
This is used in the VX900 branch.
[1] www.jedec.org/sites/default/files/docs/JESD79-3E.pdf
Change-Id: Ia8bb593e3e28a5923a866042327243d798c3b793
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3354
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This file was missing some definitions, so add them. Also turn the defines
into an enum. The reason for doing this is that functions can now
explicitly take an spd_memory_type as a parameter:
> int do_something_with_dram(enum spd_memory_type type, ...)
Which is a lot more explicit and readable than:
> int do_something_with_dram(u8 type, ...)
These are used in the VX900 branch.
Change-Id: Ic7871e82c2523a94eac8e07979a8e34e0b459b46
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3266
Tested-by: build bot (Jenkins)
Probably due to different (character) widths for a tab, sometimes only
one tab was used for aligning the define `CPU_ID_EXT_FEATURES_MSR`. For
the “correct” alignment, that means where a tab is eight characters,
two tabs are necessary. Change it accordingly.
Change-Id: I450a7796dc00b934b5a6bab8642db04a27f69f4b
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3263
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
multiply_to_tsc was being copied everywhere, which is bad
practice. Put it in the tsc.h include file where it belongs.
Delete the copies of it.
Per secunet, no copyright notice is needed.
This might be a good time to get a copyright notice into tsc.h
anyway.
Change-Id: Ied0013ad4b1a9e5e2b330614bb867fd806f9a407
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3242
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There are some boards that do a significant amount of
work after cache-as-ram is torn down but before ramstage
is loaded. For example, using vboot to verify the ramstage
is one such operation. However, there are pieces of code
that are executed that reference global variables that
are linked in the cache-as-ram region. If those variables
are referenced after cache-as-ram is torn down then the
values observed will most likely be incorrect.
Therefore provide a Kconfig option to select cache-as-ram
migration to memory using cbmem. This option is named
CAR_MIGRATION. When enabled, the address of cache-as-ram
variables may be obtained dynamically. Additionally,
when cache-as-ram migration occurs the cache-as-ram
data region for global variables is copied into cbmem.
There are also automatic callbacks for other modules
to perform their own migration, if necessary.
Change-Id: I2e77219647c2bd2b1aa845b262be3b2543f1fcb7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3232
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The cooperative multitasking support allows the boot state machine
to be ran cooperatively with other threads of work. The main thread
still continues to run the boot state machine
(src/lib/hardwaremain.c). All callbacks from the state machine are
still ran synchronously from within the main thread's context.
Without any other code added the only change to the boot sequence
when cooperative multitasking is enabled is the queueing of an idlle
thread. The idle thread is responsible for ensuring progress is made
by calling timer callbacks.
The main thread can yield to any other threads in the system. That
means that anyone that spins up a thread must ensure no shared
resources are used from 2 or more execution contexts. The support
is originally intentioned to allow for long work itesm with busy
loops to occur in parallel during a boot.
Note that the intention on when to yield a thread will be on
calls to udelay().
Change-Id: Ia4d67a38665b12ce2643474843a93babd8a40c77
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3206
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This continues the work done in patch 6b908d08abhttp://review.coreboot.org/#/c/1685/
and makes the early x86 post codes follow the same options.
Change-Id: Idf0c17b27b3516e79a9a53048bc203245f7c18ff
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3237
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This option has never had much if any use. It solved a problem over 10
years ago that resulted from an argument over the value or lack thereof
of including all the debug strings in a coreboot image. The answer is
in: it's a good idea to maintain the capability to print all messages,
for many reasons.
This option is also misleading people, as in a recent discussion, to
believe that log messges are controlled at build time in a way they are
not. For the record, from this day forward, we can print messages at all
log levels and the default log level is set at boot time, as directed by
DEFAULT_CONSOLE_LOGLEVEL. You can set the default to 0 at build time and
if you are having trouble override it in CMOS and get more messages.
Besides, a quick glance shows it's always set to max (9 in this case) in
the very few cases (1) in which it is set.
Change-Id: I60c4cdaf4dcd318b841a6d6c70546417c5626f21
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3188
Tested-by: build bot (Jenkins)
In the process of streamlining coreboot code and getting
rid of unneeded ifdefs, drop a number of unneeded checks
for the GNU C compiler. This also cleans up x86emu/types.h
significantly by dropping all the duplicate types in there.
Change-Id: I0bf289e149ed02e5170751c101adc335b849a410
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3226
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Commit "romcc: Don't fail on function prototypes" (11a7db3b) [1]
made romcc not choke on function prototypes anymore. This
allows us to get rid of a lot of ifdefs guarding __ROMCC__ .
[1] http://review.coreboot.org/2424
Change-Id: Ib1be3b294e5b49f5101f2e02ee1473809109c8ac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3216
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
it has been unused since 9 years or so, hence drop it.
Change-Id: I0706feb7b3f2ada8ecb92176a94f6a8df53eaaa1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3212
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The smm_handler_t type was added before the introduction
of the asmlinkage macro. Now that asmlinkage is available
use it.
Change-Id: I85ec72cf958bf4b77513a85faf6d300c781af603
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3215
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
In order to properly sequence the boot state machine it's
important that outside code can block the transition from
one state to the next. When timers are not involved there's
no reason for any of the existing code to block a state
transition. However, if there is a timer callback that needs to
complete by a certain point in the boot sequence it is necessary
to place a block for the given state.
To that end, 4 new functions are added to provide the API for
blocking a state.
1. boot_state_block(boot_state_t state, boot_state_sequence_t seq);
2. boot_state_unblock(boot_state_t state, boot_state_sequence_t seq);
3. boot_state_current_block(void);
4. boot_state_current_unblock(void);
Change-Id: Ieb37050ff652fd85a6b1e0e2f81a1a2807bab8e0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3204
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some boards use the local apic for udelay(), but they also provide
their own implementation of udelay() for SMM. The reason for using
the local apic for udelay() in ramstage is to not have to pay the
penalty of calibrating the TSC frequency. Therefore provide a
TSC_CONSTANT_RATE option to indicate that TSC calibration is not
needed. Instead rely on the presence of a tsc_freq_mhz() function
provided by the cpu/board. Additionally, assume that if
TSC_CONSTANT_RATE is selected the udelay() function in SMM will
be the tsc.
Change-Id: I1629c2fbe3431772b4e80495160584fb6f599e9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3168
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This re-introduces 2fde966 (http://review.coreboot.org/#/c/3177/)
which was reverted due to unsatisfied dependencies.
time.h We Hardly Knew Ye.
This deprecates time.h which is currently only used by Exynos5250 and
Snow. The original idea was to try and unify some of the various timer
interfaces and has been supplanted by the monotonic timer API.
timer_us() is now obsolete. timer_start() is now mct_start() and
is exposed in exynos5250/clk.h.
Change-Id: I8e60105629d9da68ed622e89209b3ef6c8e2445b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3201
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The current way to get a simple mono_time difference is:
1. Declare a rela_time struct
2. Assign it the value of mono_time_diff(t1, t2)
3. Get microseconds from it using rela_time_in_microseconds().
This patch adds a simpler method. Now one only needs to call
mono_time_diff_microseconds(t1, t2) to obtain the same value which
is produced from the above three steps.
Change-Id: Ibfc9cd211e48e8e60a0a7703bff09cee3250e88b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3190
Tested-by: build bot (Jenkins)
This reverts commit 2fde9668b4
Somehow this got merged before its dependencies. 3190 must be merged first, followed by 3176. However 3190 will fail while this patch is in. So the situation can't correct itself.
Reverting this until the other two go in.
Change-Id: I176f37c12711849c96f1889eacad38c00a8142c4
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3195
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
time.h We Hardly Knew Ye.
This deprecates time.h which is currently only used by Exynos5250 and
Snow. The original idea was to try and unify some of the various timer
interfaces and has been supplanted by the monotonic timer API.
timer_us() is now obsolete. timer_start() is now mct_start() and
is exposed in exynos5250/clk.h.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I14ebf75649d101491252c9aafea12f73ccf446b5
Reviewed-on: http://review.coreboot.org/3177
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A timer queue provides the mechanism for calling functions
in the future by way of a callback. It utilizes the MONOTONIC_TIMER
to track time through the boot. The implementation is a min-heap
for keeping track of the next-to-expire callback.
Change-Id: Ia56bab8444cd6177b051752342f53b53d5f6afc1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3158
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The notion of a monotonic timer is introduced. Along with it
are helper functions and other types for comparing times. This
is just the framework where it is the responsibility of the
chipset/board to provide the implementation of timer_monotonic_get().
The reason structs are used instead of native types is to allow
for future changes to the data structure without chaning all the
call sites.
Change-Id: Ie56b9ab9dedb0da69dea86ef87ca744004eb1ae3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3152
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The notion of loading a payload in the current boot state
machine isn't actually loading the payload. The reason is
that cbfs is just walked to find the payload. The actual
loading and booting were occuring in selfboot(). Change this
balance so that loading occurs in one function and actual
booting happens in another. This allows for ample opportunity
to delay work until just before booting.
Change-Id: Ic91ed6050fc5d8bb90c8c33a44eea3b1ec84e32d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3139
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On x86 systems there is a concept of cachings the ROM. However,
the typical policy is that the boot cpu is the only one with
it enabled. In order to ensure the MTRRs are the same across cores
the rom cache needs to be disabled prior to OS resume or boot handoff.
Therefore, utilize the boot state callbacks to schedule the disabling
of the ROM cache at the ramstage exit points.
Change-Id: I4da5886d9f1cf4c6af2f09bb909f0d0f0faa4e62
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3138
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The cbmem_post_handling() function was implemented by 2
chipsets in order to save memory configuration in flash. Convert
both of these chipsets to use the boot state machine callbacks
to perform the saving of the memory configuration.
Change-Id: I697e5c946281b85a71d8533437802d7913135af3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3137
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There were previously 2 functions, init_cbmem_pre_device() and
init_cbmem_post_device(), where the 2 cbmem implementations
implemented one or the other. These 2 functions are no longer
needed to be called in the boot flow once the boot state callbacks
are utilized.
Change-Id: Ida71f1187bdcc640ae600705ddb3517e1410a80d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3136
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Utilize the static boot state callback scheduling to initialize
and tear down the coverage infrastructure at the appropriate points.
The coverage initialization is performed at BS_PRE_DEVICE which is the
earliest point a callback can be called. The tear down occurs at the
2 exit points of ramstage: OS resume and payload boot.
Change-Id: Ie5ee51268e1f473f98fa517710a266e38dc01b6d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3135
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's helpful to provide a distinct state that affirmatively
describes that OS resume will occur. The previous code included
the check and the actual resuming in one function. Because of this
grouping one had to annotate the innards of the ACPI resume
path to perform specific actions before OS resume. By providing
a distinct state in the boot state machine the necessary actions
can be scheduled accordingly without modifying the ACPI code.
Change-Id: I8b00aacaf820cbfbb21cb851c422a143371878bd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3134
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Many of the boot state callbacks can be scheduled at compile time.
Therefore, provide a way for a compilation unit to inform the
boot state machine when its callbacks should be called. Each C
module can export the callbacks and their scheduling requirements
without changing the shared boot flow code.
Change-Id: Ibc4cea4bd5ad45b2149c2d4aa91cbea652ed93ed
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3133
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The boot flow currently has a fixed ordering. The ordering
is dictated by the device tree and on x86 the PCI device ordering
for when actions are performed. Many of the new machines and
configurations have dependencies that do not follow the device
ordering.
In order to be more flexible the concept of a boot state machine
is introduced. At the boundaries (entry and exit) of each state there
is opportunity to run callbacks. This ability allows one to schedule
actions to be performed without adding board-specific code to
the shared boot flow.
Change-Id: I757f406c97445f6d9b69c003bb9610b16b132aa6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3132
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
STRINGIFY makes a string from a token. It is generally useful.
Even though STRINGIFY is not defined to be in the C library it's
placed in string.h because it does make a string.
Change-Id: I368e14792a90d1fdce2a3d4d7a48b5d400623160
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3144
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Because pointers can be 32bit or 64bit big,
using them in the coreboot table requires the
OS and the firmware to operate in the same mode
which is not always the case. Hence, use 64bit
for all pointers stored in the coreboot table.
Guess we'll have to fix this up once we port to
the first 128bit machines.
Change-Id: I46fc1dad530e5230986f7aa5740595428ede4f93
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3115
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Add a microsecond timer, its declaration, the function to start it,
and its usage. To start it, one calls timer_start(). From that point
on, one can call timer_us() to find microseconds since the timer was
started.
We show its use in the bootblock. You want it started very early.
Finally, the delay.h change having been (ironically) delayed, we
create time.h and have it hold one declaration, for the timer_us() and
timer_start() prototype.
We feel that these two functions should become the hardware specific
functions, allowing us to finally move udelay() into src/lib where it
belongs.
Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3073
Tested-by: build bot (Jenkins)
This reverts commit 1fde22c54cacb15493bbde8835ec9e20f1d39bf5:
commit 1fde22c54c
Author: Patrick Georgi <patrick.georgi@secunet.com>
Date: Tue Apr 9 15:41:23 2013 +0200
siemens/sitemp_g1p1: Make ACPI report the right mmconf region
ACPI reported the entire space between top-of-memory and some
(relatively) arbitrary limit as useful for MMIO. Unfortunately
the HyperTransport configuration disagreed. Make them match up.
Other boards are not affected since they don't report any region
for that purpose at all (it seems).
Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3047
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It sneaked in without it's dependencies and, therefore, broke the build for
all amdk8 targets. Paul Menzel already commented on the issue in [1]. It
also doesn't look like the dependencies would be pulled soon [2].
[1] http://review.coreboot.org/#/c/3047/
[2] http://review.coreboot.org/#/c/2662/
Change-Id: Ica89563aae4af3f0f35cacfe37fb608782329523
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3063
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
ACPI reported the entire space between top-of-memory and some
(relatively) arbitrary limit as useful for MMIO. Unfortunately
the HyperTransport configuration disagreed. Make them match up.
Other boards are not affected since they don't report any region
for that purpose at all (it seems).
Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3047
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This re-factors the Exynos5 I2C code to be simpler and use the
new API, and updates users accordingly.
- i2c_read() and i2c_write() functions updated to take bus number
as an argument.
- Get rid of the EEPROM_ADDR_OVERFLOW stuff in i2c_read() and
i2c_write(). If a chip needs special handling we should take care
of it elsewhere, not in every low-level i2c driver.
- All the confusing bus config functions eliminated. No more
i2c_set_early_config() or i2c_set_bus() or i2c_get_bus(). All this
is handled automatically when the caller does a transaction and
specifies the desired bus number.
- i2c_probe() eliminated. We're not a command-line utility.
- Let the compiler place static variables automatically. We don't need
any of this fancy manual data placement.
- Remove dead code while we're at it. This stuff was ported early on
and much of it was left commented out in case we needed it. Some
also includes nested macros which caused gcc to complain.
- Clean up #includes (no more common.h, woohoo!), replace debug() with
printk().
Change-Id: I8e1f974ea4c6c7db9f33b77bbc4fb16008ed0d2a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3044
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The existing header was imported along with the Exynos code and left
mostly unchanged. This is the first patch in a series intended to
replace the imported u-boot I2C API with a much simpler and cleaner
interface:
- We only need to expose i2c_read() and i2c_write() in our public API.
Everything else is board/chip-dependent and should remain hidden
away.
- i2c_read and i2c_write functions will take bus number as an arg
and we'll eliminate i2c_get_bus and i2c_set_bus. Those are prone to
error and end up cluttering the code since the user needs to save
the old bus number, set the new one, do the read/write, and restore
the old value (3 added steps to do a simple transaction).
- Stop setting default values for board-specific things like SPD
and RTC bus numbers (as if we always have an SPD or RTC on I2C).
- Death to all the trivial inline wrappers. And in case there was any
doubt, we really don't care about the MPC8xx. Though if we did then
we would not pollute the public API with its idiosyncrasies.
Change-Id: I4410a3c82ed5a6b2e80e3d8c0163464a9ca7c3b0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3043
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Explicitly call out the effects of hyperthreads running the
MTRR code and its impact on the enablement of ROM caching.
Change-Id: I14b8f3fdc112340b8f483f2e554c5680576a8a7c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3018
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Based on comments in cpu/x86/msr.h for wrmsr/rdmsr, and for symmetry,
I have added __attribute__((always_inline)) for these.
Change-Id: Ia0a34c15241f9fbc8c78763386028ddcbe6690b1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2898
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The ACPI NVS region was setup in place and there was a CBMEM
table that pointed to it. In order to be able to use NVS
earlier the CBMEM region is allocated for NVS itself during
the LPC device init and the ACPI tables point to it in CBMEM.
The current cbmem region is renamed to ACPI_GNVS_PTR to
indicate that it is really a pointer to the GNVS and does
not actually contain the GNVS.
Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2970
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On certain architectures such as x86 the bootstrap processor
does most of the work. When CACHE_ROM is employed it's appropriate
to ensure that the caching enablement of the ROM is disabled so that
the caching settings are symmetric before booting the payload or OS.
Tested this on an x86 machine that turned on ROM caching. Linux did not
complain about asymmetric MTRR settings nor did the ROM show up as
cached in the MTRR settings.
Change-Id: Ia32ff9fdb1608667a0e9a5f23b9c8af27d589047
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2980
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Two convenience functions are added to operate on a range_entry:
- range_entry_update_tag() - update the entry's tag
- memranges_next_entry() - get the next entry after the one provide
These functions will be used by a follow on patch to the MTRR code
to allow hole punching in WB region when the default MTRR type is
UC.
Change-Id: I3c2be19c8ea1bbbdf7736c867e4a2aa82df2d611
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2924
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Downstream payloads may need to take advantage of caching the
ROM for performance reasons. Add the ability to communicate the
variable range MTRR index to use to perform the caching enablement.
An example usage implementation would be to obtain the variable MTRR
index that covers the ROM from the coreboot tables. Then one would
disable caching and change the MTRR type from uncacheable to
write-protect and enable caching. The opposite sequence is required
to tearn down the caching.
Change-Id: I4d486cfb986629247ab2da7818486973c6720ef5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2919
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The CONFIG_CACHE_ROM support in the MTRR code allocates an MTRR
specifically for setting up write-protect cachine of the ROM. It is
assumed that CONFIG_ROM_SIZE is the size of the ROM and the whole
area should be cached just under 4GiB. If enabled, the MTRR code
will allocate but not enable rom caching. It is up to the callers
of the MTRR code to explicitly enable (and disable afterwards) through
the use of 2 new functions:
- x86_mtrr_enable_rom_caching()
- x86_mtrr_disable_rom_caching()
Additionally, the CACHE_ROM option is exposed to the config menu so
that it is not just selected by the chipset or board. The reasoning
is that through a multitude of options CACHE_ROM may not be appropriate
for enabling.
Change-Id: I4483df850f442bdcef969ffeaf7608ed70b88085
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2918
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The memrange infrastructure allows for keeping track of the
machine's physical address space. Each memory_range entry in
a memory_ranges structure can be tagged with an arbitrary value.
It supports merging and deleting ranges as well as filling in
holes in the address space with a particular tag.
The memrange infrastructure will serve as a shared implementation
for address tracking by the MTRR and coreboot mem table code.
Change-Id: Id5bea9d2a419114fca55c59af0fdca063551110e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2888
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There wasn't an equivalent to align down so add ALIGN_DOWN.
For symmetry provide an ALIGN_UP macro as well.
Change-Id: I7033109311eeb15c8c69c649878785378790feb9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2951
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Certain MMIO resources can be set to a write-combining cacheable
mode to increase performance. Typical resources that use this would
be graphics memory.
Change-Id: Icd96c720f86f7e2f19a6461bb23cb323124eb68e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2891
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The IORESOURCE_UMA_FB and IORESOURCE_IGNORE_MTRR attributes
on a resource provided hints to the MTRR algorithm. The
IORESOURCE_UMA_FB directed the MTRR algorithm to setup a uncacheable
space for the resource. The IORESOURCE_IGNORE_MTRR directed
the MTRR algorithm to ignore this resource as it was used reserving
RAM space.
Now that the optimizing MTRR algorithm is in place there isn't a need
for these flags. All IORESOURCE_IGNORE_MTRR users are handled by the
MTRR code merging resources of the same cacheable type. The users
of the IORESOURCE_UMA_FB will find that the default MTRR type
calculation means there isn't a need for this flag any more.
Change-Id: I4f62192edd9a700cb80fa7569caf49538f9b83b7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2890
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The old MTRR code had issues using too many variable
MTRRs depending on the physical address space layout dictated
by the device resources. This new implementation calculates
the default MTRR type by comparing the number of variable MTRRs
used for each type. This avoids the need for IORESOURE_UMA_FB
because in many of those situations setting the default type to WB
frees up the variable MTTRs to set that space to UC.
Additionally, it removes the need for IORESOURCE_IGNORE_MTRR
becuase the new mtrr uses the memrange library which does merging
of resources.
Lastly, the sandybridge gma has its speedup optimization removed
for the graphics memory by writing a pre-determined MTRR index.
That will be fixed in an upcoming patch once write-combining support
is added to the resources.
Slight differences from previous MTRR code:
- The number of reserved OS MTRRs is not a hard limit. It's now advisory
as PAT can be used by the OS to setup the regions to the caching
policy desired.
- The memory types are calculated once by the first CPU to run the code.
After that all other CPUs use that value.
- CONFIG_CACHE_ROM support was dropped. It will be added back in its own
change.
A pathological case that was previously fixed by changing vendor code
to adjust the IO hole location looked like the following:
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
As noted by the output below it's impossible to accomodate those
ranges even with 10 variable MTRRS. However, because the code
can select WB as the default MTRR type it can be done in 6 MTRRs:
MTRR: default type WB/UC MTRR counts: 6/14.
MTRR: WB selected as default type.
MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0
MTRR: 3 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0
MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 5 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0
Change-Id: Idfcc78d9afef9d44c769a676716aae3ff2bd79de
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2889
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
mmio_resource() was previously being used for reserving
RAM from the OS by using IORESOURCE_IGNORE_MTRR atrribute.
Instead, be more explicit for those uses with
reserved_ram_resource(). bad_ram_resource() now calls
reserved_ram_resource(). Those resources are marked as cacheable
but reserved.
The sandybridge and haswell code were relying on the implementation
fo the MTRR algorithm's interaction for reserved regions. Instead
be explicit about what ranges are MMIO reserved and what are RAM
reserved.
Change-Id: I1e47026970fb37c0305e4d49a12c98b0cdd1abe5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2886
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The vboot module relied on being able to flush the console
after it called vtxprintf() from its log wrapper function.
Expose the console_tx_flush() function in romstage so the
vboot module can ensure messages are flushed.
Change-Id: I578053df4b88c2068bd9cc90eea5573069a0a4e8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2882
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The amd_mtrr.c file contains a copy of the fixed MTRR algorithm.
However, the AMD code needs to handle the RdMem and WrMem attribute
bits in the fixed MTRR MSRs. Instead of duplicating the code
with the one slight change introduce a Kconfig option,
X86_AMD_FIXED_MTRRS, which indicates that the RdMem and WrMem fields
need to be handled for writeback fixed MTRR ranges.
The order of how the AMD MTRR setup routine is maintained by providing
a x86_setup_fixed_mtrrs_no_enable() function which does not enable
the fixed MTRRs after setting them up. All Kconfig files which had a
Makefile that included amd/mtrr in the subdirs-y now have a default
X86_AMD_FIXED_MTRRS selection. There may be some overlap with the
agesa and socket code, but I didn't know the best way to tease out
the interdependency.
Change-Id: I256d0210d1eb3004e2043b46374dcc0337432767
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2866
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
coreboot tables are, unlike general system tables, a platform
independent concept. Hence, use the same code for coreboot table
generation on all platforms. lib/coreboot_tables.c is based
on the x86 version of the file, because some important fixes
were missed on the ARMv7 version lately.
Change-Id: Icc38baf609f10536a320d21ac64408bef44bb77d
Signed-off-by: Stefan Reinauer <reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/2863
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
The vboot_handoff structure contians the VbInitParams as well as the
shared vboot data. In order for the boot loader to find it, the
structure address and size needs to be obtained from the coreboot
tables.
Change-Id: I6573d479009ccbf373a7325f861bebe8dc9f5cf8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2857
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
For completeness add a vboot rmodule type since vboot will be
built as an rmodule.
Change-Id: I4b9b1e6f6077f811cafbb81effd4d082c91d4300
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2853
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The vboot firmware selection from romstage will need to
pass the resulting vboot data to other consumers. This will
be done using a cbmem entry.
Change-Id: I497caba53f9f3944513382f3929d21b04bf3ba9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2851
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Dynamic cbmem is now a requirement for relocatable ramstage.
This patch replaces the reserve_* fields in the romstage_handoff
structure by using the dynamic cbmem library.
The haswell code is not moved over in this commit, but it should be
safe because there is a hard requirement for DYNAMIC_CBMEM when using
a reloctable ramstage.
Change-Id: I59ab4552c3ae8c2c3982df458cd81a4a9b712cc2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2849
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Here's the great news: From now on you don't have to worry about
hitting the right io.h include anymore. Just forget about romcc_io.h
and use io.h instead. This cleanup has a number of advantages, like
you don't have to guard device/ includes for SMM and pre RAM
anymore. This allows to get rid of a number of ifdefs and will
generally make the code more readable and understandable.
Potentially in the future some of the code in the io.h __PRE_RAM__
path should move to device.h or other device/ includes instead,
but that's another incremental change.
Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch adds a parallel implementation of cbmem that supports
dynamic sizing. The original implementation relied on reserving
a fixed-size block of memory for adding cbmem entries. In order to
allow for more flexibility for adding cbmem allocations the dynamic
cbmem infrastructure was developed as an alternative to the fixed block
approach. Also, the amount of memory to reserve for cbmem allocations
does not need to be known prior to the first allocation.
The dynamic cbmem code implements the same API as the existing cbmem
code except for cbmem_init() and cbmem_reinit(). The add and find
routines behave the same way. The dynamic cbmem infrastructure
uses a top down allocator that starts allocating from a board/chipset
defined function cbmem_top(). A root pointer lives just below
cbmem_top(). In turn that pointer points to the root block which
contains the entries for all the large alloctations. The corresponding
block for each large allocation falls just below the previous entry.
It should be noted that this implementation rounds all allocations
up to a 4096 byte granularity. Though a packing allocator could
be written for small allocations it was deemed OK to just fragment
the memory as there shouldn't be that many small allocations. The
result is less code with a tradeoff of some wasted memory.
+----------------------+ <- cbmem_top()
| +----| root pointer |
| | +----------------------+
| | | |--------+
| +--->| root block |-----+ |
| +----------------------+ | |
| | | | |
| | | | |
| | alloc N |<----+ |
| +----------------------+ |
| | | |
| | | |
\|/ | alloc N + 1 |<-------+
v +----------------------+
In addition to preserving the previous cbmem API, the dynamic
cbmem API allows for removing blocks from cbmem. This allows for
the boot process to allocate memory that can be discarded after
it's been used for performing more complex boot tasks in romstage.
In order to plumb this support in there were some issues to work
around regarding writing of coreboot tables. There were a few
assumptions to how cbmem was layed out which dictated some ifdef
guarding and other runtime checks so as not to incorrectly
tag the e820 and coreboot memory tables.
The example shown below is using dynamic cbmem infrastructure.
The reserved memory for cbmem is less than 512KiB.
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000002ffff: RAM
2. 0000000000030000-000000000003ffff: RESERVED
3. 0000000000040000-000000000009ffff: RAM
4. 00000000000a0000-00000000000fffff: RESERVED
5. 0000000000100000-0000000000efffff: RAM
6. 0000000000f00000-0000000000ffffff: RESERVED
7. 0000000001000000-000000007bf80fff: RAM
8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES
9. 000000007c000000-000000007e9fffff: RESERVED
10. 00000000f0000000-00000000f3ffffff: RESERVED
11. 00000000fed10000-00000000fed19fff: RESERVED
12. 00000000fed84000-00000000fed84fff: RESERVED
13. 0000000100000000-00000001005fffff: RAM
Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf
coreboot table: 948 bytes.
CBMEM ROOT 0. 7bfff000 00001000
MRC DATA 1. 7bffe000 00001000
ROMSTAGE 2. 7bffd000 00001000
TIME STAMP 3. 7bffc000 00001000
ROMSTG STCK 4. 7bff7000 00005000
CONSOLE 5. 7bfe7000 00010000
VBOOT 6. 7bfe6000 00001000
RAMSTAGE 7. 7bf98000 0004e000
GDT 8. 7bf97000 00001000
ACPI 9. 7bf8b000 0000c000
ACPI GNVS 10. 7bf8a000 00001000
SMBIOS 11. 7bf89000 00001000
COREBOOT 12. 7bf81000 00008000
And the corresponding e820 entries:
BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16
BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable
BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved
BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable
BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable
BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved
BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable
BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16
BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved
BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved
BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved
BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved
BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable
Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2848
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is updated to handle LynxPoint-H and LynxPoint-LP
and a new wake event is added for the power button.
Boot, suspend/resume, reboot, etc on WTM2
and then check the event log to see if expected events
have been added.
Change-Id: I15cbc3901d81f4fd77cc04de37ff5fa048f9d3e8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2817
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Instead of hard coding the policy for how a relocated ramstage
image is saved add an interface. The interface consists of two
functions. cache_loaded_ramstage() and load_cached_ramstage()
are the functions to cache and load the relocated ramstage,
respectively. There are default implementations which cache and
load the relocated ramstage just below where the ramstage runs.
Change-Id: I4346e873d8543e7eee4c1cd484847d846f297bb0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2805
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Accessing the flash part where the ramstage resides can be slow
when loading it. In order to save time in the S3 resume path a copy
of the relocated ramstage is saved just below the location the ramstage
was loaded. Then on S3 resume the cached version of the relocated
ramstage is copied back to the loaded address.
This is achieved by saving the ramstage entry point in the
romstage_handoff structure as reserving double the amount of memory
required for ramstage. This approach saves the engineering time to make
the ramstage reentrant.
The fast path in this change will only be taken when the chipset's
romstage code properly initializes the s3_resume field in the
romstage_handoff structure. If that is never set up properly then the
fast path will never be taken.
e820 entries from Linux:
BIOS-e820: [mem 0x000000007bf21000-0x000000007bfbafff] reserved
BIOS-e820: [mem 0x000000007bfbb000-0x000000007bffffff] type 16
The type 16 is the cbmem table and the reserved section contains the two
copies of the ramstage; one has been executed already and one is
the cached relocated program.
With this change the S3 resume path on the basking ridge CRB shows
to be ~200ms to hand off to the kernel:
13 entries total:
1:95,965
2:97,191 (1,225)
3:131,755 (34,564)
4:132,890 (1,135)
8:135,165 (2,274)
9:135,840 (675)
10:135,973 (132)
30:136,016 (43)
40:136,581 (564)
50:138,280 (1,699)
60:138,381 (100)
70:204,538 (66,157)
98:204,615 (77)
Change-Id: I9c7a6d173afc758eef560e09d2aef5f90a25187a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2800
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When CONFIG_EARLY_CBMEM_INIT is selected romstage is supposed to have
initialized cbmem. Therefore provide a weak function for the chipset
to implement named cbmem_get_table_location(). When
CONFIG_EARLY_CBMEM_INIT is selected cbmem_get_table_location() will be
called to get the cbmem location and size. After that cbmem_initialize()
is called.
Change-Id: Idc45a95f9d4b1d83eb3c6d4977f7a8c80c1ffe76
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2797
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Provide a field in the romstage_handoff structure to indicate if the
current boot is an ACPI S3 wake boot. There are currently quite a few
non-standardized ways of passing this knowledge to ramstage from
romstage. Many utilize stashing magic numbers in device-specific
registers. The addition of this field adds a more formalized method
passing along this information. However, it still requires the romstage
chipset code to initialize this field. In short, this change does not
make this a hard requirement for ramstage.
Change-Id: Ia819c0ceed89ed427ef576a036fa870eb7cf57bc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2796
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The romstage_handoff structure can be utilized from different components
of the romstage -- some in the chipset code, some in coreboot's core
libarary. To ensure that all users handle initialization of a newly
added romstage_handoff structure properly, provide a common function to
handle structure initialization.
Change-Id: I3998c6bb228255f4fd93d27812cf749560b06e61
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2795
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some of the functions called from assembly assume the standard
x86 32-bit ABI of passing all arguments on the stack. However,
that calling ABI can be changed by compiler flags. In order to
protect against the current implicit calling convention annotate
the functions called from assembly with the cdecl function
attribute. That tells the compiler to use the stack based parameter
calling convention.
Change-Id: I83625e1f92c6821a664b191b6ce1250977cf037a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2794
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch adds an option to build the ramstage as a reloctable binary.
It uses the rmodule library for the relocation. The main changes
consist of the following:
1. The ramstage is loaded just under the cmbem space.
2. Payloads cannot be loaded over where ramstage is loaded. If a payload
is attempted to load where the relocatable ramstage resides the load
is aborted.
3. The memory occupied by the ramstage is reserved from the OS's usage
using the romstage_handoff structure stored in cbmem. This region is
communicated to ramstage by an CBMEM_ID_ROMSTAGE_INFO entry in cbmem.
4. There is no need to reserve cbmem space for the OS controlled memory for
the resume path because the ramsage region has been reserved in #3.
5. Since no memory needs to be preserved in the wake path, the loading
and begin of execution of a elf payload is straight forward.
Change-Id: Ia66cf1be65c29fa25ca7bd9ea6c8f11d7eee05f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2792
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The romstage_handoff structure is intended to be a way for romstage and
ramstage to communicate with one another instead of using sideband
signals such as stuffing magic values in pci config or memory
scratch space. Initially this structure just contains a single region
that indicates to ramstage that it should reserve a memory region used
by the romstage. Ramstage looks for a romstage_handoff structure in cbmem
with an id of CBMEM_ID_ROMSTAGE_INFO. If found, it will honor reserving
the region defined in the romstage_handoff structure.
Change-Id: I9274ea5124e9bd6584f6977d8280b7e9292251f0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2791
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Introduce a new cbmem id to indicate romstage information. Proper
coordination with ramstage and romstage can use this cbmem entity
to communicate between one another.
Change-Id: Id785f429eeff5b015188c36eb932e6a6ce122da8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2790
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
There is a need to calculate the proper placement for an rmodule
in memory. e.g. loading a compressed rmodule from flash into ram
can be an issue. Determining the placement is hard since the header
is not readable until it is decompressed so choosing the wrong location
may require a memmove() after decompression. This patch provides
a function to perform this calculation by finding region below a given
address while making an assumption on the size of the rmodule header..
Change-Id: I2703438f58ae847ed6e80b58063ff820fbcfcbc0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2788
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This code is taken from an EDID reader written at Red Hat.
The key function is
int decode_edid(unsigned char *edid, int size, struct edid *out)
Which takes a pointer to an EDID blob, and a size, and decodes it into
a machine-independent format in out, which may be used for driving
chipsets. The EDID blob might come for IO, or a compiled-in EDID
BLOB, or CBFS.
Also included are the changes needed to use the EDID code on Link.
Change-Id: I66b275b8ed28fd77cfa5978bdec1eeef9e9425f1
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are some external libraries that are built within
coreboot's environment that expect a more common C standard
environment. That includes things like inttypes.h and UINTx_MAX
macros. This provides the minimal amount of #defines and files
to build vboot_reference.
Change-Id: I95b1f38368747af7b63eaca3650239bb8119bb13
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2859
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Coreboot's ramstage defines certain sections/symbols in its fixed
static linker script. It uses these sections/symbols for locating the
drivers as well as its own program information. Add these sections
and symbols to the rmodule linker script so that ramstage can be
linked as an rmodule. These sections and symbols are a noop for other
rmodule-linked programs, but they are vital to the ramstage.
Also add a comment in coreboot_ram.ld to mirror any changes made there
to the rmodule linker script.
Change-Id: Ib9885a00e987aef0ee1ae34f1d73066e15bca9b1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2786
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This patch only applies to CONFIG_MICROCODE_IN_CBFS. The intel microcode
update routine would always walk the CBFS for the microcode file. Then
it would loop through the whole file looking for a match then load the
microcode. This process was maintained for intel_update_microcode_from_cbfs(),
however 2 new functions were exported:
1. const void *intel_microcode_find(void)
2. void intel_microcode_load_unlocked(const void *microcode_patch)
The first locates a matching microcode while the second loads that
mircocode. These new functions can then be used to cache the found
microcode blob w/o having to re-walk the CBFS.
Booted baskingridge board to Linux and noted that all microcode
revisions match on all the CPUs.
Change-Id: Ifde3f3e5c100911c4f984dd56d36664a8acdf7d5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2778
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add an rmodules class so that there are default rules for compiling
files that will be linked by the rmodule linker. Also, add a new type
for SIPI vectors.
Change-Id: Ided9e15577b34aff34dc23e5e16791c607caf399
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2751
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There is a plan to utlize rmodules for loading ramstage as a
relocatable module. However, the rmodule header may change.
In order to provide some wiggle room for changing the contents
of the rmodule header add some padding. This won't stop the need
for coordinating properly between the romstage loader that may be
in readonly flash and rmodule header fields. But it will provide
for a way to make certain assumptions about alignment of the
rmodule's program when the rmodule is compressed in the flash.
Change-Id: I9ac5cf495c0bce494e7eaa3bd2f2bd39889b4c52
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2749
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A rmodule is short for relocation module. Relocaiton modules are
standalone programs. These programs are linked at address 0 as a shared
object with a special linker script that maintains the relocation
entries for the object. These modules can then be embedded as a raw
binary (objcopy -O binary) to be loaded at any location desired.
Initially, the only arch support is for x86. All comments below apply to
x86 specific properties.
The intial user of this support would be for SMM handlers since those
handlers sometimes need to be located at a dynamic address (e.g. TSEG
region).
The relocation entries are currently Elf32_Rel. They are 8 bytes large,
and the entries are not necessarily in sorted order. An future
optimization would be to have a tool convert the unsorted relocations
into just sorted offsets. This would reduce the size of the blob
produced after being processed. Essentialy, 8 bytes per relocation meta
entry would reduce to 4 bytes.
Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2692
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Paul points out that some people like 1024*1024, others like
1048576, but in any case these are all open to typos.
Define KiB, MiB, GiB, and TiB as in the standard so people can use them.
Change-Id: Ic1b57e70d3e9b9e1c0242299741f71db91e7cd3f
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2769
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Duncan Laurie