summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2012-07-26ELOG: Add support for SMM and kernel GSMI driverDuncan Laurie
The linux kernel contains an SMI driver that was written by me (Duncan) and upstreamed a couple years ago called GSMI. This driver will format a parameter buffer and pass pointers to this parameter buffer to the SMI handler. It uses this to generate events for kernel shutdown reasons: Clean, Panic, Oops, etc. This function expects to be passed pointers into the SMM state save area that correspond to the prameter buffer and the return code, which are typically EAX and EBX. The format of the parameter buffer is defined in the kernel driver so we implement the same interface here in order to be compatible. GSMI_CMD_HANDSHAKE: this is an early call that it does to try and detect what kind of BIOS is running. GSMI_CMD_SET_EVENT_LOG: this contains a parameter buffer that has event type and data. The kernel-specific events are translated here and raw events are passed through as well which allows any run-time event to be added for testing. GSMI_CMD_CLEAR_EVENT_LOG: this command clears the event log. First the gsmi driver must be enabled in the kernel with CONFIG_GOOGLE_GSMI and then events can be added via sysfs and events are automatically generated for various kernel shutdown reasons. These can be seen in the event log as the 'Kernel Event' type: 169 | 2012-06-23 15:03:04 | Kernl Event | Clean Shutdown 181 | 2012-06-23 16:26:32 | Kernl Event | Oops 181 | 2012-06-23 16:26:32 | Kernl Event | Panic Change-Id: Ic0a3916401f0d9811e4aa8b2c560657dccc920c1 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/1316 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-25SMM: Fix state table for Intel Core2 CPUsStefan Reinauer
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>
2012-07-25SMM: Skip locking SPI registers in finalize stepDuncan Laurie
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>
2012-07-25ELOG: Log boot-time events found in southbridgeDuncan Laurie
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>
2012-07-25ELOG: Log events for Chrome OS developer/recovery modeDuncan Laurie
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>
2012-07-25Fix comment to reference IvyBridge, tooStefan Reinauer
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>
2012-07-25Include SandyBridge Microcode when IvyBridge is enabledStefan Reinauer
.. 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>
2012-07-25AMD parmer: Set correct azalia code verb tablezbao
Change-Id: I0b10080deb971cdefa4d3916fabd40f5a81b11f4 Signed-off-by: Zheng Bao <zheng.bao@amd.com> Signed-off-by: zbao <fishbaozi@gmail.com> Reviewed-on: http://review.coreboot.org/1352 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-25AMD family15tn: Add BIOS callback hook for getting VBIOS Imagezbao
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>
2012-07-25AMD Family 15tn: Set the default return value as AGESA_SUCCESS instead of TRUEzbao
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>
2012-07-25AMD Family15tn: Set the mask of MTRR to 0000FFFXX0000800zbao
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>
2012-07-25Change multiply ONE_MB to bit shifting.zbao
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>
2012-07-25SMM: rename tseg_fixup to tseg_relocate and exportDuncan Laurie
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>
2012-07-25Fix date output in Microcode updateStefan Reinauer
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)
2012-07-25CougarPoint/PantherPoint: Add HM77 device ID to tableKimarie Hoot
Change-Id: Ic5aada423d8e61abbebfcaaf5cb02ede80dfae02 Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-on: http://review.coreboot.org/1339 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins)
2012-07-25Extend smbios api to allow runtime change of mainboard serial and versionChristian Gmeiner
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>
2012-07-25Remove useless semicolonPatrick Georgi
Change-Id: Idc4d5737f5b49108987ca7fe90410d4e80b723f2 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/1354 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Mathias Krause <minipli@googlemail.com> Tested-by: build bot (Jenkins)
2012-07-25chromeos: Pass pointer to ChromeOS ACPI structure instead of VB Shared DataStefan Reinauer
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>
2012-07-25sync the northbridge.c with other family.zbao
Change-Id: Ice4d0202590fca0169dcda2770ca6add166b5c13 Signed-off-by: Zheng Bao <zheng.bao@amd.com> Signed-off-by: zbao <fishbaozi@gmail.com> Reviewed-on: http://review.coreboot.org/1262 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-25Fix LAPIC timer on Ivy Bridge systemsStefan Reinauer
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)
2012-07-25ELOG: Add support for a monotonic boot counter in CMOSDuncan Laurie
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>
2012-07-25ELOG: Add support for generating SMBIOS type15 tableDuncan Laurie
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>
2012-07-25More descriptive error messages in Sandybridge raminit codeStefan Reinauer
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>
2012-07-25bd82x6x: Drop unneeded pci_dev_tStefan Reinauer
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)
2012-07-24ELOG: Fix boot count increment for non-wake caseDuncan Laurie
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>
2012-07-24Ivybridge: fix workaround and enable PAIRDuncan Laurie
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>
2012-07-24CPU: Set flex ratio to nominal TDP ratio in bootblockDuncan Laurie
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>
2012-07-24SMM: Fix state save map for sandybridge and TSEGDuncan Laurie
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>
2012-07-24SMM: Add option for SPI driver to be available in SMMDuncan Laurie
- 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>
2012-07-24SMM: Add support for malloc in SMM if using TSEGDuncan Laurie
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>
2012-07-24ELOG: Add support for flash based event logDuncan Laurie
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>
2012-07-24SMM: Add heap region and move C handler higher in regionDuncan Laurie
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>
2012-07-24CPU: Update ivybridge PP1 current limit valueDuncan Laurie
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>
2012-07-24CPU: Add basic support for Nominal Configurable TDPDuncan Laurie
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>
2012-07-24Rename cache_lbmem() to cache_ramstage()Stefan Reinauer
... 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>
2012-07-24Implement stack overflow checking for the BSPRonald G. Minnich
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>
2012-07-24Fix automatic ME detection in finalizeStefan Reinauer
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>
2012-07-24ChromeOS: Remove board specific acpi_get_vdat_info()Stefan Reinauer
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>
2012-07-24Cougar/Panther Point: Compile in ME7 and ME8 code at the same timeStefan Reinauer
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>
2012-07-24Fix ME hash functions on Panther Point/Cougar PointStefan Reinauer
- 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>
2012-07-24Config changes to support microcode in CBFSVadim Bendebury
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>
2012-07-24Add BAR address debug information to Oxford PCIe serial driverMarc Jones
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>
2012-07-24Add microcode blob processingVadim Bendebury
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)
2012-07-24Add code to read Intel microcode from CBFSVadim Bendebury
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)
2012-07-24Add PCIe port disable debug messageMarc Jones
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)
2012-07-24Make MAX_PHYSICAL_CPUS invisible on non-AMD boardsStefan Reinauer
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>
2012-07-24bd82x6x: Support power-on-after-power-fail betterStefan Reinauer
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>
2012-07-24Rename microcode include file to be model agnosticVadim Bendebury
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)
2012-07-24Fix function generating GPIO state based vectorVadim Bendebury
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)
2012-07-24Make ACPI code detect Sandy/Ivy Bridge dynamicallyStefan Reinauer
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>