Patch from Macronix.
BUG=None
TEST=Compiled + verified system boot
BRANCH=Rambi
Signed-off-by: Patrick Ha <patrick@samsung.com>
Change-Id: I932b7041f6409ed8a5e65580e9e983908ab2dd3d
Reviewed-on: https://chromium-review.googlesource.com/211068
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: patrick Ha <patrick@samsung.com>
Commit-Queue: patrick Ha <patrick@samsung.com>
Tested-by: patrick Ha <patrick@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/211411
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The current 2 boards were setting up clocks and enabling
peripherals that apply to the SoC generically. Therefore,
move the common pieces into the SoC code.
BUG=chrome-os-partner:31105
BRANCH=None
TEST=Built and booted through depthcharge on ryu.
Change-Id: I6df1813f88362b8beaf1a716f4f92e42e4b73406
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211191
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
The I2C pads connected to the EC are pulled to 3.3V. Therefore
the pads need to be configured as open drain.
BUG=chrome-os-partner:29981
BRANCH=None
TEST=Built and booted through depthcharge on ryu
Change-Id: Ia4ad2377d01296235fc7efbba72fa790016c04af
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211135
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Ryu's EC talks proto v3 over i2c. Select the correct protocol.
BUG=chrome-os-partner:31148
BRANCH=None
TEST=Built and ran on ryu. Coreboot can speak to the EC now.
Change-Id: I50e192cd58f7a29103ab94afc002da18822d4080
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211240
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Certain boards need to speak proto v3 over i2c. Leverage the
transport agnostic API to share the logic with other proto v3
impelementations.
BUG=chrome-os-partner:31148
BRANCH=None
TEST=Built and ran on ryu. Can talk to the EC successfully.
Change-Id: Ib699120fd232392e8caa0889c2bf40f4587a8a35
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211139
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Depending on the transport mechanism for proto v3 different bytes
need to be send and/or read before the request and response. Depending
on the software and/or controller interface that requirement leads to
needing to copy data into temporary buffers. Avoid this by allowing
the transport mechanism to provide the request and response
buffers.
BUG=chrome-os-partner:31148
BRANCH=None
TEST=Built for rush and ryu. Ran on ryu with i2c implementation.
Also built for rambi to check x86 systems.
Change-Id: Iad6cce566a253ca72e6f5009a97235ece0a6c1b5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211138
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Storm provides three real and two fake gpios. To keep things simple,
define them all as active low and provide appropriate values for the
fake ones.
BUG=chrome-os-partner:30705
TEST=with the appropriate depthcharge change booted proto0, observed
appropriate behavior following the dev switch setting
Change-Id: Icb7fb55949fa97ead9d19f0da76392ee63bbb5b8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210922
The EC doesn't return any data when one performs a write to
VBNV context. Therefore there is a mismatch of expectations.
Correct this by properly setting the expected response length.
BUG=chrome-os-partner:31148
BRANCH=None
TEST=No longer hanging while writing to VBNV on ryu.
Change-Id: I455724f20f5442bd62a792f09273227417475f07
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211137
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Add the supporting Kconfig options and infrastructure for
performing vboot firmware verification.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Built and ran on ryu into depthcharge noting vboot paths
being taken.
Change-Id: Ie4c8c3939990a12fc528423948b236230392eb7c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211134
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The original intent was to set the equivalent flags by default
for the PAD_CFG_* macros so as not to make the usage too chatty.
The GPIO_INPUT variant didn't have the PINMUX_INPUT_ENABLE field
set. Therefore, automaticaly set it for PAD_CFG_GPIO_INPUT().
BUG=chrome-os-partner:29981
BRANCH=None
TEST=Built and ran on ryu.
Change-Id: Ifb630601cf04d2984542933382aace16540863ad
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211133
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The tegra132 SoC provides the monotonic timer API. Therefore,
ensure the reset of the coreboot infrastructure is aware.
BUG=None
BRANCH=None
TEST=Built and ran on Ryu. Noted that ramsgage is showing timings
for each bootstate.
Change-Id: I9b8fcf38cba9bdaaf0455701df1d6328bf1927c1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211132
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
coreboot already has a reset API. Utilize it by selecting
HAVE_HARD_RESET. The tegra132 boards have to provide the
hard_reset() implementation as that involves board-specific
bits. The tegra132 code then provides a cpu_reset() routine
that just promotes that call to a hard_reset().
For the existing tegra132 boards remove the unnecessary files
from the build.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Ensured hard_reset() does something on Ryu.
Change-Id: I1e1b014062dafb5d81fb9da40006c5405073a95d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211131
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Now that there's a working udelay() in tegra132, upclock
CAM_I2C and SPI1 to the same speeds as used on Nyan.
BUG=chrome-os-partner:30998
BRANCH=rush_ryu
TEST=Built Rush and tested, no nack errors seen.
Change-Id: I58fd03ed3512c2498c793cfe30b0c302e4b0e3d4
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/211043
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
No need to define these everywhere, one place will serve all uses.
BUG=none
TEST=compiled various targets without any problem
Change-Id: Iabf31baad6049c758e078727ba3ebe830c3c7684
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210921
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There was an empty udelay() implementation result in 0 waits.
Provide an actual implementation.
BUG=None
BRANCH=None
TEST=Built and ran through to depthcharge on rush.
Change-Id: I201f2fdc4e4f5c88d48e4002839b03e808a5a1bc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210827
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
During a refactor the stage->load address was being returned as
an entry point. That is only true when the first instruction is
the entry point of the stage. Fix the handling of the load and
entry points.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Building still works. vboot still runs on rush.
Change-Id: I65a93c1c785569190406cd23006ea840c0011936
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211010
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
The gpio_index_to_port() incorrectly was dividing by
GPIO_PORTS_PER_BANK on a value including the bit number. After
masking off the BANK offset just divide by the number of gpios
in a port to get the port offset.
BUG=chrome-os-partner:29981
BRANCH=None
TEST=Built and ran through to depthcharge. Printed bank, port, and
bit numbers for validation.
Change-Id: I8bb50e922c9fd7c0a1c247ba95394f6deb9f1533
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210909
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
I erroneously added GPIO_NONE_INDEX at the beginning of the
enum block effectively putting every GPIO index off by 1.
Instead, move it to the end.
BUG=chrome-os-partner:29981
BRANCH=None
TEST=Built and ran through to depthcharge on rush. Also
printed out banks, port, and bit offsets to validate.
Change-Id: I0471480e8658de9e534beb859a1f5027a961d73e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210908
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The DRAM include files are not used on Ryu as the BootROM initializes
the memory from the BCT tables.
BUG=None
BRANCH=None
TEST=Built rush_ryu.
Change-Id: If216096ffc9e9836b6d082ad0668640b3eec37b7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210904
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
It's helpful to be able to track this information. Therefore
dump it in to the console log.
BRANCH=None
BUG=chrome-os-partner:31126
TEST=Built and ran on rush. Revision information is put out on the
console.
Change-Id: Ic95382126a6b8929d0998d1c9adfcbd10e90663f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210903
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Instead of calling out with function names all the possible
combinations of interface and device provide one call to the
mainboard to configure all the necessary bits.
BUG=chrome-os-partner:31104
BUG=chrome-os-partner:31105
BRANCH=None
TEST=Built and ran on rush.
Change-Id: Id27d9c2da4dccdff38c48dc5cdeb1a68cf23cbfc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210838
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Switch over to the padconfig API for bootblock PAD configurations.
Aside from support code, each entry is 4 bytes. The open coded
calls were 12 bytes each.
BUG=chrome-os-partner:29981
BRANCH=None
TEST=Built for ryu.
Change-Id: I2d32d702da38bc0d87a1c159113bba32f4c03407
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210837
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Switch over to the padconfig API for bootblock PAD configurations.
Aside from support code, each entry is 4 bytes. The open coded
calls were 12 bytes each.
BUG=chrome-os-partner:29981
BRANCH=None
TEST=Built and ran on rush. Observed consistent results.
Change-Id: I1d5d38322bda6740a0ea50b89f88b722febdee22
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210836
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Instead of hard coding certain pieces of a board in the common
chipset code provide a way to initialize things early in the
bootblock path. Add a bootblock_mainboard_early_init() function
before console init to performany necessary mainboard initialization
early in the bootblock.
BUG=chrome-os-partner:31104
BUG=chrome-os-partner:31105
BUG=chrome-os-partner:29981
BRANCH=None
TEST=built both on rush and ryu. rush still behaves the same.
Change-Id: I7d93641dff3a961f120e8f0ec2d959182477ef87
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210835
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Start using the soc_configure_pads() API. This allows for
bulk processing of pads.
BUG=chrome-os-partner:31105
BUG=chrome-os-partner:31104
BUG=chrome-os-partner:29981
BRANCH=None
TEST=Built and can get console messages on rush.
Change-Id: Iaa6a6ff4d559aedb98b078e87b0ecddefd3402d6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210834
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Instead of sprinkling the pad configuration and pinmux
selection throughout the code allow for a data-driven
initialization sequence. Most of the calls in the
original pinmux functions require 12 bytes per pad
plus the support code. This implementation allows for
4 bytes per pad in addition to the support code.
BUG=chrome-os-partner:29981
TEST=Built and booted into depthcharge on rush.
Change-Id: I3a119b4068e880b74a0a1597f143d7c4e108a6c1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210833
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
It's helpful to view program size by inspecting the symbols.
_start and _end exist on romstage and ramstage. In order to
be consistent add _end for bootblock too.
BUG=None
BRANCH=None
TEST=Built and noted bootblock has _end symbol.
Change-Id: I7f0b4dd4078c7d23c70949563b4c3f4df9e66142
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210832
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Workaround for auto shutdown issue on broadwell SKU.
Now we can see C7 transition, and MRC fastboot
BUG=chrome-os-partner:29787,chrome-os-partner:29117
BRANCH=None
TEST=build ok and boot on samus
Signed-off-by: Kane Chen <kane.chen@intel.com>
Change-Id: Id1f174b67fa3e6f248dd8b21aee25e6e01abf33e
Reviewed-on: https://chromium-review.googlesource.com/210870
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Kane Chen <kane.chen@intel.com>
Commit-Queue: Kane Chen <kane.chen@intel.com>
Rush has its EC on SPI, and Ryu has it on I2C, so need both
mainboard_init_ec_spi and mainboard_init_ec_i2c in both builds,
due to romstage.c being in the common tegra132 subdir.
BUG=none
BRANCH=rush_ryu
TEST=Built both rush and rush_ryu images OK. Will try to
boot on Ryu later.
Change-Id: I48d9530697d5669177ecd9ba3c34360197002003
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/210595
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
This is a quick port from wtm2 to test on the broadwell Y CRB.
Note that it produces an 8MB image and yet the board has a
16MB SPI flash part. The build tools are not ready to handle
a 16MB image yet so just add 8MB of FFs to the end for now.
BUG=chrome-os-partner:28234
TEST=boot on pearl valley
Change-Id: I849075fc07fa017b5ccca17d0736342a1518db7d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210661
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- geometry was incorrect for 8GB modules, should be x32,
so refactor the rest of the geometry to match
- some of the timing values were off, calcualte new values
from the datasheet
BUG=chrome-os-partner:28234
BRANCH=None
TEST=build and boot on samus
Change-Id: I645f354ef21c5032ab73c66e1ad843136ec93eff
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210660
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is useful for debug and testing.
BUG=chrome-os-partner:29649
BRANCH=None
TEST=build and boot on samus
Change-Id: I9050e75fd7c308ebd97d196298c687f8b0f8f97d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210599
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These boards are supposed to be able to determine the board ID at run
time based on the certain GPIO settings.
BUG=chrome-os-partner:30489
TEST=verified that all boards build. Checked that storm proto0 reports
board ID of 0 on the console
Change-Id: Iadd758a799d69e1e34579d7d495378856b64c45b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210119
storm uses three GPIOs in tertiary mode, such that proto0 returns
value of 8 when the GPIOs are interpreted as a single tertiary number.
Adjust the calculated value to return board ID of 0 on proto0, and
monotonously incrementing values on newer boards.
BUG=chrome-os-partner:30489
TEST=when enabled, the board ID value of zero is reported on the console.
Change-Id: I2ff8fd5cbc8d568877b6f8bf220e146893f1e4be
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210118
For the majority of Chrome OS boards there is no need to include board
ID calculation in any stage but ramstage, where the ID should be
available for inclusion into the coreboot table.
BUG=chrome-os-partner:30489
TEST=build only, no other tests yet
Change-Id: Ib9c06698a399d31e79a9b14143343ba2ad46d0fb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210117
Reviewed-by: Julius Werner <jwerner@chromium.org>
Board ID value is usually of interest to bootloaders. Instead of
duplicating the board ID discovery code in different bootloaders let's
determine it in coreboot and publish it through coreboot table, when
configured.
BUG=chrome-os-partner:30489
TEST=none yet
Change-Id: Iee247c44a1c91dbcedcc9058e8742c75ff951f43
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210116
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Add implementation of the GPIO API defined in src/include/gpiolib.h.
Also, clean up the GPIO driver, make it use pointers instead of
integers for register address.
This requires a touch in the SPI driver, where the CS GPIO is toggled
and in the board function where it enables USB interface.
BUG=chrome-os-partner:30489
TEST=tested with the following patches, observed proto0 properly read
the board ID.
Change-Id: I0962947c6bb32a854ca300752d259a48e9e7b4eb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210115
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Some platforms use tertiary interpretation of GPIO input state to
increase number of distinct values represented by a limited number of
GPIOs. The three states are
- external pull down (interpreted as 0)
- external pull up (1)
- not connected (2)
This has been required by Nvidia devices so far, but Exynos and
Ipq8086 platforms need this too.
This patch moves the function reading the tertiary state into the
library and exposes the necessary GPIO API functions in a new include
file. The functions are still supposed to be provided by platform
specific modules.
The function interpreting the GPIO states has been modified to allow
to interpret the state either as a true tertiary number or as a set
two bit fields.
Since linker garbage collection is not happening when building x86
targets, a new configuration option is being added to include the new
module only when needed.
BUG=chrome-os-partner:30489
TEST=verified that nyan_big still reports proper revision ID.
Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209673
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Iniitialize I2C bus required for TPM operation. Problem observed was that if
frequency is raised above 20KHz, TPM starts responding with NAKs either for
address or for data. Need to look into that.
BUG=None
BRANCH=None
TEST=Compiles successfully and TPM success messages seen while booting.
Change-Id: I9e1b4958d2ec010e31179df12a099277e6ce09e0
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/210001
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
