summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2013-03-21cbmem: add CBMEM_ID_ROMSTAGE_INFO idAaron Durbin
Introduce a new cbmem id to indicate romstage information. Proper coordination with ramstage and romstage can use this cbmem entity to communicate between one another. Change-Id: Id785f429eeff5b015188c36eb932e6a6ce122da8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2790 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-21ramstage: prepare for relocationAaron Durbin
The current ramstage code contains uses of symbols that cause issues when the ramstage is relocatable. There are 2 scenarios resolved by this patch: 1. Absolute symbols that are actually sizes/limits. The symbols are problematic when relocating a program because there is no way to distinguish a symbol that shouldn't be relocated and one that can. The only way to handle these symbols is to write a program to post process the relocations and keep a whitelist of ones that shouldn't be relocated. I don't believe that is a route that should be taken so fix the users of these sizes/limits encoded as absolute symbols to calculate the size at runtime or dereference a variable in memory containing the size/limit. 2. Absoulte symbols that were relocated to a fixed address. These absolute symbols are generated by assembly files to be placed at a fixed location. Again, these symbols are problematic because one can't distinguish a symbol that can't be relocated. The symbols are again resolved at runtime to allow for proper relocation. For the symbols defining a size either use 2 symbols and calculate the difference or provide a variable in memory containing the size. Change-Id: I1ef2bfe6fd531308218bcaac5dcccabf8edf932c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2789 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-21rmodule: add ability to calculate module placementAaron Durbin
There is a need to calculate the proper placement for an rmodule in memory. e.g. loading a compressed rmodule from flash into ram can be an issue. Determining the placement is hard since the header is not readable until it is decompressed so choosing the wrong location may require a memmove() after decompression. This patch provides a function to perform this calculation by finding region below a given address while making an assumption on the size of the rmodule header.. Change-Id: I2703438f58ae847ed6e80b58063ff820fbcfcbc0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2788 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21armv7: add function for dcache_clean_by_mva()David Hendricks
This adds a function for using the DCCMVAC instruction (dcache clean by MVA at point of coherency (main memory)). We already have the inline defined, it's just not used by anything. Change-Id: Ia0641566a8881335bed8da2963e1db8321d74267 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2871 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-21armv7: add a helper function for dcache ops by MVADavid Hendricks
This adds a helper function for dcache ops by MVA which will perform the specified operation on a given memory range. This will make it more trivial to add other data cache maintenance routines. Change-Id: I01d746d5fd2f4138257ca9cab9e9d738e73f8633 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2870 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-21armv7: cosmetic changes to new cache codeDavid Hendricks
This clarifies and/or fixes formatting of some comments and alphabetizes some function prototypes and inlines. It also corrects references to "modified virtual address" (MVA). Change-Id: Ibcdda4febf915cc4a1996a5bbb4ffecbcb50a324 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2869 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-21armv7: remove old isb() and dsb() macrosDavid Hendricks
This removes some old macros that we no longer use. Change-Id: I9d87beb5c2deca228cdf89a98e54b2779be0f0ea Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2868 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-21armv7: move armv7_invalidate_caches() to cache.cDavid Hendricks
This just moves cache maintenance stuff from the armv7 bootblock code to cache.c Change-Id: I0b3ab58a1d8a3fe3d9568e02e156a36b6f33ca0b Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2867 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-20x86: don't clear bss in ramstage entryAaron Durbin
The cbfs stage loading routine already zeros out the full memory region that a stage will be loaded. Therefore, it is unnecessary to to clear the bss again after once ramstage starts. Change-Id: Icc7021329dbf59bef948a41606f56746f21b507f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2865 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-20f15tn/Include/OptionIdsInstall.h: Remove idle `… || )`Siyuan Wang
Change-Id: I4aba6cc490ab24c6db345c0c5a64a6a9985ed0ab Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com> Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com> Reviewed-on: http://review.coreboot.org/2864 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-20ARM: remove assembly code dump when stages.o is builtRonald G. Minnich
For diagnostic purposes we had been dumping the assembly code when stages.o was built. We've past the need to do this and it's confusing to watch. Change-Id: Ib84cb73ed9dad3454efcb2be90d990ce88575229 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2555 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-20ARM: Fix the ldscripts so that exit/enter stage work correctly.Ronald G. Minnich
Remove the spurious creation of a start symbol, and use the stage_entry symbol directly. Change-Id: Ia62d5c056ac8b20c8ffdb78bff3d306065b6c45f Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2560 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-20Supermicro H8SCM: Use SPD read code from F15 wrapperKimarie Hoot
Changes: - Get rid of the h8scm mainboard specific code and use the platform generic function wrapper that was added in change http://review.coreboot.org/#/c/2777/ AMD Fam15: Add SPD read functions to wrapper code - Move DIMM addresses into devicetree.cb Notes: - The DIMM reads only happen in romstage, so the function is not available in ramstage. Point the read-SPD callback to a generic function in ramstage. Change-Id: I575221039ad65a59ae0f93397ef1038b669e81c7 Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-on: http://review.coreboot.org/2829 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-20AMD Dinar: Use SPD read code from F15 wrapperKimarie Hoot
Changes: - Get rid of the dinar mainboard specific code and use the platform generic function wrapper that was added in change http://review.coreboot.org/#/c/2777/ AMD Fam15: Add SPD read functions to wrapper code - Move DIMM addresses into devicetree.cb Notes: - The DIMM reads only happen in romstage, so the function is not available in ramstage. Point the read-SPD callback to a generic function in ramstage. - select_socket() and restore_socket() were created from code that was removed from AmdMemoryReadSPD() in dimmSpd.c. The functionality is specific to the dinar mainboard configuration and was therefore split from the generic read SPD functionality. Change-Id: I1e4b9a20dc497c15dbde6d89865bd5ee7501cdc0 Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-on: http://review.coreboot.org/2830 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-20Tyan S8226: Use SPD read code from F15 wrapperKimarie Hoot
Changes: - Get rid of the s8226 mainboard specific code and use the platform generic function wrapper that was added in change http://review.coreboot.org/#/c/2777/ AMD Fam15: Add SPD read functions to wrapper code - Move DIMM addresses into devicetree.cb Notes: - The DIMM reads only happen in romstage, so the function is not available in ramstage. Point the read-SPD callback to a generic function in ramstage. - select_socket() and restore_socket() started by duplicating sp5100_set_gpio() and sp5100_restore_gpio(), which were in dimmSpd.c. In addition to renaming the functions to more specifically state their purpose, some cleanup and magic number reduction was done. Change-Id: I1eaf64986ef4fa3f89aed2b69d3f9c8c913f726f Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-on: http://review.coreboot.org/2827 Tested-by: build bot (Jenkins) Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-20Supermicro H8QGI: Use SPD read code from F15 wrapperKimarie Hoot
Changes: - Get rid of the h8qgi mainboard specific code and use the platform generic function wrapper that was added in change http://review.coreboot.org/#/c/2777/ AMD Fam15: Add SPD read functions to wrapper code - Move DIMM addresses into devicetree.cb Notes: - The DIMM reads only happen in romstage, so the function is not available in ramstage. Point the read-SPD callback to a generic function in ramstage. - select_socket() and restore_socket() started by duplicating sp5100_set_gpio() and sp5100_restore_gpio(), which were in dimmSpd.c. In addition to renaming the functions to more specifically state their purpose, some cleanup and magic number reduction was done. Change-Id: I346ebd8399d4ba3e280576e667fdc62fa75a63b8 Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-on: http://review.coreboot.org/2828 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-20link/graphics: Add support for EDIDRonald G. Minnich
This code is taken from an EDID reader written at Red Hat. The key function is int decode_edid(unsigned char *edid, int size, struct edid *out) Which takes a pointer to an EDID blob, and a size, and decodes it into a machine-independent format in out, which may be used for driving chipsets. The EDID blob might come for IO, or a compiled-in EDID BLOB, or CBFS. Also included are the changes needed to use the EDID code on Link. Change-Id: I66b275b8ed28fd77cfa5978bdec1eeef9e9425f1 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2837 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-20link/graphics: New state machineRonald G. Minnich
This is a new state machine. It is more programmatic, in the case of auxio, and has much more symbolic naming, and very few "magic" numbers, except in the case of undocumented settings. As before, the 'pre-computed' IO ops are encoded in the iodefs table. A function, run, is passed and index into the table and runs the ops. A new operator, I, has been added. When the I operator is hit, run() returns the index of the next operator in the table. The i915lightup function runs the table. All the AUX channel ops have been removed from the table, however, and are now called as functions, using the previously committed auxio function. The iodefs table has been grouped into blocks of ops, which end in an I operator. As the lightup function progresses through startup, and the run() returns, the lightup function performs aux channel operations. This code is symbolic enough, I hope, that it will make haswell graphics bringup simpler. i915io.c, and the core of the code in i915lightup.c, were programatically generated, starting with IO logs from the DRM startup code in the kernel. It is possible to apply the tools that do this generation to newer IO logs from the kernel. Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2836 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-20link/graphics: implement a palette setting operatorRonald G. Minnich
Add a new operator, P, for the state machine, meaning implement a palette fill. Implement a function (palette) that fills the palette when the P operator is hit. This replaces 256 lines in the state machine table with 1. Change-Id: I67d9219fe7de0ecf1fb9faf92130c00c9f5f8e88 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Reviewed-on: http://review.coreboot.org/2835 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-20x86: provide more C standard environmentAaron Durbin
There are some external libraries that are built within coreboot's environment that expect a more common C standard environment. That includes things like inttypes.h and UINTx_MAX macros. This provides the minimal amount of #defines and files to build vboot_reference. Change-Id: I95b1f38368747af7b63eaca3650239bb8119bb13 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2859 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-20haswell: drop memory reservation for sandybridge GPU bugDuncan Laurie
This is not needed in haswell. Change-Id: I23817c2e01be33855f9d5a5e389e8ccb7954c0e2 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2847 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-20Intel: Update CPU microcode for Sandybridge/Ivybridge CPUsStefan Reinauer
Using the CPU microcode update script and Intel's Linux* Processor Microcode Data File from 2013-02-22 Change-Id: I853e381240b539b204c653404ca3d46369109219 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2846 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-20Intel: Update CPU microcode for 1067x CPUsStefan Reinauer
Using the CPU microcode update script and Intel's Linux* Processor Microcode Data File from 2013-02-22 Change-Id: I4585288905cf7374e671894ab37f125220ae535e Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2843 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-19link/graphics: add functions to support aux channel communicationsRonald G. Minnich
For full integration of FUI into coreboot, we need aux channel communcations. The intel_dp.c is a file taken from Linux and is used for aux channel comms. This file has been cut down to work with coreboot. For now it is associated with the link mainboard until we get a better handle on how this all fits together. This code is almost certainly usable on other platforms in the long term. But one step at a time. Change-Id: I7be4c56e0a7903f3901ac86e12b28f3bdc0f7947 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Reviewed-on: http://review.coreboot.org/2834 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-19armv7/exynos/snow: new cache maintenance APIDavid Hendricks
This adds a new API for cache maintenance operations. The idea is to be more explicit about operations that are going on so it's easier to manage branch predictor, cache, and TLB cleans and invalidations. Also, this adds some operations that were missing but required early on, such as branch predictor invalidation. Instruction and sync barriers were wrong earlier as well since the imported API assumed we compield with -march=armv5 (which we don't) and was missing wrappers for the native ARMv7 ISB/DSB/DMB instructions. For now, this is a start and it gives us something we can easily use in libpayload for doing things like cleaning and invalidating dcache when doing DMA transfers. TODO: - Set cache policy explicitly before re-enabling. Right now it's left at default. - Finish deprecating old cache maintenance API. - We do an extra icache/dcache flush when going from bootblock to romstage. Change-Id: I7390981190e3213f4e1431f8e56746545c5cc7c9 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2729 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-19rmodule: add ramstage supportAaron Durbin
Coreboot's ramstage defines certain sections/symbols in its fixed static linker script. It uses these sections/symbols for locating the drivers as well as its own program information. Add these sections and symbols to the rmodule linker script so that ramstage can be linked as an rmodule. These sections and symbols are a noop for other rmodule-linked programs, but they are vital to the ramstage. Also add a comment in coreboot_ram.ld to mirror any changes made there to the rmodule linker script. Change-Id: Ib9885a00e987aef0ee1ae34f1d73066e15bca9b1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2786 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-19google/snow: fix a GPIO array indexDavid Hendricks
This fixes a trivial error with the recovery mode GPIO index. Change-Id: I7290c1e23cdddaf91c9021d4e4252c0c772b6eab Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2825 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-19lynxpoint: Add cbfs_load_payload() implementationAaron Durbin
SPI accesses can be slow depending on the setup and the access pattern. The current SPI hardware setup to cache and prefetch. The alternative cbfs_load_payload() function takes advantage of the caching in the CPU because the ROM is cached as write protected as well as the SPI's hardware's caching/prefetching implementation. The CPU will fetch consecutive aligned cachelines which will hit the ROM as cacheline-aligned addresses. Once the payload is mirrored into RAM the segment loading can take place by reading RAM instead of ROM. With the alternative cbfs_load_payload() the boot time on a baskingridge board saves ~100ms. This savings is observed using cbmem.py after performing warm reboots and looking at TS_SELFBOOT_JUMP (99) entries. This is booting with a depthcharge payload whose payload file fits within the SMM_DEFAULT_SIZE (0x10000 bytes). Datapoints with TS_LOAD_PAYLOAD (90) & TS_SELFBOOT_JUMP (99) cbmem entries: Baseline Alt -------- -------- 90:3,859,310 (473) 90:3,863,647 (454) 99:3,989,578 (130,268) 99:3,888,709 (25,062) 90:3,899,450 (477) 90:3,860,926 (463) 99:4,029,459 (130,008) 99:3,890,583 (29,657) 90:3,834,600 (466) 90:3,890,564 (465) 99:3,964,535 (129,934) 99:3,920,213 (29,649) Booted baskingridge many times and observed 100ms reduction in TS_SELFBOOT_JUMP times (time to load payload). Change-Id: I27b2dec59ecd469a4906b4179b39928e9201db81 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2783 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-19x86: remove stack definition in linker scriptAaron Durbin
In order to prepare the ramstage to be linked by the rmodule linker the stack needs to be self-contained within the ramstage objects. The reasoning is that the rmodule linker provides a way to define a heap, but it doesn't currently have a region for the stack. The downside to this is that memory footprint of the ramstage can change when compared before this change. The size difference stems from the link ordering of the objects as the stack is now defined within c_start.S. The size fluctuation ranges from 0 to CONFIG_STACK_SIZE - 1 because of the previous behavior or aligning to CONFIG_STACK_SIZE. It should be noted that such an alignment is unnecessary for 32-bit x86 as the alignment requirement for the stacks are 4 byte alignment. Also the memory footprint is still dominated by CONFIG_RAMTOP and CONFIG_RAMBASE. Change-Id: I63a4ddd249104bc27aff2ab6b39fc6db12b54028 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2785 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-19cbfs: alternative support for cbfs_load_payload()Aaron Durbin
In certain situations boot speed can be increased by providing an alternative implementation to cbfs_load_payload(). The ALT_CBFS_LOAD_PAYLOAD option allows for the mainboard or chipset to provide its own implementation. Booted baskingridge board with alternative and regular cbfs_load_payload(). Change-Id: I547ac9881a82bacbdb3bbdf38088dfcc22fd0c2c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2782 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-19bd82x6x: Fix compiling with USB debug port supportRonald G. Minnich
At some point, compiles with USB Debug port stopped working. This change makes a trivial reordering in the code and adds two makefile entries to make it build without errors. It also works on stout. Build and boot as normal. Works. Enable CONFIG_USB, connect USB debug hardware to the correct port (on stout, that's the one on the left nearest the back) and watch for output. Change-Id: I7fbb7983a19b0872e2d9e4248db8949e72beaaa0 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Reviewed-on: http://review.coreboot.org/2784 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-19AMD Fam15: Add SPD read functions to wrapper codeKimarie Hoot
Change: This is the initial step for moving the AMD F15 & HUDSON1,2,3 SPD-read callout out of the mainboard directories and into the wrapper. The next step is to update the platforms to use this routine in BiosCallouts.c and to delete the code from the mainboard directories. The DIMM addresses should be moved into devicetree.cb. If there are significant differences or reasons that the mainboard needs to override this code, it's perfectly reasonable to keep using the version in the mainboard, but this allows us to remove duplicated code and simplify the mainboard directories. Notes: This started by duplicating what was in Dinar, and was changed to use the devicetree.cb structures. Significant cleanup and magic number reduction was done as well. It is intended that this file will not be included in ramstage as the DIMM init is all done in romstage. This is similar to what was done for Parmer/Thatcher in commit 7fb692bd - http://review.coreboot.org/#/c/2190/ Fam15tn: Move SPD read from mainboards into wrapper Yes, it would make sense to split this into two separate files and move the SMBus initialization and access into the southbridge wrapper. Maybe that can come next. Change-Id: I4e00ada288e1486cf30684403505e475f9093ec2 Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-on: http://review.coreboot.org/2777 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-19cbfstool locate: Rename -a align switch to -P for page sizeHung-Te Lin
cbfstool usage change: The "-a" parameter for "cbfstool locate" is switched to "-P/--page-size". The "locate" command was used to find a place to store ELF stage image in one memory page. Its argument "-a (alignment)" was actually specifying the page size instead of doing memory address alignment. This can be confusing when people are trying to put a blob in aligned location (ex, microcode needs to be aligned in 0x10), and see this: cbfstool coreboot.rom locate -f test.bin -n test -a 0x40000 # output: 0x44, which does not look like aligned to 0x40000. To prevent confusion, it's now switched to "-P/--page-size". Verified by building i386/axus/tc320 (with page limitation 0x40000): cbfstool coreboot.rom locate -f romstage_null.bin -n romstage -P 0x40000 # output: 0x44 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Change-Id: I0893adde51ebf46da1c34913f9c35507ed8ff731 Reviewed-on: http://review.coreboot.org/2730 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-19Include byteorder.h for the definition of ntohl in romstage.cHung-Te Lin
A fix to eliminate warnings when building romstage files with ChromeOS compilers Change-Id: Ia5d7bbdde3aa3439fd493f5795f2cc2bf4c4c187 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2781 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-19haswell: wait 10ms after INIT IPIAaron Durbin
There should be a fixed 10ms wait after sending an INIT IPI. The previous implementation was just waiting up to 10ms for the IPI to complete the send. That is not correct. The 10ms is unconditional according to the documentation. No ill effects were observed with the previous behavior, but it's important to follow the documentation. Change-Id: Ib31d49ac74808f6eb512310e9f54a8f4abc3bfd7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2780 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-19haswell: Parallel AP bringupAaron Durbin
This patch parallelizes the AP startup for Haswell-based devices. It does not touch the generic secondary startup code. Instead it provides its own MP support matching up with the Haswell BWG. It seemed to be too much trouble to support the old startup way and this new way. Because of that parallel loading is the only thing supported. A couple of things to note: 1. Micrcode needs to be loaded twice. Once before MTRR and caching is enabled. And a second time after SMM relocation. 2. The sipi_vector is entirely self-contained. Once it is loaded and written back to RAM the APs do not access memory outside of the sipi_vector load location until a sync up in ramstage. 3. SMM relocation is kicked off by an IPI to self w/ SMI set as the destination mode. The following are timings from cbmem with dev mode disabled and recovery mode enabled to boot directly into the kernel. This was done on the baskingridge CRB with a 4-core 8-thread CPU and 2 DIMMs 1GiB each. The kernel has console enabled on the serial port. Entry 70 is the device initialization, and that is where the APs are brought up. With these two examples it looks to shave off ~200 ms of boot time. Before: 1:55,382 2:57,606 (2,223) 3:3,108,983 (3,051,377) 4:3,110,084 (1,101) 8:3,113,109 (3,024) 9:3,156,694 (43,585) 10:3,156,815 (120) 30:3,157,110 (295) 40:3,158,180 (1,069) 50:3,160,157 (1,977) 60:3,160,366 (208) 70:4,221,044 (1,060,677) 75:4,221,062 (18) 80:4,227,185 (6,122) 90:4,227,669 (484) 99:4,265,596 (37,927) 1000:4,267,822 (2,225) 1001:4,268,507 (685) 1002:4,268,780 (272) 1003:4,398,676 (129,896) 1004:4,398,979 (303) 1100:7,477,601 (3,078,621) 1101:7,480,210 (2,608) After: 1:49,518 2:51,778 (2,259) 3:3,081,186 (3,029,407) 4:3,082,252 (1,066) 8:3,085,137 (2,884) 9:3,130,339 (45,202) 10:3,130,518 (178) 30:3,130,544 (26) 40:3,131,125 (580) 50:3,133,023 (1,897) 60:3,133,278 (255) 70:4,009,259 (875,980) 75:4,009,273 (13) 80:4,015,947 (6,674) 90:4,016,430 (482) 99:4,056,265 (39,835) 1000:4,058,492 (2,226) 1001:4,059,176 (684) 1002:4,059,450 (273) 1003:4,189,333 (129,883) 1004:4,189,770 (436) 1100:7,262,358 (3,072,588) 1101:7,263,926 (1,567) Booted the baskingridge board as noted above. Also analyzed serial messages with pcserial enabled. Change-Id: Ifedc7f787953647c228b11afdb725686e38c4098 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2779 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-19intel microcode: split up microcode loading stagesAaron Durbin
This patch only applies to CONFIG_MICROCODE_IN_CBFS. The intel microcode update routine would always walk the CBFS for the microcode file. Then it would loop through the whole file looking for a match then load the microcode. This process was maintained for intel_update_microcode_from_cbfs(), however 2 new functions were exported: 1. const void *intel_microcode_find(void) 2. void intel_microcode_load_unlocked(const void *microcode_patch) The first locates a matching microcode while the second loads that mircocode. These new functions can then be used to cache the found microcode blob w/o having to re-walk the CBFS. Booted baskingridge board to Linux and noted that all microcode revisions match on all the CPUs. Change-Id: Ifde3f3e5c100911c4f984dd56d36664a8acdf7d5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2778 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-19AMD Dinar: Remove Unused Oem.h Header FileKimarie Hoot
Having this header file in the mainboard directory breaks the dinar build on cygwin because the header file in the dinar mainboard is used instead of the correct header file src/vendorcode/amd/cimx/sb700/OEM.h. The build probably works fine on Linux systems because, due to case-sensitivity, Oem.h will not match the #include "OEM.h" statement in src/southbridge/amd/cimx/sb700/Platform.h. The Oem.h file in the dinar mainboard is not used by any other source files, and the defines in the dinar mainboard are duplicated by defines in the correct OEM.h file. Therefore, the file can be safely removed. Change-Id: I81b97eca8116d63644d335edc3bb51f90c7094d9 Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-on: http://review.coreboot.org/2776 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-18SMM: link against libgccStefan Reinauer
The non-relocatable SMM code was changed to link against libgcc a while back so that printk could use built-in division instead of a hand crafted div() function. However, the relocatable SMM code was not adapted by mistake. This patch links the relocatable SMM against libgcc, too, so we can enable it for Haswell. Change-Id: Ia64a78e2e62348d115ae4ded52d1a02c74c5cea4 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2727 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: add romstage_after_car() functionAaron Durbin
There are changes coming to perform more complex tasks after cache-as-ram has been torn down but before ramstage is loaded. Therefore, add the romstage_after_car() function to call after cache-as-ram is torn down. Its responsibility is for loading the ramstage and any other complex tasks. For example, the saving of OS-controlled memory in the resume path has now been moved into C instead of assembly. Change-Id: Ie0c229cf83a9271c8995b31c534c8e5a696b164e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2757 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: move call site of save_mrc_data()Aaron Durbin
The save_mrc_data() was previously called conditionally in the raminit code. The save_mrc_data() function was called in the non-S3 wake paths. However, the common romstage_common() code was checking cbmem initialization things on s3 wake. Between the two callers cbmem_initialize() was being called twice in the non-s3 wake paths. Moreover, saving of the mrc data was not allowed when CONFIG_EARLY_CBMEM_INIT wasn't enabled. Therefore, move the save_mrc_data() to romstage_common. It already has the knowledge of the wake path. Also remove the CONFIG_EARLY_CBMEM_INIT requirement from save_mrc_data() as well as the call to cbmem_initialize(). Change-Id: I7f0e4d752c92d9d5eedb8fa56133ec190caf77da Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2756 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: romstage: pass stack pointer and MTRRsAaron Durbin
Instead of hard coding the policy for the stack and MTRR values after the cache-as-ram is torn down, allow for the C code to pass those policies back to the cache-as-ram assembly file. That way, ramstage relocation can use a different stack as well as different MTRR policies. Change-Id: Ied024d933f96a12ed0703c51c506586f4b50bd14 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2755 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: unify romstage logicAaron Durbin
This commit pulls in all the common logic for romstage into the Haswell cpu directory. The bits specific to the mainboard still reside under their respective directories. The calling sequence bounces from the cpu directory to mainboard then back to the cpu directory. The reasoning is that Haswell systems use cache-as-ram for backing memory in romstage. The stack is used to allocate structures. However, now changes can be made to the romstage for Haswell and apply to all boards. Change-Id: I2bf08013c46a99235ffe4bde88a935c3378eb341 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2754 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: remove unused sys_info structureAaron Durbin
This structure is not used nor the variable being instantiated on the stack. Remove them. Change-Id: If3abe2dd77104eff49665dd33570b07179bf34f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2753 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: adjust CAR usageAaron Durbin
It was found that the Haswell reference code was smashing through the stack into the reference code's heap implementation. The reason for this is because our current CAR allocation is too small. Moreover there are quite a few things to coordinate between 2 code bases to get correct. This commit separates the CAR into 2 parts: 1. MRC CAR usage. 2. Coreboot CAR usage. Pointers from one region can be passed between the 2 modules, but one should not be able to affect the others as checking has been put into place in both modules. The CAR size has effectively been doubled from 0x20000 (128 KiB) to 0x40000 (256KiB). Not all of that increase was needed, but enforcing a power of 2 size only utilizes 1 MTRR. Old CAR layout with a single contiguous stack with the region starting at CONFIG_DCACHE_RAM_BASE: +---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE | MRC global variables | | CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes | +---------------------------------------+ | ROM stage stack | | | | | +---------------------------------------+ | MRC Heap 30000 bytes | +---------------------------------------+ | ROM stage console | | CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes | +---------------------------------------+ | ROM stage CAR_GLOBAL variables | +---------------------------------------+ Offset 0 There was some hard coded offsets in the reference code wrapper to start the heap past the console buffer. Even with this commit the console can smash into the following region depending on what size CONFIG_CONSOLE_CAR_BUFFER_SIZE is. As noted above This change splits the CAR region into 2 parts starting at CONFIG_DCACHE_RAM_BASE: +---------------------------------------+ | MRC Region | | CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes | +---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE | ROM stage stack | | | | | +---------------------------------------+ | ROM stage console | | CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes | +---------------------------------------+ | ROM stage CAR_GLOBAL variables | +---------------------------------------+ Offset 0 Another variable was add, CONFIG_DCACHE_RAM_ROMSTAGE_STACK_SIZE, which represents the expected stack usage for the romstage. A marker is checked at the base of the stack to determine if either the stack was smashed or the console encroached on the stack. Change-Id: Id76f2fe4a5cf1c776c8f0019f406593f68e443a7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2752 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18rmodule: add rmodules class and new typeAaron Durbin
Add an rmodules class so that there are default rules for compiling files that will be linked by the rmodule linker. Also, add a new type for SIPI vectors. Change-Id: Ided9e15577b34aff34dc23e5e16791c607caf399 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2751 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18wtm2: Disable USB port 7 (SD card) due to hangDuncan Laurie
This is causing a hang in depthcharge. For now just disable this port. Change-Id: I87a6db2d8361588e82eee640c74cea690115bed5 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2764 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18rmodule: include heap in bss sectionAaron Durbin
By including the heap in the bss output section the size is accounted for in a elf PT_LOAD segment. Without this change the heap wasn't being put into a PT_LOAD segment. The result is a nop w.r.t. functionality, but readelf and company will have proper MemSiz fields. Change-Id: Ibfe9bb87603dcd4c5ff1c57c6af910bbba96b02b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2750 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18rmodule: add 16 bytes of paddingAaron Durbin
There is a plan to utlize rmodules for loading ramstage as a relocatable module. However, the rmodule header may change. In order to provide some wiggle room for changing the contents of the rmodule header add some padding. This won't stop the need for coordinating properly between the romstage loader that may be in readonly flash and rmodule header fields. But it will provide for a way to make certain assumptions about alignment of the rmodule's program when the rmodule is compressed in the flash. Change-Id: I9ac5cf495c0bce494e7eaa3bd2f2bd39889b4c52 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2749 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: lapic timer supportAaron Durbin
Haswell's BCLK is fised at 100MHz like Sandy/Ivy. Add Haswell's model to the switch statement. Change-Id: Ib9e2afc04eba940bfcee92a6ee5402759b21cc45 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2747 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18lynxpoint: Move a bit of generic RCBA into early_pchDuncan Laurie
Rather than have to repeat this bit in every mainboard. Also, remove the reset of the RTC power status from here. We had done this in TOT for current platforms but did not carry it back to emeraldlake2 where this branched from. If we clear the status here then we don't get an event logged later which can be important for the devices that do not have a CMOS battery. Change-Id: Ia7131e9d9e7cf86228a285df652a96bcabf05260 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2683 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18lib: add rmodule supportAaron Durbin
A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2692 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: fix ACPI MCFG tableAaron Durbin
The acpi_fill_mcfg() was still using ivy/sandy PCI device ids which Hawell obviously doesn't have. This resulted in an empty MCFG table. Instead of relying on PCI device ids use dev/fn 0/0 since that is where the host bridge always resides. Additionally remove the defines for the IB and SB pci device ids. Replace them with mobile and ult Haswel device ids and use those in the pci driver tables for the northbridge code. Booted to Linux and noted that MCFG was properly parsed. Change-Id: Ieaab2dfef0e9daf3edbd8a27efe0825d2beb9443 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2748 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: enable caching before SMM initializationAaron Durbin
The SMM handler resides in the TSEG region which is far above CONFIG_RAM_TOP (which is the highest cacheable address) before MTRRs are setup. This means that calling initialize_cpus() before performing MTRR setup on the BSP means the SMM handler is copied using uncacheable accesses. Improve the SMM handler setup path by enabling performing MTRR setup on for the BSP before the call to initialize_cpus(). In order to do this the haswell_init() function was split into 2 paths: BSP & AP paths. There is a cpu_common_init() that both call to perform similar functionality. The BSP path in haswell_init() then starts the APs using intel_cores_init(). The AP path in haswell_init() loads microcode and sets up MTRRs. This split will be leveraged for future support of bringing up APs in parallel as well as adhering to the Haswell MP initialization requirements. Change-Id: Id8e17af149e68d708f3d4765e38b1c61f7ebb470 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2746 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: Clear correct number of MCA banksAaron Durbin
The configure_mca() function was hard coding the number of banks the cpu supported. Query this dynamically so that it no longer clears only 7 banks. Change-Id: I33fce8fadc0facd1016b3295faaf3ae90e490a71 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2745 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: move definition of CORE_THREAD_COUNT_MSRAaron Durbin
This just moves the definiton of CORE_THREAD_COUNT_MSR so that future code can utilize it. Change-Id: I15a381090f21ff758288f55dc964b6694feb6064 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2744 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: Use SMM ModulesAaron Durbin
This commit adds support for using the SMM modules for haswell-based boards. The SMI handling was also refactored to put the relocation handler and permanent SMM handler loading in the cpu directory. All tseg adjustment support is dropped by relying on the SMM module support to perform the necessary relocations. Change-Id: I8dd23610772fc4408567d9f4adf339596eac7b1f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2728 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18Add support for "Stout" ChromebookStefan Reinauer
We're happy to announce coreboot support for the "Stout" Chromebook, a.k.a Lenovo X131e Chromebook. Change-Id: I9b995f8d0dd48e41c788b7c3d35b4fac5840e425 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2636 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18Add Intel Whitetip Mountain 2 mainboardDuncan Laurie
This is mostly a copy of Whitetip Mountain 1 with specific GPIO map for this Customer Reference Board (CRB). This mainboard currently has basic funcionality and is able to boot a Linux Kernel but many of the new Haswell ULT specific devices are not yet enabled. Change-Id: I999452d86f00a2c245fa39b1b76080f6a3b1e352 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2725 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17Intel HD Audio: clean up initialization codeStefan Reinauer
- Some initialization steps were done twice - One step was missing for Panther Point HDA - Added a 1ms delay after reset - Increased timeout to 1ms for all codec operations Change-Id: Ib751f1a16ccd88ea2fbbb2a10737f76277574026 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2518 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17x86 intel: Add Firmware Interface Table supportAaron Durbin
Haswell CPUs require a FIT table in the firmware. This commit adds rudimentary support for a FIT table. The number of entries in the table is based on a configuration option. The code only generates a type 0 entry. A follow-on tool will need to be developed to populate the FIT entries as well as checksumming the table. Verified image has a FIT pointer and table when option is selected. Change-Id: I3a314016a09a1cc26bf1fb5d17aa50853d2ef4f8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2642 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17haswell platforms: restructure romstage mainAaron Durbin
There was a mix of setup code sprinkled across the various components: southbridge code in the northbridge, etc. This commit reorganizes the code so that northbridge code doesn't initialize southbridge components. Additionally, the calling dram initialization no longer calls out to ME code. The main() function in the mainboard calls the necessary ME functions before and after dram initialization. The biggest change is the addition of an early_pch_init() function which initializes the BARs, GPIOs, and RCBA configuration. It is also responsible for reporting back to the caller if the board is being woken up from S3. The one sequence difference is that the RCBA config is performed before claling the reference code. Lastly the rcba configuration was changed to be table driven so that different board/configurations can use the same code. It should be possible to have board/configuration specific gpio and rcba configuration while reusing the romstage code. Change-Id: I830e41b426261dd686a2701ce054fc39f296dffa Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2681 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17Add Intel Whitetip Mountain 1 mainboardDuncan Laurie
Lots of things are still placeholder and need work. Due to the useful GPIOs being run to either the EC or the SIO1007 I have hard coded developer mode on and recovery mode off. Change-Id: I4c308bd90db03ac5bffdfde566e5adbbaabac632 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2724 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17bd82x6x: Add config option to force SATA link to different speeds.Shawn Nematbakhsh
Certain SATA devices claim to support SATA 6 Gbps, but in fact have bugs. For these devices, add a config option to force the SATA link speed to something other than default. Change-Id: I2dc1793cd58771298a392345162d39d20eb0afbb Signed-off-by: Shawn Nematbakhsh <shawnn@google.com> Reviewed-on: http://review.coreboot.org/2765 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17Pantherpoint: Add XHCI device initDuncan Laurie
This enables power management and clock gating on XHCI. Change-Id: I124ea6c5aca034b7ec4b5286d971c2adfce25c88 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2761 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17bd82x6x: don't use absolute symbolsAaron Durbin
objcopy -B provides symbols of the form _binary_<name>_(start|end|size). However, the _size variant is an absoult symbol. If one wants to relocate the smi loading the _size symbol will be relocated which is wrong since it is suppose to be a fixed size. There is no way to distinguish symbols that shouldn't be relocated vs ones that can. Instead use the _start and _end variants to determine the size. Change-Id: I55192992cf36f62a9d8dd896e5fb3043a3eacbd3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2760 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17Add bd82x6x XHCI(USB3) S3/S4 workaroundMarc Jones
The bd82x6x requires some additional setting on S3/S4 entry. Change-Id: I24489ab94dd7cd5a4a64044f25153f5b01a45b77 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/2759 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17Add bd82x6x PCH functions to SMMMarc Jones
Add the PCH function to SMM for follow-on SMM patches that require these functions. Change-Id: I7f3a512c5e98446e835b59934d63a99e8af15280 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/2758 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17haswell: include TSEG region in cacheable memoryAaron Durbin
The SMRR takes precedence over the MTRR entries. Therefore, if the TSEG region is setup as cacheable through the MTTRs, accesses to the TSEG region before SMM relocation are cached. This allows for the setup of SMM relocation to be faster by caching accesses to the future TSEG (SMRAM) memory. MC MAP: TOM: 0x140000000 MC MAP: TOUUD: 0x18f600000 MC MAP: MESEG_BASE: 0x13f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x13f000000 MC MAP: REMAP_LIMIT: 0x18f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BGSM: 0xad800000 MC MAP: BDSM: 0xada00000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 TSEG->BGSM: PCI: 00:00.0 resource base ad000000 size 800000 align 0 gran 0 limit 0 flags f0004200 index 4 BGSM->TOLUD: PCI: 00:00.0 resource base ad800000 size 2200000 align 0 gran 0 limit 0 flags f0000200 index 5 Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 512MB, type WB Setting variable MTRR 2, base: 2560MB, range: 256MB, type WB Adding hole at 2776MB-2816MB Setting variable MTRR 3, base: 2776MB, range: 8MB, type UC Setting variable MTRR 4, base: 2784MB, range: 32MB, type UC Zero-sized MTRR range @0KB Allocate an msr - basek = 00400000, sizek = 0023d800, Setting variable MTRR 5, base: 4096MB, range: 2048MB, type WB Setting variable MTRR 6, base: 6144MB, range: 256MB, type WB Adding hole at 6390MB-6400MB Setting variable MTRR 7, base: 6390MB, range: 2MB, type UC MTRR translation from MB to addresses: MTRR 0: 0x00000000 -> 0x80000000 WB MTRR 1: 0x80000000 -> 0xa0000000 WB MTRR 2: 0xa0000000 -> 0xb0000000 WB MTRR 3: 0xad800000 -> 0xae000000 UC MTRR 4: 0xae000000 -> 0xb0000000 UC I'm not a fan of the marking physical address space with MTRRs as being UC which is PCI space, but it is technically correct. Lastly, drop a comment describing AP startup flow through coreboot. Change-Id: Ic63c0377b9c20102fcd3f190052fb32bc5f89182 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2690 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17i945: Replace some two magic values by defined namesPatrick Georgi
Devoutly to be wish'd. To die,—to sleep;— To sleep! perchance to dream:—ay, there's the rub; For in that sleep of death what dreams may come, (Since who could argue with William Shakespeare?) Change-Id: I4e4c617dcd3ede81a0abbe16f9916562d24fa8ce Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/2733 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-17ASROCK Fam14 DSDT: Add secondary bus range to PCI0Mike Loptien
Adding the 'WordBusNumber' macro to the PCI0 CRES ResourceTemplate in the Persimmon DSDT. This sets up the bus number for the PCI0 device and the secondary bus number in the CRS method. This change came in response to a 'dmesg' error which states: '[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS' By adding the 'WordBusNumber' macro, ACPI can set up a valid range for the PCIe downstream busses, thereby relieving the Linux kernel from "guessing" the valid range based off _BBN or assuming [0-0xFF]. The Linux kernel code that checks this bus range is in `drivers/acpi/pci_root.c`. PCI busses can have up to 256 secondary busses connected to them via a PCI-PCI bridge. However, these busses do not have to be sequentially numbered, so leaving out a section of the range (eg. allowing [0-0x7F]) will unnecessarily restrict the downstream busses. This is the same change as made to Persimmon with change-id I44f22: http://review.coreboot.org/#/c/2592/ Change-Id: I5184df8deb7b5d2e15404d689c16c00493eb01aa Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2736 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17AMD Fam14 DSDT: Remove INI method from AZHD deviceMike Loptien
I am removing the _INI method from the AZHD device because it does not seem to do anything and causes errors in the FWTS[1] (Firmware Test Suite) test 'method'. The INI method performs device specific initialization and is run when OSPM loads a description table. It must only access OperationRegions that have been indicated as available by the _REG (Region) method. We do not have a _REG method and during my testing, I added a REG method but it did not seem to make a difference in the PCI register space. The bit fields defined as NSDI (Disable No Snoop), NSDO (Disable No Snoop Override), and NSEN (Enable No Snoop Request) do not ever get written from their default values. And writing to these bit fields does not seem to be necessary because I did not notice any change in audio functionality. In an effort to clean up as many FWTS errors as possible, I propose removing this method altogether. I have seen no change in operation (audio works with and without this method) and there does not seem to be any change in lspci or dmesg. FWTS information can be found here: [1]: https://wiki.ubuntu.com/Kernel/Reference/fwts This is the same chagne as made to Persimmon in Change-ID If8d86f: http://review.coreboot.org/#/c/2726/ Change-Id: Id560ea85a38f73aaba2c35447bbce46bd9c0d0dd Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2741 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17ASROCK Fam14 DSDT: Remove INI method from AZHD deviceMike Loptien
I am removing the _INI method from the AZHD device because it does not seem to do anything and causes errors in the FWTS[1] (Firmware Test Suite) test 'method'. The INI method performs device specific initialization and is run when OSPM loads a description table. It must only access OperationRegions that have been indicated as available by the _REG (Region) method. We do not have a _REG method and during my testing, I added a REG method but it did not seem to make a difference in the PCI register space. The bit fields defined as NSDI (Disable No Snoop), NSDO (Disable No Snoop Override), and NSEN (Enable No Snoop Request) do not ever get written from their default values. And writing to these bit fields does not seem to be necessary because I did not notice any change in audio functionality. In an effort to clean up as many FWTS errors as possible, I propose removing this method altogether. I have seen no change in operation (audio works with and without this method) and there does not seem to be any change in lspci or dmesg. FWTS information can be found here: [1]: https://wiki.ubuntu.com/Kernel/Reference/fwts This is the same change as made to Persimmon in Change-ID If8d86f: http://review.coreboot.org/#/c/2726/ Change-Id: Iae70c3d0af1cdaca31b206ad6daba4d38ee6b780 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2742 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17Lippert Fam14 DSDT: Remove INI method from AZHD deviceMike Loptien
I am removing the _INI method from the AZHD device because it does not seem to do anything and causes errors in the FWTS[1] (Firmware Test Suite) test 'method'. The INI method performs device specific initialization and is run when OSPM loads a description table. It must only access OperationRegions that have been indicated as available by the _REG (Region) method. We do not have a _REG method and during my testing, I added a REG method but it did not seem to make a difference in the PCI register space. The bit fields defined as NSDI (Disable No Snoop), NSDO (Disable No Snoop Override), and NSEN (Enable No Snoop Request) do not ever get written from their default values. And writing to these bit fields does not seem to be necessary because I did not notice any change in audio functionality. In an effort to clean up as many FWTS errors as possible, I propose removing this method altogether. I have seen no change in operation (audio works with and without this method) and there does not seem to be any change in lspci or dmesg. FWTS information can be found here: [1]: https://wiki.ubuntu.com/Kernel/Reference/fwts This is the same change as made to Persimmon in Change-ID If8d86f: http://review.coreboot.org/#/c/2726/ Change-Id: Iff594d4a3493531561eb25d1cceeb97bcefde424 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2743 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17Lippert Fam14 DSDT: Add secondary bus range to PCI0Mike Loptien
Adding the 'WordBusNumber' macro to the PCI0 CRES ResourceTemplate in the Persimmon DSDT. This sets up the bus number for the PCI0 device and the secondary bus number in the CRS method. This change came in response to a 'dmesg' error which states: '[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS' By adding the 'WordBusNumber' macro, ACPI can set up a valid range for the PCIe downstream busses, thereby relieving the Linux kernel from "guessing" the valid range based off _BBN or assuming [0-0xFF]. The Linux kernel code that checks this bus range is in `drivers/acpi/pci_root.c`. PCI busses can have up to 256 secondary busses connected to them via a PCI-PCI bridge. However, these busses do not have to be sequentially numbered, so leaving out a section of the range (eg. allowing [0-0x7F]) will unnecessarily restrict the downstream busses. This is the same change as made to Persimmon with change-id I44f22: http://review.coreboot.org/#/c/2592/ Change-Id: Ie36b60973c6a5f9076bb55c8f451532711a2f8a8 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2737 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17AMD Fam14 DSDT: Add OSC methodMike Loptien
The _OSC method is used to tell the OS what capabilities it can take control over from the firmware. This method is described in chapter 6.2.9 of the ACPI spec v3.0. The method takes 4 inputs (UUID, Rev ID, Input Count, and Capabilities Buffer) and returns a Capabilites Buffer the same size as the input Buffer. This Buffer is generally 3 Dwords long consisting of an Errors Dword, a Supported Capabilities Dword, and a Control Dword. The OS will request control of certain capabilities and the firmware must grant or deny control of those features. We do not want to have control over anything so let the OS control as much as it can. The _OSC method is required for PCIe devices and dmesg checks for its existence and issues an error if it is not found. This is the same change made to Persimmon with Change-ID I149428: http://review.coreboot.org/#/c/2684/ Change-Id: If6dd1a558d9c319d9a41ce63588550c8e81e595f Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2738 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17ASROCK Fam14 DSDT: Add OSC methodMike Loptien
The _OSC method is used to tell the OS what capabilities it can take control over from the firmware. This method is described in chapter 6.2.9 of the ACPI spec v3.0. The method takes 4 inputs (UUID, Rev ID, Input Count, and Capabilities Buffer) and returns a Capabilites Buffer the same size as the input Buffer. This Buffer is generally 3 Dwords long consisting of an Errors Dword, a Supported Capabilities Dword, and a Control Dword. The OS will request control of certain capabilities and the firmware must grant or deny control of those features. We do not want to have control over anything so let the OS control as much as it can. The _OSC method is required for PCIe devices and dmesg checks for its existence and issues an error if it is not found. This is the same change made to Persimmon with Change-ID I149428: http://review.coreboot.org/#/c/2684/ Change-Id: I2701d915338294bdade2ad334b22a51db980892e Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2739 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17Lippert Fam14 DSDT: Add OSC methodMike Loptien
The _OSC method is used to tell the OS what capabilities it can take control over from the firmware. This method is described in chapter 6.2.9 of the ACPI spec v3.0. The method takes 4 inputs (UUID, Rev ID, Input Count, and Capabilities Buffer) and returns a Capabilites Buffer the same size as the input Buffer. This Buffer is generally 3 Dwords long consisting of an Errors Dword, a Supported Capabilities Dword, and a Control Dword. The OS will request control of certain capabilities and the firmware must grant or deny control of those features. We do not want to have control over anything so let the OS control as much as it can. The _OSC method is required for PCIe devices and dmesg checks for its existence and issues an error if it is not found. This is the same change made to Persimmon with Change-ID I149428: http://review.coreboot.org/#/c/2684/ Change-Id: Iaf7b8153cec4d730efbceae3e6957d2904b8fae4 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2740 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17lynxpoint: Add support for disabling ULT devicesDuncan Laurie
These enables are hidden behind IOBP for some reason. Boot to linux with SDIO disabled and see that the SDIO driver does not load and crash the system. Change-Id: Icfbfa117e9e57a51d32db7f6366a9d0d790adcf0 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2695 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-16stddef.h: Add standard defines for KiB, MiB, GiB, and TiBRonald G. Minnich
Paul points out that some people like 1024*1024, others like 1048576, but in any case these are all open to typos. Define KiB, MiB, GiB, and TiB as in the standard so people can use them. Change-Id: Ic1b57e70d3e9b9e1c0242299741f71db91e7cd3f Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2769 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-16haswell: don't add a 0-sized memory range resourceAaron Durbin
It's possible that TOUUD can be 4GiB in a small physical memory configuration. Therefore, don't add a 0-size memory range resouce in that case. Change-Id: I016616a9d9d615417038e9c847c354db7d872819 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2691 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-16google/snow: rename a file so that it is clear what board it is forRonald G. Minnich
One might wonder what a board named 'build' does. Rename the file to build-snow. The fact that it is in a directory with google in the name should be enough to identify the vendor. Change-Id: I0b473cdce67d56fc6b92032b55180523eb337d66 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2766 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-15Google Link: Add remaining code to support native graphicsRonald G. Minnich
The Link native graphics commit 49428d84 [1] Add support for Google's Chromebook Pixel was missing some of the higher level bits, and hence could not be used. This is not new code -- it has been working since last August -- so the effort now is to get it into the tree and structure it in a way compatible with upstream coreboot. 1. Add options to src/device/Kconfig to enable native graphics. 2. Export the MTRR function for setting variable MTRRs. 3. Clean up some of the comments and white space. While I realize that the product name is Pixel, the mainboard in the coreboot tree is called Link, and that name is what we will use in our commits. [1] http://review.coreboot.org/2482 Change-Id: Ie4db21f245cf5062fe3a8ee913d05dd79030e3e8 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2531 Tested-by: build bot (Jenkins)
2013-03-15AMD Fam14 DSDT: Add secondary bus range to PCI0Mike Loptien
Adding the 'WordBusNumber' macro to the PCI0 CRES ResourceTemplate in the Persimmon DSDT. This sets up the bus number for the PCI0 device and the secondary bus number in the CRS method. This change came in response to a 'dmesg' error which states: '[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS' By adding the 'WordBusNumber' macro, ACPI can set up a valid range for the PCIe downstream busses, thereby relieving the Linux kernel from "guessing" the valid range based off _BBN or assuming [0-0xFF]. The Linux kernel code that checks this bus range is in `drivers/acpi/pci_root.c`. PCI busses can have up to 256 secondary busses connected to them via a PCI-PCI bridge. However, these busses do not have to be sequentially numbered, so leaving out a section of the range (eg. allowing [0-0x7F]) will unnecessarily restrict the downstream busses. This is the same change as made to Persimmon with change-id I44f22: http://review.coreboot.org/#/c/2592/ Change-Id: I9017a7619b3b17e0e95ad0fe46d0652499289b00 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2735 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15Super I/O W83627DHG: Enable UART B by redirecting pinsWolfgang Kamp
Pins 78-85 are set to GPIO after power on or reset. To enable UART B the pins must be redirected to it. Look at W83627DHG databook version 1.4 page 185 Chip (global) Control Register CR2C. Change-Id: I12b094a60d9c5cb2447a553be4679a4605e19845 Signed-off-by: Wolfgang Kamp <wmkamp@datakamp.de> Reviewed-on: http://review.coreboot.org/2626 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-15Persimmon DSDT: Remove INI method from AZHD deviceMike Loptien
I am removing the _INI method from the AZHD device because it does not seem to do anything and causes errors in the FWTS[1] (Firmware Test Suite) test 'method'. The INI method performs device specific initialization and is run when OSPM loads a description table. It must only access OperationRegions that have been indicated as available by the _REG (Region) method. We do not have a _REG method and during my testing, I added a REG method but it did not seem to make a difference in the PCI register space. The bit fields defined as NSDI (Disable No Snoop), NSDO (Disable No Snoop Override), and NSEN (Enable No Snoop Request) do not ever get written from their default values. And writing to these bit fields does not seem to be necessary because I did not notice any change in audio functionality. In an effort to clean up as many FWTS errors as possible, I propose removing this method altogether. I have seen no change in operation (audio works with and without this method) and there does not seem to be any change in lspci or dmesg. FWTS information can be found here: [1]: https://wiki.ubuntu.com/Kernel/Reference/fwts Change-Id: If8d86f959822d528c44ab011a851659d486289b5 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2726 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15Persimmon DSDT: Add OSC methodMike Loptien
The _OSC method is used to tell the OS what capabilities it can take control over from the firmware. This method is described in chapter 6.2.9 of the ACPI spec v3.0. The method takes 4 inputs (UUID, Rev ID, Input Count, and Capabilities Buffer) and returns a Capabilites Buffer the same size as the input Buffer. This Buffer is generally 3 Dwords long consisting of an Errors Dword, a Supported Capabilities Dword, and a Control Dword. The OS will request control of certain capabilities and the firmware must grant or deny control of those features. We do not want to have control over anything so let the OS control as much as it can. The _OSC method is required for PCIe devices and dmesg checks for its existence and issues an error if it is not found. Change-Id: I1494285def7440972f0549b7cb73eb94dafc72c2 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2684 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15Drop CHIP_NAME from intel/baskingridgeStefan Reinauer
It's no longer required. Change-Id: I621226a3bdfba9bc8edfd6e511a5337ae603ae19 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2723 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-15haswell: Fix BDSM and BGSM indicies in memory mapAaron Durbin
This wasn't previously spotted because the printk's were correct. However if one needed to get the value of the BDSM or BGSM register the value would reflect the other register's value. Change-Id: Ieec7360a74a65292773b61e14da39fc7d8bfad46 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2689 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-15haswell: reserve default SMRAM spaceAaron Durbin
Currently the OS is free to use the memory located at the default SMRAM space because it is not marked reserved in the e820. This can lead to memory corruption on S3 resume because SMM setup doesn't save this range before using it to relocate SMRAM. Resulting tables: coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000002ffff: RAM 2. 0000000000030000-000000000003ffff: RESERVED 3. 0000000000040000-000000000009ffff: RAM 4. 00000000000a0000-00000000000fffff: RESERVED 5. 0000000000100000-0000000000efffff: RAM 6. 0000000000f00000-0000000000ffffff: RESERVED 7. 0000000001000000-00000000acebffff: RAM 8. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 9. 00000000ad000000-00000000af9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000018f5fffff: RAM e820 map has 13 items: 0: 0000000000000000 - 0000000000030000 = 1 RAM 1: 0000000000030000 - 0000000000040000 = 2 RESERVED 2: 0000000000040000 - 000000000009f400 = 1 RAM 3: 000000000009f400 - 00000000000a0000 = 2 RESERVED 4: 00000000000f0000 - 0000000000100000 = 2 RESERVED 5: 0000000000100000 - 0000000000f00000 = 1 RAM 6: 0000000000f00000 - 0000000001000000 = 2 RESERVED 7: 0000000001000000 - 00000000acec0000 = 1 RAM 8: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 9: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 10: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 11: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 12: 0000000100000000 - 000000018f600000 = 1 RAM Booted and checked e820 as well as coreboot table information. Change-Id: Ie4985c748b591bf8c0d6a2b59549b698c9ad6cfe Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2688 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-15haswell: resource allocationAaron Durbin
The previous code w.r.t. resource allocation was getting lucky based on the way fixed mmio resources on the system were being chosen. Namely, PCIEXBAR was the lowest mmio space and the other fixed non-standar BARs were above it. The resource allocator would then start allocating standard BARs below that. On top of that other resources were being added when dev_ops->set_resources() was being called on the PCI domain. At that point the PCI range limit were already picked for where to start allocating from. To ensure we no longer get lucky during resource allocation add the fixed resources in the host bridge and add the memory controller cacheable memory areas. With those resources added the range limit for standard PCI BARs is chosen properly. Depending on haswell board configurations we may need to adjust and pass in the size of physical address space needed for PCI resources to the reference code. For the time being the CRBs appear to be OK. Lastly, remove the SNB workaround for reserving 2MiB at 1GiB and 512MiB. Output from 6GiB memory configuration: MC MAP: TOM: 0x140000000 MC MAP: TOUUD: 0x18f600000 MC MAP: MESEG_BASE: 0x13f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x13f000000 MC MAP: REMAP_LIMIT: 0x18f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BDSM: 0xada00000 MC MAP: BGSM: 0xad800000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000018f5fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 00000000acec0000 = 1 RAM 6: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 000000018f600000 = 1 RAM Output from 4GiB memory configuration: MC MAP: TOM: 0x100000000 MC MAP: TOUUD: 0x14f600000 MC MAP: MESEG_BASE: 0xff000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x100000000 MC MAP: REMAP_LIMIT: 0x14f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BDSM: 0xada00000 MC MAP: BGSM: 0xad800000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000014f5fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 00000000acec0000 = 1 RAM 6: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 000000014f600000 = 1 RAM Output from 2GiB memory configuration: MC MAP: TOM: 0x40000000 MC MAP: TOUUD: 0x100600000 MC MAP: MESEG_BASE: 0x3f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x100000000 MC MAP: REMAP_LIMIT: 0x1005fffff MC MAP: TOLUD: 0x3ea00000 MC MAP: BDSM: 0x3ca00000 MC MAP: BGSM: 0x3c800000 MC MAP: TESGMB: 0x3c000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-000000003bebffff: RAM 6. 000000003bec0000-000000003bffffff: CONFIGURATION TABLES 7. 000000003c000000-000000003e9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 000000003bec0000 = 1 RAM 6: 000000003bec0000 - 000000003ea00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 0000000100600000 = 1 RAM Verified through debug messages that range limits as well as resources were being properly honored. Change-Id: I2faa7d8a2a34a6a411a2885afb3b5c3fa1ad9c23 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2687 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-14lynxpoint: lpc resource reservationsAaron Durbin
This commit updates the Lynx Point resource reservations before the coreboot allocator assigns resources. There is no need to mark anything as subtractive decode because there are no devices/buses linked to the LPC device. The I/O range reservations consists of claiming the first 4KiB of I/O space. The PMBASE, GPIOBASE, and LPC generic I/O decode ranges are checked against the default claimed range. If those ranges overlap or fall outside of the default range then those resources are added. The MMIO range reservations consist of claiming everything from the I/O APIC to 4GiB. The RCBA and the LPC Generic Memory range register are then conditionally added if they fall outside of the default MMIO range. Change-Id: I0f560a03814a2b15961fdbe61e4164cd54cff7a5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2682 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: more ULT/LP support and minor tweaksDuncan Laurie
- Add ME device ID for Lynxpoint LP - Add GPU device IDs for ULT - SATA init tweaks from checking against DXE reference code - Remove the ICH7 from the SPI driver so it works on all lynxpoint without having to add more LPC device ID checks - Add function disable for audio dsp and xhci, remove PCI bridge - Add interrupt route registers for new devices (needs romstage setup) Change-Id: Idb48f50d0bacb6bf90531c3834542b9abb54fb8a Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2680 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14baskingridge: Report static temperature in _TMPDuncan Laurie
The current code is attempting to convert from an invalid starting temperature. Since we aren't sure where the temperature will come from yet just return a static value. This stops the kernel from going to S5 on boot because it thinks the temperature is too high. Change-Id: I433fa407e545458344af5842b353df5bc71bfdad Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2679 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: remove CONFIG_GFXUMAAaron Durbin
This option is not required for haswell. Enabling the option doesn't do anything aside from complicate mtrr calculation. Therefore, remove it. Change-Id: I897523ff7d3606eb89961674c2eb3d384e584857 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2678 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14x86: improve lb_cleanup_memory_rangesAaron Durbin
There are 2 issues in lb_cleanup_memory_ranges(). The first is that during sort there is a neighbor comparison that initially starts with the current entry. The second issue is that merging has an off by one comparison for adjacent entries. Before: coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000018f5fffff: RAM After: coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed19fff: RESERVED 10. 00000000fed84000-00000000fed84fff: RESERVED 11. 0000000100000000-000000018f5fffff: RAM Change-Id: I656aab61b0ed4711c9dceaedb81c290d040ffdec Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2671 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14baskingridge: dev, recovery, and WP switch supportAaron Durbin
This commit adds support for the deveveloper, recovery, and write protect querying. It just uses jumpers on the Basking Ridge board. Noted ability to togggle jumpers results in toggling the respective modes. Change-Id: Iac189a1fa0245654591e2e9075380db422a329a0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2676 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14baskingridge: update gpio map documentationAaron Durbin
While looking at the Basking Ridge schematic I noticed some changes and wanted to make sure they were reflected in the GPIO map. Change-Id: I686653c164314ae9f68c42331d2f950751411d4a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2675 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14haswell: Add VGA PCI ID mappingsAaron Durbin
Needed to map VGA OPROM IDs to actual device IDs Change-Id: I6743905c3db52519bf18f4bcc1a972aec43d3e9d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2674 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14baskingridge: zero out alt_gp_smi_en in devicetreeAaron Durbin
The baskingridge has a non-zero alt_gp_smi_en value in the devicetree.cb file. It has just to be determined which GPI pins should trigger an SMI on basking ridge. Without this change the board would hang during boot (presumably through a SMI flood). No more hangs once the value is zero. Change-Id: I9704071bb7966bd3d0bbbc4aafede3f42d829b17 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2673 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>