Some USB sticks seem to send a NAK at a place where they mustn't
by spec, leading to a controller side error condition.
To avoid it, wait a millisecond which is enough to get past the
NAK condition. That delay only happens on device discovery so it
won't affect boot time by more than 1ms per device.
BUG=chromium:414959
BRANCH=none
TEST=depthcharge recognizes a Lexar 16GB USB stick after applying
this change.
Change-Id: I6dd5ca34e9f3767003ccb0ca9daaf16116f4a2df
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228791
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
spi_flash->write returns non-zero on error and zero on success, not the
number of bytes written.
BUG=none
BRANCH=ToT
TEST=Booted storm. Verified successfully nvdata was saved.
Change-Id: If50cc1a62a4f06398d1830cca60085b6f925fff3
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229389
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Provide support for SoCs to participate in PSCI
commands. There are 2 steps to a command:
1. prepare() - look at request and adjust state accordingly
2. commit() - take action on the command
The prepare() function is called with psci locks held while
the commit() function is called with the locks dropped. For
now, the one SoC doesn't implement the appropriate logic
yet.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Booted PSCI kernel -- no SMP because cmd_prepare()
knowingly fails. Spintable kernel still brings up both
CPUs.
Change-Id: I0821dc2ee8dc6bd1e8bc1c10f8b98b10e24fc97e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226485
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Newly turned on CPUs need a place to go bring its EL3
state inline with expectations. Plumb this path in for
CPUs turning on as well as waking up from a power down
state. Some of the infrastructure declarations were
moved around for easier consumption in ramstage and
secmon. Lastly, a psci_soc_init() is added to
inform the SoC of the CPU's entry point as well do
any initialization.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and booted. On entry point not actually utilized.
Change-Id: I7b8c8c828ffb73752ca3ac1117cd895a5aa275d8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228296
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
It can't compile due to tpmp flag was removed in nvs.h
BRANCH=none
BUG=none
TEST=compile ok and boot to OS on pearlvalley
Signed-off-by: Kane Chen <kane.chen@intel.com>
Change-Id: I718b70c6194365ee19b93224b52b7bcf3a5055d0
Reviewed-on: https://chromium-review.googlesource.com/228975
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Kane Chen <kane.chen@intel.com>
Tested-by: Kane Chen <kane.chen@intel.com>
Enable display only developer and recovery mode.
Will add in the actual display supporting functions in coming
patches.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: Idfa24d23c81baaedb944d2b9835255edad4e422b
Reviewed-on: https://chromium-review.googlesource.com/226904
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
1. Add page address, an i2c address, into register address table
2. Add pmic read function
3. Add more registers and setting values.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I227b3e9390e6fc020707d4730c19945760df6ca2
Reviewed-on: https://chromium-review.googlesource.com/226902
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
This enables RAM_CODE_SUPPORT for veyron* platforms and uses the
generic gpio_get_binaries() function to read RAM_ID GPIOs.
BUG=chrome-os-partner:31728
BRANCH=none
TEST=built and booted on pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ibc4c61687f1c59311cbf6b48371f9a9125dbe115
Reviewed-on: https://chromium-review.googlesource.com/227249
Reviewed-by: Julius Werner <jwerner@chromium.org>
Take codec out of reset (GPIO_PH1 aka CODEC_RST_L) and enable LDO2
(GPIO_PR2/KB_ROW2 aka AUDIO_ENABLE). Muxes are setup and the two
GPIOs are set to output and driven high.
BUG=chrome-os-partner:32582
BRANCH=none
TEST=RealTek ALC5677 codec shows up in I2C6 scan at address 0x2D,
can read/write registers.
Change-Id: Iedce7bb9f8e61d3b8cd693fc5e567323d89f8046
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/228920
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Proto 0,1,2 boards had pwr btn active high. Proto 3 onwards boards will have pwr
btn active low. Thus, select power btn polarity based on board id.
BUG=chrome-os-partner:33545
BRANCH=None
TEST=Compiles successfully and boots to kernel prompt on ryu proto 1.
Change-Id: Icdf51b9324385de00f5787e81018518c5397215f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/229011
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
This adds the RAM config code to the coreboot tables. The purpose is
to expose this information to software running at higher levels, e.g.
to print the RAM config coreboot is using as part of factory tests.
The prototype for ram_code() is in boardid.h since they are closely
related and will likely have common code.
BUG=chrome-os-partner:31728
BRANCH=none
TEST=tested w/ follow-up CLs on pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Idd38ec5b6af16e87dfff2e3750c18fdaea604400
Reviewed-on: https://chromium-review.googlesource.com/227248
Reviewed-by: Julius Werner <jwerner@chromium.org>
This will be connected to the coded for firmware upload.
BUG=chrome-os-partner:33495
BRANCH=samus
TEST=build and boot on samus, check that GSPI driver is loaded
Change-Id: I25c91145aef8ca2aef229ffb27e8a45df659982e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228835
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Switched to CRC 16 as it's 40% faster than CRC x25.
Both CRC 16 and CRC x25 are supported and either can be selected through
define directives.
BUG=chrome-os-partner:31438
TEST=built urara bootblock and verified content of bootblock.bin, observed
expected content; ran it on Pistachio FPGA and observed that its
content is read properly by bootrom.
BRANCH=none
Change-Id: If1a78350e0b48d91bfe64ead45f852f44ba3cf9a
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: https://chromium-review.googlesource.com/226840
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
When the driver is included in bootblock, malloc() is not available.
Come to think of it, it is perfectly fine to use a statically
allocated structure for the SPI device descriptor - coreboot is
unlikely to require concurrent support of multiple SPI devices of the
same kind.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=bootblock on the FPGA board recognizes the installed Winbond
device:
coreboot-4.0 bootblock Tue Nov 11 07:27:24 PST 2014 starting...
SF: Detected W25Q16 with page size 1000, total 200000
Change-Id: Iaa69d610ef18e69b1ae5ade2d958f9fe1595a723
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228959
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is a (hopefully temporary) workaround for some bad panels
that do not work unless we have extra delay before running the
option rom.
BUG=chrome-os-partner:33671
BRANCH=samus
TEST=build and boot on samus with 'bad' panel and ensure that
the panel is always (50/50 times) brought up in developer and
recovery modes.
Change-Id: Ife779803c89ff56ff9b50e6b7c7c022300062a63
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228883
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This changes the broadwell graphics init path to only do the delay
before initializing graphics when running chromeos if we are also
going to execute the option rom.
BUG=chrome-os-partner:33671
BRANCH=samus
TEST=build and boot on samus
Change-Id: I350f85738efe3d17152de4f025adbfd52ae15b95
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228882
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This combines the board version reading and parsing to
a separate file that is compiled in both romstage (for
early serial output) and ramstage (for smbios tables).
It also adds a new board version that is wrapped back
to number zero as we are running out of available IDs.
BUG=chrome-os-partner:32895
BRANCH=samus
TEST=build and boot on samus EVT1 and EVT2 and check
for proper board versions reported in console and smbios.
Change-Id: I2aa03e7486a9581f94dc4e12f6f29eb0c5b3bdbb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229041
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
C0_COUNT register is a free running counter clocked by the CPU
frequency divided by two. On the FPGA board it results in 25 MHz, on
real SOCs it will have to be figured out later.
Some magic addresses and numbers are used to find out if the code is
running on the FPGA board.
timestamp_get() and timer_monotonic_get() are kept in the same file.
The CPU initialization makes sure that CO COUNT is in fact enabled and
starts from zero.
BRANCH=none
BUG=chrome-os-partner:33595,chrome-os-partner:31438
TEST=with timer enabled, the startup code properly initializes UART
and prints the coreboot bootblock banner message on the serial
console.
Change-Id: I2d518213de939e91a35f8aea174aed76d297dd72
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227888
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
C0 is a coprocessor register set defined in certain MIPS
architectures. This patch adds macros necessary to access the
registers and a couple of helper macros to access two particular
registers needed in the next patch.
The definitions come straight from arch/mips/include/asm/mipsregs.h in
the 3.14 kernel tree.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=the following patch demonstrates timer counter C0 register
configuration and use.
Change-Id: Ia4b1da40ecc1a03cf1cba0c648d42cd189fbcf93
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227887
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Urara CBFS header configuration is broken. CBFS header needs to be
right above the bootblock, and the CBFS data - 0x100 bytes above, to
allow room for proper CBFS wrapper structures.
Ideally only the header offset should be specified (and even that
could be derived from the bootblock size). But this is a more generic
problem to be addressed with different architectures' image layout
requirements in mind.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=coreboot image passes the integrity check now (it was failing
before because CBGS header was overlaying the bootblock)
$ FEATURES=noclean emerge-urara coreboot
$ /build/urara/tmp/portage/sys-boot/coreboot-9999/work/coreboot-9999/build/util/bimgtool/bimgtool \
/build/urara/firmware/coreboot.rom.serial
$ cbfstool /build/urara/firmware/coreboot.rom.serial print
coreboot.rom.serial: 1024 kB, bootblocksize 9956, romsize 1048576, offset 0x4100
alignment: 64 bytes, architecture: mips
Name Offset Type Size
fallback/romstage 0x4100 stage 7100
fallback/ramstage 0x5d00 stage 18995
config 0xa780 raw 2452
(empty) 0xb140 null 1003096
Change-Id: Id200ab5421661ef39b7c7713e931c39153fdc8be
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227523
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This makes board_id() use the generic gpio_base2_value() function
to obtain the value of the board ID straps.
BUG=none
BRANCH=none
TEST=tested on pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I5847bf1c5b26bcaf7d36103f31bb255b31ff8185
Reviewed-on: https://chromium-review.googlesource.com/228370
Reviewed-by: Julius Werner <jwerner@chromium.org>
Since gpio.c is more generic now and will be used in various
stages (ie for board_id()), compile it for all stages.
BUG=none
BRANCH=none
TEST=compiled for peppy and veyron_pinky
Change-Id: I77ec56a77e75e602e8b9406524d36a8f69ce9128
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228325
Reviewed-by: Julius Werner <jwerner@chromium.org>
This deprecates TERTIARY_BOARD_ID. Instead, a board will set
BOARD_ID_SUPPORT (the ones affected already do) which will set
GENERIC_GPIO_SUPPORT and compile the generic GPIO library.
The user is expected to handle the details of how the ID is encoded.
BUG=none
BRANCH=none
TEST=Compiled for peppy, nyan*, storm, and pinky
Change-Id: I687877e5bb89679d0133bed24e2480216c384a1c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228322
Reviewed-by: Julius Werner <jwerner@chromium.org>
This adds gpio_base2_value() which reads an array of 2-state
GPIOs and returns a base-2 value, where gpio[0] represents the
least significant bit.
BUG=none
BRANCH=none
TEST=tested with follow-up patches for pinky
Change-Id: Ia7ffc16eb60e93413c0812573b9cf0999b92828e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228323
Reviewed-by: Julius Werner <jwerner@chromium.org>
Our CBFS header offset on rk3288 was very low and overlapped with the
end of the bootblock on recent Pinky builds. This can create all kinds
of fun effects like BSS variables suddenly being initialized to
something else than zero, in an effect that jumps somewhere else for
every slightest code size change.
This patch moves the CBFS header offset up a bit and the CBFS ROM offset
down (because there's really no point in leaving such a large gap). This
resolves our immediate booting problems, and I'll also start on a patch
to add further checks somewhere that catch these overlaps in the future.
BRANCH=None
BUG=None
TEST=Created a Pinky image from the exact same commit version as the
official 6443.0.0 build, with a KERNELREVISION string of the exact same
length as the builder (which for some arcane reason is different than
running emerge locally, shifting the whole bootblock around with it).
Confirmed that I saw the same "Not enough room for another
sub-pagetable!" hang, and that this patch fixes it.
Change-Id: I8be5b7b7e87021cc1b3a91d336e8d233546ee188
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228326
Reviewed-by: Gediminas Ramanauskas <gedis@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch makes a few cosmetic changes:
- Rename tristate_gpios.c to gpio.c since it will soon be used for
binary GPIOs as well.
- Rename gpio_get_tristates() to gpio_base3_value() - The binary
version will be called gpio_base2_value().
- Updates call sites.
- Change the variable name "id" to something more generic.
BUG=none
BRANCH=none
TEST=compiled for veyron_pinky and storm
Change-Id: I36d88c67cb118efd1730278691dc3e4ecb6055ee
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228324
since the LAST_THSUT bit is uncertain value when it cold-reboot,
so we remove the printout about this bit status in coreboot.
BUG=chrome-os-partner:33521
TEST=Boot on veyron_pinky rev2
Change-Id: I258750797e32c28f86e73a01eede005e890a6906
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/228391
Reviewed-by: Julius Werner <jwerner@chromium.org>
LDO7 (VCC10_LCD_PWREN_H) is essentially just a glorified GPIO that turns
the real VCC10 regulator on or off. We tried setting it to 3.3V since it
matches the VCC33_SYS voltage on the input of that regulator. However,
we didn't notice that the LDO only supports going up to 2.5V.
This patch changes the voltage to the allowed maximum, which should
still work fine as an enable line (and is the same value used by the
kernel). This removes an assertion error in the ramstage.
Also change the PMIC driver to assert maximum VSEL values based on the
LDO, because the lower-voltage ones support one more setting. (LDO3 is
actually listed to only go up to 0b1111 in the manual, and has a weird
jump from 0b1101 -> 2.2V (skipping over 0b1110) to 0b1111 -> 2.5V. I
don't know if that's a documentation error or what they were smoking
when they designed that, but we don't need to care for now.)
BRANCH=None
BUG=None
TEST=Booted on Pinky, no more ASSERTION FAILED.
Change-Id: I68a3bb882cf25d98aca8922ede2a17e1ef6524de
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228292
Commit-Queue: Lin Huang <hl@rock-chips.com>
Tested-by: Lin Huang <hl@rock-chips.com>
Reviewed-by: Jerry Parson <jwp@chromium.org>
The veyron_jerry board code was just copied over from veyron_pinky
1-to-1. The Jerry board IDs start at 1, but there has never been a Jerry
rev0 so we can remove the code for board ID 0 from it.
BRANCH=none
BUG=None
TEST=Booted Jerry image on a Pinky rev2, worked fine.
Change-Id: I45a18b288c8d8b1399ceedf582addcce1c7e857d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228254
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Serial port on ITE 8772 SuperIO must be initialized before
console_init is called. So the pre console init callback
is added to let mainboard code do proper initialization.
Change-Id: I594e6e4a72f65744deca5cad666eb3b227adeb24
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/227933
Reviewed-by: Kenji Chen <kenji.chen@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Rajmohan Mani <rajmohan.mani@intel.com>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Empty functions are provided when !CONFIG_COLLECT_TIMESTAMPS
so stop guarding the compilation.
BUG=None
BRANCH=None
TEST=Built
Change-Id: Ib0f23e1204e048a9b928568da02e9661f6aa0a35
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228190
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
BUG=chrome-os-partner:33395
BRANCH=none
TEST=emerge and test using crossystem
Change-Id: I0d49f85219d45c837a7100e0195bef86da2c6cdd
Signed-off-by: Gediminas Ramanauskas <gedis@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227546
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are changes in upcoming board revs that need to take
different action depending on board revision. Update the
enumeration to reflect upcoming reality.
BUG=chrome-os-partner:33578
BRANCH=None
TEST=Built and booted.
Change-Id: I64cdeab806e7a665051f1d47bbf044413f7a1196
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227681
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The gpio_get_tristates() function prints out the values
observed while processing the GPIOs. Additionally, the
values for the normalization were completely consecutive.
Therefore, this indirection can be removed.
BUG=chrome-os-partner:33578
BRANCH=None
TEST=Built and booted.
Change-Id: I17d85891087e3128790329a5f05cbdab4cbc950e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227680
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
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>
