SPD GPIOs were being read prior to initialization in romstage_common. To
fix, pass the copy_spd function to romstage_common, to be called at the
appropriate time (after PCH init, before DRAM init).
BUG=chrome-os-partner:20162.
TEST=Manual. Test on peppy board with non-zero SPD GPIOs, verify correct
SPD is selected.
Change-Id: I2554813e56a58c8c81456f1a53cc8ce9c2030a73
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58608
The PCI ids for the EHCI devices were not update to reflect
LynxPoint's PCI ids.
BUG=chrome-os-partner:20174
BRANCH=None
TEST=Manual: looked for "EHCI: Setting up controller.. " in console.
Change-Id: I5a2e1d746700d45341817b065bc41dc83f508063
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58622
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit with another change and an external tool, and was
able to get serial output. Built for snow.
BRANCH=None
Change-Id: Ie27ae7a7b22f336d23893618969efde4145fefd7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57725
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
There are hundreds of GPIOs on the Exynos5420. Don't
always print all of them per default.
BUG=none
BRANCH=none
TEST=Notice a much saner output on serial console
Change-Id: Ie0749e2a7757fd06549918208c9d6e6366f1f2f9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55812
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
remove some unused code
BRANCH=none
TEST=none
BUG=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I048f111b4f4c7a6c987cc7404bd073848619e908
Reviewed-on: https://gerrit.chromium.org/gerrit/57017
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
If we clear the framebuffer and then flush it back to memory using cache
operations, the writes are going to be full cachelines at a time. If we
make it uncacheable first, the writes will be serialized writes of
whatever sized chunks memset uses, probably 4 bytes or less.
BUG=None
TEST=None
BRANCH=None
Change-Id: I59d6699fcea1c5ca4402ae6cf45df9c14878943a
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55837
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
At one time it seemed to be necessary to disable and then re-enable the
MMU when setting the framebuffer to be uncache-able due to bugs in the
MMU management code. Since those bugs have been fixed, this is no longer
necessary.
BUG=None
TEST=None
BRANCH=None
Change-Id: I1fb2bd6e14777470456e9517d3efba24c3b170a0
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55836
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already
known when that structure was put together. Eliminate the extra space,
and pass the single value instead of the structure.
BUG=None
TEST=None
BRANCH=None
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ia21bcbfdd0007e9088c98c339aa031853a282cf5
Reviewed-on: https://gerrit.chromium.org/gerrit/55835
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
These are based on the datasheet and I included the timing
values I used from the docs.
BUG=chrome-os-partner:19637
BRANCH=none
TEST=manual: Boot on falco and see working display
Change-Id: Ib75b2c5e50ac09d1e4cf9dd22229bb0f0a8965a4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58540
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code which figured out the rate of the input clock to a peripheral was
doing several things wrong. First, it was using the wrong values when
determing what the source of a clock was set to. Second, it was using the
wrong offset into that register to find the current source setting.
This change fixes the constants which select a clock source which get some
more things working, but doesn't attempt to fix the bit position table.
BUG=chrome-os-partner:19420
TEST=Built for pit with another change and an external tool, and was able to
receive serial output.
BRANCH=None
Change-Id: Ia2cea7ce8ee2c8ae721e09069bcf9711b1d30aec
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57726
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Not all ARM systems need "BL1", and the layout of BL* and bootblock may be
different (ex, Exynos 5250 may use a new BL1 with variable length checksum
header).
To support that better, define the real base address (and ROM offset) of boot
block, and then we can post-processing ROM image file by filling data / checksum
and any other information.
BUG=none
TEST=manual: emerge-daisy chromeos-coreboot-snow;
emerge-peach_pit chromeos-coreboot-peach_pit
BRANCH=none
Change-Id: I9b3ee083c2edac64a653d5d7dffc123d252878d7
Reviewed-on: https://gerrit.chromium.org/gerrit/58342
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The LPC-based ChromeOS EC uses several ioport regions to communicate with
the AP. In order for the new unified userspace access method to work, we
need them to be reserved by the BIOS.
Before /proc/ioports shows:
0800-0803
0804-08ff
We'd like just a single 256-byte region at 0x800, but ASL can't handle that.
So this will work:
0800-087f
0880-08ff
BUG=chromium:249009
BRANCH=none
TEST=manual
cat /proc/ioports, look for the correct regions.
Change-Id: I08ab8c3d3607ef2d43fc2b33bb20235679f2e2e4
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58389
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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>
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>
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 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>
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>
