summaryrefslogtreecommitdiff
path: root/src/include
AgeCommit message (Collapse)Author
2013-05-25Intel GM45, 945, SNB: Move `multiply_to_tsc()` to `tsc.h`Ronald G. Minnich
multiply_to_tsc was being copied everywhere, which is bad practice. Put it in the tsc.h include file where it belongs. Delete the copies of it. Per secunet, no copyright notice is needed. This might be a good time to get a copyright notice into tsc.h anyway. Change-Id: Ied0013ad4b1a9e5e2b330614bb867fd806f9a407 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3242 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.huber@secunet.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-05-23include/timer.h: Fix typo in in*iti*alize in commentPaul Menzel
Correct a typo in a comment introduced in commit »coreboot: introduce monotonic timer API« (a421791d) [1]. [1] http://review.coreboot.org/3152 Change-Id: Ia0abc5304547d419478db1ae37b5525406fa19cc Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3261 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-16x86: add cache-as-ram migration optionAaron Durbin
There are some boards that do a significant amount of work after cache-as-ram is torn down but before ramstage is loaded. For example, using vboot to verify the ramstage is one such operation. However, there are pieces of code that are executed that reference global variables that are linked in the cache-as-ram region. If those variables are referenced after cache-as-ram is torn down then the values observed will most likely be incorrect. Therefore provide a Kconfig option to select cache-as-ram migration to memory using cbmem. This option is named CAR_MIGRATION. When enabled, the address of cache-as-ram variables may be obtained dynamically. Additionally, when cache-as-ram migration occurs the cache-as-ram data region for global variables is copied into cbmem. There are also automatic callbacks for other modules to perform their own migration, if necessary. Change-Id: I2e77219647c2bd2b1aa845b262be3b2543f1fcb7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3232 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-14coreboot: add thread cooperative multitaskingAaron Durbin
The cooperative multitasking support allows the boot state machine to be ran cooperatively with other threads of work. The main thread still continues to run the boot state machine (src/lib/hardwaremain.c). All callbacks from the state machine are still ran synchronously from within the main thread's context. Without any other code added the only change to the boot sequence when cooperative multitasking is enabled is the queueing of an idlle thread. The idle thread is responsible for ensuring progress is made by calling timer callbacks. The main thread can yield to any other threads in the system. That means that anyone that spins up a thread must ensure no shared resources are used from 2 or more execution contexts. The support is originally intentioned to allow for long work itesm with busy loops to occur in parallel during a boot. Note that the intention on when to yield a thread will be on calls to udelay(). Change-Id: Ia4d67a38665b12ce2643474843a93babd8a40c77 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3206 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-11Make early x86 POST codes written to IO port optionalMartin Roth
This continues the work done in patch 6b908d08ab http://review.coreboot.org/#/c/1685/ and makes the early x86 post codes follow the same options. Change-Id: Idf0c17b27b3516e79a9a53048bc203245f7c18ff Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3237 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-10Get rid of MAXIMUM_CONSOLE_LOGLEVEL; compile all messages into the coreboot ↵Ronald G. Minnich
binary This option has never had much if any use. It solved a problem over 10 years ago that resulted from an argument over the value or lack thereof of including all the debug strings in a coreboot image. The answer is in: it's a good idea to maintain the capability to print all messages, for many reasons. This option is also misleading people, as in a recent discussion, to believe that log messges are controlled at build time in a way they are not. For the record, from this day forward, we can print messages at all log levels and the default log level is set at boot time, as directed by DEFAULT_CONSOLE_LOGLEVEL. You can set the default to 0 at build time and if you are having trouble override it in CMOS and get more messages. Besides, a quick glance shows it's always set to max (9 in this case) in the very few cases (1) in which it is set. Change-Id: I60c4cdaf4dcd318b841a6d6c70546417c5626f21 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3188 Tested-by: build bot (Jenkins)
2013-05-10Get rid of a number of __GNUC__ checksStefan Reinauer
In the process of streamlining coreboot code and getting rid of unneeded ifdefs, drop a number of unneeded checks for the GNU C compiler. This also cleans up x86emu/types.h significantly by dropping all the duplicate types in there. Change-Id: I0bf289e149ed02e5170751c101adc335b849a410 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3226 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-05-10Drop prototype guarding for romccStefan Reinauer
Commit "romcc: Don't fail on function prototypes" (11a7db3b) [1] made romcc not choke on function prototypes anymore. This allows us to get rid of a lot of ifdefs guarding __ROMCC__ . [1] http://review.coreboot.org/2424 Change-Id: Ib1be3b294e5b49f5101f2e02ee1473809109c8ac Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3216 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-08hardwaremain: drop boot_complete parameterStefan Reinauer
it has been unused since 9 years or so, hence drop it. Change-Id: I0706feb7b3f2ada8ecb92176a94f6a8df53eaaa1 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3212 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-05-08x86: use asmlinkage macro for smm_handler_tAaron Durbin
The smm_handler_t type was added before the introduction of the asmlinkage macro. Now that asmlinkage is available use it. Change-Id: I85ec72cf958bf4b77513a85faf6d300c781af603 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3215 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-05-07boot state: add ability to block state transitionsAaron Durbin
In order to properly sequence the boot state machine it's important that outside code can block the transition from one state to the next. When timers are not involved there's no reason for any of the existing code to block a state transition. However, if there is a timer callback that needs to complete by a certain point in the boot sequence it is necessary to place a block for the given state. To that end, 4 new functions are added to provide the API for blocking a state. 1. boot_state_block(boot_state_t state, boot_state_sequence_t seq); 2. boot_state_unblock(boot_state_t state, boot_state_sequence_t seq); 3. boot_state_current_block(void); 4. boot_state_current_unblock(void); Change-Id: Ieb37050ff652fd85a6b1e0e2f81a1a2807bab8e0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3204 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-07x86: add TSC_CONSTANT_RATE optionAaron Durbin
Some boards use the local apic for udelay(), but they also provide their own implementation of udelay() for SMM. The reason for using the local apic for udelay() in ramstage is to not have to pay the penalty of calibrating the TSC frequency. Therefore provide a TSC_CONSTANT_RATE option to indicate that TSC calibration is not needed. Instead rely on the presence of a tsc_freq_mhz() function provided by the cpu/board. Additionally, assume that if TSC_CONSTANT_RATE is selected the udelay() function in SMM will be the tsc. Change-Id: I1629c2fbe3431772b4e80495160584fb6f599e9e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3168 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-06exynos5250/snow: deprecate time.hDavid Hendricks
This re-introduces 2fde966 (http://review.coreboot.org/#/c/3177/) which was reverted due to unsatisfied dependencies. time.h We Hardly Knew Ye. This deprecates time.h which is currently only used by Exynos5250 and Snow. The original idea was to try and unify some of the various timer interfaces and has been supplanted by the monotonic timer API. timer_us() is now obsolete. timer_start() is now mct_start() and is exposed in exynos5250/clk.h. Change-Id: I8e60105629d9da68ed622e89209b3ef6c8e2445b Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3201 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-05timer.h: add mono_time_diff_microseconds()David Hendricks
The current way to get a simple mono_time difference is: 1. Declare a rela_time struct 2. Assign it the value of mono_time_diff(t1, t2) 3. Get microseconds from it using rela_time_in_microseconds(). This patch adds a simpler method. Now one only needs to call mono_time_diff_microseconds(t1, t2) to obtain the same value which is produced from the above three steps. Change-Id: Ibfc9cd211e48e8e60a0a7703bff09cee3250e88b Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3190 Tested-by: build bot (Jenkins)
2013-05-04Revert "exynos5250/snow: deprecate time.h"David Hendricks
This reverts commit 2fde9668b47e74d1bfad2f1688a4481e6b966d04 Somehow this got merged before its dependencies. 3190 must be merged first, followed by 3176. However 3190 will fail while this patch is in. So the situation can't correct itself. Reverting this until the other two go in. Change-Id: I176f37c12711849c96f1889eacad38c00a8142c4 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3195 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-05-03exynos5250/snow: deprecate time.hDavid Hendricks
time.h We Hardly Knew Ye. This deprecates time.h which is currently only used by Exynos5250 and Snow. The original idea was to try and unify some of the various timer interfaces and has been supplanted by the monotonic timer API. timer_us() is now obsolete. timer_start() is now mct_start() and is exposed in exynos5250/clk.h. Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I14ebf75649d101491252c9aafea12f73ccf446b5 Reviewed-on: http://review.coreboot.org/3177 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01coreboot: add timer queue implementationAaron Durbin
A timer queue provides the mechanism for calling functions in the future by way of a callback. It utilizes the MONOTONIC_TIMER to track time through the boot. The implementation is a min-heap for keeping track of the next-to-expire callback. Change-Id: Ia56bab8444cd6177b051752342f53b53d5f6afc1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3158 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01coreboot: introduce monotonic timer APIAaron Durbin
The notion of a monotonic timer is introduced. Along with it are helper functions and other types for comparing times. This is just the framework where it is the responsibility of the chipset/board to provide the implementation of timer_monotonic_get(). The reason structs are used instead of native types is to allow for future changes to the data structure without chaning all the call sites. Change-Id: Ie56b9ab9dedb0da69dea86ef87ca744004eb1ae3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3152 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot state: rebalance payload load vs actual bootAaron Durbin
The notion of loading a payload in the current boot state machine isn't actually loading the payload. The reason is that cbfs is just walked to find the payload. The actual loading and booting were occuring in selfboot(). Change this balance so that loading occurs in one function and actual booting happens in another. This allows for ample opportunity to delay work until just before booting. Change-Id: Ic91ed6050fc5d8bb90c8c33a44eea3b1ec84e32d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3139 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01x86: use boot state callbacks to disable rom cacheAaron Durbin
On x86 systems there is a concept of cachings the ROM. However, the typical policy is that the boot cpu is the only one with it enabled. In order to ensure the MTRRs are the same across cores the rom cache needs to be disabled prior to OS resume or boot handoff. Therefore, utilize the boot state callbacks to schedule the disabling of the ROM cache at the ramstage exit points. Change-Id: I4da5886d9f1cf4c6af2f09bb909f0d0f0faa4e62 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3138 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot: remove cbmem_post_handling()Aaron Durbin
The cbmem_post_handling() function was implemented by 2 chipsets in order to save memory configuration in flash. Convert both of these chipsets to use the boot state machine callbacks to perform the saving of the memory configuration. Change-Id: I697e5c946281b85a71d8533437802d7913135af3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3137 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01cbmem: use boot state machineAaron Durbin
There were previously 2 functions, init_cbmem_pre_device() and init_cbmem_post_device(), where the 2 cbmem implementations implemented one or the other. These 2 functions are no longer needed to be called in the boot flow once the boot state callbacks are utilized. Change-Id: Ida71f1187bdcc640ae600705ddb3517e1410a80d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3136 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01coverage: use boot state callbacksAaron Durbin
Utilize the static boot state callback scheduling to initialize and tear down the coverage infrastructure at the appropriate points. The coverage initialization is performed at BS_PRE_DEVICE which is the earliest point a callback can be called. The tear down occurs at the 2 exit points of ramstage: OS resume and payload boot. Change-Id: Ie5ee51268e1f473f98fa517710a266e38dc01b6d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3135 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01acpi: split resume check and actual resume codeAaron Durbin
It's helpful to provide a distinct state that affirmatively describes that OS resume will occur. The previous code included the check and the actual resuming in one function. Because of this grouping one had to annotate the innards of the ACPI resume path to perform specific actions before OS resume. By providing a distinct state in the boot state machine the necessary actions can be scheduled accordingly without modifying the ACPI code. Change-Id: I8b00aacaf820cbfbb21cb851c422a143371878bd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3134 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot state: schedule static callbacksAaron Durbin
Many of the boot state callbacks can be scheduled at compile time. Therefore, provide a way for a compilation unit to inform the boot state machine when its callbacks should be called. Each C module can export the callbacks and their scheduling requirements without changing the shared boot flow code. Change-Id: Ibc4cea4bd5ad45b2149c2d4aa91cbea652ed93ed Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3133 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01ramstage: introduce boot state machineAaron Durbin
The boot flow currently has a fixed ordering. The ordering is dictated by the device tree and on x86 the PCI device ordering for when actions are performed. Many of the new machines and configurations have dependencies that do not follow the device ordering. In order to be more flexible the concept of a boot state machine is introduced. At the boundaries (entry and exit) of each state there is opportunity to run callbacks. This ability allows one to schedule actions to be performed without adding board-specific code to the shared boot flow. Change-Id: I757f406c97445f6d9b69c003bb9610b16b132aa6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3132 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01string: Add STRINGIFY macroAaron Durbin
STRINGIFY makes a string from a token. It is generally useful. Even though STRINGIFY is not defined to be in the C library it's placed in string.h because it does make a string. Change-Id: I368e14792a90d1fdce2a3d4d7a48b5d400623160 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3144 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-20Eliminate use of pointers in coreboot tableStefan Reinauer
Because pointers can be 32bit or 64bit big, using them in the coreboot table requires the OS and the firmware to operate in the same mode which is not always the case. Hence, use 64bit for all pointers stored in the coreboot table. Guess we'll have to fix this up once we port to the first 128bit machines. Change-Id: I46fc1dad530e5230986f7aa5740595428ede4f93 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3115 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-04-18spkmodem consoleVladimir Serbinenko
Change-Id: Ie497e4c8da05001ffe67c4a541bd24aa859ac0e2 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/2987 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-13Exynos5250: add a microsecond timerRonald G. Minnich
Add a microsecond timer, its declaration, the function to start it, and its usage. To start it, one calls timer_start(). From that point on, one can call timer_us() to find microseconds since the timer was started. We show its use in the bootblock. You want it started very early. Finally, the delay.h change having been (ironically) delayed, we create time.h and have it hold one declaration, for the timer_us() and timer_start() prototype. We feel that these two functions should become the hardware specific functions, allowing us to finally move udelay() into src/lib where it belongs. Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3073 Tested-by: build bot (Jenkins)
2013-04-12Revert "siemens/sitemp_g1p1: Make ACPI report the right mmconf region"Nico Huber
This reverts commit 1fde22c54cacb15493bbde8835ec9e20f1d39bf5: commit 1fde22c54cacb15493bbde8835ec9e20f1d39bf5 Author: Patrick Georgi <patrick.georgi@secunet.com> Date: Tue Apr 9 15:41:23 2013 +0200 siemens/sitemp_g1p1: Make ACPI report the right mmconf region ACPI reported the entire space between top-of-memory and some (relatively) arbitrary limit as useful for MMIO. Unfortunately the HyperTransport configuration disagreed. Make them match up. Other boards are not affected since they don't report any region for that purpose at all (it seems). Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3047 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> It sneaked in without it's dependencies and, therefore, broke the build for all amdk8 targets. Paul Menzel already commented on the issue in [1]. It also doesn't look like the dependencies would be pulled soon [2]. [1] http://review.coreboot.org/#/c/3047/ [2] http://review.coreboot.org/#/c/2662/ Change-Id: Ica89563aae4af3f0f35cacfe37fb608782329523 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: http://review.coreboot.org/3063 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-04-10siemens/sitemp_g1p1: Make ACPI report the right mmconf regionPatrick Georgi
ACPI reported the entire space between top-of-memory and some (relatively) arbitrary limit as useful for MMIO. Unfortunately the HyperTransport configuration disagreed. Make them match up. Other boards are not affected since they don't report any region for that purpose at all (it seems). Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3047 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-10exynos5: Re-factor I2C codeDavid Hendricks
This re-factors the Exynos5 I2C code to be simpler and use the new API, and updates users accordingly. - i2c_read() and i2c_write() functions updated to take bus number as an argument. - Get rid of the EEPROM_ADDR_OVERFLOW stuff in i2c_read() and i2c_write(). If a chip needs special handling we should take care of it elsewhere, not in every low-level i2c driver. - All the confusing bus config functions eliminated. No more i2c_set_early_config() or i2c_set_bus() or i2c_get_bus(). All this is handled automatically when the caller does a transaction and specifies the desired bus number. - i2c_probe() eliminated. We're not a command-line utility. - Let the compiler place static variables automatically. We don't need any of this fancy manual data placement. - Remove dead code while we're at it. This stuff was ported early on and much of it was left commented out in case we needed it. Some also includes nested macros which caused gcc to complain. - Clean up #includes (no more common.h, woohoo!), replace debug() with printk(). Change-Id: I8e1f974ea4c6c7db9f33b77bbc4fb16008ed0d2a Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3044 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-09replace device/i2c.h with simpler versionDavid Hendricks
The existing header was imported along with the Exynos code and left mostly unchanged. This is the first patch in a series intended to replace the imported u-boot I2C API with a much simpler and cleaner interface: - We only need to expose i2c_read() and i2c_write() in our public API. Everything else is board/chip-dependent and should remain hidden away. - i2c_read and i2c_write functions will take bus number as an arg and we'll eliminate i2c_get_bus and i2c_set_bus. Those are prone to error and end up cluttering the code since the user needs to save the old bus number, set the new one, do the read/write, and restore the old value (3 added steps to do a simple transaction). - Stop setting default values for board-specific things like SPD and RTC bus numbers (as if we always have an SPD or RTC on I2C). - Death to all the trivial inline wrappers. And in case there was any doubt, we really don't care about the MPC8xx. Though if we did then we would not pollute the public API with its idiosyncrasies. Change-Id: I4410a3c82ed5a6b2e80e3d8c0163464a9ca7c3b0 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3043 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-05mtrr: add rom caching comment about hyperthreadsAaron Durbin
Explicitly call out the effects of hyperthreads running the MTRR code and its impact on the enablement of ROM caching. Change-Id: I14b8f3fdc112340b8f483f2e554c5680576a8a7c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3018 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-04-04AMD: Drop six copies of wrmsr_amd and rdmsr_amdKyösti Mälkki
Based on comments in cpu/x86/msr.h for wrmsr/rdmsr, and for symmetry, I have added __attribute__((always_inline)) for these. Change-Id: Ia0a34c15241f9fbc8c78763386028ddcbe6690b1 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/2898 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-04-03intel/microcode.h: Fix typo in comment: micr*o*codePaul Menzel
Introduced in commit »intel microcode: split up microcode loading stages« (98ffb426) [1]. [1] http://review.coreboot.org/2778 Change-Id: I626508b10f3998b43aaabd49853090b36f5d3eb0 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2992 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-04-01lynxpoint: Move ACPI NVS into separate CBMEM tableDuncan Laurie
The ACPI NVS region was setup in place and there was a CBMEM table that pointed to it. In order to be able to use NVS earlier the CBMEM region is allocated for NVS itself during the LPC device init and the ACPI tables point to it in CBMEM. The current cbmem region is renamed to ACPI_GNVS_PTR to indicate that it is really a pointer to the GNVS and does not actually contain the GNVS. Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2970 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-01boot: add disable_cache_rom() functionAaron Durbin
On certain architectures such as x86 the bootstrap processor does most of the work. When CACHE_ROM is employed it's appropriate to ensure that the caching enablement of the ROM is disabled so that the caching settings are symmetric before booting the payload or OS. Tested this on an x86 machine that turned on ROM caching. Linux did not complain about asymmetric MTRR settings nor did the ROM show up as cached in the MTRR settings. Change-Id: Ia32ff9fdb1608667a0e9a5f23b9c8af27d589047 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2980 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29memrange: add 2 new range_entry routinesAaron Durbin
Two convenience functions are added to operate on a range_entry: - range_entry_update_tag() - update the entry's tag - memranges_next_entry() - get the next entry after the one provide These functions will be used by a follow on patch to the MTRR code to allow hole punching in WB region when the default MTRR type is UC. Change-Id: I3c2be19c8ea1bbbdf7736c867e4a2aa82df2d611 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2924 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29x86: add rom cache variable MTRR index to tablesAaron Durbin
Downstream payloads may need to take advantage of caching the ROM for performance reasons. Add the ability to communicate the variable range MTRR index to use to perform the caching enablement. An example usage implementation would be to obtain the variable MTRR index that covers the ROM from the coreboot tables. Then one would disable caching and change the MTRR type from uncacheable to write-protect and enable caching. The opposite sequence is required to tearn down the caching. Change-Id: I4d486cfb986629247ab2da7818486973c6720ef5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2919 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29x86: mtrr: add CONFIG_CACHE_ROM supportAaron Durbin
The CONFIG_CACHE_ROM support in the MTRR code allocates an MTRR specifically for setting up write-protect cachine of the ROM. It is assumed that CONFIG_ROM_SIZE is the size of the ROM and the whole area should be cached just under 4GiB. If enabled, the MTRR code will allocate but not enable rom caching. It is up to the callers of the MTRR code to explicitly enable (and disable afterwards) through the use of 2 new functions: - x86_mtrr_enable_rom_caching() - x86_mtrr_disable_rom_caching() Additionally, the CACHE_ROM option is exposed to the config menu so that it is not just selected by the chipset or board. The reasoning is that through a multitude of options CACHE_ROM may not be appropriate for enabling. Change-Id: I4483df850f442bdcef969ffeaf7608ed70b88085 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2918 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29lib: add memrange infrastructureAaron Durbin
The memrange infrastructure allows for keeping track of the machine's physical address space. Each memory_range entry in a memory_ranges structure can be tagged with an arbitrary value. It supports merging and deleting ranges as well as filling in holes in the address space with a particular tag. The memrange infrastructure will serve as a shared implementation for address tracking by the MTRR and coreboot mem table code. Change-Id: Id5bea9d2a419114fca55c59af0fdca063551110e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2888 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29stdlib: add ALIGN_UP and ALIGN_DOWN macrosAaron Durbin
There wasn't an equivalent to align down so add ALIGN_DOWN. For symmetry provide an ALIGN_UP macro as well. Change-Id: I7033109311eeb15c8c69c649878785378790feb9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2951 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29resources: introduce IORESOURCE_WRCOMBAaron Durbin
Certain MMIO resources can be set to a write-combining cacheable mode to increase performance. Typical resources that use this would be graphics memory. Change-Id: Icd96c720f86f7e2f19a6461bb23cb323124eb68e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2891 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-29resources: remove IORESOURCE_[UMA_FB|IGNORE_MTRR]Aaron Durbin
The IORESOURCE_UMA_FB and IORESOURCE_IGNORE_MTRR attributes on a resource provided hints to the MTRR algorithm. The IORESOURCE_UMA_FB directed the MTRR algorithm to setup a uncacheable space for the resource. The IORESOURCE_IGNORE_MTRR directed the MTRR algorithm to ignore this resource as it was used reserving RAM space. Now that the optimizing MTRR algorithm is in place there isn't a need for these flags. All IORESOURCE_IGNORE_MTRR users are handled by the MTRR code merging resources of the same cacheable type. The users of the IORESOURCE_UMA_FB will find that the default MTRR type calculation means there isn't a need for this flag any more. Change-Id: I4f62192edd9a700cb80fa7569caf49538f9b83b7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2890 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29x86: add new mtrr implementationAaron Durbin
The old MTRR code had issues using too many variable MTRRs depending on the physical address space layout dictated by the device resources. This new implementation calculates the default MTRR type by comparing the number of variable MTRRs used for each type. This avoids the need for IORESOURE_UMA_FB because in many of those situations setting the default type to WB frees up the variable MTTRs to set that space to UC. Additionally, it removes the need for IORESOURCE_IGNORE_MTRR becuase the new mtrr uses the memrange library which does merging of resources. Lastly, the sandybridge gma has its speedup optimization removed for the graphics memory by writing a pre-determined MTRR index. That will be fixed in an upcoming patch once write-combining support is added to the resources. Slight differences from previous MTRR code: - The number of reserved OS MTRRs is not a hard limit. It's now advisory as PAT can be used by the OS to setup the regions to the caching policy desired. - The memory types are calculated once by the first CPU to run the code. After that all other CPUs use that value. - CONFIG_CACHE_ROM support was dropped. It will be added back in its own change. A pathological case that was previously fixed by changing vendor code to adjust the IO hole location looked like the following: MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6 0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0 0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1 0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0 0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6 As noted by the output below it's impossible to accomodate those ranges even with 10 variable MTRRS. However, because the code can select WB as the default MTRR type it can be done in 6 MTRRs: MTRR: default type WB/UC MTRR counts: 6/14. MTRR: WB selected as default type. MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0 MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0 MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0 MTRR: 3 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0 MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1 MTRR: 5 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0 Change-Id: Idfcc78d9afef9d44c769a676716aae3ff2bd79de Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2889 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23resources: introduce reserved_ram_resource()Aaron Durbin
mmio_resource() was previously being used for reserving RAM from the OS by using IORESOURCE_IGNORE_MTRR atrribute. Instead, be more explicit for those uses with reserved_ram_resource(). bad_ram_resource() now calls reserved_ram_resource(). Those resources are marked as cacheable but reserved. The sandybridge and haswell code were relying on the implementation fo the MTRR algorithm's interaction for reserved regions. Instead be explicit about what ranges are MMIO reserved and what are RAM reserved. Change-Id: I1e47026970fb37c0305e4d49a12c98b0cdd1abe5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2886 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23x86: expose console_tx_flush in romstageAaron Durbin
The vboot module relied on being able to flush the console after it called vtxprintf() from its log wrapper function. Expose the console_tx_flush() function in romstage so the vboot module can ensure messages are flushed. Change-Id: I578053df4b88c2068bd9cc90eea5573069a0a4e8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2882 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22x86: unify amd and non-amd MTRR routinesAaron Durbin
The amd_mtrr.c file contains a copy of the fixed MTRR algorithm. However, the AMD code needs to handle the RdMem and WrMem attribute bits in the fixed MTRR MSRs. Instead of duplicating the code with the one slight change introduce a Kconfig option, X86_AMD_FIXED_MTRRS, which indicates that the RdMem and WrMem fields need to be handled for writeback fixed MTRR ranges. The order of how the AMD MTRR setup routine is maintained by providing a x86_setup_fixed_mtrrs_no_enable() function which does not enable the fixed MTRRs after setting them up. All Kconfig files which had a Makefile that included amd/mtrr in the subdirs-y now have a default X86_AMD_FIXED_MTRRS selection. There may be some overlap with the agesa and socket code, but I didn't know the best way to tease out the interdependency. Change-Id: I256d0210d1eb3004e2043b46374dcc0337432767 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2866 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-22Unify coreboot table generationStefan Reinauer
coreboot tables are, unlike general system tables, a platform independent concept. Hence, use the same code for coreboot table generation on all platforms. lib/coreboot_tables.c is based on the x86 version of the file, because some important fixes were missed on the ARMv7 version lately. Change-Id: Icc38baf609f10536a320d21ac64408bef44bb77d Signed-off-by: Stefan Reinauer <reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/2863 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-22coreboot: add vboot_handoff to coreboot tablesAaron Durbin
The vboot_handoff structure contians the VbInitParams as well as the shared vboot data. In order for the boot loader to find it, the structure address and size needs to be obtained from the coreboot tables. Change-Id: I6573d479009ccbf373a7325f861bebe8dc9f5cf8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2857 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22rmodule: add vboot rmodule typeAaron Durbin
For completeness add a vboot rmodule type since vboot will be built as an rmodule. Change-Id: I4b9b1e6f6077f811cafbb81effd4d082c91d4300 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2853 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22timestamp: add vboot check pointsAaron Durbin
It's desirable to measure the vboot firmware selection time. Therefore add vboot check points to the timestamp ids. Change-Id: Ib103a9e91652cf96abcacebf0f211300e03f71fd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2852 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-22cbmem: add vboot cmbem idAaron Durbin
The vboot firmware selection from romstage will need to pass the resulting vboot data to other consumers. This will be done using a cbmem entry. Change-Id: I497caba53f9f3944513382f3929d21b04bf3ba9e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2851 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22coreboot: dynamic cbmem requirementAaron Durbin
Dynamic cbmem is now a requirement for relocatable ramstage. This patch replaces the reserve_* fields in the romstage_handoff structure by using the dynamic cbmem library. The haswell code is not moved over in this commit, but it should be safe because there is a hard requirement for DYNAMIC_CBMEM when using a reloctable ramstage. Change-Id: I59ab4552c3ae8c2c3982df458cd81a4a9b712cc2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2849 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22x86: Unify arch/io.h and arch/romcc_io.hStefan Reinauer
Here's the great news: From now on you don't have to worry about hitting the right io.h include anymore. Just forget about romcc_io.h and use io.h instead. This cleanup has a number of advantages, like you don't have to guard device/ includes for SMM and pre RAM anymore. This allows to get rid of a number of ifdefs and will generally make the code more readable and understandable. Potentially in the future some of the code in the io.h __PRE_RAM__ path should move to device.h or other device/ includes instead, but that's another incremental change. Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2872 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21cbmem: dynamic cbmem supportAaron Durbin
This patch adds a parallel implementation of cbmem that supports dynamic sizing. The original implementation relied on reserving a fixed-size block of memory for adding cbmem entries. In order to allow for more flexibility for adding cbmem allocations the dynamic cbmem infrastructure was developed as an alternative to the fixed block approach. Also, the amount of memory to reserve for cbmem allocations does not need to be known prior to the first allocation. The dynamic cbmem code implements the same API as the existing cbmem code except for cbmem_init() and cbmem_reinit(). The add and find routines behave the same way. The dynamic cbmem infrastructure uses a top down allocator that starts allocating from a board/chipset defined function cbmem_top(). A root pointer lives just below cbmem_top(). In turn that pointer points to the root block which contains the entries for all the large alloctations. The corresponding block for each large allocation falls just below the previous entry. It should be noted that this implementation rounds all allocations up to a 4096 byte granularity. Though a packing allocator could be written for small allocations it was deemed OK to just fragment the memory as there shouldn't be that many small allocations. The result is less code with a tradeoff of some wasted memory. +----------------------+ <- cbmem_top() | +----| root pointer | | | +----------------------+ | | | |--------+ | +--->| root block |-----+ | | +----------------------+ | | | | | | | | | | | | | | alloc N |<----+ | | +----------------------+ | | | | | | | | | \|/ | alloc N + 1 |<-------+ v +----------------------+ In addition to preserving the previous cbmem API, the dynamic cbmem API allows for removing blocks from cbmem. This allows for the boot process to allocate memory that can be discarded after it's been used for performing more complex boot tasks in romstage. In order to plumb this support in there were some issues to work around regarding writing of coreboot tables. There were a few assumptions to how cbmem was layed out which dictated some ifdef guarding and other runtime checks so as not to incorrectly tag the e820 and coreboot memory tables. The example shown below is using dynamic cbmem infrastructure. The reserved memory for cbmem is less than 512KiB. 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-000000007bf80fff: RAM 8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES 9. 000000007c000000-000000007e9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf coreboot table: 948 bytes. CBMEM ROOT 0. 7bfff000 00001000 MRC DATA 1. 7bffe000 00001000 ROMSTAGE 2. 7bffd000 00001000 TIME STAMP 3. 7bffc000 00001000 ROMSTG STCK 4. 7bff7000 00005000 CONSOLE 5. 7bfe7000 00010000 VBOOT 6. 7bfe6000 00001000 RAMSTAGE 7. 7bf98000 0004e000 GDT 8. 7bf97000 00001000 ACPI 9. 7bf8b000 0000c000 ACPI GNVS 10. 7bf8a000 00001000 SMBIOS 11. 7bf89000 00001000 COREBOOT 12. 7bf81000 00008000 And the corresponding e820 entries: BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16 BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16 BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2848 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21lynxpoint: Fix ELOG logging of power management eventsDuncan Laurie
This is updated to handle LynxPoint-H and LynxPoint-LP and a new wake event is added for the power button. Boot, suspend/resume, reboot, etc on WTM2 and then check the event log to see if expected events have been added. Change-Id: I15cbc3901d81f4fd77cc04de37ff5fa048f9d3e8 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2817 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21coreboot: add caching loaded ramstage interfaceAaron Durbin
Instead of hard coding the policy for how a relocated ramstage image is saved add an interface. The interface consists of two functions. cache_loaded_ramstage() and load_cached_ramstage() are the functions to cache and load the relocated ramstage, respectively. There are default implementations which cache and load the relocated ramstage just below where the ramstage runs. Change-Id: I4346e873d8543e7eee4c1cd484847d846f297bb0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2805 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21ramstage: cache relocated ramstage in RAMAaron Durbin
Accessing the flash part where the ramstage resides can be slow when loading it. In order to save time in the S3 resume path a copy of the relocated ramstage is saved just below the location the ramstage was loaded. Then on S3 resume the cached version of the relocated ramstage is copied back to the loaded address. This is achieved by saving the ramstage entry point in the romstage_handoff structure as reserving double the amount of memory required for ramstage. This approach saves the engineering time to make the ramstage reentrant. The fast path in this change will only be taken when the chipset's romstage code properly initializes the s3_resume field in the romstage_handoff structure. If that is never set up properly then the fast path will never be taken. e820 entries from Linux: BIOS-e820: [mem 0x000000007bf21000-0x000000007bfbafff] reserved BIOS-e820: [mem 0x000000007bfbb000-0x000000007bffffff] type 16 The type 16 is the cbmem table and the reserved section contains the two copies of the ramstage; one has been executed already and one is the cached relocated program. With this change the S3 resume path on the basking ridge CRB shows to be ~200ms to hand off to the kernel: 13 entries total: 1:95,965 2:97,191 (1,225) 3:131,755 (34,564) 4:132,890 (1,135) 8:135,165 (2,274) 9:135,840 (675) 10:135,973 (132) 30:136,016 (43) 40:136,581 (564) 50:138,280 (1,699) 60:138,381 (100) 70:204,538 (66,157) 98:204,615 (77) Change-Id: I9c7a6d173afc758eef560e09d2aef5f90a25187a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2800 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21ramstage: Add cbmem_get_table_location()Aaron Durbin
When CONFIG_EARLY_CBMEM_INIT is selected romstage is supposed to have initialized cbmem. Therefore provide a weak function for the chipset to implement named cbmem_get_table_location(). When CONFIG_EARLY_CBMEM_INIT is selected cbmem_get_table_location() will be called to get the cbmem location and size. After that cbmem_initialize() is called. Change-Id: Idc45a95f9d4b1d83eb3c6d4977f7a8c80c1ffe76 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2797 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21romstage_handoff: add s3_resume fieldAaron Durbin
Provide a field in the romstage_handoff structure to indicate if the current boot is an ACPI S3 wake boot. There are currently quite a few non-standardized ways of passing this knowledge to ramstage from romstage. Many utilize stashing magic numbers in device-specific registers. The addition of this field adds a more formalized method passing along this information. However, it still requires the romstage chipset code to initialize this field. In short, this change does not make this a hard requirement for ramstage. Change-Id: Ia819c0ceed89ed427ef576a036fa870eb7cf57bc Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2796 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21romstage_handoff: provide common logic for setupAaron Durbin
The romstage_handoff structure can be utilized from different components of the romstage -- some in the chipset code, some in coreboot's core libarary. To ensure that all users handle initialization of a newly added romstage_handoff structure properly, provide a common function to handle structure initialization. Change-Id: I3998c6bb228255f4fd93d27812cf749560b06e61 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2795 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21x86: protect against abi assumptions from compilerAaron Durbin
Some of the functions called from assembly assume the standard x86 32-bit ABI of passing all arguments on the stack. However, that calling ABI can be changed by compiler flags. In order to protect against the current implicit calling convention annotate the functions called from assembly with the cdecl function attribute. That tells the compiler to use the stack based parameter calling convention. Change-Id: I83625e1f92c6821a664b191b6ce1250977cf037a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2794 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21coreboot: introduce CONFIG_RELOCATABLE_RAMSTAGEAaron Durbin
This patch adds an option to build the ramstage as a reloctable binary. It uses the rmodule library for the relocation. The main changes consist of the following: 1. The ramstage is loaded just under the cmbem space. 2. Payloads cannot be loaded over where ramstage is loaded. If a payload is attempted to load where the relocatable ramstage resides the load is aborted. 3. The memory occupied by the ramstage is reserved from the OS's usage using the romstage_handoff structure stored in cbmem. This region is communicated to ramstage by an CBMEM_ID_ROMSTAGE_INFO entry in cbmem. 4. There is no need to reserve cbmem space for the OS controlled memory for the resume path because the ramsage region has been reserved in #3. 5. Since no memory needs to be preserved in the wake path, the loading and begin of execution of a elf payload is straight forward. Change-Id: Ia66cf1be65c29fa25ca7bd9ea6c8f11d7eee05f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2792 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-03-21coreboot: introduce romstage_handoff structureAaron Durbin
The romstage_handoff structure is intended to be a way for romstage and ramstage to communicate with one another instead of using sideband signals such as stuffing magic values in pci config or memory scratch space. Initially this structure just contains a single region that indicates to ramstage that it should reserve a memory region used by the romstage. Ramstage looks for a romstage_handoff structure in cbmem with an id of CBMEM_ID_ROMSTAGE_INFO. If found, it will honor reserving the region defined in the romstage_handoff structure. Change-Id: I9274ea5124e9bd6584f6977d8280b7e9292251f0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2791 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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-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-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-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-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-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-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-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-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-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-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-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-14haswell: add PCI id supportAaron Durbin
In order for coreboot to assign resources properly the pci drivers need to have th proper device ids. Add the host controller and the LPC device ids for Lynx Point. Resource assignment works correctly now w/o odd behavior because of conflicts. Change-Id: Id33b3676616fb0c428d84e5fe5c6b8a7cc5fbb62 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2638 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-14x86: SMM Module SupportAaron Durbin
Add support for SMM modules by leveraging the RMODULE lib. This allows for easier dynamic SMM handler placement. The SMM module support consists of a common stub which puts the executing CPU into protected mode and calls into a pre-defined handler. This stub can then be used for SMM relocation as well as the real SMM handler. For the relocation one can call back into coreboot ramstage code to perform relocation in C code. The handler is essentially a copy of smihandler.c, but it drops the TSEG differences. It also doesn't rely on the SMM revision as the cpu code should know what processor it is supported. Ideally the CONFIG_SMM_TSEG option could be removed once the existing users of that option transitioned away from tseg_relocate() and smi_get_tseg_base(). The generic SMI callbacks are now not marked as weak in the declaration so that there aren't unlinked references. The handler has default implementations of the generic SMI callbacks which are marked as weak. If an external compilation module has a strong symbol the linker will use that instead of the link one. Additionally, the parameters to the generic callbacks are dropped as they don't seem to be used directly. The SMM runtime can provide the necessary support if needed. Change-Id: I1e2fed71a40b2eb03197697d29e9c4b246e3b25e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2693 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-12watchdog.h: Fix compile time error on disabling watchdog handlingPatrick Georgi
There's a compile time error that we didn't catch since the board defaults as used by the build bot won't expose it. Just make watchdog_off() a no-op statement so there aren't any stray semicolons in the preprocessor output. Change-Id: Ib5595e7e8aa91ca54bc8ca30a39b72875c961464 Reported-by: 'lautriv' on irc.freenode.net/#coreboot Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/2627 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-11pci.h: Drop unused `mainboard_pci_subsystem*` prototypesPatrick Georgi
We used to allow mainboards to override subsystems using mainboard_pci_subsystem_vendor_id and mainboard_pci_subsystem_device_id. Mechanisms have changed and the only occurrence of these names is in the header. Change-Id: Ic2ab13201a2740c98868fdf580140b7758b62263 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/2625 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-01GPLv2 notice: Unify all files to just use one space in »MA 02110-1301«Paul Menzel
In the file `COPYING` in the coreboot repository and upstream [1] just one space is used. The following command was used to convert all files. $ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/' [1] http://www.gnu.org/licenses/gpl-2.0.txt Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2490 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-02-27smm: Update rev 0x30101 SMM revision save stateAaron Durbin
According to both Haswell and the SandyBridge/Ivybridge BWGs the save state area actually starts at 0x7c00 offset from 0x8000. Update the em64t101_smm_state_save_area_t structure and introduce a define for the offset. Note: I have no idea what eptp is. It's just listed in the haswell BWG. The offsets should not be changed. Change-Id: I38d1d1469e30628a83f10b188ab2fe53d5a50e5a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2515 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-20Whitespace: Replace tab character in license text with two spacesPaul Menzel
For whatever reason tabs got inserted in the license header text. Remove one occurrence of that with the following command [1]. $ git grep -l 'MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.'$'\t' | xargs sed -i 's,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.[ ]*,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\ \ ,' [1] http://sed.sourceforge.net/grabbag/tutorials/sedfaq.txt Change-Id: Iaf4ed32c32600c3b23c08f8754815b959b304882 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2460 Tested-by: build bot (Jenkins) Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-by: Cristian Măgherușan-Stanciu <cristi.magherusan@gmail.com>
2013-02-19move uartmem_getbaseaddr() to generic uart headerDavid Hendricks
This moves uartmem_getbaseaddr() from an 8250-specific header to the generic uart header. This is to accomodate non-8250 memory-mapped UARTs. Change-Id: Id25e7dab12b33bdd928f2aa4611d720aa79f3dee Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2422 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-18AMD Family12h: Fix warningsMartin Roth
Add needed prototypes to .h files. Remove unused variables and fix types in printk statements. Add #IFNDEFs around #DEFINEs to keep them from being defined twice. Fix a whole bunch of casts. Fix undefined pre-increment behaviour in a couple of macros. These now match the macros in the F14 tree. Change a value of 0xFF that was getting truncated when being assigned to a 4-bit bitfield to a value of 0x0f. This was tested with the torpedo build. This fixes roughly 132 of the 561 warnings in the coreboot build so I'm not going to list them all. Here is a sample of the warnings fixed: In file included from src/cpu/amd/agesa/family12/model_12_init.c:35:0: src/include/cpu/amd/amdfam12.h:52:5: warning: redundant redeclaration of 'get_initial_apicid' [-Wredundant-decls] In file included from src/cpu/amd/agesa/family12/model_12_init.c:34:0: src/include/cpu/amd/multicore.h:48:5: note: previous declaration of 'get_initial_apicid' was here src/northbridge/amd/agesa/family12/northbridge.c:50:10: warning: no previous prototype for 'get_node_pci' [-Wmissing-prototypes] src/northbridge/amd/agesa/family12/northbridge.c: In function 'get_hw_mem_hole_info': src/northbridge/amd/agesa/family12/northbridge.c:302:13: warning: unused variable 'i' [-Wunused-variable] src/northbridge/amd/agesa/family12/northbridge.c: In function 'domain_set_resources': src/northbridge/amd/agesa/family12/northbridge.c:587:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'device_t' [-Wformat] src/northbridge/amd/agesa/family12/northbridge.c:587:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'device_t' [-Wformat] src/northbridge/amd/agesa/family12/northbridge.c:716:1: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat] In file included from src/mainboard/amd/torpedo/agesawrapper.h:31:0, from src/northbridge/amd/agesa/family12/northbridge.c:38: src/vendorcode/amd/agesa/f12/AGESA.h:1282:0: warning: "TOP_MEM" redefined [enabled by default] In file included from src/northbridge/amd/agesa/family12/northbridge.c:34:0: src/include/cpu/amd/mtrr.h:31:0: note: this is the location of the previous definition In file included from src/mainboard/amd/torpedo/agesawrapper.h:31:0, from src/northbridge/amd/agesa/family12/northbridge.c:38: src/vendorcode/amd/agesa/f12/AGESA.h:1283:0: warning: "TOP_MEM2" redefined [enabled by default] src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetNumberOfComplexes': src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:99:19: warning: operation on 'ComplexList' may be undefined [-Wsequence-point] src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetLengthOfPcieEnginesList': src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:126:20: warning: operation on 'PciePortList' may be undefined [-Wsequence-point] src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetLengthOfDdiEnginesList': src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:153:19: warning: operation on 'DdiLinkList' may be undefined [-Wsequence-point] src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetComplexDescriptorOfSocket': src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:225:17: warning: operation on 'ComplexList' may be undefined [-Wsequence-point] src/vendorcode/amd/agesa/f12/Proc/GNB/PCIe/Family/LN/F12PciePhyServices.c:246:1: warning: no previous prototype for 'PcieFmForceDccRecalibrationCallback' [-Wmissing-prototypes] In file included from src/vendorcode/amd/agesa/f12/Proc/GNB/PCIe/Family/LN/F12PcieComplexConfig.c:58:0: src/vendorcode/amd/agesa/f12/Proc/GNB/PCIe/Family/LN/LlanoComplexData.h:120:5: warning: large integer implicitly truncated to unsigned type [-Woverflow] And fixed a boatload of these types of warning: src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c: In function 'HeapGetBaseAddress': src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:687:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:694:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:701:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:702:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:705:23: warning: assignment makes integer from pointer without a cast [enabled by default] src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:709:21: warning: assignment makes integer from pointer without a cast [enabled by default] Change-Id: I97fa0b8edb453eb582e4402c66482ae9f0a8f764 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/2348 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Dave Frodin <dave.frodin@se-eng.com> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-02-15Drop include/arch-generic/div64.hStefan Reinauer
It's unused. Change-Id: Id67ca754ff7ad148ff1ecd4f1e5c986a4e7585a8 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2400 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-14sconfig: rename lapic_cluster -> cpu_clusterStefan Reinauer
The name lapic_cluster is a bit misleading, since the construct is not local APIC specific by concept. As implementations and hardware change, be more generic about our naming. This will allow us to support non-x86 systems without adding new keywords. Change-Id: Icd7f5fcf6f54d242eabb5e14ee151eec8d6cceb1 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2377 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-14sconfig: rename pci_domain -> domainStefan Reinauer
The name pci_domain was a bit misleading, since the construct is only PCI specific in a particular (northbridge/cpu) implementation, but not by concept. As implementations and hardware change, be more generic about our naming. This will allow us to support non-PCI systems without adding new keywords. Change-Id: Ide885a1d5e15d37560c79b936a39252150560e85 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2376 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-11spi-generic.h: Adapt include guardPatrick Georgi
Rename _SPI_H_ to _SPI_GENERIC_H_ to match recent file rename. Change-Id: I8b75e2e0a515fb540587630163ad289d0a6a0b22 Reported-by: Peter Stuge <peter@stuge.se> Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/2360 Tested-by: build bot (Jenkins) Reviewed-by: Peter Stuge <peter@stuge.se>
2013-02-11spi.h: Rename the spi.h to spi-generic.hZheng Bao
Since there are and will be other files in nb/sb folders, we change the general spi.h to a file name which is not easy to be duplicated. Change-Id: I6548a81206caa608369be044747bde31e2b08d1a Signed-off-by: Zheng Bao <zheng.bao@amd.com> Signed-off-by: zbao <fishbaozi@gmail.com> Reviewed-on: http://review.coreboot.org/2309 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-02-11Intel: Replace MSR 0xcd with MSR_FSB_FREQPatrick Georgi
And move the corresponding #define to speedstep.h Change-Id: I8c884b8ab9ba54e01cfed7647a59deafeac94f2d Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/2339 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-09speedstep: Deduplicate some MSR identifiersPatrick Georgi
In particular: MSR_PMG_CST_CONFIG_CONTROL MSR_PMG_IO_BASE_ADDR MSR_PMG_IO_CAPTURE_ADDR Change-Id: Ief2697312f0edf8c45f7d3550a7bedaff1b69dc6 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/2337 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-08armv7: Use same console initialization procedure for all ARM stagesHung-Te Lin
Use same console initialization procedure for all ARM stages (bootblock, romstage, and ramstage): #include <console/console.h> ... console_init() ... printk(level, format, ...) Verified to boot on armv7/snow with console messages in all stages. Change-Id: Idd689219035e67450ea133838a2ca02f8d74557e Signed-off-by: Hung-Te Lin <hungte@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2301 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-08console: Only print romstage messages with EARLY_CONSOLE enabled.Hung-Te Lin
Revise console source file dependency (especially for EARLY_CONSOLE) and interpret printk/console_init according to EARLY_CONSOLE setting (no-ops if EARLY_CONSOLE is not defined). Verified to boot on x86/qemu and armv7/snow. Disabling EARLY_CONSOLE correctly stops romstage messages on x86/qemu (armv7/snow needs more changes to work). Change-Id: Idbbd3a26bc1135c9d3ae282aad486961fb60e0ea Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2300 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-08console: Revise serial console configuration names.Hung-Te Lin
The console drivers (especially serial drivers) in Kconfig were named in different styles. This change will rename configuration names to a better naming style. - EARLY_CONSOLE: Enable output in pre-ram stage. (Renamed from EARLY_SERIAL_CONSOLE because it also supports non-serial) - CONSOLE_SERIAL: Enable serial output console, from one of the serial drivers. (Renamed from SERIAL_CONSOLE because other non-serial drivers are named as CONSOLE_XXX like CONSOLE_CBMEM) - CONSOLE_SERIAL_UART: Device-specific UART driver. (Renamed from CONSOLE_SERIAL_NONSTANDARD_MEM because it may be not memory-mapped) - HAVE_UART_SPECIAL: A dependency for CONSOLE_SERIAL_UART. Verified to boot on x86/qemu and armv7/snow, and still seeing console messages in romstage for both platforms. Change-Id: I4bea3c8fea05bbb7d78df6bc22f82414ac66f973 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2299 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-06replace uchar and uint with standard types in generic i2c headerDavid Hendricks
Change-Id: Ie72985bb5291bcef2e837a2f4f2ec929a0c086ce Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2290 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-05exynos: de-duplicate UART header contentDavid Hendricks
Some header content got duplicated during the initial porting effort. This moves generic UART header stuff to exynos5-common and leaves exynos5250 #defines in the AP-specific UART header. Change-Id: Ifb6289d7b9dc26c76ae4dfcf511590b3885715a3 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2285 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>