The EC was disabling flash commands and sysjump was not working
properly. With those two fixed software sync works properly.
Google Chrome EC MKBP driver ready, id 'slippy_no_version'
Clearing the recovery request.
EC hash:7fea29992ef72e3e64d8ffe522aa1dfa68dcb44a2da96a4c19530ea1a0bd22c4
EC-RW hash address, size are 0xffa1cfe8, 32.
Hash = 727e79934d9394184da496cebc27f7275b9d2d91079bf125d8f977a1f8aa4cde
Expected hash:727e79934d9394184da496cebc27f7275b9d2d91079bf125d8f977a1f8aa4cde
EC-RW firmware address, size are 0xffad000c, 57180.
VbEcSoftwareSync() - expected len = 57180
Computed hash of expected image:727e79934d9394184da496cebc27f7275b9d2d91079bf125d8f977a1f8aa4cde
VbEcSoftwareSync() updating EC-RW...
VbEcSoftwareSync() jumping to EC-RW
VbEcSoftwareSync() in RW; done
Change-Id: I63ca00d6c94854f2b395eb736ce20792da5f8de2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56821
Reviewed-on: http://review.coreboot.org/4208
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
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.
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
Reviewed-on: http://review.coreboot.org/4231
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
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.
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
Reviewed-on: http://review.coreboot.org/4230
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This can be used to indicate sub-state within a POST
code range which can assist in debugging BIOS hangs.
For example this can be used to indicate which device
is about to be initialized so if the system hangs
while talking to that device it can be identified.
Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58104
Reviewed-on: http://review.coreboot.org/4229
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The CMOS post code storage mechanism does back-to-back
CMOS reads and writes that may be interleaved during
CPU bringup, leading to corruption of the log or of other
parts of CMOS.
Change-Id: I704813cc917a659fe034b71c2ff9eb9b80f7c949
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58102
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4227
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ida98f81b1ac1f6b3ba16c0b98e5c64756606fd58
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48318
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4126
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Add a comment, tweak spacing a bit, addr variable
doesn't need to be global any more.
Change-Id: Id8d8a7babce671243351074f7ac52a5c8c264de5
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/4274
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Get rid of not needed dependency to gliu0table. This change is
needed to move get_top_of_ram() to raminit.c - as needed for
EARLY_CBMEM_INIT.
Boot tested on a Bachmann OT200.
Change-Id: I0bfe40c366a3537775d5c1ff8e0b1f5ac94320b7
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/3380
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This was never completed / working and we have the working
ARMv7 port for an architecture template, so get rid of this
dead code.
Change-Id: Ic2c1267ee5546dd6e1b63220c263b2fa86c8ae33
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56065
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4235
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This function will encode the device path into 3
bytes of a dword which can be saved for debug.
It will be used by subsequent commit to store the
current device into CMOS for debugging BIOS hangs.
Change-Id: I3a5155ea53c8d280806e610a0f8998dbabe15f3c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58103
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4228
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Set verbs to reflect the layout used for ALC283 in Falco,
which ends up being the same as Slippy.
Change-Id: I3dce4effefaa91ee5bdcbe2a8a3750ebc41376ad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58196
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4232
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Do not return hardcoded numerical values to communicate succes/failure, but
instead use an enumeration.
Change-Id: I742b08796adf136dce5984b702533f91640846dd
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4265
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The idea is that instead of:
if (do_something()) do_something_else();
It is more readable to write:
if (do_something() != CB_SUCCESS) handle_error();
Change-Id: I4fa5a6f2d2960cd747fda6602bdfff6aef08f8e2
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4264
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Set verbs to reflect the layout used for the ALC283 in slippy.
install on slippy and check that headphone switch works
as does external mic.
Change-Id: I2d6bcda9cf8bbf49cbb6d2dbbe7f1a5adf315d8a
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57560
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4224
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Mass storage devices such as card readers show up as
as USB devices. However the media not be inserted. In those
situations the previous code would just fake a disk and
call usbcreate_disk. This is inappropriate because it forms
a 1:1 mapping of USB device to disk leading to the inability
to remove the disk and/or handle "hot plug" card insertion
and removals.
To alleviate this issue introduce the notion of ready to the
usbmsc structure. It tracks detached, not ready, and ready
states. The polling routine is then used to track not ready
to ready transitions thereby creating and removing disks
appropriately. This handles the case of inserting and removing
a card that shows up as a new disk.
Booted recovery mode. Able to observe inerstion and removal
of sdcard. Also able to insert valid USB flash drive to boot
as well.
Change-Id: I3eefbe537ec1b9c975744b8984b06c17ae236f40
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57948
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4226
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There is currently a hard-coded 30 sec delay in the mass storage
driver while waiting for each device to become ready. However, mass
storage card readers that are empty return an error code on the
TEST UNIT READY command. A REQUEST SENSE command then needs to be
issued and interrogate the data to determine if no media is present.
If no media determination is found to be true the USB device is no
longer considered a candidate to be a disk.
This code does lead to the fact that the media card reader needs to be
populated at enumeration time. I suspect this is not an issue as it
appears the storage stack in libpayload can't handle removable media
coming online later.
Booted recovery and dev modes. Noted that removable mass storage
devices with no media were ignored without any boot delay.
Change-Id: Ida7a45614d97c6e6fbfc9bb099765aad4df550fd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57828
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4225
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Both EHCI and XHCI controllers have additional setup steps
that are not part of the PEI reference code so they need to
be done later.
Both controllers also have specific clock gating setup
requirements that are now implemented.
Additionally they both have specific requirements when entering
sleep states. XHCI needs something in S3/S4/S5 and EHCI only
has steps for S4/S5 entry.
Change-Id: Ic62cbc8b6255455e56b72dd5d52e27a311999330
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57033
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4217
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When an INIT# is delivered to the CPU the CPU starts
executing from the reset vector. However, the internal state
is maintained. Therefore, check for such a condition and
reset the system.
Issues 'apreset warm' on the EC console. INIT# is sent and
CPU notices it's not a clean reset and forces one. No hangs.
Change-Id: I71229e0e5015ba8c60f5989c533268604ecc1ecc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57111
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4216
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Peppy RAM ID table is as follows:
000 41K256M16HA
001 H5TC4G63AFR
010 EDJ4216EFBG
Elpida SPD taken from Ib1e430cd390b4dbc013fc0802f1a59c1a0412577 by
dlaurie.
Change-Id: Iac156a2d25435514f28e2e73bef617d0fe2d90a1
Reviewed-on: https://gerrit.chromium.org/gerrit/56687
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4201
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Taken directly from slippy with only constant + string changes.
(Peppy port of I4172460d3b075bfd5bb22013a6225cf0e8f95b9c by dlaurie)
The following changes are required in a subsequent commit:
- Add Elpida SPD data.
- Update GPIO map.
- Remove iSSD power sequencing.
- Update USB port map.
Change-Id: I01dfb841f0e9186cf8a0a23f72e7be986a83be42
Reviewed-on: https://gerrit.chromium.org/gerrit/56513
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4200
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
RAM_ID indices have been changed and settled on a 2GB config
that will be the same DRAM chips but only used in one channel.
Change-Id: I444e655883ae045622ab3dfb964da4d7f86e1c0d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56810
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4198
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are placeholder values until we can configure for
the exact panel.
Change-Id: If40367c0e5f80d46d085c89b0edae60f1ccacdaf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56808
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4197
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The haswell i915 kernel driver apparently expects the VBIOS
to set a few specific registers. This sequence is enough to
make the driver happy without executing the VBIOS.
This also makes graphics work after suspend/resume.
Change-Id: I34937d55ffff8a9445442e6e6ca1bfc49869da63
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56806
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4195
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add the onboard I2C devices for Falco trackpad/lightsensor
and generate SMBIOS Type41 tables for them.
Add ACPI device for the trackpad to expose the interrupt map
to the OS so it can be used.
Configure interrupt GPIOs as PIRQ type and wake GPIOs as
just standard input type. The wake GPIO is reconfigured as
ACPI SCI in the specific device _DSW method. This prevents
the wake GPIO from generating a flood of SCI at runtime.
LTE_WAKE_L_Q and WLAN_WAKE_L_Q are left as ACPI SCI as these
are not repurposed interrupt pins so they are not generated
at runtime.
SIM_DET and ALS_INT_L are set as input since we don't have an
interrupt handler for them.
Change-Id: Ibe9687b2f7f41ead18353c3f650219fe6e94ae2f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56632
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4191
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add the onboard I2C devices for Slippy trackpad/lightsensor
and generate SMBIOS Type41 tables for them.
Add ACPI device for the trackpad to expose the interrupt map
to the OS so it can be used.
Configure interrupt GPIOs as PIRQ type and wake GPIOs as
just standard input type. The wake GPIO is reconfigured as
ACPI SCI in the specific device _DSW method. This prevents
the wake GPIO from generating a flood of SCI at runtime.
LTE_WAKE_L_Q and WLAN_WAKE_L_Q are left as ACPI SCI as these
are not repurposed interrupt pins so they are not generated
at runtime.
SIM_DET and ALS_INT_L are set as input since we don't have an
interrupt handler for them.
tested on slippy with trackpad with additional
kernel changes to chromeos_laptop.c to initialize devices.
1) Ensure trackpad interrupt is functional and that there
is not a flood of ACPI SCI when trackpad does interrupt:
9: 1 0 0 0 IO-APIC-fasteoi acpi
37: 421 0 0 0 IO-APIC-fasteoi cyapa
2) Ensure that devices are exposed as wake capable:
Device S-state Status Sysfs node
TPAD S3 *enabled pnp:00:00
TSCR S3 *disabled pnp:00:01
3) Ensure that trackpad can wake from S3 by default, but
that it does not cause an immediate wake when entering suspend.
4) Ensure that trackpad can be disabled as a wake source with
echo TPAD > /proc/acpi/wakeup
Change-Id: Id562d20b54eeefec56040b8f70ef238911312628
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56622
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4190
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is an LPT-LP specific method that will enable a specific
GPIO as an ACPI SCI wake source.
It can be used by a device _DSW method to enable a pin that is
otherwise not configured to generate SCI at runtime.
It will set:
- GPIO owner to ACPI
- GPIO route to SCI
- GPIO config to GPIO, Input, Inverted
Also clean up and remove ACPI field definitions that are unused
and/or incorrect.
Change-Id: I14acc2de50e6200f61c2898a7bd1252400e0f0be
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56621
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4189
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This was provided by the vendor but I added the part number at
byte 128-143 so it can be identified when extracted by mosys.
Change-Id: Ib1e430cd390b4dbc013fc0802f1a59c1a0412577
Reviewed-on: https://gerrit.chromium.org/gerrit/56634
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4192
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In addition to not clearing the pending interrupts, we also
don't want to reset the RTC control register when booting
with an S3 resume.
On most new systems, when the RTC well is losing power, we
will also lose state that is required to perform a resume,
so we end up in a normal boot anyways. Hence don't do any
RTC initialization in the S3 resume path.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I73b486082faa741e9dccd15f2b8e3a8399c98f80
Reviewed-on: https://gerrit.chromium.org/gerrit/56826
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4206
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some code was previously removed regarding elf notes. However,
that code left a dangling comma under !CONFIG_MULTIBOOT
configs for inline assembly constraints. Instead, place the comma
within the #ifdef stanza.
Change-Id: I805453ef57d34fbfb904b4d145d8874921d8d660
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56844
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Reviewed-on: http://review.coreboot.org/4207
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These GPIO accesses were copied by accident and don't
make sense for the baskingridge board.
Change-Id: I03bfc2cf97b6056a746a6c1a27308823ecaa9637
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4204
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
LynxPoint-LP has an additional 16 entries in the IOAPIC that
can be assigned to specific GPIOs when they are configured
as PIRQ.
The maximum redirection entries field in the IOAPIC needs to
be set to 0x27 when this is enabled.
Additionally specific GPIOs need to be routed to PIRQ so they
interrupt via the IOAPIC instead of the GPIO IRQ 14/15.
Change-Id: Ie587e1d203422ff6fb7fc5056d20a5ae66720991
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56620
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4203
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The LynxPoint southbridge ACPI code needs the SSDT2 table to function
properly. Otherwise the ACPI evaluator in the kernel spews errors.
Change-Id: I73918545a07e43f4a281ff34d8537340d601b102
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56601
Reviewed-on: http://review.coreboot.org/4188
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Mainboards were defining their own SMBIOS type41
write function. Instead pull this into the generic
SMBIOS code and change the existing mainboards to
make use of it.
Change-Id: I3c8a95ca51fe2a3118dc8d1154011ccfed5fbcbc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56619
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4187
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A parrot device with a bad flash part has been seen to hang
in the elog_shrink code becuase the flash was not successfully
erased and it gets stuck in a loop trying to shrink the log
and then add an event.
Change-Id: I8bb13dbadd293f9d892f322e213c9255c8e9acb3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56405
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4186
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Update and use the new pei_data data structure. Now that the
reference code is fixed it's possible to properly disable/enable
the USB2 and USB3 ports correctly.
Change-Id: I075c646e7574be354420b6e59507e8917a97d0f0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56594
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4185
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Only the first two DIMM SPDs are specified so far
- GPIO map is updated
- iSSD power sequencing removed
- USB port map updated
Change-Id: I4172460d3b075bfd5bb22013a6225cf0e8f95b9c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56329
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4184
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The ssdt2 generation code was calling acpigen_patch_len().
However, none of the entries had AML object lengths that
needed patching. That resulted in the following message:
ASSERTION FAILED: file 'src/arch/x86/boot/acpigen.c', line 52
Additionally, this caused an errant write to a memory address
whose value was in the variable ltop. This was the 0 address.
Change-Id: I44abf5a4e4225220575aee6b5c9bb6b0be093a28
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56299
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The ACPI code was defining two EHCI controllers and ignoring
the XHCI controller. This changes the second EHCI controller
to be XHCI instead and changes the wake resource to indicate
S3 and not S4.
cat /proc/acpi/wakeup
Device S-state Status Sysfs node
HDEF S4 *disabled pci:0000:00:1b.0
EHCI S3 *enabled pci:0000:00:1d.0
XHCI S3 *enabled pci:0000:00:14.0
Change-Id: If28775e6ef8608c22c85ca91d91d1f598ec7755d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56263
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4181
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The architecture name for our ARM port is armv7, not arm.
Hence, none of those flags were ever actually used.
Fix the architecture name and remove the flags, they should
not be set in xcompile, but in the Makefile, like in coreboot.
Change-Id: Id9c5db7ebceafddb58a1ce1988417f09c074ba6c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56084
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4179
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Enable GPIO SMI for GPIO34 and set it as inverted so it
is only generated when it is raised by the EC.
1) ec console command: lidopen
2) wait until booted to developer screen
3) ec console command: lidclose
4) ensure system turns off
Change-Id: I7d50f171f3f4539c7c264103d1ffc7c5d0f1c7ba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56052
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4177
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Restructure USB stack to not depend on PCI, and
make PCI stub available on x86, but provide fixed
BARs for ARM (Exynos 5)
Change-Id: Iee7c8b134c22b661a9a515e24943470c9dbadd1f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49970
Reviewed-on: http://review.coreboot.org/4175
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Two structures in the USB EHCI stack were pointing
to hardware but not marked attribute((packed)) hence
leaving it to GCC to correctly align the data structures.
Next, the number of reserved bytes in hc_op_t was wrong
(but implicitly aligned to the correct values on x86)
It seems this worked fine on x86, but on ARM it was doing
the wrong thing.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I94bed4850ded7d3f7bbc7ff3079c103c6054c22d
Reviewed-on: https://gerrit.chromium.org/gerrit/55555
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4174
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The vendor ids were never updated to reflect LynxPoint's device
ids. Therefore, none of the initialization was being ran. Fix
this.
Change-Id: Ic6ec00c9fb1cbcb6087fd89b0acff3d83294ac6a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55821
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4173
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to report whether coreboot enabled a SerialIO device
in ACPI mode we had been relying on reading NVS in the _STA
method for the SerialIO device.
The ACPI _STA method has restrictions on what it can access
and is unable to access OperationRegions outside its scope
which means it should not be trying to read NVS.
This change adds a new SSDT to the ACPI tables and fills it
with constants that indicate whether or not a device is enabled
in ACPI mode.
The ACPI code is changed to read these variables from the
SSDT and use that instead of trying to query a variable in NVS.
Attempt to use lpt-clk driver to probe the
device clocks for SerialIO devices and see that the kernel
does not complain about accessing the GNVS region.
Change-Id: I8538bee4390daed4ecca679496ab0cb313f174ce
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51369
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4170
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Disable EC software sync for now
- Report correct EC active firmware mode
- Force enable developer mode by default
- Set up PCH generic decode regions in romstage
- Pass the oprom_is_loaded flag into vboot handoff data
Change-Id: Ib7ab35e6897c19455cbeecba88160ae830ea7984
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51155
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4169
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These boards were returning 0 to indicate success when
the realmode handler expects it to return 1 to indicate
that it handled the interrupt.
Change-Id: I2baeaf8c2774fa7668a8b2f2d9ad698302eefb21
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50881
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4168
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are both pulled up to 3.3V in the schematic.
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>
Reviewed-on: http://review.coreboot.org/4164
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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.
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>
Reviewed-on: http://review.coreboot.org/4161
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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.
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>
Reviewed-on: http://review.coreboot.org/4159
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Duncan Laurie