summaryrefslogtreecommitdiff
path: root/src/include
AgeCommit message (Collapse)Author
2013-07-10Drop ELF remains from boot codeStefan Reinauer
This stuff is not used, so let's drop it. Change-Id: I671a5e87855b4c59622cafacdefe466ab3d70143 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3660 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARMv7: De-uboot-ify Exynos5250 codeStefan Reinauer
When starting the Exynos5250 port, a lot of unneeded u-boot code was imported. This is an attempt to get rid of a lot of unneeded code before the port is used as a basis for further ARM ports. There is a lot more that can be done, including cleaning up the 5250's Kconfig file. Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3642 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Rename hardwaremain() to main()Stefan Reinauer
... and drop the wrapper on ARMv7 Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3639 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10FUI: reorganize include filesRonald G. Minnich
We've got enough of a handle on this to realize some things: drm_dp_helper.h is by design device and architecture independent i915.h is common to most intel graphics chipsets going back several years i915_reg.h is as well Move these files to src/include/device, and adjust the .c files accordingly. Change-Id: I07512b3695fea0b22949074b467986420783d62a Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3637 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Provide support for setting up the framebuffer from EDIDRonald G. Minnich
Add three functions to edid.c: void set_vbe_mode_info_valid(struct edid *edid, uintptr_t fb_addr) takes an edid and uintptr_t, and fills in a static lb_framebuffer struct as well as setting the static vbe_valid to 1 unless some problem is found in the edid. The intent here is that this could be called from the native graphics setup code on both ARM and x86. int vbe_mode_info_valid(void) returns value of the static vbe_valid. void fill_lb_framebuffer(struct lb_framebuffer *framebuffer) copies the static edid_fb to lb_framebuffer. There is now a common vbe.h in src/include, removed the two special ones. In general, graphics in coreboot is a mess, but graphics is always a mess. We don't have a clean way to try two different ways to turn on a device and use the one that works. One battle at a time. Overall, things are much better. The best part: this code would also work for ARM, which also uses EDID. Change-Id: Id23eb61498b331d44ab064b8fb4cb10f07cff7f3 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3636 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-03pnp: Add some default functions to enter/exit config stateNico Huber
Implement some common default functions to enter and exit the configuration state. Also provide default pnp_mode_ops for common enter()/exit() function pairs. The following cocci ensures their use: @ mode_match @ identifier enter, exit, ops; @@ struct pnp_mode_ops ops = { .enter_conf_mode = enter, .exit_conf_mode = exit, }; @ enter_match_8787 @ identifier mode_match.enter, dev; @@ enter(...) { outb(0x87, dev->path.pnp.port); outb(0x87, dev->path.pnp.port); } @ depends on enter_match_8787 @ identifier mode_match.enter, mode_match.ops; @@ struct pnp_mode_ops ops = { - .enter_conf_mode = enter, + .enter_conf_mode = pnp_enter_conf_mode_8787, }; @ enter_match_55 @ identifier mode_match.enter, dev; @@ enter(...) { outb(0x55, dev->path.pnp.port); } @ depends on enter_match_55 @ identifier mode_match.enter, mode_match.ops; @@ struct pnp_mode_ops ops = { - .enter_conf_mode = enter, + .enter_conf_mode = pnp_enter_conf_mode_55, }; @ depends on enter_match_8787 || enter_match_55 @ identifier mode_match.enter; @@ -enter(...) {...} @ exit_match_aa @ identifier mode_match.exit, dev; @@ exit(...) { outb(0xaa, dev->path.pnp.port); } @ depends on exit_match_aa @ identifier mode_match.exit, mode_match.ops; @@ struct pnp_mode_ops ops = { - .exit_conf_mode = exit, + .exit_conf_mode = pnp_exit_conf_mode_aa, }; @ depends on exit_match_aa @ identifier mode_match.exit; @@ -exit(...) {...} @ depends on enter_match_8787 || enter_match_55 || exit_match_aa @ @@ #include <device/pnp.h> +#include <superio/conf_mode.h> @ mode_match_55_aa @ identifier ops; @@ struct pnp_mode_ops ops = { .enter_conf_mode = pnp_enter_conf_mode_55, .exit_conf_mode = pnp_exit_conf_mode_aa, }; @@ identifier mode_match_55_aa.ops; @@ -struct pnp_mode_ops ops = {...}; @@ identifier mode_match_55_aa.ops, devops; @@ struct device_operations devops = { - .ops_pnp_mode = &ops, + .ops_pnp_mode = &pnp_conf_mode_55_aa, }; @ mode_match_8787_aa @ identifier ops; @@ struct pnp_mode_ops ops = { .enter_conf_mode = pnp_enter_conf_mode_8787, .exit_conf_mode = pnp_exit_conf_mode_aa, }; @@ identifier mode_match_8787_aa.ops; @@ -struct pnp_mode_ops ops = {...}; @@ identifier mode_match_8787_aa.ops, devops; @@ struct device_operations devops = { - .ops_pnp_mode = &ops, + .ops_pnp_mode = &pnp_conf_mode_8787_aa, }; Change-Id: I1480336b54523cc95210d99cf31c1a0b3a14b464 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: http://review.coreboot.org/3484 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2013-07-01usbdebug: Drop duplicates of EHCI BAR relocation codeKyösti Mälkki
All the additional work that needs to be done in EHCI BAR relocation is independent of the hardware platform and was functionally identical in all the copies removed. When USBDEBUG is not selected, PCI EHCI controllers use standard pci_dev_read_resources() call. With USBDEBUG selected, PCI EHCI controller's device_operations .read_resources is replaced with pci_ehci_read_resources() call, which in turn will replace the device_operations .set_resources call. The replacement for .set_resources reconfigures usbdebug driver side, and calls the original .set_resources to configure hardware side. Change-Id: I8e136a5da4efedf60b6dd7068c0488153efaaf8e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3412 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-06-24AMD Fam15tn: Add support for AGESA runtime allocation in CBMEMRudolf Marek
The IOMMU AGESA needs a reserved scratch space and it wants to allocate the stuff for runtime. So provide a simple allocator for 4 KB CBMEM page. Change-Id: I53bdfcd2cd69f84fbfbc6edea53a051f516c05cc Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/3315 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-24AMD Fam15tn: Add IOMMU BAR allocation to northbridgeRudolf Marek
For IOMMU we need to allocate a 512 KB BAR in a non-standard location. Use the standard allocator for that and limit the BAR to 32-bits to be compatible with older systems. Change-Id: I44414ce6b264b7f1c086a9b1c7ea275a0830205e Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3314 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-17pnp: Implement common handling for PnP config modesNico Huber
Many super i/o chips only answer to PnP requests if they are in a configuration state (sometimes also called ext func mode). To cope with that, the code of many chips implements its own version of our default PnP functions like pnp_set_resource(), pnp_enable_resource() etc. To avoid this code duplication, this patch extends our PnP device interface with optional functions to enter and exit configuration mode. Change-Id: I9b7662a0db70ede93276764fa15020f251eb46bd Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: http://review.coreboot.org/3481 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-17pnp: Provide alternative pnp_enable() implementationNico Huber
The current default implementation of pnp_enable() only disables devices - if set so in the devicetree - but does not enable them. Enablement takes place in pnp_enable_resources(). Yet, many PnP chips implement their own version of pnp_enable() which also enables devices if set in the devicetree. It's arguable, if enabling those devices makes sense, before they get resources assigned. Maybe we can't write the resource registers if not, who knows? The least we can do is providing a common implementation for this behavior, and get rid of some code duplication. Used the following cocci: @@ expression e; @@ +pnp_alt_enable(e); -pnp_set_logical_device(e); ( -pnp_set_enable(e, !!e->enabled); | -(e->enabled) ? pnp_set_enable(e, 1) : pnp_set_enable(e, 0); | -if (e->enabled) { pnp_set_enable(e, 1); } -else { pnp_set_enable(e, 0); } ) Change-Id: I8d695e8fcd3cf8b847b1aa99326b51a554700bc4 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: http://review.coreboot.org/3480 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13AMD Hudson: Add support for the SD controllerDave Frodin
This patch provides the correct SD controller timings for the Family16 device. It also will remove the SD controller from PCI space when device 0:14.7 is set to off in devicetree. This was tested on a AMD Parmer board and a AMD G-series SOC reference board. The settings were found in the AMD Hudson2 RRG and family16 BKGD. Change-Id: I6d7e7997ddc39802ab75dc8a211ed29f028c0471 Signed-off-by: Dave Frodin <dave.frodin@se-eng.com> Reviewed-on: http://review.coreboot.org/3348 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-10ramtest.c: Add silent ram_checkAlexandru Gagniuc
In some cases, we want a ram_check that does not die and does not clobber the terminal with useless output that slows us down a lot. Usage examples include Checking if the RAM is up at the start of raminit, or checking if each rank is accessible as it is being initialized. As with all other ram_checks, this is more of a "Is my DRAM properly configured?" test, which is exactly what we want for something to use during memory initialization. Change-Id: I95d8d9a2ce1e29c74ef97b90aba0773f88ae832c Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/3416 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-06(Trivial) early_smbus: fix printsmbus macroAlexandru Gagniuc
When I've first written this macro in 2011, the correct define for verbose SMBus message was CONFIG_DEBUG_SMBUS_SETUP. This has since been changed to CONFIG_DEBUG_SMBUS. I didn't catch that, and this made the printsmbus macro always evaluate to an empty statement. Use the proper CONFIG_DEBUG_SMBUS define. This makes printsmbus functional again. Change-Id: Iaf03354b179cc4a061e0b65f5b746af10f5d2b88 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/3379 Tested-by: build bot (Jenkins) Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2013-06-04pci_ids.h: Add PCI IDs for VIA VX900 chipsetAlexandru Gagniuc
Change-Id: I4a75326fef0a10a6290cdd4b1b93d9af8e3ab23d Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/3268 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.huber@secunet.com>
2013-06-04coreboot: Add generic early SMBus APIAlexandru Gagniuc
Early SMBUS code with similar functionality is duplicated for all southbridges. Add a generic SMBus API (function declarations) designed to unify the early SMBus structure. This patch only adds the API. It does not implement any hardware-specific bits. Change-Id: I0861b7a3f098115182ae6de9f016dd671c500bad Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/143 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-04DDR3: Add utilities for creating MRS commandsAlexandru Gagniuc
MRS commands are used to tell the DRAM chip what timing and what termination and drive strength to use, along with other parameters. The MRS commands are defined by the DDR3 specification [1]. This makes MRS commands hardware-independent. MRS command creation is duplicated in various shapes and forms in any chipset that does DDR3. This is an effort to create a generic MRS API that can be used with any chipset. This is used in the VX900 branch. [1] www.jedec.org/sites/default/files/docs/JESD79-3E.pdf Change-Id: Ia8bb593e3e28a5923a866042327243d798c3b793 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/3354 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-03dram: Add utilities for decoding DDR3 SPDsAlexandru Gagniuc
Add convenience utilities for decoding DDR3 SPDs and printing the information to the console. These have proven invaluable when writing the VX900 memory initialization. These are used in the VX900 branch Information printed has the following format: > SPD Data for DIMM 51 > Revision: 10 > Type : b > Key : 2 > Banks : 8 > Capacity: 1 Gb > Supported voltages: 1.5V > SDRAM width : 8 > Bus extension : 0 bits > Bus width : 64 > Optional features : DLL-Off_mode RZQ/7 RZQ/6 > Thermal features : ASR ext_temp_range > Thermal sensor : no > Standard SDRAM : no > Row addr bits : 13 > Column addr bits : 10 > Number of ranks : 1 > DIMM Capacity : 1024 MB > CAS latencies : 6 7 8 9 > tCKmin : 1.500 ns > tAAmin : 13.125 ns > tWRmin : 15.000 ns > tRCDmin : 13.125 ns > tRRDmin : 6.000 ns > tRPmin : 13.125 ns > tRASmin : 36.000 ns > tRCmin : 49.125 ns > tRFCmin : 110.000 ns > tWTRmin : 7.500 ns > tRTPmin : 7.500 ns > tFAWmin : 30.000 ns Change-Id: I30725a75caf74ac637db0a143344562bd9910466 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/3267 Tested-by: build bot (Jenkins)
2013-06-03spd.h: Add all known SPD_MEMORY_TYPE definitions.Alexandru Gagniuc
This file was missing some definitions, so add them. Also turn the defines into an enum. The reason for doing this is that functions can now explicitly take an spd_memory_type as a parameter: > int do_something_with_dram(enum spd_memory_type type, ...) Which is a lot more explicit and readable than: > int do_something_with_dram(u8 type, ...) These are used in the VX900 branch. Change-Id: Ic7871e82c2523a94eac8e07979a8e34e0b459b46 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/3266 Tested-by: build bot (Jenkins)
2013-06-03include/cpu/amd: Align `CPU_ID_EXT_FEATURES_MSR` with other definesPaul Menzel
Probably due to different (character) widths for a tab, sometimes only one tab was used for aligning the define `CPU_ID_EXT_FEATURES_MSR`. For the “correct” alignment, that means where a tab is eight characters, two tabs are necessary. Change it accordingly. Change-Id: I450a7796dc00b934b5a6bab8642db04a27f69f4b Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3263 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
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)
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 17:51:49 +0000