Age | Commit message (Collapse) | Author |
|
On AMD platforms, setting of USBDEBUG_DEFAULT_PORT=0 tries to scan
all physical ports one after other in incrementing order. To avoid
possible problems with other USB devices, one can select the port
number here and bypass the scan.
Intel platforms can communicate with usbdebug dongle on one
physical port only, and this option makes no difference there.
Change-Id: I45be6cc3aa91b74650eda2d444c9fcad39d58897
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3872
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
After an USB device sees USB bus reset on the bus, it will reset to
device number 0. Per the EHCI debug port specification, a debug
dongle device may reset to the fixed debug device number of 127 instead.
Thus there is no need to try device numbers from 1 to 126.
Do a sanity-check on a returned debug descriptor as I experienced
some USB flash memory to respond on this request with zero-fill data.
Change-Id: I78d58f3dc049cd8c20c6e2aa3a4207ad7e6a6d33
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3861
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Resetting an EHCI controller when it is not halted can have
undefined behaviour. This mostly fixes a case where calling
usbdebug_init() twice would fail to reset the USB dongle device
properly.
On amd/persimmon it still requires one extra retry, but at least it
is now possible to have usbdebug enabled for both romstage and
ramstage.
Change-Id: Ib0e6e5a0167404f68af2edf112306fdb8def0be9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3862
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Letting SMI handler touch EHCI controller is an excellent source
of USB problems. Remove usbdebug entirely from SMM.
It may be possible to make usbdebug console work from SMM
after hard work and coordination with payloads and even
OS drivers. But we are not there.
Change-Id: Id50586758ee06e8d76e682dc6f64f756ab5b79f5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3858
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
This quirk is needed with a DIY debug dongle using obsolete
CY7C68013 (aka FX2) USB chips. Old revision of chip requires a
SET_CONFIGURATION to be sent, while this is not required in EHCI
debug port specs.
Change-Id: I4926eb19b7e991d6efeef782682756571ad006b9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3386
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
When we create low-level debugging of EHCI controller registers,
we call printk() within printk(). In ramstage this would leave us
with deadlock waiting on the console spinlock.
Change-Id: Idbe029af9af76de27094bb2964c60d9ccfdd96e6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3860
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Increase existing level from DEBUG to INFO.
Change-Id: Ic5934aec449f921af96dd3a6524f7275f8de1304
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3859
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
If ramstage is not compressed, the CBFS module in romstage doesn't
need to support LZMA. Removing the LZMA module in this case can save
about 3000 bytes in romstage.
Change-Id: Id6f7869e32979080e2985c07029edcb39eee9106
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3878
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
For reasons explained in a previous CL, it might be necessary to "load" a file
from CBFS in place. The loading code in CBFS was, however, zeroing the area of
memory the stage was about to be loaded into. When the CBFS data is located
elsewhere this works fine, but when it isn't you end up clobbering the data
you're trying to load. Also, there's no reason to zero memory we're about to
load something into or have just loaded something into. This change makes it
so that we only zero out the portion of the memory between what was
loaded/decompressed and the final size of the stage in memory.
Change-Id: If34df16bd74b2969583e11ef6a26eb4065842f57
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3579
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
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>
|
|
Add option to log changes in USB 2.0 EHCI debug port connection.
For romstage move usbdebug as the last initialised console so one
actually can see these messages.
Init order of consoles in ramstage is undetermined and unchanged.
Change-Id: I3aceec8a93064bd952886839569e9f5beb6c5720
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3387
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.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>
|
|
Change-Id: I74d28c13e6597c56e3b85ccd2b83386b86c200f0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3828
Tested-by: build bot (Jenkins)
|
|
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>
|
|
It might be the case that a file is being loaded from a portion of CBFS which
has already been loaded into a limitted bit of memory somewhere, and we want
to load that file in place, effectively, so that it's original location in
CBFS overlaps with its new location. That's only guaranteed to work if you use
memmove instead of memcpy.
Change-Id: Id550138c875907749fff05f330fcd2fb5f9ed924
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3577
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I4b6a57e7d8e7e685c609b1d85368585b9dd197dc
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3761
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I9cad64796fcfb7a50d9ed9ec95c56ab855c872e3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3766
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
With EARLY_CBMEM_INIT and CAR_MIGRATION selected, cbmemc_reinit()
was called twice during romstage. This effectively deleted output
of romstage in CBMEM console.
Change-Id: I21072a319c0e4a5f695b0573bc017bf7921fc663
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3609
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Store EHCI Debug Port runtime variables in CAR_GLOBAL.
For platforms without CAR_MIGRATION, logging on EHCI Debug Port is
temporarily lost when CAR is torn down at end of romstage.
On model_2065x and model_206ax ehci_debug_info was overlapping the MRC
variable region and additionally migration used incorrect size for
the structure.
Change-Id: I5e6c613b8a4b1dda43d5b69bd437753108760fca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3475
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
There are other uses for EHCI debug port besides console, so move
EHCI relocation code from console to lib.
Change-Id: I95cddd31be529351d9ec68f14782cc3cbe08c617
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3626
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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>
|
|
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>
|
|
Change-Id: I999987af9cb44906e3c3135c0351a0cd6eb210ff
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3756
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
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>
|
|
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>
|
|
src/lib/cbmem.c is for the static cbmem.
Thanks to adurbin for the Makefile.inc pointer and code on #coreboot IRC channel on freenode:
<adurbin> no. if you have CONFIG_DYNAMIC_CBMEM then cbmem.c shouldn't be compiled
[...]
<adurbin> +ifeq ($(CONFIG_EARLY_CBMEM_INIT),y)
<adurbin> +ifneq ($(CONFIG_DYNAMIC_CBMEM),y) romstage-$(CONFIG_EARLY_CBMEM_INIT) += cbmem.c
<adurbin> +endif
<adurbin> +endif
Without that fix we have:
src/lib/cbmem.c:58:43: error: no previous prototype for 'get_cbmem_toc' [-Werror=missing-prototypes]
src/lib/cbmem.c:76:6: error: no previous prototype for 'cbmem_init' [-Werror=missing-prototypes]
src/lib/cbmem.c:107:5: error: no previous prototype for 'cbmem_reinit' [-Werror=missing-prototypes]
This commit was tested on qemu-i440fx with the following commit:
qemu-i440fx: Make it compile with CONFIG_DYNAMIC_CBMEM
( http://review.coreboot.org/#/c/3504/ ).
Change-Id: I98636aad4bb4b954f3ed3957df67c77f3615964a
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3503
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I2e3fd58404c48e863a3a1b255337fb397086651b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3506
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
src/lib/edid.c:1177: error: ‘y’ may be used uninitialized in this function
Warning is bogus, but seems my gcc (4.4.7 as shipped by RHEL-6)
isn't clever enougth to figure this on its own. So help a bit
by explicitly initializing the variable.
Change-Id: Ia9f966c9c0a6bd92a9f41f1a4a3c8e49f258be37
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3501
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add comment how one can debug the usbdebug hardware init.
Do not send printk's to usbdebug console when one is debugging
the usbdebug console initialisation itself.
Change-Id: I21a285cb31cf64e853bc626f8b6a617bc5a8be19
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3382
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
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>
|
|
Allow for automatic cache-as-ram migration for the cbmem
console. The code was refactored in the thought of making
it easier to read. The #ifdefs still exist, but they are no
longer sprinkled throughout the code. The cbmem_console_p
variable now exists globally in both romstage and ramstage.
However, the cbmem_console_p is referenced using the
cache-as-ram API. When cbmem is initialized the console
is automatically copied over by calling cbmemc_reinit()
through a callback.
Change-Id: I9f4a64e33c58b8b7318db27942e37c13804e6f2c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3235
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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>
|
|
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 cbfs core code would print out the name of the file it is
searching for and when it is found would print out the name
again. This contributes to a lot of unnecessary messages in a
functioning payload’s output. Change this message to a DEBUG one
so that it will only be printed when CONFIG_DEBUG_CBFS is enabled.
Change-Id: Ib238ff174bedba8eaaad8d1d452721fcac339b1a
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3208
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Internally there were states that had an attribute to
indicate that the timers needed to be drained. Now that
there is a way to block state transitions rely on this
ability instead of draining timers. The timers will
drain themselves when a state is blocked.
Change-Id: I59be9a71b2fd5a17310854d2f91c2a8957aafc28
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3205
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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>
|
|
The cbfs core code would print out all unmatched file
names when searching for a file. This contributes to a lot
of unnecessary messages in the boot log. Change this
message to a DEBUG one so that it will only be printed when
CONFIG_DEBUG_CBFS is enabled.
Change-Id: I1e46a4b21d80e5d2f9b511a163def7f5d4e0fb99
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3131
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
|
|
When TIMER_QUEUE is configured on call the timer callbacks on
entry into a state but before its entry callbacks. In addition
provide a barrier to the following states so that timers are drained
before proceeding. This allows for blocking state traversal for key
components of boot.
BS_OS_RESUME
BS_WRITE_TABLES
BS_PAYLOAD_LOAD
BS_PAYLOAD_BOOT
Future functionality consists of evaluating the timer callbacks within
the device tree. One example is dev_initialize() as that seems state
seems to take 90% of the boot time. The timer callbacks could then be
ran in a more granular manner.
Change-Id: Idb549ea17c5ec38eb57b4f6f366a1c2183f4a6dd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3159
Tested-by: build bot (Jenkins)
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>
|
|
When the MONOTONIC_TIMER is available track the entry, run, and exit
times for each state. It should be noted that the times for states that
vector to OS or a payload do not have their times reported.
Change-Id: I6af23fe011609e0b1e019f35ee40f1fbebd59c9d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3156
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>
|