| Age | Commit message (Collapse) | Author |
|---|
|
No ROMCC involved, no need to include .c files in romstage.c.
Change-Id: I8a2aaf84276f2931d0a0557ba29e359fa06e2fba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4501
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
walkcbfs() is used only with ROMCC. Besides finding stages during the
bootblock, it's also used when applying microcode updates during the
bootblock phase. The function used to return only a pointer to the data of
the CBFS file, while making the header completely inaccessible. Since the
header contains the length of the CBFS file, the caller did not have a way
to know how long the data was. Then, other conventions had to be used to
determine the EOF, which might present problems if the user replaces the
CBFS file. This is not an issue when jumping to a stage (romstage), but can
present problems when accessing a microcode file which has not been
NULL-terminated.
Refactor walkcbfs_asm to return a pointer to the CBFS file header rather
than the data. Rename walkcbfs() to walkcbfs_head(), and reimplement a new
walkcbfs() based on walkcbfs_head(). Thus current usage of walkcbfs()
remains unaffected.
The code has been verified to run successfully under qemu.
Subsequent patches will change usage of walkcbfs() to walkcbfs_head where
knowing the length of the data is needed.
Change-Id: I21cbf19e130e1480e2749754e5d5130d36036f8e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4504
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
During the update_fit step, 'file_length' is used to determine how many
bytes are left in the CBFS file. It was decremented in a loop from an
array 'mcus[num_mcus].size', but 'num_mcus' was incremented right before.
Since 'mcus' is memset(0) externally, 'file_length' was never decremented.
The loop exited when it reached a dummy terminator, usually 48 bytes of 0
which are internationally added to microcode blobs in coreboot. However,
if that terminator is removed, the loop doesn't stop and continues until
it segfaults.
Change-Id: I840727add69379ffef75b694d90402ed89769e3b
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4508
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
If the unpacking was interrupt by Ctrl-C, probably part of
an archive is unpacked. If we run buildgcc again, the
incomplete folder would be and skipped.
We can create a file to tell the script the unpacking is done.
Change-Id: Id9eb74d119e22b62c70dca9b38a92c3dbdf0f64c
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4512
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The architecture information has been added to the folders to
build archives for crossgcc. We need to change the .gitignore
to keep ignoring them.
Change-Id: Ic18685e507f1b09088120eee6047d49141e29906
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4513
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
I am planning to write a document for new man, helping them to build a
working image from knowing nothing about Coreboot. The previous
LinuxBIOS-AMD64.tex was a good script.
LinuxBIOS was a out-of-date name. It needs to be changed it to Coreboot.
And the new document is not specific to AMD, so we get rid of the AMD64 from
the file name.
This is a separate patch for the renaming.
LinuxBIOS-AMD64.tex was still about SVN and buildtarget. Later patch
will come up for updating those old thing. And this new document,
CorebootBuildingGuide.tex, is planning to be only about building.
Navigating the source code is moved to later advanced document.
Change-Id: Ia8a2fd9db51e9870c1d645067bcfdc91ae1bf90a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4487
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Change-Id: I6acafee948b1224b88fd640e02c18168c1f90e39
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4496
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Make boards take less vertical space, and link to board pages
Change-Id: Ifdd062a15191809b75422416c874161d9114363d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4493
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Instead of having global variables put them on the stack.
Change-Id: I462e3b245612ff2dfb077da1cbcc5ac88f8b8e48
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4288
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
It was suggested to eliminate the lock for sprintf. One way to do it is
to make the fake tx_byte into a closure. This patch allows it.
It's a bit tricky since we need to preserve compatibility with romcc.
Change-Id: I877ef0cef54dcbb0589fe858c485f76f3dd27ece
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4287
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
These were terribly under-documented
Change-Id: I285ea083110d87076281e81065f5f38d0c688358
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4491
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Configure the VR controller. This enables the PSIx levels
as well as C-state ramping. PSIx thresholds are:
- PSI3: 1A.
- PSI2: 5A.
- PSI1: 15A.
Before:
0x601 0x0000000000000100
0x603 0x0036000000262626
0x636 0x000000000000006f
After:
0x601 0x4010140f00000100
0x603 0x0036000000262626
0x636 0x000000000000006f
Change-Id: I6958845ac4164ebd0f1bb2d6d9be55ba63ed9344
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60931
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://review.coreboot.org/4338
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Newer mainboards that use haswell -- and, presumably, chipsets to come -- need
some support functions. Add them in the drivers/intel/gma directory.
Currently, this is one file: intel_ddi.c, but more may come.
Compilation of this file is controlled by INTEL_DDI, defined
in the Kconfig as default n and used in the Makefile.inc
Change-Id: I501ee291c0d4589925ed3e478f67106337fcad31
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60612
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4337
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
We use junit style output these days.
Change-Id: I4110ec10bf0e9f4354ee08e7e1c5a81ae605fee0
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4484
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Add ACPI Methods to enable and disable power limiting with PL1.
This can be used in ACPI Thermal Zone or in EC ACPI _QXX events.
This commit adds new unused methods and is fully tested with the
subsequent commit that makes use of these methods.
Change-Id: I9d8d23bfe9cf7c756ff8ab0412e5a010826b12db
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60546
Reviewed-on: http://review.coreboot.org/4334
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
1) fix enable of power aware interrupt routing
2) set BIOS_RESET_CPL to 3 instead of 1
3) mirror PKG power limit values from MSR to MMIO on all SKUs
4) mirror DDR power limit values from MMIO to MSR
5) remove DMI settings that were from snb/ivb as they do
not apply to haswell
1) verify power aware interrupt routing is working by looking
in /proc/interrupts to see interrupts routed to both cores
instead of always to core0
BEFORE: 58: 4943 0 PCI-MSI-edge ahci
AFTER: 58: 4766 334 PCI-MSI-edge ahci
2) read back BIOS_RESET_CPL to verify it is == 3
localhost ~ # iotools mmio_read32 0xfed15da8
0x00000003
3) read PKG power limit from MMIO and verify it is the same
as the MSR value
localhost ~ # rdmsr 0 0x610
0x0000809600dc8078
localhost ~ # iotools mmio_read32 0xfed159a0
0x00dc8078
localhost ~ # iotools mmio_read32 0xfed159a4
0x00008096
4) read DDR power limit from MSR and verify it is the same
as the MMIO value (note this is zero based on current MRC input)
localhost ~ # rdmsr 0 0x618
0x0000000000000000
localhost ~ # iotools mmio_read32 0xfed158e0
0x00000000
localhost ~ # iotools mmio_read32 0xfed158e4
0x00000000
Change-Id: I6cc4c5b2a81304e9deaad8cffcaf604ebad60b29
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60544
Reviewed-on: http://review.coreboot.org/4333
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Limit power to 12W at 73C and remove limit at 68C.
To have the CPU consume maximum power it is necessary to stress
both the CPU and the GPU. Bastion (chrome.supergiantgames.com)
and/or webglsamples.googlecode.com can be useful for this.
Testing this properly requires a script to report the running
average power readings. The watch_power.sh script is attached
to this issue in the partner tracker.
1) Run watch_power.sh continuously:
localhost ~ # watch -n 0 bash -e /tmp/watch_power.sh
2) Start Bastion (or other stress apps). The power draw should
be close to 15W if under enough load.
3) Watch until temperature climbs above 73C and is caught by
the thermal zone 10 second poll, this can be sped up by blocking
or removing the fan.
4) The ACPI thermal zone states should change to reflect that
active[2] is now enabled and power consumption should drop to 12W.
5) Stop the stress apps and wait until the CPU cools off again,
enable the fan again if it was removed.
6) The ACPI thermal zone state should switch back to active[3].
Change-Id: Ie6714a8543d4f06edf8513086fc9c968273bdb23
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60545
Reviewed-on: http://review.coreboot.org/4335
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The elog code calculates flash offsets and their equivalent
addresses in the memory address space. However, it assumes
the detected flash size is entirely mapped into the address
space. This can lead to incorrect calculations. Add code
to allow ROM_SIZE to be less than detected flash size. The
underlying assumption is that the first ROM_SIZE bytes are
programmed into the larger device.
Change-Id: Id848f136515289b40594b7d3762e26e3e55da62f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60501
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4332
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Some files have incorrect/odd permissions,
correct them: remove unnecessary +x flags.
Change-Id: I784e6e599dfee88239f85bb58323aae9e40fb21c
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/4490
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
|
|
Delete files that (were overlooked and) are probably needed to
build with Visual Studio.
Remove doxygen helper files as well.
Change-Id: I6b6cece178917ad9da1081eb6b1bb9be33066a77
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/4489
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
|
|
The original intention was to only run UPDATE_FIT when a microcode file was
included in CBFS. This happens when either CPU_MICROCODE_CBFS_GENERATE or
CPU_MICROCODE_CBFS_EXTERNAL is selected, however, the makefile checked that
CPU_MICROCODE_IN_CBFS was selected instead. The end result was that on
hasswell, the UPDATE-FIT step was always run, even when no microcode was
included, generating a build error.
Instead, introduce a new variable which tells if a microcode update is
added in CBFS during the build.
Change-Id: I28638912ed6f77761ef8a584f7636dc907b7a9b7
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4480
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
No need to show the choice of USB port or controller in case of older
hardware where location for usbdebug was hardwired.
Change-Id: Ia186bf2c6ed60be2834cf6fd0a1965c8bf81ed4d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4290
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Use a file in CBFS for keyboard layout and ethernet MAC instead
of scanning FMAP.
Change-Id: I7658c7c4e389deb20d7d8f57cce8b568efdc575d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4307
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Variables in coreboot and not in line with GRUB ones. E.g. HOSTCC is both
HOST_CC and BUILD_CC for GRUB (consult INSTALL for more details) and
what coreboot calls CC is TARGET_CC for GRUB.
Current code plugs this by defining variables explicitly but it has a nasty
effect that make stops caring about flags added in makefile itself. Undef
as many variables as possible but still pass them to configure for them to
have correct effect and keep CC assignment as my make version doesn't undefine
it even when instructed to do so.
Tested with qemu.
Change-Id: I9d18f557138a20ae3918d698dee8f5b5c5738f75
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4310
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Change-Id: Ib8dc069c9e503747c349e96a466feb42279afd08
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/4305
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The Intel GMA driver is in, this CL splices in the Makefile bits.
Change-Id: Icf42a537575b8cc90a679ec1fc15b09294630611
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60346
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4331
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
USE_XARGS mode builds n boards in parallel (with 1 CPU each) instead of
building 1 board with n CPUs.
This requires the main build system to work under such circumstances.
Change-Id: Ib4571a78dfe78fd61ae5b26c18be9745bd8b3d52
Reviewed-on: http://review.coreboot.org/4485
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This makes USE_XARGS-abuild unhappy due to races
Change-Id: I1237468366c7f8af7eacd572c2bd32df9a3d58ca
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4486
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
These functions are not all used yet, but do compile and are partially used
in the FUI testing.
They were extracted from the 3.4 kernel using coccinnelle filters. The .c files
are only compiled in if CONFIG_INTEL_DP is set.
Change-Id: Id95622a75aa02b496c9ea4717cb143394a8332e3
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60245
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4329
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Removed two unnecessary register sets, and did the power well a bit
more correctly. Also, added a register definition include file so we can
used constants instead of magic numbers.
We also set registers to common initialized values that are
needed for FUI, VBIOS, and kernel. This set of registers
appears to be an absolute bare minimum. Since we're hoping to use
FUI for all chipsets from this one forward, we unconditionally do the
setting here.
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Change-Id: Ife3f661ba010214d92b646b336f2b06645119f17
Reviewed-on: https://gerrit.chromium.org/gerrit/59988
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4328
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The new edid functions support converting the edid to an lb_framebuffer.
Use them. Also, since panels seem to set bits per color instead of bits
per pixel, just force the right value in the edid struct.
Add helpful comment because people don't always believe we need to set
the pallette.
While we're at it, fix a problem that caused it to not compile.
Change-Id: I645edc4e442d9b96303d9e17f175458dc7ef28b6
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57619
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4327
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
- updates from 1.6.0 ref code
- remove the step comments as they are no longer even close
- add constants for LPT revisions
build and boot on Falco
Check that RCBA+2300[1] is set:
> mmio_read32 0xfed1e300
0x00000002
Change-Id: I8b3c5fda3f3170455699a7834239cb991603e7a8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59821
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4326
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Implement the LynxPoint BIOS Spec for clock gating.
Change-Id: Iaa84cb447bd29b0d13cdda481a1661ea40499de1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59590
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4325
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
There's a need to determine if a specific gpio pin is
is set up to be a native function or not. Implement this.
Change-Id: I91d57a549e0f4fddc0b1849e5f74320fc839642c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59589
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4324
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The BIOS spec for LynxPoint calls out additional
programming steps for the PCIe Root Ports. Implement those
steps from the BIOS spec. These steps are completed before
deeper PCIe probing. The "late" programming was removed as
that was applicable to Cougar/Panther point where this
code was originally copied, though there was some overlap.
Change-Id: I64f25e4451e035d98ca6b66b0335bd280b70b074
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59558
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4323
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
PCIe Root Ports should be disabled based on pin ownership
and the strapping configuration. Implement this logic
for LynxPoint. The chip_ops->enable_dev() path is no
longer used. Instead the PCIe driver handles the enabling
and disabling of devices. This allows for having an empty
or incomplete device tree since those "allocated" devices
do not travel through the chip_ops->enable_dev() path.
The coalescing was tested to be working properly, however
not all configurations were tested.
Change-Id: I1e8bfe5e447b72ff8a4b04b650982d8c1ae0823c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59424
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4322
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Don't force dev mode. Allow users to enter / exit dev mode as normal.
Change-Id: I168eb04a8ac102a8c4a1ca8936f78f62b001e0eb
Reviewed-on: https://gerrit.chromium.org/gerrit/59492
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-on: http://review.coreboot.org/4321
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
So far this is used by the USB driver, and instead of
having ifdefs all throughout that code, implement the same
API on x86 and ARM.
Change-Id: I8093ad818ad2e38a0901787aa8674faf591d580c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56105
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4320
Tested-by: build bot (Jenkins)
|
|
On some systems there may be 2GB SKU that is the same as the
4GB SKU but just one channel of memory. In that case we need
to ensure that both copies of the same SPD source end up
populated by ensuring that repeated entries are included by
using $+ instead of $^.
Alternatively we could do the check inside romstage, but it
is already set to behave this way if the SPD gets populated
correctly.
I changed spd_index to 3 in falco romstage to force it to
pretend it was a 2GB config of the same memory, then booted
to ensure it was indeed limited to 2GB.
memcfg channel[0] config (00780008):
ECC inactive
enhanced interleave mode on
rank interleave on
DIMMA 2048 MB width x16 single rank, selected
DIMMB 0 MB width x16 single rank
memcfg channel[1] config (00600000):
ECC inactive
enhanced interleave mode on
rank interleave on
DIMMA 0 MB width x8 single rank, selected
DIMMB 0 MB width x8 single rank
Change-Id: Ibfe5051ccda2fe69e8caff3f3c264116e3411c65
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59483
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Jay Kim <yongjaek@chromium.org>
Reviewed-on: http://review.coreboot.org/4319
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The numbers alone are hard to parse, so add
some timestamp names to make it easier to read.
Change-Id: Ie32d3e7ca759bd15e7c160bdd829dec19943e6cb
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65333
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4314
Tested-by: build bot (Jenkins)
|
|
On ARM the timestamps are already in micro seconds, so
no need to convert them.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: If7363b0703e144bde62d9dab4ba845e1ace5bd18
Reviewed-on: https://gerrit.chromium.org/gerrit/63991
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4313
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
It's a start...
Change-Id: Ibdb0b64ab0349df58bcad5ce553bf0dbec636925
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4483
Tested-by: build bot (Jenkins)
|
|
- Add -ffreestanding and -fomit-frame-pointer for all
platforms.
- Add ARMv7 specific flags to the armv7 Makefile
Change-Id: I71ab1b096e505940cc20c266bccd43917bcfad3a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56104
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4317
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Propagated from
http://review.coreboot.org/3347
http://review.coreboot.org/3374
The cause of this issue is:
USB devices use bit 11(0x0b) of GP0_STS represents S3 wake up event,
but this bit is not clear after wake up. So OS thinks there is a
wake up signal and wake up immediately.
Both amd/olivehill and asrock/imb-a180 have been validated.
Change-Id: I7c26cb07bcd2e62bb792809b67314e5155c6adf6
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4261
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The AML code of PTS and WAK for southbridge are in
UINT8 AlibSsdtKB[], Proc/GNB/Modules/GnbInitKB/AlibSsdtKB.h.
It was integrated into SSDT even it was called by nobody.
The source ASL was provided by AGESA for reference, but it
has been scrubbed when it was ported to Coreboot.
Without the calls, Olive Hill can not wake up if it boots Windows.
Both amd/olivehill and asrock/imb-a180 have been validated.
Change-Id: Ia7bba29904dbd6f33fdb08bf88bb499005ef561b
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4260
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The bug is hard to find. We were adding the feature of fan control. We
met some strange things which could not be explained. Like, sometimes
adding printk let the error disappear. Then we traced the code by hardware
debug tool (HDT). It turned out the data in stack was overwritten.
The values of AccessWidthxx are
{ AccessWidth8 = 1,
AccessWidth16,
AccessWidth32,}
For the case of AccessWidth8, we only need to access the index/data
once. But ReadECmsg and WriteECmsg did the loop twice, 1 more time
than they are supposed to do. The data in stack next to "Value" would
be overwritten.
For all the cases, the code should be
OpFlag = OpFlag & 0x7f;
switch (OpFlag) {
case 1: /* AccessWidth8 */
OpFlag = 0;break;
case 2: /* AccessWidth16 */
OpFlag = 1;break;
case 3: /* AccessWidth32 */
OpFlag = 3;break;
case 4: /* AccessWidth64 */
OpFlag = 7;break;
default:
error;
}
Actually, the caller only takes AccessWidth8 as the parameter. We can ignore other
cases for now.
That is an AGESA bug. AMD's AGESA team own this code. They have given the
response that they are going to update this in next release. I presume let them
decide the proper way to fix that. Before that, I change the code as little
as possible to make it run without crash.
Change-Id: I566f74c242ce93f4569eedf69ca07d2fb7fb368d
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4297
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
Commit * bdafcfa Add the Intel FSP 206ax CPU core support
Introduced this option. This option was meant to have a board generate
a CBFS file containing microcode. However, microcode generation used to be
enabled by default when CPU_MICROCODE_IN_CBFS was selected.
The introduction of BOARD_MICROCODE_CBFS_GENERATE killed that automatic
default, which is not what we want. This option is misguided in the sense
that it tends to introduce a non-default which had been intentionally a
default. We now have to select two Kconfig options in order to generate
microcode in CBFS, meaning one option is redundant.
Change-Id: I3034833df1a9afa7d6d9d537484cb4ac89d30183
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4478
Tested-by: build bot (Jenkins)
|
|
mainboard_smi_gpi has recently been updated to take a u32 argument from a
u16, but the patch introducing the fsp_bd82x6x support has been verified
on a master before this change, thus resulting in a 'cast from incompatible
type' error. Update the pointer to the correct size argument.
Change-Id: I9d62ee43f7c8ed774898f54d29a87cf463b76e91
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4479
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
On ARMv7 we need to carefully add memory barriers to
all memory read and write operations. This change
brings libpayload in sync with what coreboot is doing.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ie9c30b0f0d30531c5f9d99c2729246a86b8cec26
Reviewed-on: https://gerrit.chromium.org/gerrit/59294
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4316
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Icae8042add5f4dd5c707369ffc4587c613d69d29
Reviewed-on: https://gerrit.chromium.org/gerrit/59324
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4315
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This also adds an option -x/--hexdump to dump the whole
CBMEM area for debugging.
Change-Id: I244955394c6a2199acf7af78ae4b8b0a6f3bfe33
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62287
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4312
Tested-by: build bot (Jenkins)
|
|
on ARM the CBMEM utility requires the procfs entry
/proc/device-tree/firmware/coreboot/coreboot-table
provided by the FDT (dynamically created by depthcharge
at the moment)
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: If5f961afb23791af6f32dd4fc9a837a1aa41b70e
Reviewed-on: https://gerrit.chromium.org/gerrit/59322
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4311
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Variable use is specific to ChromeOS.
Change-Id: I5b61a038e6b08e3b2408c4d990749d45fdf2148d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4306
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Change-Id: I1a59405499deceed7df01a03834be72830e6578f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4291
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Cougar Canyon 2 is a Ivybridge/PantherPoint reference board.
This implementation uses the Intel FSP (Vist the Intel FSP
website for details on FSP architecture and support).
The FSP does not support s3 at this time. S3 may be added
when it is available in the FSP. All other features and IO
ports are functional. Booted on Ubuntu 12.04 and 13.04,
Fedora 18 with SeaBIOS payload. Memtest86, FWTS, and
other tests pass.
Board support page will be updated on acceptance.
Change-Id: I26c0b82d7ac295498376ad4c3517a9d6660d1c01
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4018
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add the FSP northbridge and southbridge includes.
Change-Id: I5c7f395dc033caa8d0bf0313382769595d77f2a5
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4019
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add support for the bd82x6x using the Intel FSP.
The FSP is different enough to warrant its own source files
for now. The mrc/system agent chromebook solution does much more
southbridge initialization and configuration than the FSP version.
It may be combined in the future.
Change-Id: Ie493945f3d321d854728d231979a0c172d2b36de
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4017
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add support for 206ax using the Intel FSP.
The FSP is different enough to warrant its own source files
for now. It has different CAR code, micorcode, and FSP inclusion.
It may be possible to combine this code with the mrc based
solution used by the chromebooks in the future.
Change-Id: I5105631af34e9c3a804ace908c4205f073abb9b4
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4016
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add support for Sandybridge and Ivybridge using the Intel FSP.
The FSP is different enough to warrant its own source files.
This source handle the majority of FSP interaction.
"Intel® Firmware Support Package (Intel® FSP) provides key
programming information for initializing Intel® silicon and can be
easily integrated into a boot loader of the developer’s choice.
It is easy to adopt, scalable to design, reduces time-to-market, and
is economical to build."
http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
Change-Id: Ib879c6b0fbf2eb1cbf929a87f592df29ac48bcc5
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4015
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It's done in bootblock_simple.c just after returning from
the mainboard specific bootblock function.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I96cab5e406132a9f7dc30d48ff99f524773a1a14
Reviewed-on: https://gerrit.chromium.org/gerrit/58473
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4257
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Ibexpeak shares few files with bd82x6x. In order for it to work correctly
their config structures from chip.h must match, so include bd82x6x/chip.h
in ibexpeak/chip.h
Change-Id: Ib56b311b8af04f4e4803d1834724680f604901cd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4277
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
This was used by Ron 13ys ago and was never used again
ever since.
Change-Id: I8ae8a570d67fa0b34b17c9e3709845687f73c724
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59320
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4256
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Currently, the exception handling code on ARM in libpayload turns on alignment
checks as an easy way to generate an exception for testing purposes. It was
leaving it on which disabled unaligned accesses for other, unlreated code
running later. This change adjusts the code so the original value of the
alignment bit is restored after the test exception.
Built and booted into depthcharge on pit with an unaligned accesses added
after the call to exception_init in the depthcharge's main. Before this
change, the access caused an exception. After this change, the access
completed successfully.
Change-Id: If92cab3cc8eabca7c5b0560ce88a8796a27fe3b2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59372
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4255
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
The address range to scan for the coreboot tables varies from machine to
machine based on the range memory occupies on the SOC being booted and on the
amount of memory installed on the machine. To make libpayload work on
different ARM systems with different needs, this change makes the region to
scan configurable. In the future, we might want to come up with a more
automatic mechanism like on x86, although there's less consistency on ARM as
far as what ranges are even memory in the first place.
Change-Id: Ib50efe25a6152171b0fbd0e324dbc5e89c527d6e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59242
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4254
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
LynxPoint-LP has a lot of GPEs and the "default" set has been
moved to register 4 starting at bit offset 96. This means
that PME_B0 bit in GPE0_EN/GPE0_STS is now bit 109 in LPT-LP
but still bit 13 in LPT-H.
suspend on falco and wake from usb
4 | 2013-06-19 10:49:17 | ACPI Enter | S3
5 | 2013-06-19 10:49:22 | ACPI Wake | S3
6 | 2013-06-19 10:49:22 | Wake Source | Internal PME | 0
Change-Id: I443cd4d17796888debed70c0bda27ae09accd09b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59265
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4253
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Otherwise the code would try to parse GPIOs when encountering
a mainboard entry in the coreboot table. This never caused any
problems because the mainboard entry is parsed before the GPIO
entry.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I1443bda8585a990a39115743d48304ec4b54bccb
Reviewed-on: https://gerrit.chromium.org/gerrit/59292
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4252
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
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().
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>
Reviewed-on: http://review.coreboot.org/4223
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Since we are using VBNV to determine if developer mode is
active we do not need the messy OPROM hook magic any longer.
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>
Reviewed-on: http://review.coreboot.org/4222
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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.
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>
Reviewed-on: http://review.coreboot.org/4221
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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.
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>
Reviewed-on: http://review.coreboot.org/4220
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Those building Chromebook firmware from coreboot git might be more
interested in building without ChromeOS extras.
Change-Id: I2f176d059fd45bf4eb02cc0f3f1dcc353095d0ce
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3977
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Instead of depending on exact mobo configure general characteristic whether
dock is configured in romstage or ramstage.
X60 and T60 have superio in dock so it needs to be inited to get serial, so
it should be inited in romstage.
On X201 there is nothing useful that early in boot but it's needed to init more
to get dock working, in particular EC init needs to be done first.
Change-Id: If5072e3dec883a94cd2d5643a92f7f6c3c9feee9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4294
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Instead define brightness up/down function and gfx device and use
preprocessor magic to glue it together.
Change-Id: I03074ae07b33c1546d229efc3e80606ddbee6300
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4282
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
Do not directly check the return value of get_option, but instead compare
the returned value against a CB_CMOS_ error code, or against CB_SUCCESS.
Change-Id: I2fa7761d13ebb5e9b4606076991a43f18ae370ad
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4266
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- Add a new USB location field
- Add a new "ddr_refresh_2x" field, enabled on Falco only
- Fix copy+paste bug in baskingridge
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>
Reviewed-on: http://review.coreboot.org/4219
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Compiler may do loads of optimisations around stack switch and so it's allowed
to break stack switch as it sees fit. Do it in assembly instead.
Not tested.
Change-Id: I277a62a9052e8fe9b04e7c65d149e087282ac2a2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4286
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The function reads the Build ID and the supported function specification
version from the running EC firmware, and stores a text representation
in the provided output buffer.
Change-Id: I3b647d7f315c9b4922fa9a9c5167a80f6d82e753
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3617
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The source files were removed with commit 3e4e3038.
Change-Id: I2df9d8cce0ec1462dcba4790a6c62abade0d223c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4298
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
These are based on the datasheet and I included the timing
values I used from the docs.
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>
Reviewed-on: http://review.coreboot.org/4234
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
- Add HDA verb table
- Add on-board device table
- Add panel power sequencing values
Change-Id: I1b3450c2740ec1d930f157a9b23550e1efc8668f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58197
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4233
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
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.
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>
Reviewed-on: http://review.coreboot.org/4218
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The Linux thinkpad_acpi.c driver looks for this string while
reading information about the system it is running on.
This commit does not make the module load but it is one of
several things that the module looks for on a ThinkPad.
Change-Id: Ia48bbd85ba4d528063695345b0f968d264573341
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3779
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Currently, all Peppy boards w/ '000' SPD GPIOs have 2GB DRAM. Disable
the second DRAM channel based upon the GPIOs.
Need to change / confirm this for upcoming builds.
Change-Id: I7085ddecb80626cc0bed99ba7b174c6b80350696
Reviewed-on: https://gerrit.chromium.org/gerrit/58620
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4238
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The EC was disabling flash commands and sysjump was not working
properly. With those two fixed software sync works properly.
(Taken from I63ca00d6c94854f2b395eb736ce20792da5f8de2).
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>
Reviewed-on: http://review.coreboot.org/4212
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
- Update GPIO table to match board.
- Update USB port map.
- Remove iSSD power sequencing code.
Change-Id: Iaa8e5921ed9db6bcfd18b5a888c7f80b2c93a710
Reviewed-on: https://gerrit.chromium.org/gerrit/56869
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4211
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
There was always exactly one elog descriptor declared and initialized, but its
contents were being accessed through a pointer that was passed back and forth
between functions instead of being accessed directly. This made the code more
verbose than it needed to be and harder to follow. To address this the
descriptor type was eliminated, its contents were turned into individual
global variables, and various functions were adjusted to no longer take the
descriptor as an argument.
Similarly, the code was more verbose and complicated than it needed to be
because of several wrapper functions which wrapped a single line of code which
called an underlying function with particular arguments and were only used
once. This makes it harder to tell what the code is doing because the call to
the real function you may already be familiar with is obscured behind a
new function you've never seen before. It also adds one more text to the file
as a whole while providing at best a marginal benefit. Those functions were
removed and their callers now call their contents directly.
Built and booted on Link. Ran mosys eventlog list. Cleared the event log
and ran mosys eventlog list again. Added 2000 events and ran mosys eventlog
list. Cleared the log again and ran mosys eventlog list.
Change-Id: I4f5f6b9f4f508548077b7f5a92f4322db99e01ca
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49310
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4245
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The elog driver's design was a bit more elaborate than it really needed to be
since it no longer had to keep track of multiple copies of the log in flash
and also in memory. This change streamlines it by removing unnecessary
compartmentalization of some bits of code, and some variables which tracked
the last entry added which were never used.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the event log and ran mosys eventlog list again. Cleared the log by echoing 1
into /sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list.
Change-Id: I7d4cdebf2f5b1f6bb1fc70e65eca18f71b124b18
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49309
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4244
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
elog_validate_and_fill was called in exactly one place, in
elog_init_descriptor. It didn't actually do what its name implied since the
data in the event log was already "filled" by elog_init_descriptor. Likewise
elog_init_descriptor was delegating an important part of its own job, scanning
through the list of events, to elog_validate_and_fill.
Since one function was basically just a displaced part of the other which
couldn't really stand on its own, this change merges them together.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events with
the SMI handler and ran mosys eventlog list again.
Change-Id: Ic899eeb18146d0f127d0dded207d37d63cbc716f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49308
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4243
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This function was just a wrapper around elog_init_descriptor, and all it did
was pass the current backing store location and size back in so it would be
reused. Those values, which never change, are now set in
elog_setup_descriptors, eliminating those parameters to init and eliminating
the need for _reinit_.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the log and ran mosys eventlog list again.
Change-Id: I133768aa798dfc10f32e14db95235a88666890c3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49307
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4242
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The event log driver keeps two copies of the event log in memory, one to
take the place of the historically memory mapped image of flash which is now
read and written manually, and one originally intended to be an in memory
cache of flash. Since both are now just copies in memory, there's no value in
having them both and keeping them in sync.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the log and ran mosys eventlog list again. Cleared the log by echoing a 1 into
/sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list again.
Change-Id: Ibed62a10c78884849726aa15ec795ab2914afc35
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49306
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4241
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The way elog_shrink currently works is that it completely clears the data in
the flash/flash descriptor and then recreates it using the part of the log
it's going to keep as stored in the memory descriptor. That scheme depends on
there being to independent copies of the log.
This change reworks elog_shrink so that it moves the data it wants to keep
within a single descriptor and then propogates it to the other and to flash
intact. This way, when one of the descriptors goes away, all we have to do is
remove the code that would update it.
Built and booted into ChromeOS on Link. Ran mosys eventlog list. Added
2000 events to the log and ran mosys eventlog list again. Echoed a 1 into
/sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list.
BRANCH=None
Change-Id: I50d77a4f00ea3c6b3e0ec8996dab1a3b31580205
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49305
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4240
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The header is at the start of the log. There's no reason to either keep a
seperate pointer to it, or to keep a copy of it in some other bit of memory.
Built and booted on Link and used 'mosys eventlog list' to list the
contents of the log. Ran
for x in $(seq 1 2000); do
cat elog.event.kernel_clean > /sys/firmware/gsmi/append_to_eventlog;
done
And ran mosys eventlog list again to verify that the log had been shrunk
correctly.
Change-Id: I2afcd52c0ce5bbb662ac56f2895cdbea28d5c2ce
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49304
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4239
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Some of the pcie logic was located in pch.c as well
as pcie.c. Move all pcie logic to the same pcie.c
file. This is a straight cut-and-paste (no logic changes)
except for a rename from pch_pcie_enable() ->
pch_pcie_enable_dev().
Change-Id: I338c53039b95f255ab9ced313c51193a9d34b404
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59277
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4251
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The function to disable devices was formerly named
pch_hide_devfn(). This routine was doing more than hiding
devices. It was disabling them, i.e. turning them off.
Therefore, rename it to pch_disable_devfn(). Also, allow
external callers to this function.
Change-Id: Id5bb319d4e67892c02a39dff49e45b2811a2f016
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59276
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4250
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The iobp functions are useful to may of the southbridge
devices as certain values need to be updated to properly
initialize the devices. Therefore expose read, write, and
updated iobp functions.
Change-Id: Id7fdd8d0d9f022f92d6285ecd8f85a52024ec2bb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59275
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4249
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
A quirk of the Kconfig used in coreboot is that config options
cannot be overriden by local config changes unless they have
a description string.
1) Add CONFIG_MAINBOARD_VENDOR="Custom" to local config
2) Build and flash coreboot
3) cat /sys/class/dmi/id/sys_vendor and look for "Custom"
Change-Id: I1b5f2124cd4a22c056c025143ae5bcaafa6b03f0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59088
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4248
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
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.
Also sync pin states from Falco initial commit.
Reference change: I15d38dcc9b2fb4b2b0eb27da358fa3c343e22323
Change-Id: I66e136d389d53a367436d816fa84dacdc8e86bad
Reviewed-on: https://gerrit.chromium.org/gerrit/58334
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@google.com>
Reviewed-on: http://review.coreboot.org/4247
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Set nid 0x12 instead of nid 0x05. The DMIC is on NIC 0x12.
Change-Id: Ifc883b65a50aeec6a6d3ad02fe8418f124e6241d
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58711
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Jay Kim <yongjaek@chromium.org>
Tested-by: Jay Kim <yongjaek@chromium.org>
Reviewed-on: http://review.coreboot.org/4246
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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).
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
Reviewed-on: http://review.coreboot.org/4237
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Due to OEM request, always set DDR refresh rate at 2x.
Change-Id: I81a4f57aca6388551dca6effbd9a4ac1a97e4f5a
Reviewed-on: https://gerrit.chromium.org/gerrit/50477
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4214
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
