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>
There are three instances of coreboot.c in libpayload. for x86, arm
and arm64 architectures. The arm and arm64 instances are exactly the
same. The differences with the x86 instance are as follows:
- a very slightly different set of coreboot table tags is parsed (one
tag added and two removed)
- instead of checking a fixed address if it contains the coreboot
table, the x86 version iterates over two address ranges.
This patch refactors the module, leaving architecture specific
processing in arch subdirectories and moving the common code into
libc.
BUG=none
TEST=none yet
Change-Id: I6dfed73f6ba5939f692d0f98d2774c0e0312a25f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210770
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@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>
Make board ID value supplied in the coreboot table available to the
bootloader on all three architectures.
BUG=chrome-os-partner:30489
TEST=none yet
Change-Id: I7847bd9fe2d000a29c7ae95144f4868d926fb198
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210430
Reviewed-by: Julius Werner <jwerner@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>
rmodules ccopts contain information about specific arch like armv4,v7. Hence, it
is important to include them in VBOOT_CFLAGS
BUG=None
BRANCH=None
TEST=Compiles correctly for armv4 in rush
Change-Id: I8f5509f753e28046678c3782d6f0b6210559f798
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/209979
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
