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>
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>
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>
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>
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>
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>
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>
Propagated from
http://review.coreboot.org/3347http://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>
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 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>
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>
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)
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)
