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.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit. Built and booted into ChromeOS
on snow.
BRANCH=None
Change-Id: Ib01c0218b95d8660418fea2181f6f38bc0675159
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60601
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Now that we have horizontal display areas that are not multiples of 32 bytes,
things are more complex. We add three struct members (x, y resolution and
bytes per line) which are to be filled in by the mainboard as it sets the mode.
In future, the EDID code may take a stab at initializing these but the values are
context-dependent.
BUG=None
TEST=Build and boot slippy with these changes
BRANCH=None
Change-Id: Ib9102d6bbf8c66931f5adb1029a04b881a982cfe
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60514
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
This was used by Ron 13ys ago and was never used again
ever since.
BUG=chrome-os-partner:18637
BRANCH=none
TEST=none
Change-Id: I8ae8a570d67fa0b34b17c9e3709845687f73c724
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59320
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
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.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit with another change and an external tool, and was
able to get serial output. Built for snow.
BRANCH=None
Change-Id: Ie27ae7a7b22f336d23893618969efde4145fefd7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57725
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Now that there is a clearly defined boot state machine
we can add some useful post codes to indicate the current
point in the state machine by having it log a post code
before the execution of each state.
This removes the currently defined POST codes that were
used by hardwaremain in favor of a new contiguous range
that are defined for each boot state.
The reason for this is that the existing codes are mostly
used to indicate when something is done, which is confusing
for actual debug because POST code debugging relies on knowing
what is about to happen (to know what may be at fault) rather
than what has just finished.
One additonal change is added during device init step as this
step often does the bulk of the work, and frequently logs POST
codes itself. Therefore in order to keep better track of what
device is being initialized POST_BS_DEV_INIT is logged before
each device is initialized.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: interrupted boot with reset button and
gathered the eventlog. Mosys has been extended to
decode the well-known POST codes:
26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset
Change-Id: Ida1e1129d274d28cbe8e49e4a01483e335a03d96
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58106
One of the most common hangs during coreboot execution
is during ramstage device init steps. Currently there
are a set of (somewhat misleading) post codes during this
phase which give some indication as to where execution
stopped, but it provides no information on what device
was actually being initialized at that point.
This uses the new CMOS "extra" log banks to store the
encoded device path of the device that is about to be
touched by coreboot. This way if the system hangs when
talking to the device there will be some indication where
to investigate next.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: interrupted boot with reset button and
gathered the eventlog after several test runs:
26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset
Change-Id: I6045bd4c384358b8a4e464eb03ccad639283939c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58105
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.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: emerge-slippy chromeos-coreboot-slippy
This adds new infrastructure that is not used yet.
Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58104
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.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=New code only, nothing uses it yet.
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>
This stuff is not used, so let's drop it.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
BRANCH=none
TEST=boot tested on Link and Snow
Change-Id: Ib3f3eab653f87a75e9e1e6a0bcdd72a605f77e6c
Reviewed-on: https://gerrit.chromium.org/gerrit/56652
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.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.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: emerge-{link,parrot,butterfly}
chromeos-coreboot-{link,parrot,butterfly}
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>
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.
BUG=chrome-os-partner:19342
BRANCH=none
TEST=Built and booted. Noted that CAR values are not read incorrectly.
Change-Id: Ie0104a6e24cc6430a575ee3691671900c36db0d9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51386
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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.
BUG=none
TEST=booted on Snow
BRANCH=none
Change-Id: I7581e9005e09ad264f85d57b6771f40faa2e63af
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51216
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.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().
BUG=None
BRANCH=None
TEST=Built.
Change-Id: I980a6daf8ea3f0475124329253ace2695fc39aa7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51162
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
... and drop the wrapper on ARMv7
BUG=none
TEST=boot tested on snow
BRANCH=none
Change-Id: Ib2b4315b664292653f8cb898fc5633fce421deca
Reviewed-on: https://gerrit.chromium.org/gerrit/50728
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
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
BUG=none
TEST=boot tested on Link
BRANCH=none
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>
Reviewed-on: https://gerrit.chromium.org/gerrit/50723
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
it has been unused since 9 years or so, hence drop it.
BRANCH=none
BUG=none
TEST=boot tested on snow
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>
Reviewed-on: https://gerrit.chromium.org/gerrit/50720
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
The smm_handler_t type was added before the introduction
of the asmlinkage macro. Now that asmlinkage is available
use it.
BUG=None
BRANCH=None
TEST=Compiled and booted
Change-Id: I8a5c98b1ee2df69494ca4c671992e4c635d09a21
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50458
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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);
BUG=None
BRANCH=None
TEST=Compiled and booted
Change-Id: I3de15e5b91e7fd1c833bc99b0d0af46a5a7c4bee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50455
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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.
BUG=None
BRANCH=None
TEST=Compiled and booted
Change-Id: Ic7096b7f5c9dec26a3f0441e6715fe02b15d44db
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50453
Reviewed-by: Stefan Reinauer <reinauer@google.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>
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>
BUG=chrome-os-partner:18638
TEST=emerge-daisy libpayload depthcharge builds with ToT coreboot
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>
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: Ia493a284efb3b34e8577e6d3db957169c6d86a1b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49753
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: If608f65efc9d2e8190dcc97f0e87c8f6a7b50745
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49748
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: I8c2af24a12a77d22e61c0bd8c392714bd1dfdedd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49747
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: If67b9b50081d21d505685a96d201c242e71b64f7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49746
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: Ic086cae17491a20d2e81aa1c7922bd821aacb00b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49745
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: I2648ebc26a753896ad4b82ab8136e9742b4d6af5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49744
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: I623e55f19f9fb52492f288c620cc966cafd0ab71
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49743
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: I298f0f1c1aa6ee62fee0067a53dc021fe07044dc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49742
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: I6a4102cb9fac3f7980c28169430251651fddeb30
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49741
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: I9555845ca3045c6d4386b79438e5f426916fe457
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49740
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: If8e16cb321bb53eed4013dc5ea2436a4f40eeb6b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49738
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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 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>
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.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: build and boot on wtm2
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>
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: Iee680a3513a957214294c19167d9487aaf2f4d97
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49184
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.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.
BUG=None
TEST=build coreboot with and without native graphics enabled. It builds.
Build with YABEL. It still builds.
BRANCH=NONE
Change-Id: Ieef2178e7e7fa850556c9af68e2d897a33aec871
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48923
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
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.
BUG=chrome-os-partner:18638
TEST=USE=depthcharge emerge-link libpayload depthcharge chromeos-coreboot-link chromeos-bootimage
produces working image
BRANCH=none
Change-Id: I46fc1dad530e5230986f7aa5740595428ede4f93
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48723
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=chrome-os-partner:16177
TEST=compile tested only, needs butterfly hardware to test
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>
Capture very early EC errors in the ELOG and power off the
system.
BUG=chrome-os-partner:13107
TEST=Cause the EC to report Thermal Sense, Fan, or Low Battery
errors. Check ELOG on next boot.
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>
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>
