summaryrefslogtreecommitdiffstats
path: root/src/device/Makefile.inc
Commit message (Collapse)AuthorAgeFilesLines
* device/mipi: Move to drivers/mipiJulius Werner2021-08-261-1/+1
| | | | | | | | | | | | | | Sounds like we prefer to have this under drivers/ instead of device/. Also move all MIPI-related headers out from device/ into their own directory. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ib3e66954b8f0cf85b28d8d186b09d7846707559d Reviewed-on: https://review.coreboot.org/c/coreboot/+/57128 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
* device: Move MIPI panel library from mainboard/google/kukui into commonJulius Werner2021-08-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | All boards that are trying to use MIPI panels eventually run into the problem that they need to store physical parameters and a list of DCS initialization commands for each panel, and these commands can be very different (e.g. a large amount of very short commands, a few very large commands, etc.). Finding a data format to fit all these different cases efficiently into the same structures keeps being a challenge, and the Kukui mainboard already once put a lot of effort into designing a clean, flexible and efficient solution for this. This patch moves that framework into a common src/device/mipi/ library where it can be used by other boards as well. (Also, this will hopefully allow us to save some duplicated work when using the same panel on different boards at some point.) Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I877f2b0c7ab984412b288e2ed27f37cd93c70863 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56965 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
* device + util/sconfig: introduce new device `gpio`Michael Niewöhner2020-12-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* device/Makefile.inc: Do not require hda_verb.cAngel Pons2020-12-111-1/+1
| | | | | | | | | | A mainboard-level hda_verb.c may not exist for variant setups. Change-Id: If2c92d9498cba7c084ef4c7065bc4ae83c7da761 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48353 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Christian Walter <christian.walter@9elements.com>
* device: Drop unused HyperTransport codeAngel Pons2020-11-251-1/+0
| | | | | | | | | | Only two definitions are actually used somewhere, the rest is unused. Change-Id: Iec52d0d47fce6a1ec5455b670824b995a7a34a4c Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47407 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/xhci: Add xHCI utility to enumerate capabilitiesRaul E Rangel2020-06-101-0/+2
| | | | | | | | | | | | | | | | | | | | This will allow enumerating an xHCI controller to allow dynamically generating the ACPI device nodes. BUG=b:154756391 TEST=Boot trembyle and see capabilities printed on console xHCI Supported Protocol: Major: 0x2, Minor: 0x0, Protocol: 'USB ' Port Offset: 1, Port Count: 2 xHCI Supported Protocol: Major: 0x3, Minor: 0x10, Protocol: 'USB ' Port Offset: 3, Port Count: 1 Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I3065c3fffad01b5378a55cfe904f971079b13d0f Reviewed-on: https://review.coreboot.org/c/coreboot/+/41899 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
* device: Add support for resource allocator v4Furquan Shaikh2020-05-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change adds back support for the resource allocator using multiple ranges as originally landed in CB:39486(commit hash 3b02006) and reverted in CB:41413(commit hash 6186cbc). The new resource allocator can be selected by Kconfig option RESOURCE_ALLOCATOR_V4. It was identified that there are some AMD chipsets in the tree that do not really work well with the dynamic resource allocation. Until these chipsets are fixed, old (v3) and new (v4) of the resource allocator need to live side-by-side in the tree. There were some other chipsets in the tree which originally demonstrated problems with the new resource allocator, but have been since fixed in the tree. This change picks up the same additions as performed in CB:39486 along with the following changes: 1. Changes to avoid fixed resources in the entire tree. Use of search_bus_resources() is replaced with a walk of the entire tree in avoid_fixed_resources(). This is required to ensure that all fixed resources added to any device (including domain) are taken into consideration to avoid overlap during dynamic resource allocation. 2. Changes to set up alignment for memranges when initializing them. This is done to ensure that the right granularity is used for IORESOURCE_IO(no special alignment) and IORESOURCE_MEM(4KiB) resource requests. 3. mark_resource_invalid() is dropped as the resource no longer needs to be marked in any special way if allocation is not being done. Instead setting of IORESOURCE_ASSIGNED flag is skipped in this case. 4. initialize_memranges() is updated to check IORESOURCE_ASSIGNED instead of base == limit. Original commit message: This change updates the resource allocator in coreboot to allow using multiple ranges for resource allocation rather than restricting available window to a single base/limit pair. This is done in preparation to allow 64-bit resource allocation. Following changes are made as part of this: a) Resource allocator still makes 2 passes at the entire tree. The first pass is to gather the resource requirements of each device under each domain. It walks recursively in DFS fashion to gather the requirements of the leaf devices and propagates this back up to the downstream bridges of the domain. Domain is special in the sense that it has fixed resource ranges. Hence, the resource requirements from the downstream devices have no effect on the domain resource windows. This results in domain resource limits being unmodified after the first pass. b) Once the requirements for all the devices under the domain are gathered, resource allocator walks a second time to allocate resources to downstream devices as per the requirements. Here, instead of maintaining a single window for allocating resources, it creates a list of memranges starting with the resource window at domain and then applying constraints to create holes for any fixed resources. This ensures that there is no overlap with fixed resources under the domain. c) Domain does not differentiate between mem and prefmem. Since they are allocated space from the same resource window at the domain level, it considers all resource requests from downstream devices of the domain independent of the prefetch type. d) Once resource allocation is done at the domain level, resource allocator walks down the downstream bridges and continues the same process until it reaches the leaves. Bridges have separate windows for mem and prefmem. Hence, unlike domain, the resource allocator at bridge level ensures that downstream requirements are satisfied by taking prefetch type into consideration. e) This whole 2-pass process is performed for every domain in the system under the assumption that domains do not have overlapping address spaces. Noticeable differences from previous resource allocator: a) Changes in print logs observed due to flows being slightly different. b) Base, limit and size of domain resources are no longer updated based on downstream requirements. c) Memranges are used instead of a single base/limit pair for determining resource allocation. d) Previously, if a resource request did not fit in the available base/limit window, then the resource would be allocated over DRAM or any other address space defeating the principle of "no overlap". With this change, any time a resource cannot fit in the available ranges, it complains and ensures that the resource is effectively disabled by setting base same as the limit. e) Resource allocator no longer looks at multiple links to determine the right bus for a resource. None of the current boards have multiple buses under any downstream device of the domain. The only device with multiple links seems to be the cpu cluster device for some AMD platforms. Change-Id: Ide4d98528197bb03850a8fb4d73c41cd2c0195aa Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41443 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Move resource allocation into a separate compilation unitFurquan Shaikh2020-05-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change moves the resource allocator functions out of device.c and into two separate files: 1. resource_allocator_v3.c: This is the old implementation of resource allocator that uses a single window for resource allocation. It is required to support some AMD chipsets that do not provide an accurate map of allocated resources by the time the allocator runs. They work fine with the old allocator since it restricts itself to allocations in a single window at the top of the 4G space. 2. resource_allocator_common.c: This file contains the functions that can be shared by the old and new resource allocator. Entry point into the resource allocation is allocate_resources() which can be implemented by both old and new allocators. This change also adds a Kconfig option RESOURCE_ALLOCATOR_V3 which enables the old resource allocator. This config option is enabled by default currently, but in the following CLs this will be enabled only for the broken boards. Reason for this split: Both the old and new resource allocators need to be retained in the tree until the broken chipsets are fixed. Change-Id: I2f5440cf83c6e9e15a5f22e79cc3c66aa2cec4c0 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41442 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Mike Banon <mikebdp2@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Add buffer_to/from_fifo32(_prefix) helpersJulius Werner2019-08-221-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Many peripheral drivers across different SoCs regularly face the same task of piping a transfer buffer into (or reading it out of) a 32-bit FIFO register. Sometimes it's just one register, sometimes a whole array of registers. Sometimes you actually transfer 4 bytes per register read/write, sometimes only 2 (or even 1). Sometimes writes need to be prefixed with one or two command bytes which makes the actual payload buffer "misaligned" in relation to the FIFO and requires a bunch of tricky bit packing logic to get right. Most of the times transfer lengths are not guaranteed to be divisible by 4, which also requires a bunch of logic to treat the potential unaligned end of the transfer correctly. We have a dozen different implementations of this same pattern across coreboot. This patch introduces a new family of helper functions that aims to solve all these use cases once and for all (*fingers crossed*). Change-Id: Ia71f66c1cee530afa4c77c46a838b4de646ffcfb Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34850 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* device/pci: Rewrite PCI MMCONF with symbol referenceKyösti Mälkki2019-04-071-1/+7
| | | | | | | | | | | | | | | | | | | | The effect of pointer aliasing on writes is that any data on CPU registers that has been resolved from (non-const and non-volatile) memory objects has to be discarded and resolved. In other words, the compiler assumes that a pointer that does not have an absolute value at build-time, and is of type 'void *' or 'char *', may write over any memory object. Using a unique datatype for MMIO writes makes the pointer to _not_ qualify for pointer aliasing with any other objects in memory. This avoid constantly resolving the PCI MMCONF address, which is a derived value from a 'struct device *'. Change-Id: Id112aa5e729ffd8015bb806786bdee38783b7ea9 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31752 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/pci_ops: Have only default PCI bus ops availableKyösti Mälkki2019-03-161-1/+0
| | | | | | | | | | | | | | | | In the current state of the tree we do not utilise the mechanism of having per-device overrides for PCI bus ops. This change effectively inlines all PCI config accessors for ramstage as well. Change-Id: I11c37cadfcbef8fb5657dec6d620e6bccab311a4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31753 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* device/pci: Organize MakefileKyösti Mälkki2019-03-031-13/+17
| | | | | | | | | | | Use a single group for all CONFIG_PCI=y sources. Change-Id: I426f4398c01dfbf03b9dd2db8c7a964512c86d5e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/31680 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/pci_early.c: Drop some guardsKyösti Mälkki2019-02-111-3/+0
| | | | | | | | | | | With PCI_DEV() always defined it is no longer necessary to exclude this code from building. Change-Id: I58a6348750d240aa6024599f7b1af1449f31e8ac Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/31303 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
* device/pci_early: Fixes for __SIMPLE_DEVICE__Kyösti Mälkki2018-12-301-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | The feature is used to enable PCI MMIO accesses behind PCIe links (or bridges) before PCI enumeration has been completed. Add the feature for bootblock, verstage and postcar, it is required with add-on PCIe serial cards for early console output. It's up to the board specific code to configure PCIe root port prior to calling console_init() for this to work. Remove feature from ramstage, it bypasses any resource allocations and bus number assignments. For the moment PCI configuration support before ramstage is available only on ARCH_X86. Also switch from device_t to pci_devfn_t. Change-Id: I08acec68b6f17f4d73d30039cc41274492ea4f45 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/30496 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
* device: Rename device_simple.c --> device_const.cNico Huber2018-05-251-6/+6
| | | | | | | | | | | | | | | | | | In early stages (pre ramstage), we have two notions of devices. To access the hardware, "simple device" handles are used. These are plain numbers. To access the static information of the device tree, we use `struct device` pointers. This is referred to as DEVTREE_EARLY in the code. This file is about the latter and its name reflects that the tree remains unmodified. Change-Id: I31aeb118615e86026f7111f83a7866d4e7426170 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/26293 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* device: Always build device_simple.c for less code duplicationNico Huber2018-05-241-0/+1
| | | | | | | | | | Change-Id: Iec0a11d67d7641996f26b3a01352be762006ebb6 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/26292 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
* Move `pci_ops_mmconf` from arch/x86/ to device/Nico Huber2018-05-081-0/+1
| | | | | | | | | | | MMConf is not architecture specific. We also always provide a pci_bus_default_ops() now if MMCONF_SUPPORT is selected. Change-Id: I3f9b403da29d3fa81914cc1519710ba7d1bf2bb5 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/26062 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Include devicetree in SMM stageSubrata Banik2018-02-221-0/+1
| | | | | | | | | | | | | | Allow bootblock to get access to the entire static device tree as other stages can access independently. TEST=SMM code now can access devicetree.cb variables. Change-Id: I59537c16f0a459e48d8b1efb5c1b196302f13381 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/23823 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
* Reinvent I2C opsNico Huber2017-08-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Do not use the global platform_i2c_transfer() function that can only be implemented by a single driver. Instead, make a `struct device` aware transfer() function the only interface function for I2C controller dri- vers to implement. To not force the slave device drivers to be implemented either above generic I2C or specialized SMBus operations, we support SMBus control- lers in the slave device interface too. We start with four simple slave functions: i2c_readb(), i2c_writeb(), i2c_readb_at() and i2c_writeb_at(). They are all compatible to respec- tive SMBus functions. But we keep aliases because it would be weird to force e.g. an I2C EEPROM driver to call smbus_read_byte(). Change-Id: I98386f91bf4799ba3df84ec8bc0f64edd4142818 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/20846 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
* device: allow devicetree accesses in postcar stageAaron Durbin2017-04-251-0/+1
| | | | | | | | | | Change-Id: Ib6f8ee937c4f3d8e2c0ff3851a819077fa499ccc Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/19334 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
* device: include devicetree in bootblock stageAaron Durbin2016-07-271-2/+3
| | | | | | | | | | | | | | | | Allow bootblock to get access to the static device tree like other early stages. device_romstage.c was renamed to device_simple.c to better articulate the usage since it's not just being used in romstage. BUG=chrome-os-partner:55357 Change-Id: I3d63d2754c737cc738c09a3e3b3b468362fb78d1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15837 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Subrata Banik <subrata.banik@intel.com> Tested-by: build bot (Jenkins)
* device/pci_rom: Always use pci_romPatrick Rudolph2016-04-131-2/+1
| | | | | | | | | | | | | | The following series always needs to access the functions provided pci_rom.c. Remove the dependency to CONFIG_VGA_ROM_RUN and depend on CONFIG_PCI instead. Change-Id: I6ed7ff5380edc7cd88dc1c71b43b1129a3de0f52 Signed-off-by: Patrick Rudolph <siro@das-labor.org> Reviewed-on: https://review.coreboot.org/14219 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
* device: Add i2c read/write register field APIYidi Lin2016-03-211-0/+5
| | | | | | | | | | | | | | | | | | | | | i2c_read_field() - read the value from the specific register field i2c_write_field() - write the value to the specific register field BRANCH=none BUG=none TEST=none Change-Id: I2098715b4583c1936c93b3ff45ec330910964304 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0817fc76d07491b39c066f1393a6435f0831b50c Original-Change-Id: I92c187a89d10cfcecf3dfd9291e0bc015459c393 Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com> Original-Reviewed-on: https://chromium-review.googlesource.com/332712 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14105 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
* x86: add standalone verstage supportAaron Durbin2015-10-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support x86 verstage one needs a working buffer for vboot. That buffer resides in the cache-as-ram region which persists across verstage and romstage. The current assumption is that verstage brings cache-as-ram up and romstage tears cache-as-ram down. The timestamp, cbmem console, and the vboot work buffer are persistent through in both romstage and verstage. The vboot work buffer as well as the cbmem console are permanently destroyed once cache-as-ram is torn down. The timestamp region is migrated. When verstage is enabled the assumption is that _start is the romstage entry point. It's currently expected that the chipset provides the entry point to romstage when verstage is employed. Also, the car_var_*() APIs use direct access when in verstage since its expected verstage does not tear down cache-as-ram. Lastly, supporting files were added to verstage-y such that an x86 verstage will build and link. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built and booted glados using separate verstage. Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11822 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* device: Use x86 specific code on x86-64Stefan Reinauer2015-06-221-0/+1
| | | | | | | | | Change-Id: I4763ce32bb0b0e301401daaeb89440524fcc682e Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-on: http://review.coreboot.org/10584 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
* device: Add class and subclass name supportLee Leahy2015-04-221-0/+1
| | | | | | | | | | | | | | | | | | | | | Add support to display class and subclass names for PCI devices. BRANCH=none BUG=None TEST=Build and run on strago/cyan. Change-Id: I5136fae45b8a1cd02541f233d29a246cdfcd8331 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a7c9b0d7201b09a06ea32f0db84187d15f767c80 Original-Change-Id: Ibf2ee89dd84040ca6ab0e52857a69f7ed0c28f37 Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/263342 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com> Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com> Reviewed-on: http://review.coreboot.org/9901 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* rk3288: Add software I2C supportJulius Werner2015-04-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the necessary platform glue to allow the use of software-driven I2C bit banging on the RK3288. This is just a debugging feature that can be used to reproduce certain I2C failure cases. Also fix Makefile verstage linking for the feature and add some new rk3288 IOMUX macros as needed. BRANCH=None BUG=None TEST=Added "CONFIG_SOFTWARE_I2C=y" to configs/config.veyron_jerry, wrapped Jerry's bootblock and verstage in software_i2c_attach/detach() calls, confirmed that both PMIC and TPM could be driven correctly with software I2C driver. Tried out different combinations of software_i2c_wedge_ack() and software_i2c_wedge_read() on the PMIC and observed transfer results with the hardware controller after reboot... the worst that would happen is that the first register read-modify-write (DCDC_ILMAX) would fail to read, but all later transfers would be fine. Since that register is written twice (due to current BUCK1 ramp implementation) and is not terribily important anyway, I think we don't need to worry about wedging problems. Change-Id: Iba801ee61d30fb1fd3aef8300612c67fa50c441b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 24dfca9bab38a20c40ef0c2dd4c775b8d8f47487 Original-Change-Id: I96777300a57c85471bad20e23a455551e9970222 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/247890 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9757 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* PCI subsystem: Remove AGP bridge typeKyösti Mälkki2015-02-101-1/+0
| | | | | | | | | | | | | | There is no auto-detection for AGP type and we have no hardware that selects this. Furthermore, we treat AGP bridges just like PCI bridges, there is no optimisation for higher bandwidth. Change-Id: I4fe87c83411643cb9b8d3216f2af07bf098174d3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8367 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* i2c: Add software_i2c driver for I2C debugging and emulationJulius Werner2014-12-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds I2C emulation in software through raw toggling of the SDA/SCL lines. Platforms need to provide bindings to toggle their respective I2C busses for this to work (e.g. by pinmuxing them as GPIOs, currently only enabled for Tegra). This is mostly useful as a debugging feature, to drive unusual states on a bus and closely monitor the device output without the need of a bus analyzer. It provides a few functions to "wedge" an I2C bus by aborting a transaction at certain points, which can be used to test if a system can correctly recover from an ill-timed reboot. However, it can also dynamically replace the existing I2C transfer functions and drive some/all I2C transfers on the system, which might be useful if a driver for the actual I2C controller hardware is not (yet) available. Based on original code by Doug Anderson <dianders@chromium.org> and Hung-ying Tyan <tyanh@chromium.org> for the ChromeOS embedded controller project. BRANCH=None BUG=chrome-os-partner:28323 TEST=Spread tegra_software_i2c_init()/tegra_software_i2c_disable() through the code and see that everything still works. Original-Change-Id: I9ee7ccbd1efb38206669a35d0c3318af16f8be63 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/198791 Original-Reviewed-by: Doug Anderson <dianders@chromium.org> Original-Reviewed-by: Tom Warren <twarren@nvidia.com> Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 8f71503dbbd74c5298e90e2163b67d4efe3e89db) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: Id6c5f75bb5baaabd62b6b1fc26c2c71d9f1ce682 Reviewed-on: http://review.coreboot.org/7947 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
* azalia: Shrink boilerplateVladimir Serbinenko2014-09-131-0/+4
| | | | | | | | | Change-Id: Ib3e09644c0ee71aacb067adaa85653d151b52078 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/6840 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
* device,Makefile.inc: Trivial - drop trailing blank lines at EOFEdward O'Callaghan2014-07-171-1/+0
| | | | | | | | Change-Id: I73fe6f37c363f4bff332ca90178a236590067170 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6287 Tested-by: build bot (Jenkins) Reviewed-by: Idwer Vollering <vidwer@gmail.com>
* gizmosphere/gizmo: Move support of SPD data in CBFSKyösti Mälkki2014-07-051-1/+1
| | | | | | | | | | | This code is not specific to any board or AGESA family. Change-Id: I26c32fbe8e45018e239762b072dfe3da05271697 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5690 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
* Introduce stage-specific architecture for corebootFurquan Shaikh2014-05-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
* OxPCIe uart: Split PCI bridge controlKyösti Mälkki2014-04-091-0/+1
| | | | | | | | | | | | None of the PCI bridge management here is specific to the PCI UART device/function. Also the Kconfig variable defaults are not globally valid, fill samsung/lumpy with working values. Change-Id: Id22631412379af1d6bf62c996357d36d7ec47ca3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5237 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* PCI: Add capability list parser to romstageKyösti Mälkki2014-02-121-1/+2
| | | | | | | | | | | | These are almost one-to-one copies from pci_device.c. However, devicetree has not been enumerated yet and we have no console. Change-Id: Ic80c781626521d03adde05bdb1916acce31290ea Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5196 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@google.com>
* Remove PCI_ROM_RUN optionVladimir Serbinenko2013-12-241-4/+0
| | | | | | | | | | | | | | | | | | The main purpose of option rom is to supply int* handlers. But supplying those is outside of coreboot scope and if someone needs those they should run SeaBIOS anyway which runs the option roms wonderfully. Running VGA oprom is kept because they're needed to init graphics. This patch still keeps the options to include the option roms to make them available to SeaBIOS. Change-Id: I646334cf88094d3bf8f527779a68a07e0b4b93ec Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/4545 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Kevin O'Connor <kevin@koconnor.net>
* Add a generic Intel HD audio (Azalia) module azalia_device.cAndrew Wu2013-08-131-0/+1
| | | | | | | | | | | | | | 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>
* Rename devices -> deviceStefan Reinauer2012-11-301-0/+24
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-18 21:09:55 +0000