1. Make the xHCI driver to support xHCI controller v1.1
2. And a new function xhci_ring_doorbell(), it aims to
add a memory barrier before ring the doorbell, ensure
all TRB changes are written to memory.
BRANCH=none
BUG=chrome-os-partner:52684
TEST=boot from USB on Kevin rk3399 platform
Change-Id: I4e38e04dc3c7d32ee4bb424a473c70956a3c3ea9
Signed-off-by: Liangfeng Wu <wulf@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/346831
Commit-Ready: Brian Norris <briannorris@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
From the User-Level ISA Specification v2.0:
"We do not mandate atomicity for misaligned accesses so simple
implementations can just use a machine trap and software handler to
handle misaligned accesses." ( http://riscv.org/specifications/)
Spike traps on unaligned accesses.
Change-Id: Ia57786916f4076cc08513f4e331c2deec9cfa785
Original-Signed-off-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Original-Reviewed-on: https://review.coreboot.org/14983
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry-picked from commit 4acb0e7742)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348411
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
MMIO region of 256 KiB under 4 GiB is not decoded by SPI controller
by hardware design. Current code incorrectly specifies size of that
region to be 128 KiB. This change corrects the value to 256 KiB.
Change-Id: Idcc67eb3565b800d835e75c0b765dd49d1656938
Original-Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14979
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry-picked from commit 204af8157d)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348409
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This adds the website URL to the board info and also enables
the realtek nic reset function as per a previous patch.
Change-Id: I2cda120c59b55f0dd2ffa78d397b16beb13d6843
Original-Signed-off-by: Damien Zammit <damien@zamaudio.com>
Original-Reviewed-on: https://review.coreboot.org/14954
Original-Reviewed-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit b28a411362)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348408
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
One thing that is vital to this patch is the MAC address setting
in case the EEPROM/efuse is unconfigured.
Linux now recognises the default MAC address on GA-G41M-ES2L which
does rely on the default bios settings for the MAC address.
Change-Id: I32e070b545b4c6369686a7087b7ff838d00764e3
Original-Signed-off-by: Damien Zammit <damien@zamaudio.com>
Original-Reviewed-on: https://review.coreboot.org/14927
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit e983f0cb4b)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348407
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This patch adds DMI/EP init to the board and fixes
a couple of minor things.
Change-Id: I10d0f6ce747b60499680e4dc229b7fcbb16cc039
Original-Signed-off-by: Damien Zammit <damien@zamaudio.com>
Original-Reviewed-on: https://review.coreboot.org/14926
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit 2abd3f9e1c)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348406
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The values were obtained from vendor bios at runtime.
I am not 100% sure of the sequence required to initiate them,
but guessed from the gm45 code. There may be some status bytes
needed to be polled during the sequence that is missing,
but as I don't have bios writer's datasheet it's very hard
for me to know.
Change-Id: Idd205e0bab5f75e01c6e3a5dc320c08639f52db8
Original-Signed-off-by: Damien Zammit <damien@zamaudio.com>
Original-Reviewed-on: https://review.coreboot.org/14925
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit a090ae04c2)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348405
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Previously, due to a bug in devicetree and incorrect IRQ
settings in ACPI, SATA controller would not initialize
any HDDs in the OS, even though it worked in SeaBIOS.
The devicetree setting is not needed because SATA must
function in plain mode on this board, as combined mode
does not work at all.
Change-Id: I0036c4734de00b84cc3d64f38e4b1fd80fd1a25d
Original-Signed-off-by: Damien Zammit <damien@zamaudio.com>
Original-Reviewed-on: https://review.coreboot.org/14776
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit 2b2f465fcb)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348404
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Add a PCI driver for the skylake SD card device and have it generate
an entry in the SSDT for the card detect GPIO if it is provided by the
mainboard in devicetree.
This sets up a card detect GPIO configuration that will trigger an
interrupt on both edges with a 100ms debounce timeout and can wake the
SD controller from D3 state.
The GpioInt() entry is bound to the cd-gpio device property which will
be consumed by the kernel driver.
The resulting ACPI output in the SSDT will be combined with the SDXC
device declaration in the DSDT.
Example:
Scope (\_SB.PCI0.SDXC)
{
Name (_CRS, ResourceTemplate () {
GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 10000,
\_SB.PCI0.GPIO, 0, ResourceConsumer) { 35 }
})
Name (_DSD, Package () {
ToUUID (daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
Package () {
Package () { cd-gpio, Package () { \_SB.PCI0.SDXC, 0, 0, 1 } }
}
})
}
Change-Id: Ie4c1bfadd962cf55a987edb9ef86e92174205770
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14995
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry-picked from commit b25a45ca46)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348403
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Minor cleanups in pci_devs.h for indentation and newlines to be
consistent throughout the file.
Change-Id: I522df141a6b33d918cfb3de1b9019c0c4a73e3e5
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14994
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry-picked from commit 98d69c0627)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348402
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Add the Audio DSP device for skylake as a PCI driver with a static
scan_bus handler so generic devices can be declared under it.
This is for devices like the Maxim 98357A which is connected on the
I2S bus for data but has no control channel bus and instead just has
a GPIO for channel selection and power down control and needs to
describe that GPIO connection to the OS via ACPI.
Change-Id: Iae02132ff9c510562483108ab280323f78873afd
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14993
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry-picked from commit 026003e621)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348401
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Add the I2C devices to skylake with the scan_bus handler for SMBUS
devices so that I2C-based devices can be declared in devicetree.cb
and get initialized properly during ramstage.
This does not yet provide the I2C driver, but it allows for devices
that are declared in devicetree.cb to provide ACPI tables to the OS.
Change-Id: I9dfe4a06a8b0bc549a2b0e2d7c033c895188ba30
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14992
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry-picked from commit 0d8bb7427b)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348400
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Add the GPE header file to skylake chip.h so the SOC-defined macros
for the various GPE values can be used in devicetree directly.
For example:
chip drivers/i2c/touchpad
register wake = GPE0_DW0_05
device i2c 15.0 on end
end
Change-Id: Ic322108561b34aa34a24a4daba6ba7a4f7a3f9a4
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14991
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry-picked from commit 011533e4c3)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348329
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The ASUS KGPE-D16/KCMA-D8 have an on-board header for a second RS-232
serial port, however it is disabled by default due to the SuperIO
default pin mux settings. Enable the secondary serial port early
in romstage to allow use during / after initial boot.
Change-Id: I5b83659dd8b0d6af559c9ceccee55c4cc2f17165
Original-Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Original-Reviewed-on: https://review.coreboot.org/14892
Original-Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
(cherry-picked from commit ca543396a7)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348327
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Since the sd card cmd, data, cd lines are configured
as native mode, allow the native controller to control
the termination.
Configure SDCARD_CLK_FB which is used for calibrating the
timing of the actual clock buffer.
BUG==chrome-os-partner:53747
TEST=verify sd card detection
Change-Id: I56611826afb4fb32fefa7f1e4ba19ca4f30ba578
Signed-off-by: Abhay Kumar <abhay.kumar@intel.com>
Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/348377
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add APU1 prefix because Kconfig throws errors if we try to
define the same variables as choice-entry for APU2 board.
Change-Id: Ic071600dd88e391a8a278d63aad13abd01fd3c9d
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14988
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://chromium-review.googlesource.com/348214
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
After we skip the bytes we send, the fifo pointer is at
right position. Reseting the fifo will change it to a
wrong place.
Please view the flashrom code, which tells the same thing.
https://code.coreboot.org/p/flashrom/source/tree/HEAD/trunk/sb600spi.c#L257
Change-Id: I31d487ce32c0d7ca3dead36d2b14611e73b1ad60
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/14955
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/348213
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Certain mainboards require SuperIO pinmux configuration before
peripherals will become operational. Allow each mainboard to
configure the pinmux(es) of Winbond chips if needed.
Change-Id: Ice19f8d8514b66b15920a5b893700d636ed75cec
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/14960
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://chromium-review.googlesource.com/348211
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This avoids re-declaring common macros like ARRAY_SIZE, MIN, MAX and
ALIGN. Also removes the issues around including both files in any
tool.
Also, fix comparison error in various files by replacing int with
size_t.
Change-Id: I06c763e5dd1bec97e8335499468bbdb016eb28e5
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14978
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348210
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
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>
Reviewed-on: https://chromium-review.googlesource.com/348019
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@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>
Reviewed-on: https://chromium-review.googlesource.com/348018
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Tested-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>
Reviewed-on: https://chromium-review.googlesource.com/348017
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Tested-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>
Reviewed-on: https://chromium-review.googlesource.com/348016
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Tested-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>
Reviewed-on: https://chromium-review.googlesource.com/348015
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Chrome OS builds always have some inherent differences to "standard"
libpayload configurations: they don't want to use curses or things like
storage drivers, they always use the coreboot framebuffer and USB, etc.
This patch reintroduces CONFIG_LP_CHROMEOS as an option that only
affects Kconfig defaults. This allows Chrome OS builds to select most of
what they need in one go and reduces board-specific .config files to
only the options that are really specific to that board.
Also restricts the 8250_SERIAL_CONSOLE Kconfig to only default to yes on
x86 boards, which probably makes sense for all of libpayload (some but
far from all ARM boards use 8250-compatible UARTs, and we should
probably not default a platform option unless it's going to be correct
with very high probability).
BRANCH=None
BUG=None
TEST=Built and booted Jerry and Oak.
Change-Id: I609637cd2ea7dfb4558aa3c04c90b64038c9ab57
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347970
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently every non-x86 platform supported by libpayload needs to
provide its own timer driver. Most of the ones we have accumulated there
look almost identical: For the frequency, return a preset constant. For
the value, read a 32-bit register, possibly read another 32-bit register
and shift+OR it with the previous one, then return that.
Let's replace this with a single .c file that can easily handle all of
those cases. Menuconfig convenience can still be maintained by providing
several presets that select different defaults for the driver's
configuration options (register address(es) and frequency).
Removes an "enabled" check from Samsung MCT driver since coreboot always
unconditionally enables that timer anyway.
CQ-DEPEND=CL:344809
BRANCH=None
BUG=None
TEST=Booted Oak and Veyron, observed how dev-mode delay was still ~30s
Change-Id: I9784e7c6aa5abd6d92478ea7ec1cf42c9a437546
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347749
Depending on which options are selected there needs to be certain
functions supplied. However, the spi, mmap_boot, and tsc_freq modules
were not included in the SMM builds. Fix the omission.
BUG=None
BRANCH=None
TEST=None
Change-Id: I25ab42886cfd46770ce0f4beee65f2f4d15649f3
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14977
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347985
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
An updated descriptor expands the BIOS region while descreasing
the 'device expansion region' utilized by the CSE. Update the
end region marker to reflect this new size as well as the
chromeos.fmd file which needs to be adjusted for logical boot
parition 2 requirement which resides halfway through the BIOS
region. The GBB was moved and shunk to accommodate the change.
BUG=None
BRANCH=None
TEST=None
Change-Id: I7baa5282d7c608af648b5773c4dfa123060a6e45
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14974
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Original-Tested-by: build bot (Jenkins)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347984
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
There previously was no support for building verstage on apollolake.
Add that suport by linking in the appropriate modules as well as
providing vboot_platform_is_resuming(). The link address for verstage
is the same as FSP-M because they would never be in CAR along side
each other. Additionally, program the ACPI I/O BAR and enable decoding
so sleep state can be determined for early firmware verification.
BUG=None
BRANCH=None
TEST=None
Change-Id: I1a0baab342ac55fd82dbed476abe0063787e3491
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14972
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347982
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@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.
BUG=None
BRANCH=None
TEST=None
Change-Id: Idd8f45bd58d3e5b251d1e38cca7ae794b8b77a28
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14971
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347981
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This patch enable and configure the clocks and IOMUX for i2s audio path,
and the i2s0 clock is from CPLL.
Please refer to TRM V0.3 Part 1 Chapter 3 CRU, P126/P128/P144/P154/P155
for the i2s clock div and gate setting.
BRANCH=none
BUG=chrome-os-partner:52172
TEST=boot kevin rev1, press ctrl+u and hear the beep voice.
Change-Id: I130a874a0400712317e5e7a8b3b10a6f04586f68
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/347526
Commit-Ready: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Since fit.c is the only caller of this function move it out of common.c
and into fit.c.
BUG=None
BRANCH=None
TEST=None
Change-Id: I64cc31a6d89ee425c5b07745ea5ca9437e2f3fcf
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://review.coreboot.org/14949
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347750
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
By design, FSP will send POST codes to port 80. In this case we have
both coreboot and FSP pushing post codes, which may make debugging
harder. In order to get a clear picture of where FSP execution begins
and ends, send post codes before and after any call to the FSP blobs.
Note that sending a post code both before and after is mostly useful
on chromeec enabled boards, where the EC console will provide a
historic list of post codes.
BUG=None
BRANCH=None
TEST=None
Change-Id: Icfd22b4f6d9e91b01138f97efd711d9204028eb1
Original-Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14951
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347589
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The NB_DEV_ROOT macro, is almost unreadable, as it depends on other
stringified macros, and acts differently depending on the coreboot
stage. For ramstage, it also hides a function call.
Rewrite the macro in terms of more basic and readable macros.
BUG=None
BRANCH=None
TEST=None
Change-Id: I9b7071d67c8d58926e9b01fadaa239db1120448c
Original-Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14890
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347587
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
memmap.c functionality is designed to be used in more than ramstage.
Therefore, it cannot use ramstage-specific APIs. In this case, the
SIMPLE_DEVICE API offers a more consistent behavior across stages.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ic381fe1eb773fb0a5fb5887eb67d2228d2f0817d
Original-Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14953
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347586
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
