summaryrefslogtreecommitdiff
path: root/src/device
AgeCommit message (Collapse)Author
2013-12-21Add Kconfig options to override Subsystem Vendor and Device IDDuncan Laurie
These can typically be set in the devicetree but we need a way to override those values with a Kconfig setting so as not to expose the Vendor ID before the product has launched. Change-Id: Ib382e6d9359d24b128c693a657ffde52604efad3 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/65310 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4455 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-17device/dram/ddr3: Move CRC calculation in a separate functionAlexandru Gagniuc
Calculating the CRC of a SPD may be useful by itself, so split that part of the code in a separate function. Change-Id: I6c20d3db380551865126fd890e89de6b06359207 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/4537 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-12-12Log device path during resource allocationDuncan Laurie
Systems are hanging in dev_configure() without a log to indicate which device is being processed. Add some logging points to save the device path before talking to the device so we can narrow in on which device is the problem. Change-Id: I3751c19a1ea68cdccbc33e4f6b2eeddd1bd9f2e4 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/61296 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4349 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-11-26Clean up POST codes for Boot State machineDuncan Laurie
Now that there is a clearly defined boot state machine we can add some useful post codes to indicate the current point in the state machine by having it log a post code before the execution of each state. This removes the currently defined POST codes that were used by hardwaremain in favor of a new contiguous range that are defined for each boot state. The reason for this is that the existing codes are mostly used to indicate when something is done, which is confusing for actual debug because POST code debugging relies on knowing what is about to happen (to know what may be at fault) rather than what has just finished. One additonal change is added during device init step as this step often does the bulk of the work, and frequently logs POST codes itself. Therefore in order to keep better track of what device is being initialized POST_BS_DEV_INIT is logged before each device is initialized. interrupted boot with reset button and gathered the eventlog. Mosys has been extended to decode the well-known POST codes: 26 | 2013-06-10 10:32:48 | System boot | 120 27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize 28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0 29 | 2013-06-10 10:32:48 | Reset Button 30 | 2013-06-10 10:32:48 | System Reset Change-Id: Ida1e1129d274d28cbe8e49e4a01483e335a03d96 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58106 Reviewed-on: http://review.coreboot.org/4231 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-11-26Log device path into CMOS during probe stagesDuncan Laurie
One of the most common hangs during coreboot execution is during ramstage device init steps. Currently there are a set of (somewhat misleading) post codes during this phase which give some indication as to where execution stopped, but it provides no information on what device was actually being initialized at that point. This uses the new CMOS "extra" log banks to store the encoded device path of the device that is about to be touched by coreboot. This way if the system hangs when talking to the device there will be some indication where to investigate next. interrupted boot with reset button and gathered the eventlog after several test runs: 26 | 2013-06-10 10:32:48 | System boot | 120 27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize 28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0 29 | 2013-06-10 10:32:48 | Reset Button 30 | 2013-06-10 10:32:48 | System Reset Change-Id: I6045bd4c384358b8a4e464eb03ccad639283939c Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58105 Reviewed-on: http://review.coreboot.org/4230 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-11-26Add function to encode device path into integerDuncan Laurie
This function will encode the device path into 3 bytes of a dword which can be saved for debug. It will be used by subsequent commit to store the current device into CMOS for debugging BIOS hangs. Change-Id: I3a5155ea53c8d280806e610a0f8998dbabe15f3c Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58103 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4228 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-11-25x86: use proper types for interrupt callbacksAaron Durbin
The mainboard_interrupt_handlers() argument for the function pointer was using void * as the type. This does not allow the compiler to catch type differences for the arguments. Thus, some code has been committed which violates the new interrupt callbacks not taking any arguments. Make sure the compiler provides a type checking benefit. Change-Id: Ie20699a368e70c33a9a9912e0fcd63f1e6bb4f18 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/48970 Reviewed-on: http://review.coreboot.org/4141 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-11-08Add new finalize functions for devices and chipsMarc Jones
Many chipset devices require additional configuration after device init. It is not uncommmon for a device early in the devicetree list to need to change a setting after a device later in the tree does PCI init. A final function call has been added to device ops to handle this case. It is called prior to coreboot table setup. Another problem that is often seen is that the chipset or mainboard need to do some final cleanup just before loading the OS. The chip finalize has been added for this case. It is call after all coreboot tables are setup and the payload is ready to be called. Similar functionality could be implemented with the hardwaremain states, but those don't fit well in the device tree function pointer structure and should be used sparingly. Change-Id: Ib37cce104ae41ec225a8502942d85e54d99ea75f Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/4012 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-08-24Add test to match struct device with pci_devfn_tKyösti Mälkki
Add a function to test if pci_devfn_t matches with a device instance of struct device, by comparing bus:dev.fn. Change-Id: Ic6c3148ac62c7183246d83302ee504b17064c794 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3474 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-08-13Add a generic Intel HD audio (Azalia) module azalia_device.cAndrew Wu
This module uses cim_verb_data to detect and initialize HD audio codecs. The module source code is based on southbridge/intel/sch/audio.c and southbridge/nvidia/mcp55/azalia.c. Change-Id: I810fef6fdcf55d66f62da58c3d7d99f006559d6e Signed-off-by: Andrew Wu <arw@dmp.com.tw> Reviewed-on: http://review.coreboot.org/3844 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-07-25Redefine pci_bus_default_ops as functionKyösti Mälkki
Taking device_t as a parameter, this allows to alter the PCI config access handlers. This is useful to add tracing of PCI config writes for devices having problems to initialise correctly. On older AMD platform PCI MMIO may not be able to fully configure all PCI devices/nodes, while MMIO_SUPPORT_DEFAULT would be preferred due to its atomic nature. So those can be forced to IO config instead. Change-Id: I2162884185bbfe461b036caf737980b45a51e522 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3608 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-07-10device: Fix spellingMartin Roth
Change-Id: I53a40d114aa2da76398c5b97443d4096809dcf36 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3730 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-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-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-04Yabel : Add tracing option needed by i915tool.Denis 'GNUtoo' Carikli
This patch was made by listenning to what Ron Minnich told me to do on #coreboot IRC channel on Freenode with my adaptations on top. i915tool is at https://code.google.com/p/i915tool/ , the one in coreboot is outdated. Change-Id: I13cd684f4c290114836fbd7babd461153e8d6124 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/3277 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> 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-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-01device tree: track init timesAaron Durbin
With the introduction of a monotonic timer it is possible to track the individual times of each device's init() call. Add this ability behind a HAVE_MONOTONIC_TIMER option. Example log messages: Root Device init 5 usecs CPU_CLUSTER: 0 init 66004 usecs PCI: 00:00.0 init 1020 usecs PCI: 00:02.0 init 456941 usecs PCI: 00:13.0 init 3 usecs PCI: 00:14.0 init 3 usecs PCI: 00:15.0 init 92 usecs PCI: 00:15.1 init 37 usecs PCI: 00:15.2 init 36 usecs PCI: 00:15.3 init 35 usecs PCI: 00:15.4 init 35 usecs PCI: 00:15.5 init 36 usecs PCI: 00:15.6 init 35 usecs PCI: 00:16.0 init 3666 usecs PCI: 00:17.0 init 63 usecs PCI: 00:1b.0 init 3 usecs PCI: 00:1c.0 init 89 usecs PCI: 00:1c.1 init 15 usecs PCI: 00:1c.2 init 15 usecs PCI: 00:1c.3 init 15 usecs PCI: 00:1c.4 init 15 usecs PCI: 00:1c.5 init 16 usecs PCI: 00:1d.0 init 4 usecs PCI: 00:1f.0 init 495 usecs PCI: 00:1f.2 init 29 usecs PCI: 00:1f.3 init 4 usecs PCI: 00:1f.6 init 4 usecs Change-Id: Ibe499848432c7ab20166ab10d6dfb07db03eab01 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3162 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-04-03Add PXE ROM selection to Kconfig menuSiyuan Wang
Adding a pxe rom manually is inconvenient. With this patch, PXE ROM can be added automatically by selecting PXE_ROM in Kconfig. I have tested this patch on AMD Parmer and Thatcher with iPXE. iPXE would be a boot device in Seabios when pressing F12. iPXE works well with coreboot and Seabios. Change-Id: I2c4fc73fd9ae6c979f0af2290d410935f600e2c8 Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com> Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com> Reviewed-on: http://review.coreboot.org/3013 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-01pci: don't load vga option rom before S3 checkAaron Durbin
The pci device code was probing and loading the option rom before it did the S3 resume check for VGA option roms. Instead move this check before probing and loading so that we don't unnecessarily do work. Change-Id: If2e62d0c0e4b34b4f1bcd56ebcb9d3f54c6d0d24 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2979 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-21ramstage: prepare for relocationAaron Durbin
The current ramstage code contains uses of symbols that cause issues when the ramstage is relocatable. There are 2 scenarios resolved by this patch: 1. Absolute symbols that are actually sizes/limits. The symbols are problematic when relocating a program because there is no way to distinguish a symbol that shouldn't be relocated and one that can. The only way to handle these symbols is to write a program to post process the relocations and keep a whitelist of ones that shouldn't be relocated. I don't believe that is a route that should be taken so fix the users of these sizes/limits encoded as absolute symbols to calculate the size at runtime or dereference a variable in memory containing the size/limit. 2. Absoulte symbols that were relocated to a fixed address. These absolute symbols are generated by assembly files to be placed at a fixed location. Again, these symbols are problematic because one can't distinguish a symbol that can't be relocated. The symbols are again resolved at runtime to allow for proper relocation. For the symbols defining a size either use 2 symbols and calculate the difference or provide a variable in memory containing the size. Change-Id: I1ef2bfe6fd531308218bcaac5dcccabf8edf932c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2789 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-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-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-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-08VBE: Skip graphics mode setting for non-VGA devicesStefan Reinauer
This hit me when running the latest Qemu with coreboot: First the graphics OPROM is running, then an iPXE OPROM. The iPXE OPROM has no int10 support (obviously) so calling vbe_set_graphics() wipes the framebuffer information from the coreboot table. Change-Id: Ie0453c4a908ea4a6216158f663407a3e72ce4d34 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2325 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-02-08oprom: fix compilation for Qemu target (and possibly others)Stefan Reinauer
Not sure why this didn't bite us earlier.. src/device/oprom/realmode/x86.c: In function 'fill_lb_framebuffer': src/device/oprom/realmode/x86.c:272:13: error: dereferencing pointer to incomplete type src/device/oprom/realmode/x86.c:274:13: error: dereferencing pointer to incomplete type src/device/oprom/realmode/x86.c:275:13: error: dereferencing pointer to incomplete type src/device/oprom/realmode/x86.c:276:13: error: dereferencing pointer to incomplete type src/device/oprom/realmode/x86.c:278:13: error: dereferencing pointer to incomplete type src/device/oprom/realmode/x86.c:280:13: error: dereferencing pointer to incomplete type src/device/oprom/realmode/x86.c:281:13: error: dereferencing pointer to incomplete type src/device/oprom/realmode/x86.c:283:13: error: dereferencing pointer to incomplete type src/device/oprom/realmode/x86.c:284:13: error: dereferencing pointer to incomplete type src/device/oprom/realmode/x86.c:286:13: error: dereferencing pointer to incomplete type src/device/oprom/realmode/x86.c:287:13: error: dereferencing pointer to incomplete type src/device/oprom/realmode/x86.c:289:13: error: dereferencing pointer to incomplete type src/device/oprom/realmode/x86.c:290:13: error: dereferencing pointer to incomplete type Change-Id: Ie3b0f731a7b995e954a26e745b07fc122088ca9f Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2321 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-07YABEL: use system {in,out}[bwl] on x86Patrick Georgi
The prototypes that were recently defined only work for the internal implementations. Change-Id: Ib34bb75a0b882533da550b9cd17cd777c2463e02 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/2318 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-30Extend CBFS to support arbitrary ROM source media.Hung-Te Lin
Summary: Isolate CBFS underlying I/O to board/arch-specific implementations as "media stream", to allow loading and booting romstage on non-x86. CBFS functions now all take a new "media source" parameter; use CBFS_DEFAULT_MEDIA if you simply want to load from main firmware. API Changes: cbfs_find => cbfs_get_file. cbfs_find_file => cbfs_get_file_content. cbfs_get_file => cbfs_get_file_content with correct type. CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM, the ROM may come from USB, UART, or SPI -- any serial devices and not available for memory mapping. To support these devices (and allowing CBFS to read from multiple source at the same time), CBFS operations are now virtual-ized into "cbfs_media". To simplify porting existing code, every media source must support both "reading into pre-allocated memory (read)" and "read and return an allocated buffer (map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*" provides simple memory mapping simulation. Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA is defined for CBFS functions to automatically initialize a per-board default media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS function names relying on memory mapped backend (ex, "cbfs_find" => actually loads files). Now we only have two getters: struct cbfs_file *entry = cbfs_get_file(media, name); void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type); Test results: - Verified to work on x86/qemu. - Compiles on ARM, and follow up commit will provide working SPI driver. Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2182 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-04Make PCIe config options depend on PCIe supportStefan Reinauer
Change-Id: I42452a044dc75e35876fcea1736481e538eed663 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2100 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-08Fix Yabel compilation on non-x86 platformsStefan Reinauer
Mostly preventing inb/outb being used on non-x86 Change-Id: I0434df4ce477c262337672867dc6ce398ff95279 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2002 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-08Allow PCI option rom execution only on systems with PCI supportStefan Reinauer
... on all other systems it will fail terribly ;-) Change-Id: I7f8d10b71b2dbc798b28aee7c36872685c793fd8 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2001 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2012-12-06Unify assembler function handlingStefan Reinauer
Instead of adding regparm(0) to each assembler function called by coreboot, add an asmlinkage macro (like the Linux kernel does) that can be different per architecture (and that is empty on ARM right now) Change-Id: I7ad10c463f6c552f1201f77ae24ed354ac48e2d9 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1973 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-30Rename devices -> deviceStefan Reinauer
to match src/include/device Change-Id: I5d0e5b4361c34881a3b81347aac48738cb5b9af0 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1960 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>