Changes might be required for .bct files as we get to know more.
Pulling in files from mainboard nyan for now
BUG=None
BRANCH=None
TEST=Compiles successfully for rush
Change-Id: Iaf81a384af0469c77940cf7309ba68018110b5eb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/203144
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
CrOS devices with Chromeos EC need only use hostevent to communicate
recovery assertion to the BIOS. This CL removes wired GPIO from
determining recovery as it appears under certain conditions (cold
reset) the internal PU on the AP isn't strong enough and therefore the
value is sometimes seen as asserted.
BRANCH=none
BUG=chrome-os-partner:29333
TEST=compiles & BIOS no longer responds to rec_mode GPIO during boot.
Change-Id: Ib220cfa5f5bfe7193d555bfd32c0444b063d00f2
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202996
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
x86 systems run their romstage as execute-in-place from flash, which
prevents them from having writable data segments. In several code pieces
that get linked into both romstage and ramstage, this has been worked
around by using a local variable and having the 'static' storage class
guarded by #ifndef __PRE_RAM__.
However, x86 is the only architecture using execute-in-place (for now),
so it does not make sense to impose the restriction globally. Rather
than fixing the #ifdef at every occurrence, this should really be
wrapped in a way that makes it easier to modify in a single place. The
chromeos/cros_vpd.c file already had a nice approach for a wrapper
macro, but unfortunately restricted it to one file... this patch moves
it to stddef.h and employs it consistently throughout coreboot.
BRANCH=nyan
BUG=None
TEST=Measured boot time on Nyan_Big before and after, confirmed that it
gained 6ms from caching the FMAP in vboot_loader.c.
Change-Id: Ia53b94ab9c6a303b979db7ff20b79e14bc51f9f8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203033
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The config files need to be renormalized after two new Kconfig options
for the IPQ806x have been added. Otherwise, trying to just 'make
oldconfig' with them from a command line hangs with extra questions. (I
never quite figured out why the ebuild seems to be unaffected by this.)
BUG=None
TEST=None
Change-Id: I272e40ef81e18c4d4e043b053d732c2e1c2599e9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202803
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The recently introduced page table location value is wrong, it
overlaps with other areas of the code. This patch fixes the location,
a more robust scheme is needed for memory layout management.
BUG=none
TEST=manual
. occasional random failures disappear after this patch is applied
Change-Id: Idc9047d38712736c5e8197e933c373488b333649
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202641
Reviewed-by: Julius Werner <jwerner@chromium.org>
Some drivers being ported to depthcharge use io bit manipulation
macros. The libpayload include file seems the most appropriate place
to keep these macros in. There is no common io.h file across
architectures, the x86 version could be added later if required.
BUG=chrome-os-partner:27784
TEST=observed ipq806x SPI driver deptcharge port (WIP) compile properly.
Change-Id: I33f3be072faefce293c871f7e3bc3b2e6bc38ffe
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202559
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
This adds a UART driver for the ipq8064 controller. It still does not
quite work in the receive direction - the receive FIFO returns read
data in 32 bit chunks, which means that 4 keys need to be pressed
before a character pops out of the driver (and it reports it as a
single character).
This issue is being addressed separately, the driver is being checked
in to facilitate concurrent development.
BUG=chrome-os-partner:27784, chrome-os-partner:29313
TEST=with deptcharge modifications in place, the AP148 board comes up
to the depthcharge prompt:
Starting depthcharge on storm...
storm:
Change-Id: Ief2cfcca73494be5c4147881144470078adcefb8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202045
Reviewed-by: Deepa Dinamani <deepad@codeaurora.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This adds some assembly code to clear .bss segment. It might have been
already cleared by the loader, but it is not guaranteed. This also
helps when the program is loaded by the debugger.
BUG=none
TEST=observed that .bss is now initialized when the program is
restarted. Verified correct boundaries of the segment.
Change-Id: I0aed0070da53881e4cf8c27049459040c006e765
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201784
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
When preparing an image for source level debugging, it is convenient
to be able to compile some modules with '-g -O0', which makes it much
easier to follow the execution flow.
This patch allows to do it by defining GDB_DEBUG=1 in the environment
before invoking make. Adding this feature as a common config flag is
problematic, because we don't want to compile the entire image with
-O0.
BUG=None
TEST=manual
. ran make with V=1 GDB_DEBUG=1 and observed the modified compiler
invocation line in the log.
Change-Id: I4a902ad25157fa7f93614917f440e56145405a1d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201783
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
This is an interim change (before EFS is enabled), align ROM and RAM
stages so that they have enough room and do not step over each other.
BUG=chrome-os-partner:27784
TEST=manual
. booted coreboot successfully on ap148
Change-Id: I6e1710ac7ca494a69aea5ba3b117bfd882aded26
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202046
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
The driver as it was copied from u-boot provided a function to
transmit multiple characters in one invocation. This feature was not
ported to coreboot, there is no need to maintain the complexity when
only one character at a time is transmitted. It is also very desirable
to get rid of a 1024 byte array allocated on the stack.
The array was necessary to allow to convert multiple newline
characters in the transmit data flow into two character sequences
CRLF. Now just a single word is enough to keep one or two characters
to transmit.
BUG=chrome-os-partner:27784
TEST=verified that coreboot with the new code prints generates console
output.
Change-Id: I73869c5f4ca87210b34811b583386554bafff1e7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201782
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Both DDI ports may be used on this board so it needs to be
able to detect a device on either port.
BUG=chrome-os-partner:28234
TEST=None (needs hardware)
Change-Id: I5fc5ec3fe887fb51e7bdeae43c8297580e0ba6d6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202358
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The ME debug info is not compiled in when the loglevel is
turned down to save the space of all the strings so the
contents in me_status.c should not be included either.
BUG=chrome-os-partner:28234
TEST=Build and boot with LOGLEVEL=BIOS_ERROR
Change-Id: Ibef46d0da038e13b0de0a29ab038ab6fce395730
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202357
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Enable the option to always load the VBIOS even when not executing
- If the option rom is not executed then DDI-A needs to be enabled
for the internal panel to work when the kernel comes up.
BUG=chrome-os-partner:28234
TEST=Build and boot with working OS graphics in normal mode.
Change-Id: I4ebfbf9d8714490dfd2dc2e634928c449719a2bf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202356
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
xHCI Spec says TD Size (5 bits) field shall be forced to 31,
if the number of packets to be scheduled is greater than 31.
BUG=chrome-os-partner:27837
BRANCH=rambi,nyan
TEST=Manual: Ensure recovery boot with USB 2.0 media on Squawks
works fine without any babble errors.
Change-Id: Iff14000e2a0ca1b28c49d0da921dbb2a350a1bbd
Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Originally-Reviewed-on: https://chromium-review.googlesource.com/202297
Reviewed-on: https://chromium-review.googlesource.com/202330
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Define a base address for page table entries. Place it 64KB below the
bootblock loading address.
BUG=chrome-os-partner:28467
TEST=verified that the page tables are being populated at this
address. Also observed that the SPI driver takes 900 ns to
process a byte as opposed to 1.5 us in case caching is not
enabled.
Change-Id: I3d8bd3104c55389aa5768033642ebbf1fda0fec7
Signed-off-by: Deepa Dinamani <deepad@codeaurora.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200332
This change updates the cfg file for Hynix/Micron/Samsung 4GB,
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: I7621e60d8dcc568e0bb400a6c96b7f8909a15aa6
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/202059
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
- Update GPIO map
- Update SPD for new memory and 4-bit table decode
- Enable USB3 port 3 and 4 (shared with PCIe port 1)
- Enable PCIe port 3 and disable port 1
- Enable SerialIO ACPI mode for devices
- Disable S0ix for now to prevent use of C10
- Special handling for memory with broadwell CPU
BUG=chrome-os-partner:28234
TEST=Boot on P1.9
Change-Id: If6adcc2ea76f1af7613b715133483d7661e94dd8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201083
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Put all the SPD related information in one place including
the onboard SPD sources and the board specific parsing.
BUG=chrome-os-partner:28234
TEST=Build and boot on samus
Change-Id: If5cd826ecc9cc856008b7c29aa3cfade5ae7f685
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201082
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- The old pei_data structure from haswell was still present
- Add a function for romstage to read CPU family/model
- Add quick_ram_check after memory init
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2 with broadwell CPU
Change-Id: I48ae199351d383796b28197fc0368770cba80ec4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201690
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Broadwell CPUs can have a region reserved just below TSEG for a
PCODE patch or TXT/BootGuard data. The DPR register reports the
TOP of this region with the size also reported in bits 8:4.
Compute and use the DPR base address as the top of memory for
coreboot.
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2+broadwell, check that the
usable memory is adjusted by 1MB:
- 3. 0000000000100000-000000007ce3efff: RAM
- 4. 000000007ce3f000-000000007cffffff: CONFIGURATION TABLES
- 5. 000000007d000000-000000007f9fffff: RESERVED
+ 3. 0000000000100000-000000007cd3efff: RAM
+ 4. 000000007cd3f000-000000007cefffff: CONFIGURATION TABLES
+ 5. 000000007cf00000-000000007f9fffff: RESERVED
Change-Id: Ia6ba25bc9992c3a3f859edd8d4a9c64aa42cfa98
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201081
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In https://chromium-review.googlesource.com/181272 the payload->type has been
changed to big-endian (network ordering) but the cbfs_image is still parsing
type as host ordering, which caused printing cbfs image verbosely
(cbfstool imge print -v) would fail to find entry field and print numerous
garbage output.
Payload fields should be always parsed in big-endian (network ordering).
BUG=none
TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly
Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200158
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Libpayload libc requires timer clock frequency to be at least 1MHz.
Ipq8064 code presently provides a single option of 32kHz. Pretend to
be running at 1 MHz without additional accuracy.
This is a hack which will be reverted as soon as the SOC is configured
to supply a faster running clock.
BUG=chrome-os-partner:27784, chrome-os-partner:28880
TEST=with other changes depthcharge boots to the CLI console
Change-Id: I80ec6652bc5693a549668cd6e824e9cf5c26b182
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201342
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The earlier compilation warning fix (7e4aa17) incorrectly assumed that
selfboot() is a function defined in the cbfs driver. This is a
commonly available function, it should not come from cbfs.h.
BUG=none
TEST=the following command succeeds:
$ for b in rambi storm nyan_big; do
cros_workon-$b start libpayload
emerge-$b libpayload || break
done
Change-Id: I3ef49d849168ad9dc24589cbd9ce7382052345bd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201386
Broadwell devices have new _HID values, although the kernel
drivers do not seem to treat them differently right now.
ADSP was using an incorrect _HID for lynxpoint devices which
conflicted with the I2C controller.
The SerialIO ACPI devices need custom methods to put the
controller in D0 or D3 state. These need to use the PCIe
config space that is mirrored in BAR1.
Additionally the device should not be put into D3hot state
until after setup is complete, which also means that it needs
to use the BAR instead of PCIe config cycles.
BUG=chrome-os-partner:28234
TEST=boot with devices in ACPI mode and ensure the kernel
I2C driver can bring them out of D3 and initialize them properly.
Also ensure that the driver puts the controller in D3 state
when there is no activity on the bus.
Change-Id: I82a860fceb2a32d9975f93dedcaaf2a48e354d1c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201080
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This commit includes bayleybay board related settings for bring up baytrail crb
BUG=none
TEST=emerge-bayleybay coreboot chromeos-bootimage compile ok.
It can boot to dev chromium desktop without verify boot(due to no TPM built in bayleybay)
Change-Id: I659293d7a8fcdae40b60fd127e19b7284e75aa10
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/201002
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is still using the 32kHz timer coreboot uses. A finer granularity
timer implementation for 806x is in the works.
BUG=chrome-os-partner:27784,chrome-os-partner:28880
TEST=none yet.
Change-Id: Iae206749000d45040090df48199c8d86d76bbae5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198021
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
As the USB driver for storm hardware is not yet available, do not
define it in llibpayload.
BUG=chrome-os-partner:27784
TEST=not much testing yet, just compilation/building
Change-Id: I6aea72cda33b61deb0a7dc69f8295f8c3f61406b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200827
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Convert wtm2 board to use the broadwell soc chipset.
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2 with haswell and broadwell
CQ-DEPEND=CL:201067
CQ-DEPEND=CL:*164226
Change-Id: Ifb0db15cc23a3b66430b32b2ad3f8ab2fb03c4c3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201070
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The VDDIO to GEN2 I2C SCL/SDA pins is 1.8V and the external
pull-up voltage is 3.3V (the external 3.3V > I/O 1.8V) thus
the pinmux E_OD bit of these two pins needs to be set to
ensure GEN2 I2C pads work fine on 3.3V.
BRANCH=nyan
BUG=none
TEST=observed voltage drop from 3.3V to 2.36V on gen2 i2c
on blaze w/o this change. the waveform looks good on both
scl/sda pins w/ this change.
Change-Id: I1b97f0c9c7580d1e532c3bdf7ac8690241ee7ee3
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/200996
Reviewed-by: Julius Werner <jwerner@chromium.org>
The -z "${V}" sure must have meant to be -n "${V}", but come to think
of it, this check is not necessary, as the following check will
succeed if and only if V is set to 1.
BUG=none
TEST=verified that adding V=1 to the environment causes the lpgcc
debug statements to show up in the output.
Change-Id: I1eb43ef49aeb4f16aef4fbee3a1037e853f9b40f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200501
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Make sure the build breaks in case of warnings.
BUG=none
TEST=run the following command with the previous patch removed and
then restored:
$ for b in rambi storm nyan_big; do
cros_workon-$b start libpayload
emerge-$b libpayload
done
all builds succeed with the restored patch and fail when a
compilation warning is thrown.
Change-Id: I9bdcd8938f59913e4ba86df5e4921b3f821ef920
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200110
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Seems that the 'if (cursor_enabled)' check in
video_console_fixup_cursor() that was removed in commit 1f880bca0 really
meant to check for 'if (console)'. Looks like the whole video console
driver is built extra robust to not fail no matter how screwed up the
console is, so let's add this missing check here as well. Also fixed up
a few other missing 'if (!console)' checks while I'm at it.
However, what payloads should really be doing is check the return value
of video_(console_)init() and not call the other video functions if that
failed. This also adapts video_console_init() to correctly pass through
the return value for that purpose (something that seems to have been
overlooked in the dd9e4e58 refactoring).
BUG=chrome-os-partner:28494
TEST=None. I don't know what Dave did to trigger this in the first
place, but it's pretty straight-forward.
Change-Id: I1b9f09d49dc70dacf20621b19e081c754d4814f7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200688
Reviewed-by: David Hendricks <dhendrix@chromium.org>
GPIO init marcos are not enough to initialize different gpio attributes
BUG=none
TEST=emerge-rambi coreboot works well
Change-Id: I193fa7b3e22632cacb555e726e3dd3991f4f4faa
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/200531
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When doing DP attach, we need to make sure the register change to
take effect immediately, otherwise it may fail to catch the attach
timing.
BRANCH=None
BUG=chrome-os-partner:28128
TEST=Display works and system boots up on Nyan and Big
Change-Id: I569dc435a1aa4aac0d5ecd0655d2ad87a791246d
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/200414
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
We initialized the dc before the plld's initialization. So some
of the dc init settings did not took effect. This patch moves
the clock_display() before the dc init call.
BRANCH=None
BUG=chrome-os-partner:28128
TEST=Display works and system boots up on Nyan and Big
Change-Id: If2c40e2526fdf7a6aa33a2684ba324bd0ec40e90
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/200413
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
There is a hub in USB port2 downstream.
BUG=chrome-os-partner:28964
BRANCH=None
TEST=emerge-nyan_blaze coreboot depthcharge chromeos-bootimage and verify usb
port2 is workable
Change-Id: I0e698970729911f401f89594232f9d49e4da93cc
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/200417
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Our tests with the I2C bit clear mechanism (recovering from "lost
arbitration" errors) show that the bit clear hardware does not work
correctly in some situations. When a wedged slave device tries to send
more than one 0-to-1-to-0 transition to the host (e.g. leftover bits
from an aborted read), the controller never transitions the BC_ENABLE
bit back to zero.
This patch adds a long timeout to the bit clear code that waits for
register transitions as a safeguard. This way, We will still eventually
exit the function (probably followed by a reboot). Our tests show that
this will recover from all conditions after at most a few reboots.
BRANCH=nyan
BUG=chrome-os-partner:28323
TEST=Ran wedge_ack and wedge_read tests with software_i2c patch, system
recovered as expected in all cases.
Change-Id: I6c37119130e1240e1ef3a5944582abbcd2e39ff0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200265
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
This patch adds I2C emulation in software through raw toggling of the
SDA/SCL lines. Platforms need to provide bindings to toggle their
respective I2C busses for this to work (e.g. by pinmuxing them as GPIOs,
currently only enabled for Tegra).
This is mostly useful as a debugging feature, to drive unusual states on
a bus and closely monitor the device output without the need of a bus
analyzer. It provides a few functions to "wedge" an I2C bus by aborting
a transaction at certain points, which can be used to test if a system
can correctly recover from an ill-timed reboot. However, it can also
dynamically replace the existing I2C transfer functions and drive
some/all I2C transfers on the system, which might be useful if a driver
for the actual I2C controller hardware is not (yet) available.
Based on original code by Doug Anderson <dianders@chromium.org> and
Hung-ying Tyan <tyanh@chromium.org> for the ChromeOS embedded
controller project.
BRANCH=None
BUG=chrome-os-partner:28323
TEST=Spread tegra_software_i2c_init()/tegra_software_i2c_disable()
through the code and see that everything still works.
Change-Id: I9ee7ccbd1efb38206669a35d0c3318af16f8be63
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198791
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The kernel will not track wakeup events for devices unless they have
a defined _PRW. There is no EC output of the lid signal coming to
a GPIO and instead it pulses PCH_WAKE#.
BUG=chrome-os-partner:27631
TEST=Manual on Rambi.
- Run lidclose + lidopen on EC console, verify that wakeup_count
increments.
- Run lidclose + lidopen in rapid succession, verify that suspend
request is aborted.
BRANCH=Rambi.
Change-Id: I8d4c58a7bb37d7e474ec094fe96e46e1bfd980de
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200289
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
BUG=none
BRANCH=nyan
TEST=built and booted on Big under various modes, verified that
expected boot mode showed up using "mosys eventlog list"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I8d98487a2cb910874c8d741008ae59a6c89102e7
Reviewed-on: https://chromium-review.googlesource.com/199691
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
