| Age | Commit message (Collapse) | Author |
|---|
|
Have acpigen_write_package() return a pointer to the package element
counter so it can be used for dynamic package generation where needed.
Change-Id: Id7f6dd03511069211ba3ee3eb29a6ca1742de847
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15536
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Have the different acpi_device_ path functions use a different static
buffer so they can be called interchangeably.
Change-Id: I270a80f66880861d5847bd586a16a73f8f1e2511
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15521
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Add a function for an SOC to define that will allow it to map the
SOC-specific gpio_t value into an appropriate ACPI pin. The exact
behavior depends on the GPIO implementation in the SOC, but it can
be used to provide a pin number that is relative to the community or
bank that a GPIO resides in.
Change-Id: Icb97ccf7d6a9034877614d49166bc9e4fe659bcf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15512
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Ic42d8490cc02a3907e2989435aab786f7c0f39c9
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15287
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ib0535bf25ce25550cc17f64177f804a70aa13fb3
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15286
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The different entry points (0x100, 0x140, ...), which were defined in
the RISC-V Privileged Specification 1.7, aren't used anymore. Instead
the Spike bootrom jumps at the start of our image, and traps are handled
through mtvec.
Change-Id: I865adec5e7a752a25bac93a45654ac06e27d5a8e
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15283
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Implement writeat and eraseat support into the region_device_ops struct.
Change-Id: Iac2cf32e523d2f19ee9e5feefe1fba8c68982f3d
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/15318
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Correct standard manufacturer's identification code.
Change-Id: I273711e121a61a91176c15cd4cab75420f1f5a39
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/15271
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
There is nothing to backup with RELOCATABLE_RAMSTAGE.
Change-Id: I780a71e48d23e202fb0e9c70e34420066fa0e5b5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15243
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
No boards affected, resume is always allowed when enabled
in the build.
Change-Id: I1816557da8201af9e137c389b57852ec20390b6a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15275
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Some of the support functions will be built for romstage
once HIGH_MEMORY_SAVE is removed.
Change-Id: I43ed9067cf6b2152a354088c1dcb02d374eb6efe
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15242
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
No need to make low memory backup unless we are on
S3 resume path.
Hide those details from ACPI.
Change-Id: Ic08b6d70c7895b094afdb3c77e020ff37ad632a1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15241
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Without RELOCATABLE_RAMSTAGE have WB cache large enough
to cover the greatest ramstage needs, as there is no benefit
of trying to accurately match the actual need. Choose
this to be bottom 16MiB.
With RELOCATABLE_RAMSTAGE write-back cache of low ram is
only useful for bottom 1MiB of RAM as a small part of this gets used
during SMP initialisation before proper MTRR setup.
Change-Id: Icd5f8461f81ed0e671130f1142641a48d1304f30
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15249
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This is where the RAM is (now), on RISC-V.
We need to put coreboot.rom in RAM because Spike (at the moment) only
supports loading code into the RAM, not into the boot ROM.
Change-Id: I6c9b7cffe5fa414825491ee4ac0d2dad59a2d75c
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15149
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Variable name shadows parameter name used on other functions,
and it can be local anyway after function removal.
Change-Id: I3164b15b33d877fef139f48ab2091e60e3124c3b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15240
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Add Ramaxel DRAM manufacturer id.
Tested on Lenovo T520 and DDR3-1600 DIMM (RMT3170eb86e9w16).
The manufacturer name shows up in dmidecode.
Change-Id: I14cdc82c09f0f990e2ba18083748d11d79e53874
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15183
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This is more of ACPI S3 resume and x86 definition than CBMEM.
Change-Id: Iffbfb2e30ab5ea0b736e5626f51c86c7452f3129
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15190
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This Kconfig is deprecated, new platforms need to locate
ramstage stack in CBMEM instead.
Change-Id: I20ece297302321337cc2ce17fdef0c55242a4fc3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15189
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>
|
|
In the default (medlow) code model, pointers are loaded with a lui, addi
instruction sequence:
lui a0, 0xNNNNN
addi a0, a0, 0xNNN
Since lui sign-extends bits 32-63 from bit 31 on RV64, lui/addi can't
load pointers just above 0x80000000, where RISC-V's RAM now lives.
The medany code model gets around this restriction by loading pointers
trough auipc and addi:
auipc a0, 0xNNNNN
addi a0, a0, 0xNNN
This way, any pointer within the current pc ±2G can be loaded, which is
by far sufficient for coreboot.
Change-Id: I77350d9218a687284c1337d987765553cf915a22
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15148
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The uart8250mem driver needs it.
Change-Id: I09e6a17cedf8a4045f008f5a0d225055d745e8db
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15147
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I12de8f82499074f0fbbc1c09210b00c6a9614c1b
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15146
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I9759771fa6fc708d7d97509c5f5e0cefb8ab4c96
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/14962
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Not all x86 architectures support the mm register set. The default
routine that saves BIST in mm0 and a "weak" routine that saves the TSC
value in mm2:mm1. Select the Kconfig value
BOOTBLOCK_SAVE_BIST_AND_TIMESTAMP to provide a replacement routine to
save the BIST and timestamp values.
TEST=Build and run on Amenia and Galileo Gen2.
Change-Id: I8119e74664ac3522c011767d424d441cd62545ce
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15126
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Use Kconfig values to enable debug spinloops in assembly_entry.S. This
makes it easy to debug the assembly code.
TEST=Build and run on Galileo Gen2
Change-Id: Ic56bf2260b8e3181403623961874c9289f3ca945
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15135
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Conditionally add a debug spinloop to enable easy connection of JTAG
debuggers.
TEST=Build and run on Galileo Gen2 with a JTAG debugger.
Change-Id: I7a21f9e6bfb10912d06ce48447c61202553630d0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15127
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Support ROM_SIZE greater than 16 MiB. Work around SMBIOS rom size
limitation of 16 MiB by specifying 16 MiB as the ROM size.
TEST=Build and run on neoncity
Change-Id: I3f464599cd8a1b6482db8b9deab03126c8b92128
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15108
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Don't write reserved bits in the Quark platform. Follow the previous
boot behavior and just enable SSE.
TEST=Build and run on Galileo Gen2
Change-Id: Ib3143eff02b2610b595bd666c10d70e43103ccda
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15128
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Leave it for the platform to fill in the string.
Change-Id: I7b4fe585f8d1efc8c9743f0d8b38de1f98124aab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14996
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
The recent ACPI specification extensions have formally defined a
method for describing device information with a key=value format that
is modeled after the Devicetree/DTS format using a special crafted
object named _DSD with a specific UUID for this format.
There are three defined Device Property types: Integers, Strings, and
References. It is also possible to have arrays of these properties
under one key=value pair. Strings and References are both represented
as character arrays but result in different generated ACPI OpCodes.
Various helpers are provided for writing the Device Property header
(to fill in the object name and UUID) and footer (to fill in the
property count and device length values) as well as for writing the
different Device Property types. A specific helper is provided for
writing the defined GPIO binding Device Property that is used to allow
GPIOs to be referred to by name rather than resource index.
This is all documented in the _DSD Device Properties UUID document:
http://uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
This will be used by device drivers to provide device properties that
are consumed by the operating system. Devicetree bindings are often
described in the linux kernel at Documentation/devicetree/bindings/
A sample driver here has an input GPIO that it needs to describe to
the kernel driver:
chip.h:
struct drivers_generic_sample_config {
struct acpi_gpio mode_gpio;
};
sample.c:
static void acpi_fill_ssdt_generator(struct device *dev) {
struct drivers_generic_sample_config *config = dev->chip_info;
const char *path = acpi_device_path(dev);
...
acpi_device_write_gpio(&config->mode_gpio);
...
acpi_dp_write_header();
acpi_dp_write_gpio("mode-gpio", path, 0, 0, 0);
acpi_dp_write_footer();
...
}
devicetree.cb:
device pci 1f.0 on
chip drivers/generic/sample
register "mode_gpio" = "ACPI_GPIO_INPUT(GPP_B1)"
device generic 0 on end
end
end
SSDT.dsl:
Name (_CRS, ResourceTemplate () {
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionInputOnly,
"\\_SB.PCI0.GPIO", 0, ResourceConsumer) { 25 }
})
Name (_DSD, Package () {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"mode-gpio", Package () { \_SB.PCI0.LPCB, 0, 0, 1 }}
}
})
Change-Id: I93ffd09e59d05c09e38693e221a87085469be3ad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14937
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add required definitions to describe an ACPI SPI bus and a method to
write the SpiSerialBus() descriptor to the SSDT.
This will be used by device drivers to describe their SPI resources to
the OS. SPI devices are not currently enumerated in the devicetree but
can be enumerated by device drivers directly.
generic.c:
void acpi_fill_ssdt_generator(struct device *dev) {
struct acpi_spi spi = {
.device_select = dev->path->generic.device.id,
.device_select_polarity = SPI_POLARITY_LOW,
.spi_wire_mode = SPI_4_WIRE_MODE,
.speed = 1000 * 1000; /* 1 mHz */
.data_bit_length = 8,
.clock_phase = SPI_CLOCK_PHASE_FIRST,
.clock_polarity = SPI_POLARITY_LOW,
.resource = acpi_device_path(dev->bus->dev)
};
...
acpi_device_write_spi(&spi);
...
}
devicetree.cb:
device pci 1e.2 on
chip drivers/spi/generic
device generic 0 on end
end
end
SSDT.dsl:
SpiSerialBus (0, PolarityLow, FourWireMode, 8, ControllerInitiated,
1000000, ClockPolarityLow, ClockPhaseFirst,
"\\_SB.PCI0.SPI0", 0, ResourceConsumer)
Change-Id: I0ef83dc111ac6c19d68872ab64e1e5e3a7756cae
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14936
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add required definitions to describe an ACPI I2C bus and a method to
write the I2cSerialBus() descriptor to the SSDT.
This will be used by device drivers to describe their I2C resources to
the OS. The devicetree i2c device can supply the address and 7 or 10
bit mode as well as indicate the GPIO controller device, and the bus
speed can be fixed or configured by the driver.
chip.h:
struct drivers_i2c_generic_config {
enum i2c_speed bus_speed;
};
generic.c:
void acpi_fill_ssdt_generator(struct device *dev) {
struct drivers_i2c_generic_config *config = dev->chip_info;
struct acpi_i2c i2c = {
.address = dev->path->i2c.device,
.mode_10bit = dev->path.i2c.mode_10bit,
.speed = config->bus_speed ? : I2C_SPEED_FAST,
.resource = acpi_device_path(dev->bus->dev)
};
...
acpi_device_write_i2c(&i2c);
...
}
devicetree.cb:
device pci 15.0 on
chip drivers/i2c/generic
device i2c 10.0 on end
end
end
SSDT.dsl:
I2cSerialBus (0x10, ControllerInitiated, 400000, AddressingMode7Bit,
"\\_SB.PCI0.I2C0", 0, ResourceConsumer)
Change-Id: I598401ac81a92c72f19da0271af1e218580a6c49
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14935
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add definitions to describe GPIOs in generated ACPI objects and a
method to write a GpioIo() or GpioInt() descriptor to the SSDT.
ACPI GPIOs have many possible configuration options and a structure
is created to describe it accurately in ACPI terms. There are many
shared descriptor fields between GpioIo() and GpioInt() so the same
function can write both types.
GpioInt shares many properties with ACPI Interrupts and the same types
are re-used here where possible. One addition is that GpioInt can be
configured to trigger on both low and high edge transitions.
One descriptor can describe multiple GPIO pins (limited to 8 in this
implementation) that all share configuration and controller and are
used by the same device scope.
Accurately referring to the GPIO controller that this pin is connected
to requires the SoC/board to implement a function handler for
acpi_gpio_path(), or for the caller to provide this directly as a
string in the acpi_gpio->reference variable.
This will get used by device drivers to describe their resources in
the SSDT. Here is a sample for a Maxim 98357A I2S codec which has a
GPIO for power and channel selection called "sdmode".
chip.h:
struct drivers_generic_max98357a_config {
struct acpi_gpio sdmode_gpio;
};
max98357a.c:
void acpi_fill_ssdt_generator(struct device *dev) {
struct drivers_generic_max98357a_config *config = dev->chip_info;
...
acpi_device_write_gpio(&config->sdmode_gpio);
...
}
devicetree.cb:
device pci 1f.3 on
chip drivers/generic/max98357a
register "sdmode_gpio" = "ACPI_GPIO_OUTPUT(GPP_C5)"
device generic 0 on end
end
end
SSDT.dsl:
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.PCI0.GPIO", 0, ResourceConsumer, ,) { 53 }
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ibf5bab9c4bf6f21252373fb013e78f872550b167
Reviewed-on: https://review.coreboot.org/14934
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add definitions for ACPI device extended interrupts and a method to
write an Interrupt() descriptor to the SSDT output stream.
Interrupts are often tied together with other resources and some
configuration items are shared (though not always compatibly) with
other constructs like GPIOs and GPEs.
These will get used by device drivers to write _CRS sections for
devices into the SSDT. One usage is to include a "struct acpi_irq"
inside a config struct for a device so it can be initialized based
on settings in devicetree.
Example usage:
chip.h:
struct drivers_i2c_generic_config {
struct acpi_irq irq;
};
generic.c:
void acpi_fill_ssdt_generator(struct device *dev) {
struct drivers_i2c_generic_config *config = dev->chip_info;
...
acpi_device_write_interrupt(&config->irq);
...
}
devicetree.cb:
device pci 15.0 on
chip drivers/i2c/generic
register "irq" = "IRQ_EDGE_LOW(GPP_E7_IRQ)"
device i2c 10 on end
end
end
SSDT.dsl:
Interrupt (ResourceConsumer, Edge, ActiveLow, Exclusive,,,) { 31 }
Change-Id: I3b64170cc2ebac178e7a17df479eda7670a42703
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14933
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
When CONFIG_C_ENVIRONMENT_BOOTBLOCK is employed there's no need for
a chipset specific verstage entry point because cache-as-ram has
already been initialized. Therefore, provide a default entry point
for verstage in that environment.
Change-Id: Idd8f45bd58d3e5b251d1e38cca7ae794b8b77a28
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14971
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
Some exceptions (like from calling a NULL function pointer) are easier
to narrow down with a dump of the call stack. Let's take a page out of
ARM32's book and add that feature to ARM64 as well. Also change the
output format to two register columns, to make it easier to fit a whole
exception dump on one screen.
Applying to both coreboot and libpayload and syncing the output format
between both back up.
Change-Id: I19768d13d8fa8adb84f0edda2af12f20508eb2db
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14931
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add a function to "struct device_operations" to return the ACPI name
for the device, and helper functions to find this name (either from
the device or its parent) and to build a fully qualified ACPI path
from the root device.
This addition will allow device drivers to generate their ACPI AML in
the SSDT at boot, with customization supplied by devicetree.cb,
instead of needing custom DSDT ASL for every mainboard.
The root device acpi_name is defined as "\\_SB" and is used to start
the path when building a fully qualified name.
This requires SOC support to provide handlers for returning the ACPI
name for devices that it owns, and those names must match the objects
declared in the DSDT. The handler can be done either in each device
driver or with a global handler for the entire SOC.
Simplified example of how this can be used for an i2c device declared
in devicetree.cb with:
chip soc/intel/skylake # "\_SB" (from root device)
device domain 0 on # "PCI0"
device pci 19.2 on # "I2C4"
chip drivers/i2c/test0
device i2c 1a.0 on end # "TST0"
end
end
end
end
And basic SSDT generating code in the device driver:
acpigen_write_scope(acpi_device_scope(dev));
acpigen_write_device(acpi_device_name(dev));
acpigen_write_string("_HID", "TEST0000");
acpigen_write_byte("_UID", 0);
acpigen_pop_len(); /* device */
acpigen_pop_len(); /* scope */
Will produce this ACPI code:
Scope (\_SB.PCI0.I2C4) {
Device (TST0) {
Name (_HID, "TEST0000")
Name (_UID, 0)
}
}
Change-Id: Ie149595aeab96266fa5f006e7934339f0119ac54
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14840
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
acpigen_write_uuid() will generate a ToUUID() 128-bit buffer object for a
common universally unique identifier that is passed as a string. The
resulting buffer is the UUID in byte format with a specific order of the
bytes as described in the ACPI specification:
ToUUID (uuid)
Compiles to:
Buffer (16) { uuid[3], uuid[2], uuid[1], uuid[0], uuid[5], uuid[4],
uuid[7], uuid[6], uuid[8], uuid[9], uuid[10], uuid[11],
uuid[12], uuid[13], uuid[14], uuid[15] }
Change-Id: Ibbeff926883532dd78477aaa2d26ffffb6ef30c0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14838
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
timestamp.c was not included in bootblock and postcar. This means that
these two stages would use the weak implementation in lib/timestamp.c
instead of the arch-specific implementation based on rdtsc.
This resulted in using timer_monotonic_get() which resets the
timestamps from 0. timer_monotonic_get() only provides per-stage
incrementing semantics on x86 because lapic implementation has
counting down values. A globally incrementing counter like rdtsc
provides the semantics like every other non-x86.
On the test configuration, the weak implementation of timestamp_get()
returned zero, resulting in wrong timestamps coming from the bootblock,
while romstage and ramstage used the arch implementation and returned
correct timestamps.
This is a great example of why weak functions are dangerous, and how
easy it is to miss subtle yet strong interactions between subsystems
and the coreboot buildsystem.
Change-Id: I656f9bd58a6fc179d9dbbc496c5b684ea9288eb5
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14860
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
strlen(string) was on the "negative" side of the selection operator, the
side where string is NULL.
Change-Id: Ic421a5406ef788c504e30089daeba61a195457ae
Reported-by: Coverity Scan (CID 1355263)
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/14867
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
|
|
Add helper functions for generating some common objects:
acpigen_write_STA(status) will generate a status method that will
indicate the device status as provided:
Method (_STA) { Return (status) }
Full status byte configuration is possible and macros are provided for
the common status bytes used for generated code:
ACPI_STATUS_DEVICE_ALL_OFF = 0x0
ACPI_STATUS_DEVICE_ALL_ON = 0xF
acpigen_write_PRW() will generate a Power Resoruce for Wake that describes
the GPE that will wake a particular device:
Name (_PRW, Package (2) { wake, level }
Change-Id: I10277f0f3820d272d3975abf34b9a8de577782e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14795
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
In order to produce smaller AML and not rely on the caller to size the
output type appropriately add a helper function that will output an
appropriately sized integer.
To complete this also add helper functions for outputting the single
OpCode for Zero and One and Ones.
And finally add "name" variants of the helpers that will output a
complete sequence like "Name (_UID, Zero)".
Change-Id: I7ee4bc0a6347d15b8d49df357845a8bc2e517407
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14794
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add helper function to emit a string into the SSDT AML bytestream with a
NULL terminator. Also add a helper function to emit the string OpCode
followed by the string itself.
acpigen_emit_string(string) /* Raw string output */
acpigen_write_string(string) /* OpCode followed by raw string */
Change-Id: I4a3a8728066e0c41d7ad6429fad983e6ae6962fe
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14793
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Add helpers for writing word and dword values in acpigen and use them
throughout the file to clean things up:
acpigen_emit_word - write raw word
acpigen_emit_dword - write raw dword
acpigen_write_word - write word opcode and value
Change-Id: Ia758d4dd25d0ae5b31be7d51b33866dddd96a473
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14792
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
BRANCH=none
BUG=chrome-os-partner:51537
TEST=build pass
Change-Id: Id3dd3a553370eada1e79708dc71afc2d94d6ce93
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0949b0d9ec12eff7edb3d7de738833f29507c332
Original-Change-Id: I8052f86d4d846e5d544911c5b9e323285083fb5c
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/340024
Original-Commit-Ready: Vadim Bendebury <vbendeb@google.com>
Original-Tested-by: Shunqian Zheng <zhengsq@rock-chips.com>
Original-Reviewed-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-on: https://review.coreboot.org/14747
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I5373be7ab55ac3c4f2e4dd753c6ad8e91712ff7e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14738
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
BUG=chrome-os-partner:49249
TEST=None. Initial code not sure if it will even compile
BRANCH=none
Change-Id: Ib0fccfe2d103710c006cb3950c65b11b8d596912
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9be5f58bb89ec43d4eb264c94c3f745dcade35dd
Original-Change-Id: If50efb55d4974dfcab07d3ae6488c2413b505a1f
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333301
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14657
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins)
|
|
It's unused.
Change-Id: I50af2b50d2c5a7a24afe9099c5c01d17ce54a6c9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14569
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
It isn't used anymore.
Change-Id: Ie554d1dd87ae3f55547466e484c0864e55c9d102
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14567
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The skylake-based Chromebooks use a separate verstage which runs
just after bootblock and prior to romstage. The normal path for
romstage would be to reload the gdt, however in the previously
described scenario has verstage performing that work. Therefore,
provide that path under those conditions. The only difference
from the C_ENVIRONMENT_BOOTBLOCK scenario is that the stack
should not be reloaded since there's no way to know the top
of the stack.
Change-Id: Ic39ab52a856233d3042ac02a15ae4816ddfe07c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14548
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
|
|
The path that just clears CAR_GLOBAL variables and jumps
to the stage entry point needs another condition for
separate verstage just after bootblock. However, the
current conditional is a negative conditional so
swap the logic around to make it easier to extend.
Change-Id: Iab6682498054715a6eaa0476390da6355238b9bc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14547
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
|
