Instead of relying on CONFIG_MAX_CPUS to be the number of
CPUs running a platform pass the number of online cpus
from coreboot secmon. That allows for actually enabled
CPUs < CONFIG_MAX_CPUS.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Booted SMP kernel.
Change-Id: Ice10b8ab45bb1190a42678e67776846eec4eb79a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227529
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The struct cpu_action already tracks entry/arg pointers. Use that
instead of duplicating the same information.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and booted.
Change-Id: I4070ef0df19bb1141a1a47c4570a894928d6a5a4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227549
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The current implementation of secmon assumes just entry/arg
are passed to secmon for starting up a CPU. That's lacking
in flexibility. Therefore change secmon_params to contain
both the BSP and secondary CPUs' entry/arg information.
That way more information can be added to secmon_params when
needed.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and booted SMP kernel using PSCI and spin table.
Change-Id: Iafb82d5cabc806b6625799a6b3dff8d77bdb27e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227548
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
There is state within the system that relies on having
all CPUs present in order to proceed with initialization.
The current expectation is that all CPUs are online and
entering the secure monitor. Therefore, wait until all
CONFIG_MAX_CPUs show up.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Can get all CPUs up in kernel using PSCI.
Change-Id: Ia0f744c93766efc694b522ab0af9aedf7329ac43
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227547
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The arch_run_on_all_cpus[_async]() APIs can run the BSP before
the APs if the BSP's id is less than the APs' ids. Fix this by
ensuring we run the necessary callback on all but self.
BUG=chrome-os-partner:33532
BRANCH=None
TEST=Booted spin table kernel. All CPUs are up.
Change-Id: I87e944f870105dbde33b5460660c96c93c3cdf93
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227488
Tested-by: David Riley <davidriley@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
slowly raise to max cpu voltage to prevent overshoot,
and in our experience,when cpu run in 1.8GHz,the
vdd_cpu must up to 1.4V
BUG=chrome-os-partner:32716, chrome-os-partner:31896
TEST=Boot on veyron_pinky rev2,check the rk808 buck1 voltage 1400mv
and measure the overshoot is 1440mv
Change-Id: I9bb739b49ae4b4f7a60133fa38b0fe51b95c0d78
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/226753
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
this adds a driver for vboot to read and write nvdata in spi flash.
it's assumed that flash contents are erased to 1-bits and write
operations can only change 1-bits to 0-bits.
when all nvram space is used, the driver will erase the whole block
and start the next write from the beginning.
BUG=chrome-os-partner:32774
BRANCH=ToT
TEST=Built for cosmos.
Change-Id: Ia9049f342b21fa4c289cb7b9254ab89ec1ef1699
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226525
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use timestamp region instead of storing timestamps in local data structures
before cbmem is up.
BUG=None
BRANCH=None
TEST=cbmem -t reports correct timestamps on rambi(for both normal boot and
suspend/resume).
Change-Id: I4cce22514041edc7808278d45eac4370a2bf0810
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/226421
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Use timestamp region instead of storing timestamps in local data structures
before cbmem is up
BUG=None
BRANCH=None
TEST=Compiles successfully for Auron and Samus. cbmem -t reports correct
timestamps on auron(for both normal boot and suspend/resume)
Change-Id: Ib70a3632c2034963c819c1bb90a3cdb2d7d9c355
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/226420
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Use timestamp region instead of storing timestamps in local variables before
cbmem is up.
BUG=None
BRANCH=None
TEST=cbmem -t reports correct timestamps on falco and peppy (for both normal
boot and suspend/resume).
Change-Id: If5883721553090f51c0bfcb5677aad55c54f82b3
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/226362
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Add a region TIMESTAMP to store all the timestamps starting from bootblock to
end of romstage. At the end of romstage take all the timestamps in TIMESTAMP
region and put it into cbmem
BUG=chrome-os-partner:32973
BRANCH=None
TEST=Compiles successfully and cbmem -t prints all timestamps
Change-Id: I856564de80589bede660ca6bc1275193f8a2fa4b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/223110
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Add support for:
1) Using timestamps in bootblock and verstage
2) Allowing the timestamps to be stashed into _timestamp region so that they can
be used across multiple stages
3) Performing operations over the timestamps in _timestamp region
Instead of having two separate APIs for stashing and adding timestamps, let the
timestamp library decide on its own where to save depending on timestamp cache
status. Now the sequence of operations would be something like:
timestamp_init / timestamp_early_init : Set the base time
timestamp_add / timestamp_add_now
cbmem_initialize : It internally calls timestamp_sync
timestamp_add / timestamp_add_now
BUG=chrome-os-partner:32973
BRANCH=None
TEST=Compiles successfully for ryu and samus. cbmem -t on ryu works fine.
Change-Id: Ie5ffda3112d626068bd1904afcc5a09bc4916d16
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/224024
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
This region is used to store the timestamps from bootblock and verstage when
cbmem is not yet initialized. Once cbmem is setup, the timestamps from this
region can be retrieved and filled up properly in cbmem. In order to achieve
this a new Kconfig option is introduced HAS_TIMESTAMP_REGION. This is to
maintain compatbility with older boards which do not use this region.
BUG=chrome-os-partner:32973
BRANCH=None
TEST=cbmem -t and verified timestamps on ryu
Change-Id: I4d78653c0595523eeeb02115423e7fecceea5e1e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/223348
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
This code change is trying to avoid system hang due to "no enough MTRRs"
This is based on https://chromium-review.googlesource.com/174653
BUG=chrome-os-partner:33417
BRANCH=None
TEST=compile ok, make sure MTRRs are enough for memory regions.
Check 4GiB memory usage by cat /proc/meminfo
Change-Id: Ide8177577314fddceaf20e14615b745d888b3743
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/226511
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Add a section .illegal_globals to romstage and check that the section does not
contain any variables while creating romstage.
BUG=None
BRANCH=None
TEST=Compiles for falco and boots to kernel. No size change for romstage with
and without this check.
Change-Id: Ib2ac0c9b8106547f286f5202682a431e2ce886f9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/226190
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
With EVT2 systems GPIO9 is now used for touchpad wake.
BUG=chrome-os-partner:32232
BRANCH=samus
TEST=suspend/resume by touchpad on samus, with kernel workaround
to disable setting of T19 in atmel driver mxt_suspend()
51 | 2014-11-03 12:41:34 | ACPI Enter | S3
52 | 2014-11-03 12:41:37 | ACPI Wake | S3
53 | 2014-11-03 12:41:37 | Wake Source | GPIO | 9
Change-Id: I8120747986e694b64d464826f87c9afa68af157a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227157
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We don't want segment for .car.data section to be considered while elf_to_stage
transformation is being done. Thus, use -S option for add-stage. With this
change in place, we can get rid of the Forbidden global variable check in x86
Makefile to ensure that no data / bss section is present in romstage.
BUG=None
BRANCH=None
TEST=Compiles for falco and boots to kernel prompt
Change-Id: I175a6d3f25febf22ae6e05e5edd9f6de597aece2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/226169
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Allow add-stage to have an optional parameter for ignoring any section. This is
required to ensure proper operation of elf_to_stage in case of loadable segments
with zero filesize.
BUG=None
BRANCH=None
TEST=Compiles successfully for falco and boots to kernel prompt
Change-Id: Ife0594927e67eca5be6ecba2c93be3b8e517a28a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/226168
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Change cbfs-mkstage to use parsed elf instead of calling elf_headers. That
allows us to have access to the complete elf including the string table.
BUG=None
BRANCH=None
TEST=Compiles successfully for falco and creates coreboot.rom image that boots
fine on falco.
Change-Id: I222ef8afa5e1fcbb54ebb45e804bb341a796872d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/226167
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The eMMC enable pin is in a 3.3V IO domain. Unfortunately the eMMC
expects this pin to be 1.8V. The way we were driving this pin would
cause the eMMC to pull power through this pin and that was causing
current leaks.
In future revisions of hardware we should move this pin somewhere more
legit. However, in the current hardware we can get things working
pretty well by using a pullup to "drive" this pin. This will work in
conjunction with the external 100K pullup to give a somewhat
reasonable voltage. The eMMC will also not be able to pull much
current through this pin, so it can't leak too badly.
BRANCH=none
BUG=chrome-os-partner:33319
TEST=Boot a kernel that doesn't touch the mux/pulls and see no leak:
dut-control --port=${SERVO} vcc_flash_ma -t 5
Change-Id: Iadfc1477cd478773cc9d159e3fbc22b66b8f0f78
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226039
Reviewed-by: Julius Werner <jwerner@chromium.org>
Need to configure debug uart port to have proper baudrate/width/parity.
Hard-code it to 115200n8.
BUG=chrome-os-partner:32015
BRANCH=None
TEST=successfully suspend/resume on Rush/Ryu
Change-Id: I6a96c80654ce52f5b877fd46995ca8c1aceb7017
Signed-off-by: Yen Lin <yelin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/226407
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds the TPM device to the devicetree and configures an
active high edge triggered interrupt at IRQ10 and adds the ACPI
Device for the TPM into the DSDT.
It also cleans up the EC PNP ID to use the EISAID for an EC since
there are now two PNP devices declared, and removes the unused
ENABLE_TPM define at the top of the DSDT.
BUG=chrome-os-partner:33385
BRANCH=auron
TEST=same change tested on broadwell samus device
CQ-DEPEND=CL:226661
Change-Id: I4e106a3ae4f9fb4042ce75f010a68d91bbd4b8a6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226664
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds the TPM device to the devicetree and configures an
active high edge triggered interrupt at IRQ10 and adds the ACPI
Device for the TPM into the DSDT.
It also cleans up the EC PNP ID to use the EISAID for an EC since
there are now two PNP devices declared, and removes the unused
ENABLE_TPM define at the top of the DSDT.
BUG=chrome-os-partner:33385
BRANCH=samus
TEST=build and boot on samus, ensure TPM is functional at IRQ10
CQ-DEPEND=CL:226661
Change-Id: I2660cb30ac535da0b255603a619b9c09681ca947
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226663
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is not a standard feature so it should be included by the
mainboard if it is actually present in a sysetm.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=build and boot on samus
CQ-DEPEND=CL:226663, CL:226664
Change-Id: Ib7c171a5a007a2dddfb3d80341c6dc488e383e99
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226662
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds a ramstage driver for the TPM and allows the interrupt
to be configured in devicetree.cb.
The interrupt vector is set like other PNP devices, and the
interrupt polarity is set with a register configuration variable.
These values are written into locality 0 TPM_INT_VECTOR and
TPM_INT_ENABLE and then all interrupts are disabled so they are
not used in firmware but can be enabled by the OS.
It also adds an ACPI device for the TPM which will configure the
reported interrupt based on what has been written into the TPM
during ramstage. The _STA method returns enabled if CONFIG_LPC_TPM
is enabled, and the _CRS method will only report an interrupt if one
has been set in the TPM itself.
The TPM memory address is added by the driver and declared in the
ACPI code. In order to access it in ACPI a Kconfig entry is added for
the default TPM TIS 1.2 base address. Note that IO address 0x2e is
required to be declared in ACPI for the kernel driver to probe correctly.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=manual testing on samus:
1) Add TPM device in devicetree.cb with configured interrupt and
ensure that it is functional in the OS.
2) Test with active high and active low, edge triggered and level
triggered setups.
3) Ensure that with no device added to devicetree.cb that the TPM
is still functional in polling mode.
Change-Id: Id8a5a251f193c71ab2209f85fb470120a3b6a80d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226661
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This moves the LPC TPM driver to drivers/pc80/tpm so it can
be turned into a ramstage driver with a chip.h
It includes no other changes yet.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=emerge-samus coreboot
Change-Id: I60ddd1d2a3e72bcf169a0b44e0c7ebcb87f4617d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226660
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Nothing is connected to this port.
BUG=chrome-os-partner:33366
BRANCH=auron
TEST=emerge-auron coreboot
Change-Id: I9b4f4883f4c450f0e0462a99cabe939c61adfc1f
Signed-off-by: Ryan Lin <ryan.lin@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/226657
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Since display controller and panel configuration is done
in coreboot but the frame buffer address is not
available until payload stage, it is needed to have a
function in libpayload to set fb address and enable window
in dc registers.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Change-Id: Ib5fe9da4d8257d616e13c5556ec25d8b900d60e3
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/226406
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Need to add function to set framebuffer address to dc register.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I3f2ed7a15cabf6be02786c5245d055b2bc6c7491
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/226405
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Allocate noncacheable memory for frame buffer and save base
address to sys_libinfo.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Change-Id: I7bfbfefb92001632ce3d572a50e46188795c4ab8
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/226404
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
file; configuration needed to enable UART.
BUG=chrome-os-partner:31438
TEST=built urara bootblock and ran it on the Pistachio FPGA,
observed exepected console output
BRANCH=none
Change-Id: I4947ea8608593ec3f44e336ebdf3930f44493ec9
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: https://chromium-review.googlesource.com/226841
Reviewed-by: David Hendricks <dhendrix@chromium.org>
In order to properly support more arm64 SoCs PSCI needs
to handle the hierarchy of cpus/clusters within the SoC.
The nodes within PSCI are kept in a tree as well as
a depth-first ordered array of same tree. Additionally,
the PSCI states are now maintained in a hierachal manner.
OFF propogates up the tree as long as all siblings are
set to OFF. ON propogates up the tree until a node is
not already set to OFF.
The SoC provides the operations for determining how many
children are at a given affinity level. Lastly, the
secmon startup has been reworked in that all non-BSP CPUs
wait for instructions from the BSP.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Can still boot into kernel with SMP.
Change-Id: I520a9726e283bee7edcb514cda28ec1eb31b5ea0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226480
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
In order to dynamically allocate structures based on
affinity levels add malloc() support.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and booted to kernel.
Change-Id: Ie1412a3a9eb07689059a2cd69bd111274bcb88fa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226482
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The cpu_info struct can be easily obtained at runtime
based on smp_processor_id(). To allow easier mapping
between cpu_info and PSCI entities add the mpidr info
to the cpu_info struct.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and booted in SMP. Noted MPIDR messages for each cpu.
Change-Id: Ib10ee4413d467b22050edec5388c0cae57128911
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226481
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
I2C bus SDA hold time can be marginal with 60ns value, especially
when there is level shifter on the bus. So program it to 300ns
based on Fast-mode specification, which is between 0 to 900ns.
Apply the same timing for Standard-mode as well.
Refer to original bug on BayTrail chrome-os-partner:28092, this
is to carry forward the fix to Broadwell.
BRANCH=chromeos-2013.04
BUG=chrome-os-partner:33378
TEST=suspend resume test, watch for I2C errors
Change-Id: I995d6868a44f2578a6d0b18dd5e8548f3c3cd494
Signed-off-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/226386
Reviewed-by: Wenkai Du <wenkai.du@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
These allow to define a kernel image, initrd and command line.
BUG=None
BRANCH=None
TEST=Compiles successfully
Change-Id: Ia07b08b4cf385b17dc85f779cc7583db354bf99b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3893
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/222624
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
In the great tradition of LinuxBIOS this allows adding
a kernel as payload. add-payload is extended to also
allow adding an initial ramdisk (-I filename) and a
command line (-C console=ttyS0).
BUG=None
BRANCH=None
TEST=Compiles successfully
Change-Id: Icf09bb2e22e62b38c6332c38e650ec19605b47b8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3302
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/222623
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
First phase of urara (runnig on FPGA board) can not support verified
boot, let's not enable it yet.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with this and poreceeding patches the Urara board builds again.
Change-Id: I9ecdae32a0372219686348cb0b314a2e825ecea3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226182
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is necessary to support generic gpio interface in src/lib. This
file will be later populated with more GPIO definitions.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=none
Change-Id: I68c9c3a28fcc747575436b502cb25b31afed8700
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226181
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The architectiure check in fmap.c is in fact used to delineate between
platforms where SPI flash is mapped to memory address space and where
it needs to be accessed through CBFS.
In fact cosmos board uses an ARM SOC which also maps SPI flash to
processor address space, this will have to be addressed when that
SOC's support is introduced, for now let's just presume that all but
X86 platforms require CBFS layer to access fmap.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=none
Change-Id: Id135dc63278555a7fc5039a568fb28864f7cb8d1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226180
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Chrome OS support needs to be enabled on urara. This patch adds a
placeholder file to keep Chrome OS support code.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=none
Change-Id: I8ec328d4f965ff80d17847f2f8ce62b402c42a46
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226179
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The kernel will not track wakeup events for devices unless they have
a defined _PRW. There is no EC output of the lid signal coming to
a GPIO and instead it pulses WAKE#. There is no actual GPE for
WAKE# so pretend that PCI_EXP is the right GPE.
From the EDS: "WAKE# is treated as a wake event, but does not cause
any bits to go active in the GPE_STS register."
BUG=chromium:427769
BRANCH=none
TEST=manual on auron
- Run lidclose + lidopen in rapid succession, verify that suspend
request is aborted.
Change-Id: I116f3b98f5f31f3ded7c6b403ffa35724176a52d
Signed-off-by: Wei Shun Chang <wei.shun.chang@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/226160
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
