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>
The WiFi calibration blob saved in the CBMEM by coreboot needs to be
visible by depthcharge to supply it to the kernel.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=none yet
Change-Id: Iecd8739c9269b58064b3c3275f5376cebcd6804b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225506
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Invoke the function which copies WiFi calibration data in a CBMEM
table.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=verified that the WIFI entry is added to CBMEM when the
calibration data is present in the VPD.
Change-Id: I5fa77da98e37b88da01fb7884e713535fc178006
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225272
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds functions looking in the VPD for WiFi calibration
data, and if found, copying the calibration blobs into CBMEM.
Two possible key names templates are used: wifi_base64_calibrationX
and wifi_calibrationX, where X is replaced by the WiFi interface
number. Up to four interfaces can be provisioned.
The calibration data will be retrieved from CBMEM by the bootloader
and placed into the device tree before starting the kernel.
The structure of the WiFi calibration data CBMEM entry is defined
locally: it is a concatenation of the blob names and their contents.
Each blob is padded as necessary to make sure that the size divisible
by four.
To make sure that the exactly required amount of memory is allocated
for the CBMEM entry, the function first scans the VPD, caching the
information about the available blobs and calculating their combined
size.
Then the required size CBMEM entry is allocates and the blobs are
copied into it.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=when this function is called, and the VPD includes calibration
data blobs, the WIFI entry shows up in the list of CBMEM entries
reported by coreboot.
Change-Id: Ibe02dc36ff6254e3b9ad0a5bd2696ca29e1b2be3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225271
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds plumbing necessary to ensure that the CBMEM WiFi
calibration blobs entry, if present, is referenced if the coreboot
table.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=none - the entry is not yet in the CBMEM
Change-Id: I04d52934ad1c5466d0d124b32df5ab17c0f59686
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225270
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In the case of an EC wake event that is pending but not cleared
it is possible for the EC wake pin (i.e. GPIO27) to be asserted
after the kernel triggers the sleep SMI but before the system
goes to sleep.
If this happens then the GPE will be reported as a wake source
when the system wakes up again.
BUG=chrome-os-partner:33218
BRANCH=samus,auron
TEST=build and boot on samus, use the keyboard to enter suspend
with suspend_stress_test and ensure that only the RTC is listed
as a wake source upon resume.
Change-Id: I319dc22e21126a3086415f8f8b2b35eaec66fd50
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225540
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
git add fwserial.auron_pearlvalley is missed in previous commit
So, it casue compile error when download new source code
BRANCH=none
BUG=None
TEST=re-download code, compile ok and boot OS
Change-Id: I40795415d0ff811bea1ac9427a98e34880efb8ac
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/224912
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
