The CTDP related methods are moved from systemagent.asl to a
new ctdp.asl file.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I4d0df9af27501b925ec0f12daeb5980903a637d6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198898
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Removed unused variables from the ACPI NVS region and separate
out the variables used to communicate SerialIO base address and
enable status.
Some now unused ACPI methods in globalnvs.asl have been removed.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I20e26c7ebfb25975f315c3e41e67fee3f50df539
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198897
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and
COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these
attributes are associated with each of the stages.
BUG=None
BRANCH=None
TEST=Compiled successfully for all mainboard/google boards. Image booted
successfully on link, rambi and nyan.
Change-Id: I10d36ff950712756fb16dcb4d315924d177846b5
Reviewed-on: https://chromium-review.googlesource.com/195574
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others
from arch level Makefile.inc to top level Makefile.inc.
Also, organize Makefile.inc at arch level into per-stage rules and variables.
BUG=None
BRANCH=None
TEST=Compiled successfully. Image booted successfully on link,nyan and rambi.
Change-Id: I22f5ef692b740f84d73071534732286e809f3bc4
Reviewed-on: https://chromium-review.googlesource.com/195446
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
CONFIG_ARCH is a property of the cpu or soc rather than a property of the
board. Hence, move ARCH_* from every single board to respective cpu or soc
Kconfigs. Also update abuild to ignore ARCH_ from mainboards.
BUG=None
BRANCH=None
TEST=Compiled successfully for all mainboard/google boards. Successfully booted
link image.
Change-Id: I42323ac33c236d26654a26b591378781aeecabd4
Reviewed-on: https://chromium-review.googlesource.com/195350
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Add the header file used to communicate information to the intel
reference code binaries. This is shared directly with the PEI
wrapper in the binary. A broadwell specific function is defined
to fill out platform specific information and a function prototype
is provided for the mainboard to implement.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: Ib3254cbd0c1a890ffb716cab551f68b6201812d2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198743
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This broadwell implementation will support Haswell ULT in
addition to broadwell CPUs. Add the latest available microcode
for the broadwell C0 and D0 parts as well as Haswell ULT.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I1beb71e0e28af3508e2260751b6fdfe47d53d90d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198742
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Put some generic ramstage function prototypes into the a new
header at broadwell/ramstage.h for easy access. Some of these
functions are defined in a later commit.
This file also contains the exported 'broadwell_pci_ops' that can
be used by ramstage drivers and is defined in broadwell/chip.c
BUG=chrome-os-partner:28234
TEST=None
Change-Id: Idfa1f9ab46d1bf4efbefea46548f97653786e6f1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198741
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Put all the exported romstage functions (that are not also defined
in ramstage) into broadwell/romstage.h for easy access.
Some of the stuff in this file is not used yet but will be part of
a later commit.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I69db33ba95afa3c3868c7c09ed53ed80567d17f4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198740
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Create a new header at broadwell/msr.h that contains the various
defined MSRs for this CPU generation. The MSRs from cpu.h and
the ones defined in smmrelocate.c are in this new header.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: Id0652d0f7e4bad0992c057b530fc5e05e2dfabb2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198739
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This puts all the SMM related information into one location
instead of being split across several headers.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: If4782d37f28b325ff76dd8efa560840d4e1da276
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198738
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This header will allow the broadwell code to access specific
devices without worrying about the differences in device_t
type between romstage/smm and ram stage.
These new devices will be used in subsequent commits that clean
up the broadwell drivers.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I457c39b6a5262a6ad50034e711de4e8174815d8d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198737
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of having various defined base addresses in different
headers put them all in one well defined location. The names
are changed to be more consistent with baytrail implementation.
Some defines are for early temporary base addresses, a few of
which are taken from Kconfig variables and are set here in order
to be consistent with the ones that are not defined in Kconfig.
The code will be changed to use the new defines in subsequent
commits.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I315d8c6f4188244bc86342e8c5dce60924653c58
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198736
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the smbus romstage/ramstage related code into smbus_common.c
and split out the smbus related defines/prototypes from pch.h
to broadwell/smbus.h.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: Ide534ee8d13868fb3ab0a277c958b862c5dfeeb7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198735
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Pull the IOBP related defines and functions from pch.c/pch.h
into separate iobp.c/iobp.h.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: Ic510360c14594f4fd46249c238ac851372045893
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198734
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
LPAE (large physical address extension) is not available on this SOC
core, do not enable it.
BUG=chrome-os-partner:27784
TEST=coreboot still comes up on AP148
Change-Id: I9e9ad1aeaf613f04987c0c306a574085042d0e7b
Signed-off-by: Deepa Dinamani <deepad@codeaurora.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198023
Reviewed-by: deepa dinamani <deepad@quicinc.com>
There is redundancy in terms of use of init_timer. We have a Kconfig option to
decide whether a board has init_timer as well as we use stub for init_timer in
places where we do not have any init_timer defined. Thus, removing the Kconfig
option. Henceforth, all boards that do not have init_timer functionality can
include include a stub_timer if required.
BUG=None
BRANCH=None
TEST=Compiled successfully for all mainboard/google/ boards as well as all the
other boards that were compiling fine before this change using abuild still
compile fine. No additional errors introduced because of this change
Change-Id: Iaffec9ce92107e55d65cc7c9f317feeeba700242
Reviewed-on: https://chromium-review.googlesource.com/195250
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Patch to rename coreboot_ram stage to ramstage. This is done in order to provide
consistency with other stage names(bootblock, romstage) and to allow any
Makefile rule generalization. (Required for patches to be submitted later)
CQ-DEPEND=CL:195101
BUG=None
BRANCH=None
TEST=Compiled successfully for all boards under mainboard/google/. Image booted
successfully on link board
Change-Id: I3e2495fc6a5cc91695ae04ffb438dd4ac265be64
Reviewed-on: https://chromium-review.googlesource.com/195059
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Move the XHCI and EHCI related register/bit defines into a separate
header file at broadwell/ehci.h and broadwell/xhci.h
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I24df90c797ebdc5dee1fe84ed57c565c5360dd1c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198554
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the GPIO related register/bit defines into a separate header
file at broadwell/gpio.h. Also clean up the existing file to remove
the "low-power" variant differences since this is now the only
supported GPIO interface for broadwell.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I8c50bf368753e40a90940e387d7dc79dc5568f55
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198553
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the LPC related register/bit defines into a separate header
file at broadwell/lpc.h
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I42acc57e436524103500f05bdc2c8f7a02b3a918
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198552
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the SerialIO related register/bit defines into a separate header
file at broadwell/serialio.h
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I84fea5fd0b2c82f37e7aa025ed0188e0bf19c411
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198551
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Split the SPI related register/bit defines into a separate header
at broadwell/spi.h
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I6d675ede9f3d25a47761543dbf1e18e15e8f63e8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198550
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the SATA related register/bit defines into a separate header
file at broadwell/sata.h
BUG=chrome-os-partner:28234
TEST=None
Change-Id: Ia92439533d99def96316bab4898d38388e52c4dd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198429
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Split out defines for RCBA related registers/bits into a separate
header file in broadwell/rcba.h.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I070317015b546bb8a641e9a12279e3f86152ca66
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198428
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Various register/bit defines for power management offsets
in PMBASE are split into a separate header together with
the prototypes for pmutil helper functions.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I3d79e288b79641d8c4b4c8d10ed122b0c5c7e143
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198427
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use the same copyright string and license formatting in
every file in the soc/intel/broadwell directory.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: Ibfa9f1f10ad0e2410d200f7120d07a793a2bbfb2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198426
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The haswell and lynxpoint code will form the starting point for
broadwell support but it will be heavily reworked to fit into
a unified soc directory.
For now just copy in the raw starting sources.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I013c5c95e839a27979da8b6ebbee290529ae3279
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198425
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When a watchdog reset happens, the SOC will reset but other parts of the
system might not. That puts the machine in a funny state and may prevent it
from booting properly.
BUG=chrome-os-partner:28559
TEST=Built for nyan, nyan_big and nyan_blaze. Booted normally, through EC
reset, software reset ("reboot" command from the terminal), and through watch
dog reset. Verified that the new code only triggered during the watchdog reset
and that the system rebooted and was able to boot without going into recovery
mode unnecessarily.
BRANCH=nyan
Change-Id: Id92411c928344547fcd97e45063e4aff52d2e9e8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/198582
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
When a watchdog reset happens, the SOC will reset but other parts of the
system might not. In order to detect those situations we can check the
rst_status register in the PMC.
BUG=chrome-os-partner:28559
TEST=With this and a change which uses the new function in the nyan boards,
built for nyan, nyan_big and nyan_blaze. Booted normally, through EC reset,
software reset ("reboot" command from the terminal), and through watch dog
reset. Verified that the new code only triggered during the watchdog reset and
that the system rebooted and was able to boot without going into recovery mode
unnecessarily.
BRANCH=nyan
Change-Id: I7430768baa0304d4ec8524957a9cc37078ac5a71
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/198581
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Added the empty function clear_recovery_mode_switch (weak)
Problem:
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC is set,
the following will happen:
1. Boot device in recovery mode with Esc + F3 + Pwr.
2. Turn device off with Pwr button.
3. Turn device on with Pwr button.
Device still boots to recovery screen with
recovery_reason:0x02 recovery button pressed.
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC isn't set,
turning the device off and on again
with the Pwr button does a normal boot.
Solution:
Unconditionally clear the recovery flag.
BUG=chromium:279607
BRANCH=TOT
TEST=Compile OK.
Change-Id: Ie1e3251a6db12e75e385220e9d3791078393b1bf
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197780
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Sheng-liang Song <ssl@google.com>
Tested-by: Sheng-liang Song <ssl@google.com>
The original sdram-hynix-2GB-792.inc was just copied from nyan
bct file. This change updates the cfg file for Hynix 2GB, 792MHz
DRAM based on the data generated by t124_emc_reg_tool.
BUG=none
BRANCH=blaze
TEST=emerged coreboot, booted successfully into kernel.
Change-Id: I9534b4df6d35193179de124309df12ed830098a0
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/197660
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
All what's needed apart from configuring the feature is to provide a
function which would report the top of DRAM address.
BUG=chrome-os-partner:27784
TEST=manual
. with all other patches applied, the image proceeds all the way to
trying to download 'fallback/payload'.
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Change-Id: Ifa586964c931976df1dff354066670463f8e9ee3
Reviewed-on: https://chromium-review.googlesource.com/197897
Length arguments for VbExTpmSendReceive have type uint32_t but it calls function
which expects size_t. This change converts uint32_t to size_t on call and
size_t to uint32_t on return.
BUG=None
BRANCH=None
TEST=Booted Nyan Big to Linux
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I1971488baae2d060c0cddec7749461c91602a4f9
Reviewed-on: https://chromium-review.googlesource.com/198016
This is a fix for the 'Lost arb' we're seeing on Nyan* during
reboot stress testing. It occurs when we are slamming the
default PMIC registers with pmic_write_reg().
Currently, I've only captured this a few times, and the bus
clear seemed to work, as the PMIC writes continued (where
they'd hang the system before bus clear) for a couple of regs,
then it hangs hard, no messages, no 2nd lost arb, etc. So
I've added code to the PMIC write function that will reset the
SoC if any I2C error occurs. That seems to recover OK, i.e. on
the next reboot the PMIC writes all go thru, boot is OK, kernel
loads, etc.
BUG=chrome-os-partner:28323
BRANCH=nyan
TEST=Tested on nyan. Built for nyan and nyan_big.
Change-Id: I1ac5e3023ae22c015105b7f0fb7849663b4aa982
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/197732
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
This service is required by various coreboot code modules. It looks
like the 8064 SOC does not provide anything better than a 32 KHz free
running counter (it is used in u-boot for us timer as well). Let's use
this for now.
BUG=chrome-os-partner:27784
TEST=manual
. with the rest of the patches applied AP148 boots all the way to
trying to start the payload.
Change-Id: I98b91ce179f7388d59c769a59caf49ca7640e047
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197896
This change forces storm platform to use the common CBFS SPI wrapper,
which makes the SOC specific CBFS code unnecessary and requires
including SPI controller support in all coreboot stages.
BUG=chrome-os-partner:27784
TEST=manual
. with this change and the rest of the patches coreboot on AP148
comes up all the way to attempting to boot the payload (reading
earlier stages from the SPI flash along the way).
Change-Id: Ib468096f8e844deca11909293d90fc327aa99787
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197932
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Since the same driver is going to be used at all coreboot stages, it
can not use malloc() anymore. Replace it with static allocation of the
driver container structure.
The read interface is changed to spi_flash_cmd_read_slow(), because of
the problems with spi_flash_cmd_read_fast() implementation. In fact
there is no performance difference in the way the two interface
functions are implemented.
BUG=chrome-os-partner:27784
TEST=manual
. with all patches applied coreboot proceeds to attempting to load
the payload.
Change-Id: I1c7beedce7747bc89ab865fd844b568ad50d2dae
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197931
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Coreboot has all necessary infrastructure to use the proper SPI flash
interface in bootblock for CBFS. This patch creates a common CBFS
wrapper which can be enabled on different platforms as required.
COMMON_CBFS_SPI_WRAPPER, a new configuration option, enables the
common CBFS interface and prevents default inclusion of all SPI chip
drivers, only explicitly configured ones will be included when the new
feature is enabled. Since the wrapper uses the same driver at all
stages, enabling the new feature will also make it necessary to
include the SPI chip drivers in bootblock and romstage images.
init_default_cbfs_media() can now be common for different platforms,
and as such is defined in the library.
BUG=none
TEST=manual
. with this change and the rest of the patches coreboot on AP148
comes up all the way to attempting to boot the payload (reading
earlier stages from the SPI flash along the way).
Change-Id: Ia887bb7f386a0e23a110e38001d86f9d43fadf2c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197800
Tested-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
A typical SPI operation consists of two phases - command and data
transfers. Command transfer is always from the host to the chip (i.e.
is going in the 'write' direction), data transfer could be either read
or write.
We don't want the receive FIFO to be operating while the command phase
is in progress. A simple way to keep the receive FIFO shut down is to
not to enable it until the command phase is completed.
Selective control of the receive FIFO allows to consolidate the
receive and transmit functions in a single spi_xfer() function, as it
happens in other SPI controller drivers.
The FIFO FULL and FIFO NOT EMPTY conditions are used to decide if the
next byte can be written or received, respectively. While data is
being received the 0xFF bytes are transmitted per each received byte,
to keep the SPI bus clocking.
The data structure describing the three GSBI ports is moved from the
.h file into .c file. A version of the clrsetbits macro is added to
work with integer addresses instead of pointers.
BUG=chrome-os-partner:27784
TEST=not yet, but with the res of the changes the bootblock loads and
starts the rombase section successfully.
Change-Id: I78cd0054f1a8f5e1d7213f38ef8de31486238aba
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197779
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
I always thought the support for multiple logical SCSI units in the USB
mass storage class was a dead feature. Turns out that it's actually used
by SD card readers that provide multiple slots (e.g. one regular sized
and one micro-SD). Implementing perfect support for that would require a
major redesign of the whole MSC stack, since the one device -> one disk
assumption is deeply embedded in our data structures.
Instead, this patch implements a poor man's LUN support that will just
cycle through all available LUNs (in multiple calls to usb_msc_poll())
until it finds a connected device. This should be reasonable enough to
allow these card readers to be usable while only requiring superficial
changes.
Also removes the unused 'protocol' attribute of usb_msc_inst_t.
BRANCH=rambi?,nyan
BUG=chrome-os-partner:28437
TEST=Alternatively plug an SD or micro-SD card (or both) into my card
reader, confirm that one of them is correctly detected at all times.
Change-Id: I3df4ca88afe2dcf7928b823aa2a73c2b0f599cf2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198101
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
So I was debugging this faulty USB SD card reader that would just fail
it's REQUEST SENSE response for some reason (sending the CSW immediately
without the data), cursing those damn device vendors for building
non-compliant crap like I always do... when I noticed that we do not
actually set the Allocation Length field in our REQUEST SENSE command
block at all! We set a length in the CBW, but the SCSI command still has
its own length field and the SCSI spec specifically says that the device
has to return the exact amount of bytes listed there (even if it's 0). I
don't know what's more suprising: that we had such a blatant bug in this
stack for so long, or that this card reader is really the first device
to actually be spec compliant in that regard.
This patch fixes the bug and changes the command block structures to be
a little easier to read (why that field was called 'lun' before is
beyond me... LUN is a transport level thing and should never appear in
the command block at all, for any command). It also fixes a memcpy() in
wrap_cbw() to avoid a read buffer overflow that might expose stack frame
data to the device.
BRANCH=rambi?,nyan
BUG=chrome-os-partner:28437
TEST=The card reader works now (for it's first LUN at least).
Change-Id: I86fdcae2ea4d2e2939e3676d31d8b6a4e797873b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198100
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
To avoid LCD_VCC glitch on cold reset, set SOC_DISP_ON as GPIO output high.
After gfx initialize was done set it to native funtion 2.
BUG=chrome-os-partner:25159
BRANCH=firmware-rambi-5216.B
TEST=Tested on Rambi and squawks, no LCD_VCC glitch anymore.
Change-Id: If16af498e910a8da1d77a9a66456eb767286a61a
Original-Change-Id: Icf62588fa0338f89fafb3fe9246c26f16bcdaa60
Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/197985
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Use the RTC driver interface to find the timestamp for events instead of
reading the CMOS based RTC directly on x86 or punting on ARM. This makes
timestamps available on both architectures, assuming an RTC driver is
available.
BUG=None
TEST=Built and booted on nyan_big and link and verified that the timestamps
in the event log were accurate.
BRANCH=nyan
Change-Id: Id45da53bc7ddfac8dd0978e7f2a3b8bc2c7ea753
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197798
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Enable the AS3722 RTC driver for use with event log.
BUG=None
TEST=Built and booted on nyan_big. Built for nyan and nyan_blaze.
BRANCH=nyan
Change-Id: I8c26c304f4bed52d3fe5d2756931075d27bc2c6d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197797
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
