This change is based on wtm2
BUG=none
BRANCH=none
TEST=compile ok and boot to OS
Change-Id: I9625662eaf782f44258c15b956d04cbfdb82a14a
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/212368
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This matches the label exported by the GPIO controller in the
kernel and allows more speicific matches if there are other
devices that also export GPIOs.
BUG=chrome-os-partner:33098
BRANCH=samus
TEST=crossystem wpsw_cur returns 1
Change-Id: I655549d0f0eca341581bfbf845162d8b9f5e993d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224136
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
As per NV SysEng, setting PINMUX_CLAMP_INPUTS=1 is now
considered a bad thing. It clamps _all_ tristated inputs
to zero, and isn't really the panacea for duplicated pinmux
mappings as was stated previously.
BUG=None
BRANCH=None
TEST=Built both Rush and Ryu OK. Tested on Rush, booted kernel
OK.
Change-Id: I566c4516b34686b744a47a2b0c18c4b801456727
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/224032
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since the PD software sync is slow enable support for displaying
a screen telling the user that something is happening.
BUG=chrome-os-partner:32379
BRANCH=samus
TEST=manual testing:
1) in normal mode, with EC/PD in RW, ensure that they are rebooted
to RO and the VGA Option ROM is loaded and the wait screen is
displayed, and then the system is rebooted at the end and the
VGA Option ROM is not loaded.
2) same as #1 with EC/PD in RO already, same result
3) same as #1 with system in developer mode, same result except
there is no reboot at the end of software sync
4) same as #1 with system in developer mode and EC/PD in RO,
ensure that there is no extra reboot at the beginning or end of
software sync.
Change-Id: I125744f58c6b84df1af3943d9be98fe55c7117d5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223850
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Paging code is tricky and figuring out what is wrong with it can be a
pain. This patch tries to ease the burden by giving a little more
information for prefetch and data aborts, dumping the Instruction Fault
Address Register (IFAR), Instruction Fault Status Register (IFSR) and
Auxiliary Instruction Fault Status Register (AIFSR) or the respective
Data registers. These contain additional information about the cause of
the abort (internal/external, write or read, fault subtype, etc.) and
the faulting address.
BUG=None
TEST=I have read through enough imprecise asynchronous external abort
reports with this patch that I learned the bit pattern by heart.
Change-Id: I56a0557d4257f40b5b30c559c84eaf9b9f729099
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223784
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to display a "update in progress" screen on devices with
a slow EC or PD chip it may be necessary to also load the VGA
Option ROM when doing EC software sync.
This adds config options for VBOOT_EC_SLOW_UPDATE which simply sets
a flag in the input parameters that is already handled by vboot.
It also adds a config option for VBOOT_OPROM_MATTERS which is a bit
more tricky in that it sets a flag in input parameters, but also
needs to keep track of the option rom being loaded and pass that
flag into VbInit as well.
Since VbInit will clear the NV bit for option rom loaded the check
that is done in vboot_wants_oprom() needs to first compare against
the vboot handoff copy of the input flags.
BUG=chrome-os-partner:32379
BRANCH=samus
TEST=manual testing:
1) in normal mode, with EC/PD in RW, ensure that they are rebooted
to RO and the VGA Option ROM is loaded and the wait screen is
displayed, and then the system is rebooted at the end and the
VGA Option ROM is not loaded.
2) same as #1 with EC/PD in RO already, same result
3) same as #1 with system in developer mode, same result except
there is no reboot at the end of software sync
4) same as #1 with system in developer mode and EC/PD in RO,
ensure that there is no extra reboot at the beginning or end of
software sync.
Change-Id: Ic2b34bf9e7c6cc5498413fa1b8dff6e6207c9d0a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223831
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remember the XN bit? The one we had so much fun with on Nyan (LPAE)
because not setting it allows random instruction prefetches to device
memory that hang the system every few thousand boots? Thankfully, we had
always been setting it in the non-LPAE MMU code already...
"When the XN bit is 1, a Permission fault is generated if the processor
attempts to execute an instruction fetched from the corresponding memory
region. However, when using the Short-descriptor translation table
format, the fault is generated only if the access is to memory in the
Client domain, see Domains[...]" - ARM A.R.M. section B3.7.2
Oops. This patch changes our Domain Access Control Register (DACR) to
set domain 0 (the only one we are using) to Client. This means that
access permissions (AP[2:0] bits) become enforced, but they are already
set to full access (0b011). It also means that non-LPAE systems will not
be allowed to execute from DCACHE_OFF memory with enabled MMU anymore.
As far as I can see, Veyron_Pinky has been the only board that does
that.
BUG=chrome-os-partner:32118
TEST=Booted Veyron_Pinky with MMU in the bootblock, saw hangs that look
like spurious prefetches and confirmed that this patch fixes them.
Change-Id: I30676a5bfe12d516e5f910f51ee6854f6e5be557
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223783
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Solving the DACR bug will mean that XN bits suddenly become enforced on
non-LPAE systems, and we will no longer be able to execute out of a
region mapped DCACHE_OFF. When we enable the MMU in romstage we are
still executing out of SRAM, so we would instantly kill ourselves.
Solve this issue by enabling the MMU earlier (in the bootblock) and
mapping the SRAM regions as DCACHE_WRITETHROUGH. They should really be
DCACHE_WRITEBACK, but it looks like there might be hardware limitations
in the Cortex-A12 cache architecture that prevent us from doing so.
Write-through mappings are equivalent to normal non-cacheable on the A12
anyway, and by using this attribute we don't need to introduce a new
DCACHE_OFF_BUT_WITHOUT_XN_BIT type in our API. (Also, using normal
non-cacheable might still have a slight speed advantage over strongly
ordered since it should fetch whole cache lines at once if the processor
finds enough accesses it can combine.)
CQ-DEPEND=CL:223783
BUG=chrome-os-partner:32118
TEST=None (depends on follow-up CL)
Change-Id: I53e827d95acc2db909f1251de78d65e295eceaa7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223782
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds an mmu_config_range_kb() function, which can set memory
types at the 4KB level by chaining a fine-grained page table to an
existing superpage entry. It is only intended for special cases where
this level of precision is really necessary and therefore comes with a
few practical limitations (the area for each invocation must be confined
within a single superpage, and you are not allowed to remap the same
region with mmu_config_range() again later). Since the fine-grained page
tables need some space, boards intending to use this feature must define
a TTB_SUBTABLES() region in their memlayout.ld.
BUG=chrome-os-partner:32848
TEST=Booted both Veyron_Pinky (normal) and Nyan_Blaze (LPAE), ensured
that they still work. Checksummed the page tables with and without this
patch, confirmed that they end up equal. Hacked in some subtable test
entries, hexdumped all tables and manually confirmed that they look as
expected.
Change-Id: Iedf7ca435ae337ead85115200d6987fb0d4828d7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223781
Enable SPI support for cosmos, the earlier patches provided plumbing
for the CBFS SPI wrapper support.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=cosmos image builds with the SPI driver skeleton compiled in
Change-Id: If9dd80cb96120d34a0865f7882cd62e45fed749d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223752
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Vboot2 targets so far did not have COMMON_CBFS_SPI_WRAPPER
configuration option enabled, so the verstage is missing the relevant
files in some Makefiles. This patch fixes the problem.
BRANCH=none
BUG=none
TEST=with the rest of the patches applied cosmos target builds fine
with COMMON_CBFS_SPI_WRAPPER enabled
Change-Id: Iab813b9f5b0156c45b007fe175500ef0de50e65c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223751
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The SOC code should include the SPI controller driver when configured.
With the upcoming configuration change media.c is not needed anymore.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=the driver compiles when the upcoming patches are applied
Change-Id: If7e12e2fb04e63c36d9696d13e08397b91a77a8c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223750
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This file provides the SOC specific SPI driver API, it needs to be
filled up with code. Function descriptions can be found in
src/include/spi-generic.h.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=compiles with the upcoming patches applied.
Change-Id: I0ee04ca17874a13403007bba80d5e8a7708bc625
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223719
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With a few recently added configuration options many libpayload board
config got out of sync. The following command was used to normalize
them (with default answers to all questions):
for f in configs/config.*; do
cp $f .config
make oldconfig
mv .config $f
done
BRANCH=as required
BUG=none
TEST=none
Change-Id: I25b9862d868f9a62d663567b077e7b2b8cc42e22
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223650
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add necessary configuration to enable the inclusion of the UART driver
into the image when serial console is enabled.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=building with serial console enabled includes the skeleton uart
driver into the build
Change-Id: I6cbd110f600169021901b3f864d596404587fbcc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223598
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds a new option to the set of console UART choices and uses the
common console wrapper for bg4cd based devices.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=with the upcoming SOC specific patch applied, when building with
serial console enabled the following option shows up in
auto.conf:
CONFIG_CONSOLE_SERIAL_BG4CD=y
Change-Id: Id2aa2ed4827740aaf04514233bd57cd8df0fea55
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223596
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds the file to be filled up with the uart driver implementation
for bg4cd.
The console driver structure when required is provided by
src/console/uart_wrapper.c.
BRANCH=none
BUG=chrome-os-partner:32772
TEST=none yet, this file is not event being compiled
Change-Id: I73c12ddcd6f5099cc2196820452e714eeb736cdc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223595
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
MEI PCI device has internal logic to flush out the posted writes
before returning completion for non-posted request. When doing a RCBA
write to function disable and then using the PCI CFG RD cycle, need
to do RCBA posting read after writing to it to make sure the write
went through.
As Aaron sugegsted, abstracted function disable path to a common
function.
BUG=chrome-os-partner:33048
TEST=run warm and cold reboot testing
Change-Id: I87aa8ccd604446263fc3621c9a01839a5a75b644
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/223715
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
before the rkclk_init(), we must set rk808
buck1 voltage up to 1300mv
BUG=chrome-os-partner:32716, chrome-os-partner:31896
TEST=Boot on veyron_pinky rev2,check the rk808 buck1 voltage 1300mv
and check the cpu frequency up to 1.8GHz
Change-Id: I6a8c6e35bd7cc6017f2def72876a9170977f206e
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/222957
Reviewed-by: Doug Anderson <dianders@chromium.org>
change i2c clock low period and high perid propoton to 7:3
guarantee the low period more than 1.3us
BUG=None
TEST=Boot on veyron_pinky rev2,check the i2c clock frequency
Change-Id: I235e9e3ff54ab3b9cabad36bab58a8409f7005a0
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/223002
Reviewed-by: Julius Werner <jwerner@chromium.org>
BUG=None
BRANCH=None
TEST=Verified by reading back the value of SMMU_CONFIG register that enable bit
is set to 1
Change-Id: Iccc870141f9b9729971bf12119f9f3dae8181a43
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/222770
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Since the E0 and F0 stepping parts have the same CPUID it is
necessary to use the MCH PCI device revision to determine what
the actual stepping is.
Add this decode table so the early output gives proper identification
of the installed CPU type.
BUG=chrome-os-partner:32359
BRANCH=samus,auron
TEST=build and boot on samus with E0 and F0 parts
Change-Id: I1bc127badd75ecc34d3d2dbae5d272bd4d9f9082
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223158
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Force 4-byte alignment for .bs_init section to ensure that no padding
data is added to init structures.
BUG=chromium:416651
BRANCH=none
TEST=build firmware with GCC 4.9 and test on Auron and Rambi.
Change-Id: I3f94cd419b5951fdc6e5749576c4df2cc44f8a24
Signed-off-by: Ryan Lin <ryan.lin@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/223116
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Kenji Chen <kenji.chen@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The F0 stepping has the same CPUID as E0 stepping so report
it as either stepping to avoid confusion.
BUG=chrome-os-partner:32359
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: Ia4955f346ceb9be92e06ecea5b7a8fe2db84cabc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223097
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of having this in mosys just have coreboot report the
board version in SMBIOS tables.
BUG=chrome-os-partner:32359
BRANCH=samus
TEST=build and boot on samus, check /sys/class/dmi/id/product_version
Change-Id: Ib851d2e79ed721dcbc1c2f2eda6da50cac064cf3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223096
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If you try to boot a VBOOT2_VERIFY_FIRMWARE with less than 4K CBFS cache
right now, your system will try and fail to validate the FMAP signature
at (u8 *)0xFFFFFFFF and go into recovery mode. This patch avoids the
memcmp() to potentially invalid memory, and also adds an error message
to cbfs_simple_buffer_map() to make it explicit that we ran out of CBFS
cache space.
BUG=None
TEST=Booted on Veyron_Pinky with reduced CBFS cache, saw the message.
Change-Id: Ic5773b4e0b36dc621513f58fc9bd29c17afbf1b7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222899
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It's been a while since SBL blob size was reduced. As CBFS area by
definition includes the bootblock, storm configuration needs to be
updated to address the changes in layout.
Incidentally, it looks like CBFS_SIZE configuration setting is not
used on ARM platforms, this will have to be addressed separately.
BRANCH=storm
BUG=chromium:422501
TEST=storm firmware does not report the failure to find payload anymore
Change-Id: I37abf76a9d8884b3431633f57f64896c3a5fb135
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222898
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When cbfs debug is enabled, compilation fails because one of the debug
messages is using an non-existing variable.
BRANCH=nonr
BUG=None
TEST=compiling with CONFIG_DEBUG_CBFS enabled does not fail anymore.
Change-Id: Ic83f5e96cdcb5275ec0b7fadbc901e254a1002ca
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222897
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In able to do earlyprintk spew on LP0 resume, the kernel needs to
know the board UART. ODMDATA (in bct/odmdata.cfg) contains this info,
and the kernel looks for it in PMC_SCRATCH20. Fetch the ODMDATA word
from the BCT copy stored in IRAM by the BootROM.
BUG=chrome-os-partner:32015
BRANCH=none
TEST=Built for Rush and Ryu OK. Dumped PMC_SCRATCH20 in TegraShell
on Rush and confirmed value is what's in odmdata.cfg.
Change-Id: I63f33558ee8b00bd6c1e313efcd531e1d5fc67eb
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/222402
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch does some general cleanup in the Rockchip clock code, and
adds some more assertions regarding the PLL VCO and output frequency
ranges. It changes all PLL divisors to use the lowest values that can
still hit the target frequency, since higher NR values lead to higher
jitter and higher NO values increase power draw.
Also change DDR3 frequency code to hardcode the optimal divisors for
certail frequencies. As a little hack we will interpret 666000000 to
actually mean 666666666.6P (and analogous for 533MHz), since that's what
you usually want for memory.
BUG=chrome-os-partner:32139
TEST=Boot on veyron_pinky rev2, check that dpll_is shown as 666666666 in
/sys/kernel/debug/clk/clk_summary.
Change-Id: I4f3c39641955a95c6dfbe9334035eb670b138bf0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221801
This change re-writes the spi_xfer() function to support full-duplex
transfers.
Even though the code looks much different, the same basic algorithm
for setting up the transfer is used. The main difference is that
reads from rxdr and writes to txdr occur simultaneously and accounting
is more complicated, so I separated the higher-level accounting
portion from the low-level FIFO handling portion to simplify things.
BUG=chrome-os-partner:31850
BRANCH=none
TEST=Loaded content from SPI ROM fine, needs testing w/ EC
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I33d2f5179360baf94627c86b57d12f032897caf5
Reviewed-on: https://chromium-review.googlesource.com/218881
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is important since mmu is disabled during the post_sysinfo_mmu_setup call
and calling printf can cause unaligned access.
BUG=None
BRANCH=None
TEST=Compiles successfully and boots to kernel prompt with console_init
Change-Id: Ie376e394d084edd6c999fc9edde79f15a0264e7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/222664
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Provide a function to obtain a new memrange with requested properties (type,
size, alignment, max_addr and other restrictions) from the set of available
memranges passed in coreboot table. One user of this function would be getting
memrange for dma, another one would be framebuffer.
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles successfully and boots to kernel prompt
Change-Id: I187d73a4d55d3c6f49afbe9852901672d25de8dc
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/222110
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Fix the typo of sate to state and add uKernel phase to just
output the current state byte.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: I520a4cc75faffa5feeb6113ffd7b07a48c4e6f28
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222677
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The first 64 bytes of the framebuffer contain garbage after running
the option rom and after calling the VBE mode set with the flag to
clear the framebuffer.
Work around this issue by clearing the first 64 bytes in the framebuffer
in the broadwell graphics setup code after it executes the VBIOS.
BUG=chrome-os-partner:32771
BRANCH=samus,auron
TEST=build and boot on samus in dev mode, check for graphical corruption
Change-Id: I072bc913f7daea16e4861a7549e1b4ec85cde4cd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222676
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This selects the correct custom vesa mode for Samus which is
added to the VBIOS for bitmaps to be scaled appropriately.
BUG=chrome-os-partner:32643
BRANCH=samus
TEST=build and boot on samus
Change-Id: Id2b3349340e85ab6f29374dff096c39ac0506fc6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222675
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
BUG=chrome-os-partner:31424
TEST=Build a image and run on Samus proto boards to confirm if the
settings are applied correctly.
Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Change-Id: I8138507506771148420a585fd12897a3bfe91916
Reviewed-on: https://chromium-review.googlesource.com/221387
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
CQ-DEPEND=CL:218766
BUG=none
BRANCH=none
TEST=built and booted on Pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Icbee95350949bd9bfa4490a8a4b6bbf09beb4170
Reviewed-on: https://chromium-review.googlesource.com/221019
Reviewed-by: Julius Werner <jwerner@chromium.org>
Enable L1 Sub-State when both root port and endpoint support it.
BUG=chrome-os-partner:31424
TEST=Build a image and run on Samus proto boards to check if the
settings are applied correctly. I just only have proto boars and
need someone having EVT boards to confirm the settings.
Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Change-Id: Id1b5a52ff0b896f4531c4a6e68e70a2cea8c736a
Reviewed-on: https://chromium-review.googlesource.com/221436
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
according to schematic, GPIO29 needs to output high to enable M.2
socket power
BUG=none
BRANCH=none
TEST=build ok and see wifi device on M.2 socket working in OS
Change-Id: I7f122541a7bf3a5d7872f37a866ea3f1e52e8b47
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/221927
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
this adds a flash vbnv driver for vboot to store non-volatile data in a flash
storage.
BUG=chrome-os-partner:32774
BRANCH=none
TEST=Built samus, veyron pinky, and cosmos
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: If5fc1b779722528134ad283fa030f150b3bab55f
Reviewed-on: https://chromium-review.googlesource.com/222258
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
There's no need to reserve the framebuffer within corebot. If the
payloads need a framebuffer they can allocate one themselves.
BUG=chrome-os-partner:31355
BRANCH=None
TEST=Built and booted on ryu.
Change-Id: I8d8b159e7fdd877e392193c5474a7518e9b3ad21
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221726
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
If a TD is comprised of one or more Normal TRBs and terminated with an
Event Data TRB, then the transition to the Idle state (and associated
Stream state save) could occur after all the data for the TD has been
moved (e.g. after Transfer Event TRBs have been executed), but before the
Event Data TRB is executed. Under these conditions, the execution of the
Event Data TRB is necessary to complete the TD, otherwise it does not
occur until the nexttime the Stream is scheduled. This could lead to the
lock up.
The Evaluate Next TRB(ENT) flag provides a means of forcing the execution
of a terminating Event Data TRB. Setting ENT flag in last Normal TRB makes
the xHC to evaluate the Even Data TRB.
BUG=chrome-os-partner:29375
TEST=Verified kernel boot-up on storm from previously failing USB stick.
USB stick model: Sandisk Ultra USB 3.0 Pen Drive 32 GB
Strontium Jet USB 3.0 Pen Drive(32 GB)
Change-Id: I4e123577ec5a5996d87d2fc52cb6cf5c571c9fae
Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org>
Reviewed-on: https://chromium-review.googlesource.com/220123
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
