- Update chipset_fsp_util.h to add the UPD_MEMDOWN_CHECK pointing into
the PcdMemoryParameters structure. This is baytrail FSP specific, so
it's put into the chipset code instead of the 'driver' code. Since some
of the values need to be decremented and some do not, a second parameter
was added to control this. This macro also does not print out the
values as they are printed out separately if memory down is enabled.
- Update chipset_fsp_util.c to use the UPD_MEMDOWN_CHECK macro. This
makes the code more standardized and easier to read.
Change-Id: I233e45db43af4726cab41f4880f1706cf8abb0b7
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7632
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Update chipset_fsp_util.c to use the UPD_SPD_CHECK macro. This
makes the code more standardized and easier to read.
Change-Id: I9944e1a4df82e64a205598e98ed0f3b840af1019
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7489
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
- Update chipset_fsp_util.c to use the UPD_DEFAULT_CHECK macro. This
makes the code more standardized and easier to read.
- Update chip.h to use standardized macros
Change-Id: Icbe5ec92b0aa31e21f3dd1593a96b246d83008f7
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7488
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
There were instances of unneeded arch/hlt.h includes,
various hlt() calls that weren't supposed to exit (but
might have) and various forms of endless loops around
hlt() calls.
All these are sorted out now: unnecessary includes are
dropped, hlt() is uniformly replaced with halt() (except
in assembly, obviously).
Change-Id: I3d38fed6e8d67a28fdeb17be803d8c4b62d383c5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7608
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
No need to mark Makefiles, C files or devicetrees
executable.
Change-Id: Ide3a0efc5b14f2cbd7e2a65c541b52491575bb78
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7618
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
According to spec IRQ1 isn't available for PIRQ assignment.
Has gone unnoticed probably because modern OS use MSI or
at least APIC and even with noapic don't use IRQ1 with PCI
IRQs.
Change-Id: Idc7db249007df629b27e8cae41cc80358d5306f6
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7478
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Baytrail Gold3 FSP adds a couple of parameters in UPD_DATA_REGION
making platform more configurable via devicetree.cb
Update the UPD_DATA_REGION structure and pass settings to FSP
Add Baytrail Gold2 and earlier FSP backward compatible, as Gold3
FSP changes UPD_DATA_REGION struct
Change-Id: Ia2d2d0595328ac771762a84da40697a3b7e900c6
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: http://review.coreboot.org/7334
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
As build.h is an auto-generated file it was necessary to add it as
an explicit prerequisite in the Makefiles. When this was forgotten
abuild would sometimes fail with following error:
fatal error: build.h: No such file or directory
Fix this error by compiling version.c into all stages.
Change-Id: I342f341077cc7496aed279b00baaa957aa2af0db
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7510
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The ACPI compiler is trying to be helpful in letting us know that we're
not using various fields in the MCRS 'ResourceTemplate' when we define
it inside of the _CRS method. Since we're not intending to use those
objects in the method, it shouldn't be an issue, but the warning is
annoying. Moving the creation of the MCRS object to outside of the
_CRS method and referencing it from there solves this problem.
Change-Id: I222642e9a93f3078b46ed74f57b83a5834657abf
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7499
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The entries in chip.h are used to set the UPD values. These had
originally been shortened and did not match the names of the structure
entries in vendorcode/intel/fsp/baytrail/include/fspvpd.h
This patch aligns the names.
- Update names in chip.h.
- Update names in devictree registers for bayley bay and minnow max.
- Update names in chipset_fsp_util.c
Change-Id: I8d7e34195cec2e63802d7e07e5aed71735556936
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7486
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: FEI WANG <wangfei.jimei@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Most of the code related to the mc146818 is not related to the RTC and is
really for managing the CMOS storage. Since we intend to add a generic API
for RTC drivers it's inconvenient for those functions to have an rtc_ prefix.
This CL renames those functions so they start with cmos_ instead. There are
some places where rtc_init was called with a comment that says something about
starting the RTC. That wasn't correct before (the RTC is always running), but
it looks a little odd now that the function is called cmos_init.
This CL also opportunistically cleans up some style problems in this file.
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197794
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 9a9ad24888b185fb58965457704e326bb508d788)
Removed the addition of stdint.h to mc146818rtc.h since
types.h is now included. Changed rtc_init to cmos_init for
fsp_bd82x6x, fsp_rangeley, fsp_baytrail, ibexpeak, vortex86ex.
Change-Id: Id4b9f6bea93e8bd5eaef2cb17f296adb9697114c
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6977
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The offset of the device_nvs in the gnvs struct is expected to be
0x1000. It is actually 0x100 so padding is needed to move device_nvs
to the expected location. ACPI references to device_nvs objects will
be correct with the padding.
This was tested using a Micro Industries customized Baytrail-I board
based on the Intel Bayley Bay CRB. In intel/baytrail/nvs.h, there's
a Google customized structure located at 0x0100-0x0FFF that is
removed from the fsp_baytrail/nvs.h which explains the mismatch here.
Change-Id: I4721a79b53b5b3345ff9b0c053bdd31d2cf9cb61
Signed-off-by: Scott Radcliffe <sradcliffe@microind.com>
Reviewed-on: http://review.coreboot.org/7038
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
ACPI globalnvs.asl expects the gnvs memory area size to be 0x2000.
Padding has been added to device_nvs struct to reserve the full
0x2000 bytes for gnvs usage.
No known issues are caused by having the GNVS area shorter than
what ACPI thinks. Since there's nothing defined in this area,
O/S shouldn't try to access it. Only problem might be if O/S
notices the SSDT is located within the GNVS defined area.
I verified that the next table written to memory (SSDT) is 0x2000
past GNVS start using a custom-designed Baytrail-I motherboard
based on the Intel Bayley Bay CRB.
Change-Id: I9792954c7a3403eba6f37d7e53ea4a9ed3a2e4ac
Signed-off-by: Scott Radcliffe <sradcliffe@microind.com>
Reviewed-on: http://review.coreboot.org/7039
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Zero out the GNVS area so that uninitialized portions are defined.
Tests using Microsoft Windows (XP/7/8) gave a bluescreen bugcheck: A5
(ACPI_BIOS_ERROR) with the first parameter (0x00001000)
(ACPI_BIOS_USING_OS_MEMORY). Some ACPI enumerated devices use the
GNVS area to define whether they're enabled and their MMIO regions.
On my custom baytrail-based board and build, these devices were
disabled but GNVS had uninitialized data indicating the devices
were enabled with improper MMIO regions.
Should investigate further to see where the GNVS device values are
set if enabled and make sure they're set to valid values even when
the devices are disabled via the mainboard/devicetree.cb.
Change-Id: I2b575c65bfaab58ae6206ac6f457c259c27a7d97
Signed-off-by: Scott Radcliffe <sradcliffe@microind.com>
Reviewed-on: http://review.coreboot.org/7040
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Fix the error 'implicit declaration of function
"southcluster_smm_save_gpio_route"', when SMM module is added.
Change-Id: Ia050ab7e2b036541537b645d3fe4dc747cd1dff8
Signed-off-by: Kayalvizhi Dhandapani <kayalvizhid@ami.com>
Reviewed-on: http://review.coreboot.org/7024
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
With SMM enabled the boot stopped while patching up global NVS in DSDT.
The cause is that both CPUs are assigned the same SMBASE address.
So update the "cpu_smm_do_relocation()" function so that each
CPU gets a different SMBASE address
Based on rmodule work that wasn't propagated to the FSP
version: commit 3eb8eb7eba
Change-Id: I77cd27d3a4f207411a689b5be572b4406a03f16b
Signed-off-by: Kayalvizhi Dhandapani <kayalvizhid@ami.com>
Reviewed-on: http://review.coreboot.org/7026
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
This adds S3 Suspend / Resume support to Intel's Bay Trail FSP
It is based on the "src/soc/intel/baytrail/romstage/romstage.c"
implementation.
Change-Id: If0011068eb7290d1b764c5c4b12c17375fb69008
Signed-off-by: Mohan D'Costa <mohan@ndr.co.jp>
Reviewed-on: http://review.coreboot.org/6937
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
irq_helper.h intentionally gets included into irqroute.asl twice - once
for pic mode and once for apic mode. Since people are used to seeing
guard statements on the .h files, add the guards to irqroute.h and add
a comment to irq_helper.h explaining why they aren't there. Add a
time.
Change-Id: I882cbbff0f73bdb170bd0f1053767893722dc60a
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6572
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The GPIO_NC setting sets up the gpio as a no-connect - sets it as an
input, and pulls it high. It makes an assumption that the GPIO
function is muxing function 0. There are a few GPIOs that are on
function 1 instead:
* GPIO_S0_SC[092-93]
* GPIO_S5[11-21]
For these GPIOs, use the GPIO_NC1 setting instead of GPIO_NC.
Change-Id: Iac6790b40e87ad4ac9a3b265a8e10662186c1201
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6428
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Fixed spelling and added empty lines to separate the help
from the text automatically added during make menuconfig.
Change-Id: I6eee2c86e30573deb8cf0d42fda8b8329e1156c7
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Reviewed-on: http://review.coreboot.org/6313
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
SPI controllers in Intel and AMD bridges have a slightly different
restriction on how long transactions they can handle.
Change-Id: I3d149d4b7e7e9633482a153d5e380a86c553d871
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6163
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Whenever spi_xfer is called and whenver it's implemented, the natural unit for
the amount of data being transfered is bytes. The API expected things to be
expressed in bits, however, which led to a lot of multiplying and dividing by
eight, and checkes to make sure things were multiples of eight. All of that
can now be removed.
BUG=None
TEST=Built and booted on link, falco, peach_pit and nyan and looked for SPI
errors in the firmware log. Built for rambi.
BRANCH=None
Change-Id: I02365bdb6960a35def7be7a0cd1aa0a2cc09392f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/192049
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
[km: cherry-pick from chromium]
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6175
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The spi_flash_probe and and spi_setup_slave functions each took a max_hz
parameter and a spi_mode parameter which were never used.
BUG=None
TEST=Built for link, falco, rambi, nyan.
BRANCH=None
Change-Id: I3a2e0a9ab530bcc0f722f81f00e8c7bd1f6d2a22
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/192046
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
[km: cherry-pick from chromium]
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6174
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The override value in the mainboard that was removed was correct.
Change-Id: Ie820df0d6b7a713488173240f0c0ca4a9e108f71
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6095
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
- remove the Kconfig text when setting the default for the FSP location.
The text was showing up twice in the config menu.
- Remove an extra 'the' in the help text.
Change-Id: I3777833bf32e19bbe5a8493578a9346d6ab062a4
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6090
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The default FSP location needs to be in the chipset, not the mainboard.
This was removed from the Bayley Bay mainboard in patch 41ea7230f7
reviewed at http://review.coreboot.org/#/c/5982/
Change-Id: Ia26ed34e1401cbd2303166628e7a4e357d79c874
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/5985
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Tested-by: build bot (Jenkins)
- Add the Bay Trail B0/B1 microcode. These versions of the SOC were
released as a "Super SKU" which had features of all the different
SKUS (M/D/T/I), and identified as a Bay Trail T as noted by the
number 2 in the third character from the left in the microcode name.
- Update the size of the microcode blob. We should be pushing a patch
to eliminate the need for this shortly.
Change-Id: I57ba51eabe9ea0609ab809f18b95e3bc9d5cb191
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/5986
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
This existed for ChromeOS but was no longer used with DYNAMIC_CBMEM.
Change-Id: I558a7ae333e5874670206e20a147dd6598a3a5e7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6032
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Intel requested that we remove the version number from the default
vbios path.
Change-Id: I2590fed0db157e3e430212336fc55eb099d28a72
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/5984
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
While pushing the fsp_baytrail code, it was requested that we change
CONFIG_ENABLE_FAST_BOOT to CONFIG_ENABLE_FSP_FAST_BOOT.
These were missed in the change.
Change-Id: If8af3f90b0f5cc9154ff1d3a387f442430f42dee
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/5972
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
realpath and readlink can be used to do the same thing - in this case
we're turning path1/path2/../path3/path4 into path1/path3/path4 so
that the makefile's wildcard routine can evaluate it.
Debian derivatives don't seem to include realpath. (and even when it's
installed, it's not the gnu coreutils version.)
Change-Id: I0a80a1d9b563810bdf96aea9d5de79ce1cea457a
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/5793
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
While similar to the Bay Trail-M/D code based on the MRC, there are
many differences as well:
- Obviously, uses the FSP instead of the MRC binaries.
- FSP does additional hardware setup, so coreboot doesn't need to.
- Different microcode & microcode loading method
- Uses the cache_as_ram.inc from the FSP Driver
- Various other changes in support of the FSP
Additional changes that don't have to to with the FSP vs MRC:
- Updated IRQ Routing
- Different FADT implementation.
This was validated with FSP:
BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014.fd
SHA256: d29eefbb33454bd5314bfaa38fb055d592a757de7b348ed7096cd8c2d65908a5
MD5: 9360cd915f0d3e4116bbc782233d7b91
Change-Id: Iadadf8cd6cf444ba840e0f76d3aed7825cd7aee4
Signed-off-by: Martin Roth <gaumless@gmail.com>
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/5791
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
