| Age | Commit message (Collapse) | Author |
|---|
|
This is all handled at runtime now, so there is no need to have the
ability to statically add lapics to the devicetree.
Change-Id: I0746eb808a2956ac75f76c8189a9ecf190e33ce9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69378
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch extends the available device paths with a new device 'mdio'.
MDIO is the 'Management Data Input/Output' called interface which is
used to access an Ethernet PHY behind a MAC to change settings. The real
payload data path is not handled by this interface.
To address the PHY correctly on the MDIO bus, there is a 5 bit address
needed, which often can be configured via pins on the mainboard.
Therefore, the new introduced device has an 'addr' field to define its
address. If one wants to use a MDIO device in devicetree, the syntax is
straight forward (example):
device mdio 0x2 on end
As the MDIO interface is driven by the MAC, most likely this MDIO device
will be hooked in as a child device of the (PCI attached) MAC device.
With the new introduced ops_mdio a new interface is added to provide an
API for read and write access over MDIO.
Change-Id: I6691f92c4233bc30afc9029840b06f74bb1eb4b2
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69382
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Currently we only have runtime mechanisms to assign device operations to
a node in our devicetree (with one exception: the root device). The most
common method is to map PCI IDs to the device operations with a `struct
pci_driver`. Another accustomed way is to let a chip driver assign them.
For very common drivers, e.g. those in soc/intel/common/blocks/, the PCI
ID lists grew very large and are incredibly error-prone. Often, IDs are
missing and sometimes IDs are added almost mechanically without checking
the code for compatibility. Maintaining these lists in a central place
also reduces flexibility.
Now, for onboard devices it is actually unnecessary to assign the device
operations at runtime. We already know exactly what operations should be
assigned. And since we are using chipset devicetrees, we have a perfect
place to put that information.
This patch adds a simple mechanism to `sconfig`. It allows us to speci-
fy operations per device, e.g.
device pci 00.0 alias system_agent on
ops system_agent_ops
end
The operations are given as a C identifier. In this example, we simply
assume that a global `struct device_operations system_agent_ops` exists.
Change-Id: I2833d2f2450fde3206c33393f58b86fd4280b566
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66483
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Introduce the `smbios_dev_info` devicetree keyword to specify the
instance ID and RefDes (Reference Designation) of onboard devices.
Example syntax:
device pci 1c.0 on # PCIe Port #1
device pci 00.0 on
smbios_dev_info 6
end
end
device pci 1c.1 on # PCIe Port #2
device pci 00.0 on
smbios_dev_info 42 "PCIe-PCI Time Machine"
end
end
The `SMBIOS_TYPE41_PROVIDED_BY_DEVTREE` Kconfig option enables using
this syntax to control the generated Type 41 entries. When this option
is enabled, Type 41 entries are only autogenerated for devices with a
defined instance ID. This avoids having to keep track of which instance
IDs have been used for every device class.
Using `smbios_dev_info` when `SMBIOS_TYPE41_PROVIDED_BY_DEVTREE` is not
enabled will result in a build-time error, as the syntax is meaningless
in this case. This is done with preprocessor guards around the Type 41
members in `struct device` and the code which uses the guarded members.
Although the preprocessor usage isn't particularly elegant, adjusting
the devicetree syntax and/or grammar depending on a Kconfig option is
probably even worse.
Change-Id: Iecca9ada6ee1000674cb5dd7afd5c309d8e1a64b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Even though `device` entries are children of `chip` entries in the
devicetree source format, the chips in the translated C structures
are only hooked up to device nodes. Hence, any chip with all its
settings will be silently dropped by sconfig if there is no device
node below it.
Let's adapt the parser to ensure that there is at least one `device`
entry. The intermediate `chipchildren_dev` rule applies until the
first `device` entry is found, then everything continues as before
with the `chipchildren` rule.
Change-Id: I54830bc1fc7d00a0605f3fe4d36a83ef57ef3312
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51119
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The ESPI & LPC keywords were added for the zork program, but it was
found that they weren't needed, so they were never used.
BUG=None
TEST=Build
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I3a78afc55477d62eac8056e2ca4bcdd3ab12ea47
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56197
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Sooner or later, some board was going to need extra FW_CONFIG bits for
a field that was already in production, so this patch adds support for
adding extra (unused) bits to a field.
The extra are appended via a syntax like:
`field FIELD_NAME START0 END0 | START1 END1 | START2 END2 ...`
and the suffixed bits are all treated as if they are contiguous when
defining option values.
BUG=b:185190978
TEST=Modified volteer fw_config to the following:
field AUDIO 8 10 | 29 29 | 31 31
option NONE 0
option MAX98357_ALC5682I_I2S 1
option MAX98373_ALC5682I_I2S 2
option MAX98373_ALC5682_SNDW 3
option MAX98373_ALC5682I_I2S_UP4 4
option MAX98360_ALC5682I_I2S 5
option RT1011_ALC5682I_I2S 6
option AUDIO_FOO 7
option AUDIO_BAR 8
option AUDIO_QUUX 9
option AUDIO_BLAH1 10
option AUDIO_BLAH2 15
option AUDIO_BLAH3 16
option AUDIO_BLAH4 31
end
which yielded (in static_fw_config.h):
FW_CONFIG_FIELD_AUDIO_MASK 0xa0000700
FW_CONFIG_FIELD_AUDIO_OPTION_NONE_VALUE 0x0
FW_CONFIG_FIELD_AUDIO_OPTION_MAX98357_ALC5682I_I2S_VALUE 0x100
FW_CONFIG_FIELD_AUDIO_OPTION_MAX98373_ALC5682I_I2S_VALUE 0x200
FW_CONFIG_FIELD_AUDIO_OPTION_MAX98373_ALC5682_SNDW_VALUE 0x300
FW_CONFIG_FIELD_AUDIO_OPTION_MAX98373_ALC5682I_I2S_UP4_VALUE 0x400
FW_CONFIG_FIELD_AUDIO_OPTION_MAX98360_ALC5682I_I2S_VALUE 0x500
FW_CONFIG_FIELD_AUDIO_OPTION_RT1011_ALC5682I_I2S_VALUE 0x600
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_FOO_VALUE 0x700
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BAR_VALUE 0x20000000
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_QUUX_VALUE 0x20000100
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH1_VALUE 0x20000200
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH2_VALUE 0x20000700
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH3_VALUE 0x80000000
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH4_VALUE 0xa0000700
Change-Id: I5ed76706347ee9642198efc77139abdc3af1b8a6
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52747
Reviewed-by: Duncan Laurie <duncan@iceblink.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
This change extends the devicetree override one more layer and allows
the chipset to provide the base devicetree. This allows the chipset to
assign alias names to devices as well as set default register values.
This works for both the baseboard devicetree.cb as well as variant
overridetree.cb.
chipset.cb:
device pci 15.0 alias i2c0 off end
devicetree.cb:
device ref i2c0 on end
BUG=b:156957424
Change-Id: Ia7500a62f6211243b519424ef3834b9e7615e2fd
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44037
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Rarely, the driver of one device needs to know about another device
that can be anywhere in the device hierarchy. Current applications
boil down to EEPROMs that store information that is consumed by some
code (e.g. MAC address).
The idea is to give device nodes in the `devicetree.cb` an alias that
can later be used to link it to a device driver's `config` structure.
The driver has to declare a field of type `struct device *`, e.g.
struct some_chip_driver_config {
DEVTREE_CONST struct device *needed_eeprom;
};
In the devicetree, the referenced device gets an alias, e.g.
device i2c 0x50 alias my_eeprom on end
The author of the devicetree is free to choose any alias name that
is unique in the devicetree. Later, when configuring the driver the
alias can be used to link the device with the field of a driver's
config:
chip some/chip/driver
use my_eeprom as needed_eeprom
end
Override devices can add an alias if it does not exist, but cannot
change the alias for a device that already exists.
Alias names are checked for conflicts both in the base tree and in the
override tree.
References are resolved after the tree is parsed so aliases and
references do not need to be in a specific order in the tree.
Change-Id: I058a319f9b968924fbef9485a96c9e3f900a3ee8
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35456
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change adds support to sconfig for generating the firmware
configuration field and option definitions in devicetree.cb.
In addition these fields and options can be used to probe for a device
and have that device be disabled if it is not found at boot time.
New tokens:
fw_config: top level token, table can be defined before chips
field: define field in the mask with the start and end bits
option: define option in a field with the value of the field
probe: indicate that a device should probe by field and option
Example:
fw_config
field FEATURE 0 0
option DISABLE 0
option ENABLE 1
end
end
chip drivers/generic/feature
device generic 0 on
probe FEATURE ENABLE
end
end
Variants can add new fields and add new options to existing fields in
overridetree.cb but cannot redefine an existing option.
Devices can have multiple probe tokens, and the device will be considered
to be found if any of them return true.
The output from defining this field are:
1) the various fields and options will be added as macro constants to
static.h and can be used by fw_config for probing.
2) the probe entries will result in a list of fields/options to probe
that is added to the resulting struct device and handled by coreboot.
BUG=b:147462631
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Picasso has an LPC and eSPI bridge on the same PCI DEVFN. They can both
be active at the same time. This adds a way to specify which devices
belong on which bus.
i.e.,
device pci 14.3 on # - D14F3 bridge
device espi 0 on
chip ec/google/chromeec
device pnp 0c09.0 on end
end
end
device lpc 0 on
end
end
BUG=b:154445472
TEST=Built trembyle and saw static.c contained the espi bus.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I0c2f40813c05680f72e5f30cbb13617e8f994841
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Every device belongs to a chip. And we already keep that relation by
inheriting the `.chip_info` pointer if downstream devices don't have
another chip specified. So we can also allow to specify `register`
settings at the device level.
Change-Id: I44e6b95d0cd708fef69b152ebc46b869b2bb9205
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40803
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This CL has changes that allow us to enable a configurable
ramstage, and one change that allows us to minimize PCI
scanning. Minimal scanning is a frequently requested feature.
To enable it, we add two new variables to src/Kconfig
CONFIGURABLE_RAMSTAGE
is the overall variable controlling other options for minimizing the
ramstage.
MINIMAL_PCI_SCANNING is how we indicate we wish to enable minimal
PCI scanning.
Some devices must be scanned in all cases, such as 0:0.0.
To indicate which devices we must scan, we add a new mandatory
keyword to sconfig
It is used in place of on, off, or hidden, and indicates
a device is enabled and mandatory. Mandatory
devices are always scanned. When MINIMAL_PCI_SCANNING is enabled,
ONLY mandatory devices are scanned.
We further add support in src/device/pci_device.c to manage
both MINIMAL_PCI_SCANNING and mandatory devices.
Finally, to show how this works in practice, we add mandatory
keywords to 3 devices on the qemu-q35.
TEST=
1. This is tested and working on the qemu-q35 target.
2. On CML-Hatch
Before CL:
Total Boot time: ~685ms
After CL:
Total Boot time: ~615ms
Change-Id: I2073d9f8e9297c2b02530821ebb634ea2a5c758e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
|
|
Add the new field 'smbios_slot_desc', which takes 2 to 4 arguments.
The field is valid for PCI devices and only compiled if SMBIOS table
generation is enabled.
smbios_slot_desc arguments:
1. slot type
2. slot lenth
3. slot designation (optional)
4. slot data width (optional)
Example:
device pci 1c.1 on
smbios_slot_desc "21" "3" "MINI-PCI-FULL" "8"
end # PCIe Port #2 Integrated Wireless LAN
Tested on Lenovo T520.
Change-Id: If95aae3c322d3da47637613b9a872ba1f7af9080
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32307
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
|
|
For devices supporting both Linux and Windows, we may find some ACPI
devices that only need drivers in Linux and should not even be shown in
Windows Device Manager UI.
The new 'hidden' keyword in device tree 'device' statement allows
devices sharing same driver to call acpi_gen_writeSTA with different
values.
BUG=b:72200466
BRANCH=eve
TEST=Builds and boots properly on device eve
Change-Id: Iae881a294b122d3a581b456285d2992ab637fb8e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/28566
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
This change re-factors the device structure in parse tree to be able
to support multidev devices just like non-multidev devices.
With this change, every device has a bus under it which is the parent
of all devices that fall on the bus. If there are duplicate entries in
the devicetree, then there will be multiple buses under the device and
each bus will have its own set of children.
The tree starts out with a root device which has a root bus under
it. This is a special device which is created statically and its
parent is its own root bus. When parsing the device tree file, devices
get added under the root bus as children.
Since this change re-organizes the way devicetree is represented, it
gets rid of latestchild and next_sibling pointers from struct
device. Also, the tree traversal to generate static.c is changed to
breadth-first walk instead of using the next_sibling.
BUG=b:80081934
TEST=Verified using abuild that all boards compile successfully.
Change-Id: Ic8c8a73a247e8e992ab6b1b2cc3131e06fa2e5a1
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/26800
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Now that chips and devices are treated differently in sconfig, this
change gets rid of struct header and add_header function which were
responsible for maintaining list of headers that need to be added to
static.c.
Instead, struct chip is re-factored into struct chip and
struct chip_instance, where chip is a list of unique chips required by
the mainboard whereas chip_instance is an instance of the chip. One
chip can have multiple instances dependending upon the devices in the
system. Also, struct device is updated to hold a pointer to chip
instance instead of the chip structure. This unique list of chips is
then used to add appropriate headers to static.c
BUG=b:80081934
TEST=Verified using abuild that all boards compile successfully.
Change-Id: I6fccdf7c361b4f55a831195adcda9b21932755aa
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/26739
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change adds a new structure "struct chip" to identify elements of
type chip rather than re-using the structure for device. Until now
chip was treated as a device while generating the parse tree and then
device tree postprocessing skipped over all the chip entries in
children and sibling pointers of device nodes.
With this change, the device tree will only contain struct device in
the parsed tree. It helps by avoiding unnecessary pointers to chip
structure as children or next_sibling and then skipping those elements
in post processing. Every device can then hold a pointer to its chip.
When generating static.c, chip structure is emitted before device
structure to ensure that the device structure has chip within its
scope. Externally, the only visible change in static.c should be the
order in which chip/device elements are emitted i.e. previously all
chips under a particular device were emitted to static.c and then the
devices using those chips. Now, all chips are emitted before all the
devices in static.c
BUG=b:80081934
TEST=Verified that abuild is successful for all boards. Also, verified
that static.c generated for eve, kahlee, scarlet, asrock imb_a180 is
unchanged from before in node definitions.
Change-Id: I255092f527c8eecb144385eb681df20e54caf8f5
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/26720
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This commit adds support for describing USB ports in devicetree.cb.
It allows a USB port location to be described in the tree with
configuration information, and ACPI code to be generated that
provides this information to the OS.
A new scan_usb_bus() is added that will scan bridges for devices so
a tree of ports and hubs can be created.
The device address is computed with a 'port type' and a 'port id'
which is flexible for SOC to handle depending on their specific USB
setup and allows USB2 and USB3 ports to be described separately.
For example a board may have devices on two ports, one with a USB2
device and one with a USB3 device, both of which are connected to an
xHCI controller with a root hub:
xHCI
|
RootHub
| |
USB2[0] USB3[2]
device pci 14.0 on
chip drivers/usb/acpi
register "name" = ""Root Hub""
device usb 0.0 on
chip drivers/usb/acpi
register "name" = ""USB 2.0 Port 0""
device usb 2.0 on end
end
chip drivers/usb/acpi
register "name" = ""USB 3.0 Port 2""
device usb 3.2 on end
end
end
end
end
Change-Id: I64e6eba503cdab49be393465b535e139a8c90ef4
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/26169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Add support for a mmio resource in the devicetree to allow
memory-mapped IO addresses to be assigned to given values.
AMD platforms perform a significant amount of configuration through
these MMIO addresses, including I2C bus configuration.
BUG=b:72121803
Change-Id: I5608721c22c1b229f527815b5f17fff3a080c3c8
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Reviewed-on: https://review.coreboot.org/23319
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Update sconfig lex and yacc files to add support for a new "SPI" device
type in the devicetree. SPI device takes only parameter i.e. chip select
number for the device on the SPI bus.
Re-generate the shipped files for sconfig using flex 2.6.0 and bison
3.0.4 (make CONFIG_SCONFIG_GENPARSER=1). Clean up local paths that leak
into generated files.
BUG=chrome-os-partner:59832
BRANCH=None
TEST=Compiles successfully.
Change-Id: If0831e25b3e4ed87827ad92356d7bf47b6387884
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/18339
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Add support for a basic generic device in the devicetree to bind to a
device that does not have a specific bus, but may need to be described
in tables for the operating system. For instance some chips may have
various GPIO connections that need described but do not fall under any
other device.
In order to support this export the basic 'scan_static_bus()' that can
be used in a device_operations->scan_bus() method to scan for the generic
devices.
It has been possible to get a semi-generic device by using a fake PNP
device, but that isn't really appropriate for many devices.
Also Re-generate the shipped files for sconfig. Use flex 2.6.0 to avoid
everything being rewritten. Clean up the local paths that leak into the
generated configs.
Change-Id: If45a5b18825bdb2cf1e4ba4297ee426cbd1678e3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14789
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
|
|
and re-generate _shipped files
Change-Id: I7a18824d64d3f6212e8566695376bf97e2196ee2
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14733
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
In order to enumerate CPU devices that are non-x86 (read: no lapic)
provide a generic 'cpu' device.
Change-Id: Ifeafdad8076935c3448784e6958117002509acbf
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/6824
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|
|
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>
|
|
This patch adds support for autogenerating the MPTABLE from
devicetree.cb. This is done by a write_smp_table() declared
weak in mpspec.c. If the mainboard doesn't provide it's own
function, this generic implementation is called.
Syntax in devicetree.cb:
ioapic_irq <APICID> <INTA|INTB|INTC|INTD> <INTPIN>
The ioapic_irq directive can be used in pci and pci_domain
devices. If there's no directive, the autogen code traverses
the tree back to the pci_domain and stops at the first device
which such a directive, and use that information to generate the
entry according to PCI IRQ routing rules.
Change-Id: I4df5b198e8430f939d477c14c798414e398a2027
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1138
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Allow user to add 'subsystemid <vendor> <device> [inherit]' to devicetree.cb for
PCI and PCI domain devices.
Example:
device pci 00.0 on
subsystemid dead beef
end
If the user wants to have this ID inherited to all subdevices/functions,
he can add 'inherit', like in the following example:
device pci 00.0 on
subsystemid dead beef inherit
end
If the user don't want to inherit a Subsystem for a single device, he can
specify 'subsystemid 0 0' on this particular device.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6420 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Update generated parser files.
Add proper include path for utils.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5523 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
while others dislike them being extra commits, let's clean them up once and
for all for the existing code. If it's ugly, let it only be ugly once :-)
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5507 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
to avoid clutter in revision history.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5377 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
(smaller, faster, standard parser generator, no more python)
Provide precompiled parser, so bison and flex are optional dependencies.
Adapt Makefile and abuild (which uses some sconfig file as a
magic path) to match.
Drop python as dependency from README, and add bison and flex
as optional dependencies
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5373 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
