On x86 there is a 16-byte alignment requirement for the
addresses containing the CPU microcode. The cbfs files
containing the microcode are used in memory-mapped fashion
when loading new mircocode. Therefore, the data payload's
address/offset of a cbfs file in flash dictates the resulting
alignment. Fix this by processing the CPU microcode cbfs
file separately as it uses $(CBFSTOOL) to find the proper
location within the provided rom image.
BUG=chrome-os-partner:20100
BRANCH=None
TEST=Manually inspected cbfs layout:
CBFS @ Offset 0x00700000 into 0x00800000 ROM size
[0xfff00000] cmos_layout.bin type cmos layout (0x1aa) @ 0xfff00028,
0x48c (1164) bytes
[0xfff004c0] pci8086,0406.rom type optionrom (0x30) @ 0xfff004f8,
0x10000 (65536) bytes
[0xfff10500] cpu_microcode_blob.bin type microcode (0x53) @ 0xfff10560,
0x9c40 (40000) bytes
[0xfff1a1c0] config type raw (0x50) @ 0xfff1a1e8, 0x157f (5503) bytes
[0xfff1b780] fallback/vboot type stage (0x10) @ 0xfff1b7a8, 0x3ad3
(15059) bytes
[0xfff1f280] (empty) type null (0xffffffff) @ 0xfff1f2a8, 0xcd8 (3288)
bytes
[0xfff1ff80] fallback/romstage type stage (0x10) @ 0xfff1ffe4, 0xa001
(40961) bytes
[0xfff2a000] fallback/coreboot_ram type stage (0x10) @ 0xfff2a038,
0x15373 (86899) bytes
[0xfff3f3c0] fallback/payload type payload (0x20) @ 0xfff3f3f8, 0xd00e
(53262) bytes
[0xfff4c440] u-boot.dtb type unknown (0xac) @ 0xfff4c468, 0x1e4b (7755)
bytes
[0xfff4e2c0] (empty) type null (0xffffffff) @ 0xfff4e2e8, 0x51cd8
(335064) bytes
[0xfff9ffc0] mrc.bin type mrc (0xab) @ 0xfffa0000, 0x2d8b8 (186552)
bytes
[0xfffcd8c0] (empty) type null (0xffffffff) @ 0xfffcd8e8, 0x1e6d8
(124632) bytes
[0xfffebfc0] spd.bin type mrc (0xab) @ 0xfffec000, 0x200 (512) bytes
[0xfffec200] (empty) type null (0xffffffff) @ 0xfffec228, 0x13418
(78872) bytes
Change-Id: Icc676a1c76c368d77e48cf573c6f846301da42a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58238
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Set verbs to reflect the layout used for ALC283 in Falco,
which ends up being the same as Slippy.
BUG=chrome-os-partner:19934
BRANCH=none
TEST=manual - check that headphone/mic works on falco board
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>
Change every "boot loader 1" to be same file name in different folders.
BUG=none
TEST=manual: emerge-daisy chromeos-firmware-snow
BRANCH=none
Change-Id: Ie709b74b3bd3340f2cdc7b5685300102340bb399
Reviewed-on: https://gerrit.chromium.org/gerrit/58125
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
This enables the logging of device path into CMOS
to assist in debug of boot and resume hangs.
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: Ibe78499ddfeac522a73c7324da8ab6e4f2d1945b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58107
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>
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.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: verify post codes in CMOS during suspend/resume test
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>
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.
BUG=chrome-os-partner:19596
BUG=chrome-os-parnter:20014
BRANCH=None
TEST=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>
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.
BUG=chrome-os-partner:19596
BRANCH=None
TEST=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>
Set verbs to reflect the layout used for the ALC283 in slippy.
BUG=chrome-os-partner:19934
BRANCH=none
TEST=manual - 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>
There are hundreds of GPIOs on the Exynos5250. Don't
always print all of them per default.
BUG=none
BRANCH=none
TEST=Notice a much saner output on serial console
Change-Id: Id2a7bb26356633e4e298614a051765c644fa85fc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55556
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
In order to make the proper decision on loading the
option rom or not the recovery mode setting needs to be
known. Normally this is detected by asking the EC,
but if recovery is requested with crossystem then the EC
does not know about it. Instead we need to check the
output flags from VbInit().
BUG=chrome-os-partner:19928
BRANCH=none
TEST=manual: enter recovery mode with crossystem and
ensure the vbios is loaded properly
Change-Id: I09358e6fd979b4af6b37a13115ac34db3d98b09d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57474
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since we are using VBNV to determine if developer mode is
active we do not need the messy OPROM hook magic any longer.
BUG=chrome-os-partner:19928
BRANCH=none
TEST=manual: boot in dev/rec modes and ensure vbios is loaded
Change-Id: I1b9effef3ef2aa84e916060d8e61ee42515a2b7c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57473
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The Chrome EC still does not tolerate SERIRQ in quiet mode
and so the keyboard does not work properly.
BUG=chrome-os-partner:19929
BRANCH=none
TEST=manual: verify working keyboard on slippy
Change-Id: I8468c811d312d55b2af10eab4996d6a3347816e4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57472
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The OIPG package needs to have >1 member to make the chromeos_acpi
kernel driver do the right automagic sysfs topology creation.
Additionally an "unimplemented" GPIO should be reported as 0xFF
because 0 is a valid GPIO number.
BUG=chrome-os-partner:19931
BRANCH=none
TEST=manual: verify crossystem on slippy
$ sudo crossystem | grep -e recoverysw_cur -e wpsw_cur
recoverysw_cur = (error)
wpsw_cur = 1
Change-Id: I06dff09152bde30a3ffe58b1defe9d299155472c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57471
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Now that we are executing VbInit() in coreboot we can end up
in a situation where the recovery reason is consumed during
VbInit (end of romstage) and then the EC is rebooted to RO
during ramstage EC init, thereby losing the recovery reason.
Two possiblities are to remove the EC check+reboot from ramstage
and let it happen in depthcharge. This however means that the
system has to boot all the way into depthcharge and then reboot
the EC and the system again.
Instead if we do a check in romstage before VbInit() is called
then we can reboot the EC into RO early and avoid booting all
the way to depthcharge first.
This change adds a ramstage version the EC init function and
calls it from the shared romstage code immediately after the
PCH decode windows are setup.
BUG=chrome-os-partner:19928
BRANCH=none
TEST=manual: enter recovery with crossystem recovery_request=193
Change-Id: Ic927c69a95a2114e29c343f0dcc28374266db394
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57470
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This config option was not enabled which was preventing
the user from enabling developer mode from recovery mode.
With this enabled we can disable the "dev mode by default"
behavior and let people enable it by entering recovery mode.
This will make the firmware behave like a typical chromeos
device.
Peppy is left in "default dev mode" until after bringup.
BUG=chrome-os-partner:19637
BRANCH=none
TEST=manual:
1) boot slippy in normal mode by default
2) enter recovery mode with servo button
3) Ctrl+D on USB keyboard to enter developer mode
4) boot slippy in developer mode
Change-Id: I414c0d10dd0489e3c89798f75a2872a43297c8d8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57350
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Add a new USB location field
- Add a new "ddr_refresh_2x" field, enabled on Falco only
- Fix copy+paste bug in baskingridge
BUG=chrome-os-partner:19869
BRANCH=none
CQ-DEPEND=CL:*39053
TEST=manual: test to ensure refresh rate 2x can be enabled
Checked that tREFI is halved during memory setup in the memory
training log:
tREFImin = 6240 << DEFAULT
C(0).tREFI = 0xc30 << MODIFIED (=3120)
C(0).tREFI = 0xc30 << MODIFIED (=3120)
Also ensure that the SD card is detected properly again.
Change-Id: Ie3a82c08df06ada9af56282b5255caefa56487f2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57349
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to make the proper decision on loading the
option rom or not the developer mode setting needs to be
known. Under early firmware selection it is possible to know
the state of developer mode by a flag in out flags. Use this
flag when early firmware selection is being employed to determine
if developer mode is enabled or not.
BUG=None
BRACNh=None
TEST=booted slippy w/ patch and option rom is loaded correctly when
virtual dev switch is employed.
Change-Id: I9c226d368e92ddf8f14ce4dcde00da144de2a5f3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57380
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
- Updated ec_commands.h is copied in directly from EC repo
- Removed "old" interface and update resources for "new" interface
- Updated temp sensor constants and added "not calibrated"
- Update mainboards to remove check for EC_SWITCH_KEYBOARD_RECOVERY
BUG=chrome-os-partner:19874
BRANCH=none
TEST=manual: tested on slippy to ensure EC communication still works
Change-Id: Ib9cab27d9987b380da74926794b49ebabbc9e5d7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57348
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: build and boot on slippy and verify basic USB operation
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>
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.
BUG=chrome-os-partner:19355
BRANCH=None
TEST=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>
The commit introducing dummy_media.c was placed in the
libc object list. This wasn't correct. It should be in the
libcbfs object list as well as guarded by CONFIG_CBFS.
BUG=None
BRANCH=None
TEST=Built with USE=depthcharge emerge-daisy depthcharge libpayload
Change-Id: Iace43fff8f85f60ecac5e6eb8350cd1f3ee9d35e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56925
The EC was disabling flash commands and sysjump was not working
properly. With those two fixed software sync works properly.
(Taken from I63ca00d6c94854f2b395eb736ce20792da5f8de2).
BUG=chrome-os-partner:19636
BRANCH=none
TEST=emerge-peppy chromeos-coreboot-peppy
Change-Id: I9c7d1d1f1aaf7de33d0cec5f6daf648576ba8900
Reviewed-on: https://gerrit.chromium.org/gerrit/57289
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
It's possible that the TOUUD can be set to less than
4GiB. When that is the case the size_k variable is
an extremely large value. Instead ensure TOUUD is greater
than 4GiB before adding said resources.
BUG=None
BRANCH=None
TEST=Built and booted.
Change-Id: I456633d6210824e60665281538300fd15656b86d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57329
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There are useful values in NVS that are set at boot
and runtime and they should not be cleared on resume.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: suspend/resume twice on slippy and ensure
that the USB ports are still powered on the second suspend.
Change-Id: I4bce60b02b6637f6683120ae9c4a5c64563aacf7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56941
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The wake device input pins are active low and the
GPIOs need to be set as inverted when they are marked
as an input so they are not spuriously logged.
BUG=chrome-os-partner:19664
BRANCH=none
TEST=manual: suspend/resume on slippy with trackpad wake:
8 | 2013-05-29 07:43:14 | ACPI Enter | S3
9 | 2013-05-29 07:43:18 | ACPI Wake | S3
10 | 2013-05-29 07:43:18 | Wake Source | GPIO | 12
and with power button wake:
11 | 2013-05-29 07:43:35 | ACPI Enter | S3
12 | 2013-05-29 07:43:40 | EC Event | Power Button
13 | 2013-05-29 07:43:40 | ACPI Wake | S3
14 | 2013-05-29 07:43:40 | Wake Source | Power Button | 0
Change-Id: I15d38dcc9b2fb4b2b0eb27da358fa3c343e22323
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56940
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The EC was disabling flash commands and sysjump was not working
properly. With those two fixed software sync works properly.
BUG=chrome-os-partner:19366
BRANCH=none
TEST=boot with updated EC to test software sync
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
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.
BUG=None
BRANCH=None
TEST=Successfully built wtm2.
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>
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>
BUG=none
TEST=Resume on Link, observe RTC initialization is skipped
BRANCH=none
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>
There were assumptions being made in the haswell
MP and SMM code which assumed the APIC id space
was 1:1 w.r.t. cpu number. When hyperthreading is
disabled the APIC ids of the logical processors
are all even. That means the APIC id space is sparse.
Handle this situation.
BUG=chrome-os-partner:19699
BRANCH=None
TEST=Used HT disabled part on WTM2. No more spontaneous reboots.
Change-Id: Ia4e3aa7456092e0ac0ea0ef16f10ba638a3e6dbe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56824
Reviewed-by: Duncan Laurie <dlaurie@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>
With only 19 source files it doesn't make a whole lot of sense to
create sub directories in arch/armv7, especially since the files
were distributed somewhat randomly.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
TEST=emerge-daisy chromeos-coreboot-snow builds.
BRANCH=none
Change-Id: I0c3dafb5deb7d70955a8b08be062b3c9824525ff
Reviewed-on: https://gerrit.chromium.org/gerrit/56651
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.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.
BUG=chrome-os-partner:19636
BRANCH=none
TEST=manual: emerge-peppy chromeos-coreboot-peppy
CQ-DEPEND=I3da8679d5ac9752eca75264589f66451eadad94c
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>
The generic cbfs code relies on the libpayload_init_default_cbfs_media
symbol. However, none was provided for ARM. Provide an empty
implementation that returns an error as there is no generic way
to locate the default cbfs media.
BUG=None
BRANCH=None
TEST=emerge-daisy libpayload depthcharge
Change-Id: Ie0d06fbe6fc790c9d92434cd2d60922908acdc69
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56805
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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.
BUG=chrome-os-partner:19657
BRANCH=none
TEST=emerge-falco chromeos-coreboot-falco
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>
These are placeholder values until we can configure for
the exact panel.
BUG=chrome-os-partner:19638
BRANCH=none
TEST=tested on slippy
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>
These are placeholder values until we can configure for
the exact panel.
BUG=chrome-os-partner:19638
BRANCH=none
TEST=manual: boot in normal mode on slippy
Change-Id: Ibe88cc3588947366eb1728e5b3e1ab8c8be6dfe8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56807
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=chrome-os-partner:19638
BRANCH=none
TEST=manual: boot normal mode on slippy
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>
The ram_media.c file is being compiled, however the
global functions were not exposed through a header.
BUG=chrome-os-partner:19691
BRANCH=none
TEST=Built depthcharge with including cbfs_ram.h and
calling the exposed functions.
Change-Id: I4588fbe320c29051566cef277bf4d20a83abf853
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56642
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The ram_map() handled offsets from 0->size as well as
negative offsets from the top of the region. However,
the cbfs core tries to map a offset that is actually a
pointer within the region itself. Allow for such instances.
This fixes an issue when using ram_media with tthe ebmedded
SeaBIOS cbfs.
BUG=chrome-os-partner:19691
BRANCH=none
TEST=manual: used ram_media to parse embedded SeaBIOS cbfs properly.
Change-Id: I15b0b3b643390d3784ae5887c0f17d420d59c5b6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56641
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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.
BUG=chrome-os-partner:19637
BRANCH=none
TEST=manual: emerge-falco chromeos-coreboot-falco
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>
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.
BUG=chrome-os-partner:19637
BRANCH=none
TEST=tested on slippy as part of previous commit
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>
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.
BUG=chrome-os-partner:19664
BRANCH=none
TEST=manual: 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>
