When fixing the SMM state table for SandyBridge/IvyBridge CPUs
the wrong table was used for older 64bit capable CPUs.
Change-Id: Ia7dff21aa3f0e5aa61575634fc839777de6bef10
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1353
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is a temporary workaround so the SPI bus can be accessed
at runtime in SMM code until the SPI opcode menu is used
properly.
Change-Id: I93d188c55b66d8dce49fa91a1de53ee195944b30
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1318
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is called from the SMI handler install because those
setup functions clear many of these registers.
Ensure that these events show up in the log as appropriate.
Example log output:
159 | 2012-06-23 14:31:54 | SUS Power Fail
160 | 2012-06-23 14:31:54 | System Reset
161 | 2012-06-23 14:31:54 | ACPI Wake | S5
Change-Id: I48c423c10ee7e6c2829bcc95f6cfabb4979c25a9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1319
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
If a Chrome OS device is in developer mode log an event.
When the device is in recovery mode also log an event
and provide the recovery reason.
Enable developer mode and trigger recovery mode and
verify that the events are logged:
238 | 2012-06-23 17:31:56 | Chrome OS Developer Mode
239 | 2012-06-23 17:31:56 | Chrome OS Recovery Mode | User Requested from Developer Screen
Change-Id: I14d41f44e04fd91340569617c7314da7e35a154f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1321
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On both SandyBridge and IvyBridge BCLK is fixed at 100MHz. Have the
comment reflect that.
Change-Id: Ia81c3501dc3e68cf3143c3bc864dfbf88901f9f9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1336
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
.. in case the system has pluggable CPUs or might come in different SKUs.
Change-Id: I7a7cd95b4de5dd78370355f448688e8d000434c1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1333
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is for GfxInitSview(GnbSview.c). It would create warning message if it
could not get VBIOS image.
Change-Id: I3b2726f612b4b7a237644a4b63b56efad52b7ab5
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1351
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The default return value should be AGESA_SUCCESS, which is zero. If it was set as TRUE,
the AGESA wrapper would think it was AGESA_UNSUPPORTED. That would make no sense. And it
would produce ASSERT warning in AGESA wrapper.
On my parmer board, with Engine sample processor, it can not create the correct DMI table.
Routine initlate will return AGESS_ERROR.
------Serial message---------
ASSERTION FAILED: file 'src/mainboard/amd/parmer/agesawrapper.c', line 427
DmiTable:100123c3, AcpiPstatein: 10010126, AcpiSrat:0,AcpiSlit:0, Mce:100111ba, Cmc:1001127c,Alib:1001ccd4, AcpiIvrs:0 in agesawrapper_amdinitlate
agesawrapper_amdinitlate failed: 5
-----------------------------
I believe the processor with acceptable name string will create the right DMI.
Change-Id: Ie86955cf9affffc964a7c9f4a2c63077ef2030de
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1350
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Remove the warning message from linux dmesg,
mtrr: your BIOS has configured as incorrect mask, fixing it.
Change-Id: I355509db12ab10c33b7c1c23e2c7c4783f30e67e
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1349
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2048 * ONE_MB will cause warning,
src/northbridge/amd/agesa/family15tn/northbridge.c:667:50: warning: integer overflow in expression [-Woverflow]
I guess it will change the data type to signed integer.
I think the bit shifting is better.
Change-Id: I823f7ead1f7d622bf653cb3bf2ae2343f5e76805
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1263
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This function is exported so it can be used in other
places that need similar relocation due to TSEG.
Change-Id: I68b78ca32d58d1a414965404e38d71977c3da347
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1310
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Date and time are mixed up:
microcode: updated to revision 0x12 date=2012-12-04
should be
microcode: updated to revision 0x12 date=2012-04-12
Change-Id: I85f9100f31d88bb831bef07131f361c92c7ef34e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1334
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
This patch extends the current smbios api to allow changing mainboard
serial and version during coreboot runtime. This is helpful if you
have an EEPROM etc. to access these informations and want to add
some quirks for broken hardware revision for the linux kernel.
This could be done via DMI_MATCH marco.
Change-Id: I1924a56073084e965a23e47873d9f8542070423c
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/1232
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
coreboot used to pass some information to u-boot in the coreboot table
and other information in a modified flat device tree. Since the FDT code
was never upstreamed and removed from our tree, u-boot was changed to
get the information it needs from the coreboot table alone. However,
in the process of this change only the vboot shared data structure was
passed on by coreboot, so when u-boot tried to update the ChromeOS
specific ACPI entries, it would accidently overwrite the vboot data.
This patch passes on the ChromeOS specific ACPI data structure instead
of the vboot shared data. Another change to u-boot will teach it how
to get to the vboot shared data from there.
Change-Id: Ifbb64eafc0d9967887b4cdeebf97d0c4ce019290
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1282
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The LAPIC timer is running at BCLK (100MHz) on Sandy Bridge and Ivy
Bridge systems. However, the current timer code assumed that the clock
would run at 200MHz instead. This made all delays twice as long as
needed.
Change-Id: I41b1186daee11cfd9a25b3a9d5ebdeeb271293c7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1330
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
This maintains a 32bit monotonically increasing boot counter
that is stored in CMOS and logged on every non-S3 boot when
the event log is initialized.
In CMOS the count is prefixed with a 16bit signature and
appended with a 16bit checksum.
This counter is incremented in sandybridge early_init which is
called by romstage. It is incremented early in order notice
when reboots happen after memory init.
The counter is then logged when ELOG is initialized and will
store the boot count as part of a 'System boot; event.
Reboot a few times and look for 'System boot' events in the
event log and check that they are increasing. Also verify
that the counter does NOT increase when resuming from S3.
171 | 2012-06-23 16:02:55 | System boot | 285
176 | 2012-06-23 16:26:00 | System boot | 286
182 | 2012-06-23 16:27:04 | System boot | 287
189 | 2012-06-23 16:31:10 | System boot | 288
Change-Id: I23faeafcf155edfd10aa6882598b3883575f8a33
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1315
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This standared SMBIOS 0able describes the location and format
of the event log to the OS and applications. In this case the
pointer is a 32bit physical address pointer to the log in
memory mapped flash.
Look for SMBIOS type15 entry with 'dmidecode -t 15'
Handle 0x0004, DMI type 15, 23 bytes
System Event Log
Area Length: 4095 bytes
Header Start Offset: 0x0000
Header Length: 8 bytes
Data Start Offset: 0x0008
Access Method: Memory-mapped physical 32-bit address
Access Address: 0xFFB6F000
Status: Valid, Not Full
Change Token: 0x00000000
Header Format: OEM-specific
Supported Log Type Descriptors: 0
Change-Id: I1e7729e604000f197e26e69991a2867e869197a6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1314
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
MRC returns specific error codes; print the according error
message if we know what it means.
Change-Id: Iaaf1512b9d577d4291fccfb94d879043ab5b11b5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1289
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This was introduced when porting the SPI driver over from u-boot but it
is not needed. Hence drop the extra typedef and use device_t instead.
Change-Id: I3ab797a8e482d1c9aa1d004e488e99aeaffcdd8b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1331
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
The count was only incrementing for a wake from S5 and
it was not incrementing in the normal reboot case.
Change-Id: I73bc6db6bd02e6c4677f7e44a5c098c6dcb51747
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/1328
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
MCHBAR 0x5f10[7:0] should be set to 0x30 for ivybridge
and 0x20 for sandybridge. Move this code to ramstage
and set it per-chipset.
Power Aware Interrupt Routing is supported in ivybridge,
enable it and set fixed priority.
Boot on ivybridge device and read MCHBAR 0x5f10:
mmio_read8 0xfed15f10
0x30
And verify PAIR is enabled (bit4=1):
mmio_read8 0xfed15418
0x24
Change-Id: If017d5ce2bd5ab5092c86f657434f2b645ee6613
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1303
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
CPUs with configurable TDP will run the TSC at the max non-turbo
ratio for the maximum TDP value, which can cause issues if another
TDP is desired. To deal with this we set the flex ratio to the
nominal TDP ratio early in the boot and then configure the Soft
Reset Data registers so the PCH can tell the CPU what frequency
to run at after a reset.
This is done very early in the bootblock because it is necessary
to reset the system after setting a flex ratio.
The end result is that the TSC will now increment at the max
non-turbo frequency for the nominal TDP.
On some system with 1.8GHz CPU ensure that the kernel
detects the CPU speed as ~1800mhz rather than ~2300mhz:
> dmesg | grep "MHz processor"
[ 0.004000] Detected 1795.801 MHz processor.
Change-Id: I8436dced9199003b6423186a2b041e3f7b84ab8c
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/1329
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are enough differences that it is worth defining the
proper map for the sandybridge/ivybridge CPUs. The state
save map was not being addressed properly for TSEG and
needs to use the right offset instead of pointing in ASEG.
To do this properly add a required southbridge export to
return the TSEG base and use that where appropriate.
Change-Id: Idad153ed6c07d2633cb3d53eddd433a3df490834
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1309
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- add Kconfig option for CONFIG_SPI_FLASH_SMM
- compile subsystem and chip drivers for smm if enabled
- change mdelay(1) to udelay(500) since mdelay is not defined
in SMM and a 1ms delay is worth avoiding
- make flash chip structure non-const so the probe function
pointers can be relocated for use in TSEG
- Make SMM PCI access possible in southbridge SPI code
Change-Id: Icfcbbe8e4e56658769d46af0b5bf6c79a6432641
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1313
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is used by the SPI driver and ELOG.
It requires SMM TSEG and a _heap/_eheap region defined in the
linker script. The first time malloc is called in SMM the
start and end pointers to the heap region will be relocated
for the TSEG region.
Enable SPI flash and ELOG in SMM and successfully
allocate memory. The allocated addresses are verified
to be sure they are within the TSEG heap region:
smm.elf:00014000 B _eheap
smm.elf:00010000 B _heap
TSEG base is 0xad000000
Memory allocated in ELOG:
ELOG: MEM @0xad018030
Change-Id: I5cca38e4888d597cbbfcd9983cd6a7ae3600c2a3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1312
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is based around the SMBIOS event log specification but
expanded with OEM event types to support more specific and
relevant system events.
It requires flash storage and a minimum 4K block (or flash block
size) that should be allocated in the FMAP.
A copy of the event log is maintained in memory for convenience
and speed and the in-memory copy is written to flash at specific
points.
The log is automatically shunk when it reaches a configurable
full threshold in order to not get stuck with a full log that
needs OS help to clear.
ELOG implements the specification published here:
http://code.google.com/p/firmware-event-log/wiki/FirmwareEventLogDesign
And is similar to what we use in other firmware at Google.
This implementation does not support double-buffered flash
regions. This is done because speed is valued over the log
reliability and it keeps the code simpler for the first version.
This is a large commit and by itself it just provides a new
driver that is made available to coreboot. Without additional
patches it is not very useful, but the end result is an event
log that will contain entries like this:
171 | 2012-06-23 16:02:55 | System boot | 285
172 | 2012-06-23 16:02:55 | EC Event | Power Button
173 | 2012-06-23 16:02:55 | SUS Power Fail
174 | 2012-06-23 16:02:55 | System Reset
175 | 2012-06-23 16:02:55 | ACPI Wake | S5
Change-Id: I985524c67f525c8a268eccbd856c1a4c2a426889
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1311
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to support SPI and ELOG drivers the SMM region
needs to be able to be larger than the previous allocation
below 0x7400. Now that we have support for 4M TSEG we do
not need to live in this region.
This change adds a 16KB heap region abofe the save state area
at TSEG+64KB and moves the C handler above this.
The heap region is then available for malloc and the C handler
can grow to support flash and event log features.
While updating the memory map comment in assembly stub I also
added a pause instruction to the cpu spin lock as this was
added to the C code in latest upstream rebase.
Dump sympbols from smm.elf binary to see the new regions:
00010000 B _heap
00014000 B _eheap
00014000 T _smm_c_handler_start
0001b240 T _smm_c_handler_end
Change-Id: I45f0ab4df1fdef3b626f877094a58587476ac634
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1308
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The BWG says ivybridge current limit for PP1 is 50A.
Verify the PP1 current limit value on link device:
> echo $(( ( $(rdmsr 0 0x602) & 0x1fff ) >> 3 ))
50
Change-Id: I946269d21ef605f2525fe03993f569d69128294b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1305
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Ivybridge B0+ CPUs are capable of supporting multiple TDP levels.
This complicates the default case because now the registers that
were reporting max non-turbo ratio are reporting that value for
the highest possible TDP level.
For now this change just forces everything to use the Nominal TDP
values instead of the higher (or lower) levels.
- When building P-state tables, determine the P[1] (max non turbo)
ratio based on the Nominal ratio if available.
- Set the turbo activation ratio to the Nominal max ratio.
- Mirror the power level settings in new MCHBAR register after
they are written, which happens after BIOS_RESET_CPL is set.
- Set the current ratio to Nominal ratio at boot.
1) Verify that P-state table is generated properly with
P[0]=1801MHz (ratio 0x1C) and P[1]=1800MHz (ratio 0x12)
PSS: 1801MHz power 17000 control 0x1c00 status 0x1c00
PSS: 1800MHz power 17000 control 0x1200 status 0x1200
2) Verify power limits in MCHBAR match PKG_POWER_LIMIT:
> rdmsr 0 0x610
0x800080aa00dc8088
> mmio_read32 0xfed159a4
0x000080aa
> mmio_read32 0xfed159a0
0x00dc8088
3) Verify turbo activation ratio is set to nominal ratio:
> rdmsr 0 0x64c
0x0000000000000012
4) Check that proper ratio was set at boot on one core only:
> grep 'frequency set to' /sys/firmware/log
model_x06ax: frequency set to 1800
model_x06ax: frequency set to 1800
model_x06ax: frequency set to 1800
model_x06ax: frequency set to 1800
Change-Id: I592e60a7740f31b140986a8269dca91b4adbb270
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1304
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... and don't require it to specify a cache type.
This function is only used on romcc boards, and should go away
(because all boards should be switched to CAR)
Change-Id: Ic32ca3be1afffc773c72c140e88b338d48a0c8ca
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1288
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Previous patches implemented stack overflow checking for the APs.
This patch builds on the BSP stack poisoning patch to implement
stack overflow checking for the BSP, and also prints out maximum
stack usage. It reveals that our 32K stack is ridiculously oversized,
especially now that the lzma decoder doesn't use a giant 16K on-stack
array.
Break the stack checking out into a separate function, which
we will later use for the APs.
CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8
To test failure, change the DEADBEEF stack poison value in c_start.S
to something else. Then we should get an error like this:
Stack overrun on BSP.Increase stack from current 32768 bytes
CPU0: stack from 00180000 to 00188000:Lowest stack address 00180000
Separate the act of loading from the act of starting the payload. This
allows us better error management and reporting of stack use. Now we
see:
CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8
Tested for both success and failure on Link. At the same time, feel free
to carefully check my manipulation of _estack.
Change-Id: Ibb09738b15ec6a5510ac81e45dd82756bfa5aac2
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/1286
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The ME needs to be talked to through the PCIe memory mapped config
space.
Change-Id: Ic2c5a572a126722a08a82d95df13d11507586c6b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1284
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The function acpi_get_vdat_info() was moved to the ChromeOS
vendor code, and is no longer required to be present for each
board. Hence, remove it.
Change-Id: I3dc8dbb6119ceffa057373bad7c0058ac0d40eb8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1283
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In the short term there might be devices with Sandy Bridge CPUs
on mainboards with Panther Point PCHes. While this configuration
option is perfectly valid, coreboot currently ties Sandy Bridge to
Cougar Point and Ivy Bridge to Panther Point. One occurence is in
the ME handling code.
To make coreboot most flexible, compile both ME handlers into
coreboot and decide at runtime which one to use.
Change-Id: Icffe2930873f67c99c3f73e37e7a967f4f002b88
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1280
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- On Cougar Point there may have been stack corruption during the
ME hash verification
- On Panther Point the ME firmware hash was not passed on to the
OS
Change-Id: I73fc10db63ecff939833fb856a6da1e394155043
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1279
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Nothing is yet enabled, this is just a config skeleton change.
The MICROCODE_INCLUDE_PATH definition is going to be used by the
Makefile building the microcode blob for CBFS inclusion.
Change-Id: I7868db3cfd4b181500e361706e5f4dc08ca1c87d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1292
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Oxford PCIE Serial card has a hardcoded address at setup,
which may be moved during PCI Init. The driver re-initializes
after PCI init. Add a debug print for the new BAR address.
Initializing Oxford OXPCIe952
OXPCIe952: Class=70002 Revision ID=0
OXPCIe952: 2 UARTs detected.
OXPCIe952: Uart Bar: 0xe0800000
Change-Id: I1858d3eba09749cba3c3869060d00e621dca112a
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1327
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When microcode storage in CBFS is enabled, the make system is supposed
to generate the microcode blob and place it into the generated ROM
image as a CBFS component.
The microcode source representation does not change: it is still an
array of 32 bit constants. This new addition compiles the array into a
separate object file and then strips all sections but data.
The raw data section is then included into CBFS as a file named
'microcode_blob.bin' of type 0x53, which is assigned to microcode
storage.
Change-Id: I84ae040be52f520b106e3471c7e391e64d7847d9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1295
Tested-by: build bot (Jenkins)
When CONFIG_MICROCODE_IN_CBFS is enabled, find the microcode blob in
CBFS and pass it to intel_update_microcode() instead of using the
compiled in array.
CBFS accesses in pre-RAM and 'normal' environments are provided
through different API.
Change-Id: I35c1480edf87e550a7b88c4aadf079cf3ff86b5d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1296
Tested-by: build bot (Jenkins)
The PCIe device enable function prints when it disables a device.
The PCIe ports(bridges) use a different routine that didn't print
the message. Add it to be consistent and to provide better debug
output.
Change-Id: I8462c48e7f4930db68703f0bfb710c01c9643a98
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1326
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
It's only used on AMD based boards. Hence drop it, so we don't
accidently start using it by mistake instead of MAX_CPUS
Change-Id: Id8f522f24283129874d56e70bd00df92abe9c3cf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1325
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Changing CMOS value for power-on-after-power-fail was only honored
after reboot, which is counter intuitive (set from "enable" to
"disable",
power-off, replug device -> device turns on; and similar cases).
Modelled after http://review.coreboot.org/#/c/444
Change-Id: I2b8461dff1ae085c1ea4b4926084268b4da90321
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1323
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
In preparation to support CBFS hosted microcode blobs, this change
renames the wrapper include file containing the microcode to be
independent of CPU model.
Change-Id: If1a4963a52e5037a3a3495b90708ffc08b23f4c1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1294
Tested-by: build bot (Jenkins)
The function was too eager shifting stuff around, this change corrects
the problem.
Change-Id: I4c13dbe86cb627835dae05bb74af9867c28e143d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1291
Tested-by: build bot (Jenkins)
On systems with socketed CPUs we want to be able to
drop in a Sandy Bridge or Ivy Bridge CPU without recompiling the
firmware. Hence, detect the north bridge dynamically. In order
for this to work, we need Ivy Bridge MRC and coreboot configured
for Ivy Bridge.
Change-Id: I635bef2c61d47d36a3fdd87f8ecb6e69097ba969
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1281
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
We accomplish this goal by getting rid of the huge auto array in the
ram stage. This will in turn let us reduce CONFIG_STACK_SIZE.
We have to leave it on the stack in CAR as that's the simple way to
keep it private. It does not matter then as there is only one core
that is active.
Change-Id: Ie37a057ccae088b7f3bb4aab6de2713e64d96df6
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/1271
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Stefan Reinauer