These are both pulled up to 3.3V in the schematic.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=compile tested only, still need devices to test with
Change-Id: I12e055a39ff6100300c3d285899b8d6239e3773d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50356
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With the XHCI controller enabled we no longer hang the
system when dropping into a package C-state so remove
the code that was disabling it.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=boot wtm2 and verify package C2 residency with powertop
Change-Id: Icd60488fd2506dac04fb6ec96a77bec265b10d8c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50355
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The chromeos_acpi driver sysfs naming is not what
crossystem expects if there is just one entry in the package
because it does not add a ".#" suffix in that case.
Specify all the expected GPIOs on wtm2 as undefined, which
should be 0xFF and not 0x00 becuase 0 is a valid GPIO.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: build and boot image on wtm2 and
check for 3 GPIOs exposed in /sys/devices/platform/chromeos_acpi
Change-Id: I9b17e9bab94219695e65b17914c84acf02a0983b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50337
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The update-fit command takes in a parameter for number of slots
in the FIT table. It then processes the microcobe blob in cbfs
adding those entries to the FIT table. However, the tracking of
the number of mircocode updates was incremented before validating
the update. Therefore, move the sanity checking before an increment
of the number of updates.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=emerge-fox_wtm2 chromeos-coreboot-fox and inspected microcode
FIT entries.
Change-Id: Ie8290f53316b251e500b88829fdcf9b5735c1b0e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50319
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The current microcode blobs contain both ULT and non-ULT
revisions. Only include one or the other based off of the
CONFIG_INTEL_LYNXPOINT_LP Kconfig option.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=emerge-fox_wtm2 chromeos-coreboot-fox and inspected microcode
FIT entries.
Change-Id: I3e4e41d4cd727b1a974361fb469267e6f6022d5a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50318
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
In order for the FIT entries to be populated in the table the
update-fit command needs to be done on the coreboot image. That
way the microcode entries are added to the table properly.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=emerge-fox_wtm2 chromeos-coreboot-fox and inspected microcode
FIT entries.
Change-Id: I44595aee1ca710f4f04d482d8900cf95fbc1797f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50317
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
We have the monotonic timer implemented on exynos now, and this
also enables helpful bootstage prints with timing info.
Change-Id: I3baa4c9d70d4b4d059abd5e05eddcabd5258dbfd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3210
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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 goes thru various call sites where we used timer_us() and updates
them to use the new monotonic timer API.
udelay() changed substantially and now gracefully handles wraparound.
Change-Id: Ie2cc86a4125cf0de12837fd7d337a11aed25715c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3176
Reviewed-by: Aaron Durbin <adurbin@google.com>
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>
This implements the new monotonic timer API using the global
multi-core timer (MCT).
Change-Id: Id56249ff5d3e0f85808f5754954c83c0bc75f1c1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3175
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
The old approach was to invalidate the entire TLB every time we set up
a table entry. This worked because we didn't turn the MMU on until
after we had set everything up. This patch uses the TLBIMVAA wrapper
to invalidate each entry as it's added/modified.
Change-Id: I27654a543a2015574d910e15d48b3d3845fdb6d1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3166
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
It is useful to be able to lock out certain address ranges,
NULL being the most important example.
void mmu_disable_range(unsigned long start_mb, unsigned long size_mb)
will allow us to lock out selected virtual addresses on MiB boundaries.
As in other ARM mmu functions, the addresses and quantities are in units
of MiB.
Change-Id: If516ce955ee2d12c5a409f25acbb5a4b424f699b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3160
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
It's fine to always start timer even in suspend/resume mode, so we can
move the timer_start() back to the very beginning of boot procedure.
That provides more precise boot time information.
With that timer change, the wake up state test procedure can be simplified.
Verified by building and booting firmware image on Google/Snow successfully,
and then suspend-resume without problem (suspend_stress_test).
Change-Id: I0d739650dbff4eb3a75acbbf1e4356f2569b487d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3151
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds an inline wrapper for the TLBIMVAA instruction (invalidate
unified TLB by MVA, all address space identifiers).
Change-Id: Ibcd289ecedaba8586ade26e36c177ff1fcaf91d3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3161
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The firmware media source (SPI1) is already initialized by Exynos iROM.
There is no need to do it again.
Verified by building and booting Google/Snow successfully.
Change-Id: I89390506aa825397c0d7e52ad7503f1cb808f7db
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3147
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to probe the gpio-lynxpoint kernel driver the
LP GPIO controller needs to be exposed as a specific
ACPI device.
This also allows the resources to be exposed to the OS via
this device instead of the catch-all LPC device.
BUG=chrome-os-partner:19255
TEST=manual:
Ensure the driver loads at boot:
gpiochip_find_base: found new base at 162
gpiochip_add: registered GPIOs 162 to 255 on device: INT33C7:00
Also ensure the driver is visible in sysfs:
$ cat /sys/devices/platform/INT33C7:00/gpio/gpiochip162/label
INT33C7:00
Change-Id: I9f79c008f88da9b67ed1cdfdb9d3a581ce8f05ff
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50215
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>
This sets the vbe mode to valid later in the boot process, after
cbmem resources have been allocated during displayport init.
BRANCH=none
BUG=none
TEST=booted on Snow using depthcharge in dev mode
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I5ea675de817a2cf5695ef0473550023c72dd04c7
Reviewed-on: https://gerrit.chromium.org/gerrit/50013
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
fill_lb_framebuffer() now sets the framebuffer pointer according to
the EDID information, so it must be called before setting the tag
and size.
(credit to rminnich for this, I'm just uploading it)
BRANCH=none
BUG=none
TEST=booted on Snow using depthcharge in dev mode
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I5ac783fa3a776eee504d39889284041d1dc2c92a
Reviewed-on: https://gerrit.chromium.org/gerrit/50012
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This adds back the presubmit hook configuration file
for the ChromeOS build system / repo utility.
BUG=chrome-os-partner:18638
TEST=upload a change to gerrit without --no-verify
and see that repo does not complain about the license
headers anymore.
Change-Id: I82a31afaf2b01a77a2d09da49f5c7a6531dc7681
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49772
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Now that we have RW ramstage we don't need to have the
management engine lock down step done in a final SMM.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: build and boot on wtm2 and look for messages
during the ME device init step:
ME: mkhi_end_of_post
ME: END OF POST message successful (0)
PCI: 00:16.0: Disabling device
Change-Id: I9db4e72e38be58cc875c1622a966d8fcacc83280
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49757
There were two undefined MBP types that are now defined.
These include NFC status and some interesting timing data.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: build and boot on wtm2, check for missing
MBP messages and for timing output.
ME: Wake Event to ME Reset: 6 ms
ME: ME Reset to Platform Reset: 7 ms
ME: Platform Reset to CPU Reset: 51 ms
Change-Id: I67bf1f303f3c32497041e64c40eb9ccb6a63d88a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49756
Without an LM10506-A the power sequencing for this
part needs to be done manually using GPIOs.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=emerge-slippy chromeos-coreboot-slippy
Change-Id: I842152e5f7c30c8dbe37df0c344935a659eb2887
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49648
Reviewed-by: Aaron Durbin <adurbin@chromium.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: I34c747e0d3406351318abf70994dbc0bb3fa6c01
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49766
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.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: https://gerrit.chromium.org/gerrit/49765
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Instead of having an OS re-parse cbmem book-keeping records
for the cbmem allocator just to get the console buffer export
the pointer to the memory console directly in a field named 'CBMC'.
This field lives in the GNVS table.
BUG=None
BRANCH=None
TEST=Built and booted kernel with support for this field.
/sys/firmware/log correctly shows up.
Change-Id: Ief0c4da7b18df66feb9c816c9f4abdf5a72bd3a4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49764
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
For all the current haswell boards enable the monotonic timer.
The ULT boards use the 24MHz MSR while the non-ULT boards use the
local apic.
Change-Id: I8b19f526a5a49e8467f296c566a2c4263bc5a863
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49763
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: I9be5dbd8ad3d56a17f5de827a870fa63608ab8f2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49754
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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>
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: I1ab55ca52e37db02f4fa3c0707170ab162bb78e6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49752
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Implement the timer_monotonic_get() functionality based off of
the local apic timer.
Change-Id: Ifbead8ead0142a2e246d50306f052adce979da9a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49750
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Haswell ULT devices have a 24MHz package-level counter. Use
this counter to provide a timer_monotonic_get() implementation.
Change-Id: I72dce5976acd44376bc8ac1587dcb3c3d5b9f1e7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49749
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>
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: Iae9406efa97690c2ce11737688906dc071de5c7b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49739
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
