Implement the timer_monotonic_get() functionality based off of
the local apic timer.
Change-Id: I1aa1ff64d15a3056d6abd1372be13da682c5ee2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3154
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Haswell ULT devices have a 24MHz package-level counter. Use
this counter to provide a timer_monotonic_get() implementation.
Change-Id: Ic79843fcbfbbb6462ee5ebd12b39502307750dbb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3153
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>
While debugging a crash it was discovered that ld was inserting
address space for sections that were empty depending on section
address boundaries. This led to the assumption breaking down that
on-disk payload (code/data bits) was contiguous with the address
space. When that assumption breaks down relocation updates change
the wrong memory. Fix this by making the rmodule.ld linker script
put all code/data bits into a payload section.
Change-Id: Ib5df7941bbd64662090136e49d15a570a1c3e041
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3149
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
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>
The "console_init" does initialize UART driver (which will setup peripheral and
pinmux) and print starting message. Duplicated initialization can be removed.
Also, console_init (from console.c) is always linked to bootblock (and will do
nothing if CONFIG_EARLY_CONSOLE is not defined) so it's safe to remove #ifdef.
Verified by building and booting on Google/Snow, with and without
CONFIG_EARLY_CONSOLE.
Change-Id: I0c6b4d4eb1a4e81af0f65bcb032978dfb945c63d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3150
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Enable `EARLY_CBMEM_INIT` for CBMEM console support by looking how
other boards do this.
This commit is tested by enabling the CBMEM console (`CONSOLE_CBMEM` in
Kconfig) and then in GRUB 2 (as a payload) with the cbmemc command from
the cbmemc module and in userspace with ./cbmem -c. Both worked.
Change-Id: I34618a55ded7292a411bc232eb76267eec17d91e
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3142
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
The DDR3 memory initialization (with "mem_reset" set on normal boot) will cause
resume to be unstable, especially when X is running. System may show X screen
for few seconds, then crash randomly and unable to recover - although text
console may still work for a while. Probably caused by corrupted memory pages.
'mem_reset' (which refers to RESET# in DDR3 spec) should be enabled according
to DDR3 spec. But it seems that on Exynos 5, memory can be initialized without
setting mem_reset for both normal boot and resume - at least no known failure
cases are found yet. So this can be a temporary workaround.
Verified by booting a Google/Snow device with X Window and ChromeOS, entering
browser session with fancy web pages, closing LID to suspend for 5 seconds, then
re-opening to resume. Suspend/resume worked as expected.
Also tried the "suspend_stress_test" with X running and finished 100 iterations
of suspend/resume test without failure.
Change-Id: I7185b362ce8b545fe77b35a552245736c89d465e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3148
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add the suspend/resume feature into bootblock and romstage.
Note, resuming with X and touchpad driver may be still unstable.
Verified by building and booting successfully on Google/Snow, and then executing
the "suspend_stress_test" in text mode ("stop ui; suspend_stress_test") in
Chromium OS, passed at least 20 iterations.
Change-Id: I65681c42eeef2736e55bb906595f42a5b1dfdf11
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3102
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Move board setup procedure to snow_setup_* functions, and Snow board-specific
(wakeup) code to snow_* for better function names and comments.
Verified by successfully building and booting on Google/Snow.
Change-Id: I2942d75064135093eeb1c1da188a005fd255111d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3130
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This makes the intermediate rule visible so BL1 gets automatically
placed in the final image.
Change-Id: Iffb0268e5bbcbe135f2d39863ed64fa302409a22
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3141
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This adds $$(INTERMEDIATE) as a pre-requisite for coreboot.rom on
armv7. It is modeled after the $(obj)/coreboot.rom rule for x86.
Change-Id: I483a88035fa2288829b6e042e51ef932c8c4f23c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2095
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The "wakeup" procedure will be shared by bootblock and romstage for different
types of resume processes.
Note, this commit does not include changes in romstage/bootblock to enable
suspend/resume feature. Simply adding functions to handle suspend/resume.
Verified by successfully building and booting Google/Snow firmware image.
Change-Id: I17a256afb99f2f8b5e0eac3393cdf6959b239341
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3129
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To support suspend/resume, PHY control must be reset only on normal boot
path. So add a new param "mem_reset" to specify that.
Verified to boot successfully on Google/Snow.
Change-Id: Id49bc6c6239cf71a67ba091092dd3ebf18e83e33
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3128
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It seems that ConnectorTypeDP in DdiList supports both DP and HDMI monitors.
I tested by DP monitor and HDMI monitor connected by passive DP->HDMI adapter.
Video and audio are OK. Hot plugging is also supported.
This commit partially reverts commit >AMD Thatcher: Fix PCIE link issues< (7f23aeb0) [1].
[1] http://review.coreboot.org/3011
Change-Id: I23cf1c69a8274f47daf56f1a12aafd88bad4a128
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3088
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds support for display bring-up on Snow. It
includes framebuffer initialization and LCD enable functions.
Change-Id: I16e711c97e9d02c916824f621e2313297448732b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3116
Tested-by: build bot (Jenkins)
Add a safety check in function `intel_update_microcode` to return when
accidentally `NULL` is passed as `microcode_updates`, which would lead
to a null pointer dereference later on.
for (c = microcode_updates; m->hdrver; m = (const struct microcode *)c) {
While at it, use `return NULL` for clarity in function
`intel_microcode_find` and include the header file `stddef.h`. for it.
The review of this patch had some more discussion on adding more
comments and more detailed error messages. But this should be done in
a separate patch.
For clarity here some history, on how this was found and what caused
the discussion and confusion.
Originally when Vladimir made this improvement, selecting
`CPU_MICROCODE_IN_CBFS` in Kconfig but not having the microcode blob
`cpu_microcode_blob.bin` in CBFS resulted in a null pointer dereference
later on causing a crash.
for (c = microcode_updates; m->hdrver; m = (const struct microcode *)c) {
Vladimir fixed this by returning if `microcode_updates` is `NULL`,
that means no file is found and successfully tested this on his
Lenovo X201.
When pushing the patch to Gerrit for review, the code was rewritten
though by Aaron in commit »intel microcode: split up microcode loading
stages« (98ffb426) [1], which also returns when no file is found. So
the other parts of the code were checked and the safety check as
described above is added.
[1] http://review.coreboot.org/2778
Change-Id: I6e18fd37256910bf047061e4633a66cf29ad7b69
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2990
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This makes sure that the product ID (PRO_ID) register can be read
when the OS kernel is figuring out what kind of CPU it's running on.
For historical reference, the original U-Boot code seems to have
worked basically by accident here. The hardware has a quirk where by
reading the value before gating the IP block keeps the value
persistent. U-Boot reads the chip ID early on to distinguish between
chip family, but we do not mix code the same way so we do not read
the chip ID. Since the value has been read before the clock gating
happens, the value remains available for the kernel to use during the
decompression stage. We don't want to rely on that behavior when using
coreboot. Instead the kernel should gate unused IPs.
(credit to Gabe for finding symptom in the kernel)
Change-Id: Iaa21e6e718b9000b5558f568020f393779fd208e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3121
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This simple error led to corrupted graphics.
How annoying.
Change-Id: I2295c0df0f1d16014a603dc5d66bd4d72f3fb7c9
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3120
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Due to
$ more src/southbridge/amd/cimx/sb800/Makefile.inc
[…]
romstage-y += cfg.c
romstage-y += early.c
romstage-y += smbus.c
ramstage-y += cfg.c
ramstage-y += late.c
[…]
`src/southbridge/amd/cimx/sb800/` is passed with the switch `-I` to
the compiler, where it is also going to find the header file
`sb_cimx.h`. Therefore use `#include <sb_cimx>` everywhere, which is
what some AMD SB800 based boards already do.
The only effect is, that the compiler will not needlessly look into
directories which do not contain the header file [1].
The following command was used for the replacement.
$ git grep -l sb_cimx.h src/mainboard/ | xargs sed -i 's/#include "sb_cimx.h"/#include <sb_cimx.h>/'
[1] http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
Change-Id: I96ab34bac1524e6c38c85dfe9d99cb6ef55e6d7c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3118
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>
This PLL is unused and can be disabled to save about 250mW.
Change-Id: I1be37304d6ea5ff78696e05ad1023ce3c57f636c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3109
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The original imported code used "lcdbase" and "lcd_base" which quite
predictably caused confusion and bugs. Let's put an end to this little
bit of insanity.
Change-Id: I4f995482cfbff5f23bb296a1e6d35beccf5f8a91
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3114
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This just cleans up a few areas:
- Removed an unnecessary delay from exynos_dp_bridge_setup()
- The delay at the end of exynos_dp_bridge_init() is necessary, so
removed the comment suggesting that it might not be.
- Simplified exynos_dp_hotplug
Change-Id: I44150f5ef3958e333985440c1022b4f1544a93aa
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3113
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This enables clock gating to save power on unused IPs.
Change-Id: I9ab2a2535ebb91bb4110390a6f055a67146bdbf9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3110
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch is based on >>AMD Thatcher: ConnectorTypeDP supports both DP and HDMI<< (I23cf1c6) [1]
I tested by DP monitor and HDMI monitor connected by passive DP->HDMI adapter.
Video and audio are OK. Hot plugging is also supported.
[1] http://review.coreboot.org/#/c/3088/
Change-Id: I291beff43609ecb68ece24939f2dbc7c08dd0374
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3090
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We neglected to copy xres and yres out; now we do.
Change-Id: Icc4a8eb35799d156b11274f71bcfb4a1d10e01e3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3111
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
This enables the thermal management unit (TMU) on Snow.
Change-Id: Idd76af40bf0a5408baf61ef2665fd52ae4e260ba
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3108
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This updates the Exynos TMU code for coreboot:
- Remove dependency on device tree
- Add Makefile entries
Change-Id: I55e1b624d7c7b695b1253ec55f6ae3de8dc671bc
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3107
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This simply imports the Exynos TMU driver from u-boot. It is not
built and thus should not break anything.
Change-Id: I7861132fbf97f864e4250ffbda1ef3843f296ddc
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3106
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This moves the prototype for power_enable_hw_thermal_trip() to
a generic location so it can be used by generalized thermal
management code. The implementation will still be CPU-specific.
Change-Id: Iae449cb8c72c8441dedaf65b73db9898b4730cef
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3105
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Commit 23023a5 correctly enabled the SB800 GPP PCIe ports but didn't
distribute the 4 GPP PCIe lanes amongst the enabled PCIe ports.
This fix was verified by openvoid on a AsRock E350M1 motherboard.
Change-Id: I0116c5f518e0d000be609013446e53da4112f586
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3104
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The way we got to include the compiler includes was kind of whacky.
Instead of mixing in potentially problematic headers, make libpayload
self-contained by adding some missing header files. Also clean up
conflicting definitions of size_t throughout the tree.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I0ad1194de1a00b7133c5477c00eb167d63a2ee85
Reviewed-on: https://gerrit.chromium.org/gerrit/47608
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3058
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Same splitting as done on Persimmon and ASRock.
Moving common DSDT code to common areas and adding
new files as necessary. Boards updated are:
Inagua
Union-Station
South-Station
Change-Id: I8c9eea62996b41cea23a9c16858c4249197f6216
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3051
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add the ACPI Operating System Capabilities Method and let the
operation system control everything.
Commit »AMD Fam14 DSDT: Add OSC method« (00a0e76b) [1] is used as
a template.
The Lenovo X60 [2] running the Parabola GNU/Linux distribution [3] is
used for testing.
Before that change:
$ dmesg | egrep -e OSC -e ASPM
[ 0.108036] pci_root PNP0A08:00: ACPI _OSC support notification failed, disabling PCIe ASPM
[ 0.108040] pci_root PNP0A08:00: Unable to request _OSC control (_OSC support mask: 0x08)
[ 0.118089] ACPI _OSC control for PCIe not granted, disabling ASPM
[ 16.874569] e1000e 0000:01:00.0: Disabling ASPM L0s L1
With that change:
$ dmesg | egrep -e OSC -e ASPM
[ 0.107962] pci_root PNP0A08:00: Requesting ACPI _OSC control (0x1d)
[ 0.108003] pci_root PNP0A08:00: ACPI _OSC control (0x1d) granted
[ 0.111052] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
[ 17.537970] e1000e 0000:01:00.0: Disabling ASPM L0s L1
[1] http://review.coreboot.org/2738
[2] http://www.coreboot.org/Lenovo_x60x
[3] https://parabolagnulinux.org/
Change-Id: I1caffa44eea447d553c01caaf431f2db241ea5ea
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2938
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This used to contain the path for the EC include files, but
those files are included in coreboot now.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I4fce9831c5e21b0a69a6295dbda2580e1ca83369
Reviewed-on: https://gerrit.chromium.org/gerrit/47606
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3057
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This gets rid of the clock-tick based sdelay in favor of udelay().
udelay() is more consistent and easier to work with, and this allows
us to carry one less variation of timers (and headers and sources...).
Every 1 unit in the sdelay() argument was assumed to cause a delay of
2 clock ticks (@1.7GHz). So the conversion factor is roughly:
sdelay(N) = udelay(((N * 2) / 1.7 * 10^9) * 10^6)
= udelay((N * 2) / (1.7 * 10^3))
The sdelay() periods used were:
sdelay(100) --> udelay(1)
sdelay(0x10000) --> udelay(78) (rounded up to udelay(100))
There was one instance of sdelay(10000), which looked like sort of a
typo since sdelay(0x10000) was used elsewhere. sdelay(10000) should
approximate to about 12us, so we'll stick with that for now and leave
a note.
Change-Id: I5e7407865ceafa701eea1d613bbe50cf4734f33e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3079
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The types are (esp. int) are confusing at times as to size.
Make them definite as to size.
Change-Id: Id7808f1f61649ec0a3403c1afc3c2c3d4302b7fb
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3103
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Aaron Durbin