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>
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>
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>
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>
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>
This is essentially a copy of veyron_pinky for now.
BUG=chrome-os-partner:33269
TEST=build and boot
Change-Id: I0d473361e0850ee3b11da5a809f8396826ccdad6
Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225301
- Add the Whirlwind board ID to the enum
- Replace comparisons of the board ID with 0 to the proto0 constant
TEST=Booted Storm with this coreboot version
BUG=none
BRANCH=none
Change-Id: I75c7c98732c3d4569611de54d7aa149dd3b0fb7d
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225460
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The ethernet switch, as soon as it is taken out of reset comes up in
default (bridging) mode, which allows traffic to flow freely across
the ports.
Let's keep it in reset such that there is no cross port traffic
happening while the device boots up.
BRANCH=storm
BUG=chrome-os-partner:32646
TEST=verified that the switch is held in reset during boot.
Change-Id: I6bf698beddc98ce18fee6b3b39622e356c8cfbad
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224989
Reviewed-by: Toshi Kikuchi <toshik@chromium.org>
this change sets the stack pointer to the value specified in
memlayout.ld before jumping to the bootblock.
BUG=none
BRANCH=ToT
TEST=Built cosmos and all other current boards.
Change-Id: I4bb8cea7435d2a0e2c1ced050c3366d2e636cb8a
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225420
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
this change makes bootblock and verstage built for armv7-m use generic memset,
memcpy, and memmove because arch/arm/memset.S, memcpy.S, and memmove.S are not
compatible with armv7-m.
BUG=none
BRANCH=ToT
TEST=Ran bootblock on Cosmos prototype board. Emerged all current boards.
Change-Id: Ie1df2525362ffc2e8438ff7bd5fad7629b0477de
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225312
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This patch runs basic NAND initialization code on Proto 0.2 boards which
have been reworked for NAND. It makes sense to do this in coreboot for
two reasons:
- In general, it is reasonable for coreboot to initialize clocks and such
in preparation for depthcharge's use. Waiting times can be pooled, and
the initialization itself here is very fast.
- There is a kernel bug which requires that the clock already be initialized
before the kernel loads NAND support. Coreboot is a more sensible place
to put a workaround than depthcharge because depthcharge initializes
things lazily, but when booting from USB, depthcharge won't need to look
at NAND. Partner bug 33270
This change involves bringing in an additional header file, ebi2.h, from uBoot.
TEST=Booted a kernel from USB and verified that NAND came up without any
depthcharge hacks, whereas previously a USB-booted kernel would be unable
to access NAND even with the same drivers compiled in due to an initialization
failure.
BUG=chromium:403432
BRANCH=none
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Change-Id: I1760ecb4e47438311d80e34326e45578c608481c
Reviewed-on: https://chromium-review.googlesource.com/225277
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This is a no-op change just sorting the CBMEM entries' definitions for
easy look up and comparison.
BRANCH=storm
BUG=none
TEST=Booted a storm device, observed the expected CBMEM entries
present in the console output.
Change-Id: Ibcd4f184ef1bade10ad677384f61243da7e3c713
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225259
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The new API allows to find VPD objects in the VPD cache. There is no
need for the caller to allocate or free the per object memory.
The existing API (cros_vpd_gets) now uses the new function as well.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=verified that MAC addresses still show up in the device tree on
the booted storm device
Change-Id: I6c0b11bb844d6235930124d642da632319142d88
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225258
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
this adds an entry point jumping to main for the bootblock.
BUG=None
BRANCH=ToT
TEST=Built coreboot for cosmos
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I74f2f5e3b3961ab54a7913e6b3a3ab0e6fd813a3
Reviewed-on: https://chromium-review.googlesource.com/225205
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The function to read board IDs from tristate GPIOs currently supports
two output modes: a normal base-3 integer, or a custom format where
every two bits represent one tristate pin. Each board decides which
representation to use on its own, which is inconsistent and provides
another possible gotcha to trip over when reading unfamiliar code.
The two-bits-per-pin format creates the additional problem that a
complete list of IDs (such as some boards use to build board-ID tables)
necessarily has "holes" in them (since 0b11 does not correspond to a
possible pin state), which makes them extremely tricky to write, read
and expand. It's also very unintuitive in my opinion, although it was
intended to make it easier to read individual pin states from a hex
representation.
This patch switches all boards over to base-3 and removes the other
format to improve consistency. The tristate reading function will just
print the pin states as they are read to make it easier to debug them,
and we add a new BASE3() macro that can generate ternary numbers from
pin states. Also change the order of all static initializers of board ID
pin lists to write the most significant bit first, hoping that this can
help clear up confusion about the endianness of the pins.
CQ-DEPEND=CL:219902
BUG=None
TEST=Booted on a Nyan_Blaze (with board ID 1, unfortunately the only one
I have). Compiled on Daisy, Peach_Pit, Nyan, Nyan_Big, Nyan_Blaze, Rush,
Rush_Ryu, Storm, Veryon_Pinky and Falco for good measure.
Change-Id: I6133cdaf01ed6590ae07e88d9e85a33dc013211a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219901
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We've had gpiolib.h which defines a few common GPIO access functions for
a while, but it wasn't really complete. This patch adds the missing
gpio_output() function, and also renames the unwieldy
gpio_get_in_value() and gpio_set_out_value() to the much easier to
handle gpio_get() and gpio_set(). The header is renamed to the simpler
gpio.h while we're at it (there was never really anything "lib" about
it, and it was presumably just chosen due to the IPQ806x include/
conflict problem that is now resolved).
It also moves the definition of gpio_t into SoC-specific code, so that
different implementations are free to encode their platform-specific
GPIO parameters in those 4 bytes in the most convenient way (such as the
rk3288 with a bitfield struct). Every SoC intending to use this common
API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most
4 bytes in length. Files accessing the API only need to include <gpio.h>
which may pull in additional things (like a gpio_t creation macro) from
<soc/gpio.h> on its own.
For now the API is still only used on non-x86 SoCs. Whether it makes
sense to expand it to x86 as well should be separately evaluated at a
later point (by someone who understands those systems better). Also,
Exynos retains its old, incompatible GPIO API even though it would be a
prime candidate, because it's currently just not worth the effort.
BUG=None
TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and
Veyron_Pinky.
Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220975
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns baytrail to the new SoC header include scheme.
BUG=None
TEST=Tested with whole series. Compiled Rambi.
Change-Id: If5d2a609354b3d773aa3d482e682ab97422fd9d5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222026
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
