Commit 9e7c12b added a command-line option to "make" to build
development versions of the Cr50 board. This makes the symbol
definition useful in makefiles and not just C code.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Id0719d63263b00e192a2e4866dbe1551ae49e23c
Reviewed-on: https://chromium-review.googlesource.com/391127
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The application may need to read/write/erase the flash memory,
but we not want console users to do so. This CL adds
CONFIG_FLASH_PHYSICAL, which allows the higher-level CONFIG_FLASH
to be undefined while still providing the chip-specific
flash_physical_* accessor functions.
There aren't many board.h files that needed changes, since
CONFIG_FLASH_PHYSICAL is enabled by default, just like CONFIG_FLASH.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
See that it still boots, updates, wipes, restores, etc. without
linking common/flash.o in the production image; and that the
flash commands are still there in the dev build.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I7eb1bbcb414b1c70ee427c4fcb5cea899dbb9e93
Reviewed-on: https://chromium-review.googlesource.com/391188
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
We have a large number of config.h options to enable/disable
specific console commands. This adds a few more that we will want
to control.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
Change-Id: Id41f0e9f44fc77feaf56853f357a6b33bb685b0c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/391614
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We have a bunch of options to enable/disable individual console
commands, but they're not quite sorted. Now they are.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: I186b9f82dc40c2f9fc66f493b4b6cccda020224c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/391613
Reviewed-by: Randall Spangler <rspangler@chromium.org>
And even that's a bit of a stretch. This entire endpoint will
probably be deactivated until it's more useful. In the meantime,
we can just leave the one little debug command for debug builds.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Id4c185fe66d52fa49fcbee6a549df41d297c41af
Reviewed-on: https://chromium-review.googlesource.com/391045
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The rdd features are working (and it's better to test with
hardware anyway), so just delete this command.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Ifcfc8c8a0e61a9fe31d28f0c96bcb50c3e2b93b5
Reviewed-on: https://chromium-review.googlesource.com/391314
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
It's possible the register values could be sensitive.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Id3d4df3aaca116a638332f092d4727accd0cbbcd
Reviewed-on: https://chromium-review.googlesource.com/391612
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
All it does is show the AP/EC/Servo state
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I375be8e4d9c6f01aa90d0830da1927732740ed92
Reviewed-on: https://chromium-review.googlesource.com/391611
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
It could be used to sniff TPM commands.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Ia2e11fb8e01002c2cf5e53b175e3e8b2741e4585
Reviewed-on: https://chromium-review.googlesource.com/391244
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
We're using fusb302 rev. >= B now, so let's remove rev. A support.
BUG=chrome-os-partner:57492
BRANCH=none
TEST=Manuel
- plug USBC->DP cable into TV then into kevin
localhost ~ # ectool usbpdmuxinfo
Port 0: DP INV
- plug USBC->DP cable into kevin then into TV
localhost ~ # ectool usbpdmuxinfo
Port 0: DP INV
- unplug USBC->DP cable from TV
Port 0: OPEN INV
- plug USBC->ETHERNET into kevin and verified that network
displayed ethernet
Change-Id: Ia84dc2480c1a8b003ab8dfdcdaa9f82f6d429e4b
Reviewed-on: https://chromium-review.googlesource.com/388925
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The pwm prescaler wasn't being calculated properly when used with
the 32 Khz clock.
BUG=chrome-os-partner:57526
BRANCH=none
TEST=Manuel
- With PWM frequency set to 100Hz, I verified on the scope that
the duty cycle changed from 0 to 100% in 10% increments.
- Verified on the scope that PWM frequency could be set to 100Hz,
200Hz, 300Hz, 400Hz, and 2600Hz.
Change-Id: Idf8ffb6b20d469c9ea58e5a34e944f79d475eb15
Reviewed-on: https://chromium-review.googlesource.com/388814
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
If BD9995X_CMD_MAP_SET fails, the charger's internal map command set
may be the old set (if the charger failed to process the command) or the
new set (if the EC failed to receive the response). Therefore, reset the
EC's known map command state on failure, so that it will always be
re-set on the next transaction.
BUG=None
TEST=Build + boot kevin.
BRANCH=Kevin
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Id16273ccf2e39b5aae7776d626aae8863e713df5
Reviewed-on: https://chromium-review.googlesource.com/390318
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Partition number must be set before partition lock is attempted.
BRANCH=none
BUG=none
TEST=the cert installation image does not crash on gru any more
Change-Id: Ibc81e2e741fafb75f4e4bb5dbfc0dae32d354646
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/390416
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Some Type-C to DP adapters generate two or more HPD events while
others generate only one HPD event. Currently hotplugging only
works with the former adapter. Now hotplugging is triggered on
one or more HPD events.
BUG=chrome-os-partner:57198
BRANCH=none
TEST=Manuel
- plug USBC->DP cable into TV then into kevin
localhost ~ # ectool usbpdmuxinfo
Port 0: DP INV
- plug USBC->DP cable into kevin then into TV
localhost ~ # ectool usbpdmuxinfo
Port 0: DP INV
- unplug USBC->DP cable from TV
Port 0: OPEN INV
Change-Id: Ied30f1eb3e1186b52067ffc9a37ed22a9012b457
Reviewed-on: https://chromium-review.googlesource.com/388737
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388531
Commit-Ready: Shawn N <shawnn@chromium.org>
There is no point in invoking TPM reset while the current invocation
is in progress. One of the cases when this is happening is early start
up on Kevin/Gru: the device starts booting, the EC comes around to
pulsing sys_rst_l when TPM is already busy installing endorsement
certificates.
There is no point in issuing another reset at that point, just let the
process continue.
BRANCH=none
BUG=chrome-os-partner:52366
TEST=firmware_TPMKernelVersion firmware_TPMExtend autotests still pass
on kevin. Certificate installation during startup does not get
interrupted any more.
Change-Id: Ibdface9f7a76186e210ef0f4111cd5fe9905bba9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/389811
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
TPM resets happen asynchronously, conceivably there is some interface
(i2cs or sps) activity under way when TPM is reset.
Sps driver provides a means of disconnecting the client of the driver,
while the i2cs driver does not. Come to think of it, there is no real
need to provide a special function to disconnect a client, this makes
API simpler and allows to add driver initialization to the client
registration function.
To make tpm_registers.c more flexible - allow to register a callback
for interface initialization, this way when TPM is reset, the
interface can be also re-initialized and is guaranteed to start from
scratch after reset.
BRANCH=none
BUG=chrome-os-partner:52366
TEST=both firmware_TPMExtend and firmware_TPMKernelVersion autotests
pass
Change-Id: I212166a23f9cd512d8f75315377d1f5620aea070
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388886
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
use the right prototype for the memset() clearing the TPM .bss space
on reset, use addresses of variables instead of their values, and do
not clear tpm_resisters.c .bss section, tpm_init() does the right
thing.
BRANCH=gru
BUG=chrome-os-partner:52366
TEST=make buildall
Change-Id: I4c8c0ae61a0e70c9fc211420bbf44bbc7d8de3ed
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/389331
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The power state driver would print out the current power state along
with its signals everytime a power signal interrupt was fired. On some
systems, a signal may briefly go low and then come back before our
chipset module has a chance to notice. This causes what appears to be
duplicate prints.
This commit tries to only print out the current power state when
something has actually changed. If the input power signals or state
differs from the last time it checked, then the information will be
printed.
BUG=None
BRANCH=gru
TEST=Find a kevin where PGOOD goes away quite frequently. Build and
flash; Verify that significantly less "power state S0" console spam is
emitted.
TEST=Verify that all state transitions are still printed.
Change-Id: I9d66c04e2ed79ab203c54f0a8dad82f32856bbf0
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/388761
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Similar to the TPM SPI interface, added code to disable sleep an I2CS
interrupt is received. Enabling sleep follwoing a 1 second delay when
the TPM fifo register has been read by the host. The I2CS TPM layer
doesn't know when a command has finished, but the one second delay is
more than enough delay since sleep will be disabled again when the
next I2CS interrupt is received.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
Tested without these changes first. Shortened sleep delay to 30
seconds, and disconnected suzyq. Waited 30 seconds then issued the
command on the AP console:
tpmc read 0x1007 0xa
[ 59.796813] tpm tpm0: tpm_transmit: tpm_send: error -16
ERROR: write failure to TPM device: Device or resource busy
In addition, using logic analyzer verifed that there was activity on
SDA/SCL but no response from Cr50. With this CL in place, ran the
test and got the following:
tpmc read 0x1007 0xa
2 0 1 0 1 0 0 0 0 4f
With the logic analyzer I was able to confirm that there was no
activity from the host on the I2CS bus until the command was issued.
Change-Id: If07573ae8f72b983bca57979d53c22660b91b95e
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/387910
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Fixed an issue with word aligned write to fifo routine. There were two
errors. In the top section, the fifo was being read always from the
beginning word or the hw fito, but the updated word was written back
to the proper location.
The same error was in the section that dealt with the last < 4 bytes.
Both have been corrected. The error in the top section would in practice
be invisible because flow control prevents TPM fifo reads from
happening while one is in progress. The error in the bottom section
was responsible for the problem as described in chrome-os-partner:57782.
BRANCH=none
BUG=chrome-os-partner:57782
TEST=manual
Used special AP fw build that supports a 'tpm_raw' command to initiate
the Cr50 TPM fifo write/read.
'tpm_raw 0x80 0x01 0x00 0x00 0x00 0x16 0x00 0x00 0x01 0x7a 0x00
0x00 0x00 0x06 0x00 0x00 0x02 0x00 0x00 0x00 0x00 0x7f'
Without this CL, the 1st two bytes were incorrect ~50% of the time.
With the fix in place, verified that the first two bytes returned were
always correct.
Change-Id: Iff7620561eee463d599abfa6c07455c56bb5a5a6
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388785
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
cr50 should pretty much never reset, but when it does, for whatever
reason, the device it is running on must reset as well.
This patch makes every cr50 reset (be it command line induced, or
caused by an exception) a hard reset, such that it re-initializes the
R-box, which in turn causes reset of the entire platform.
CQ-DEPEND=CL:361680
BRANCH=none
BUG=chrome-os-partner:55948
TEST=verified that running commands like 'reset' or 'md 0xf0000'
(which triggers an exception) causes the entire chromebook to reboot.
Change-Id: Ifa160450b9b4c5ef25e512caf1ffdced9c97acd6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388007
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This locks the Cr50 console by default, and makes the unlock
process take the full 5 minutes unless the battery is removed.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; test on Gru & Reef
Build the image with
make buildall
or
make BOARD=cr50
Put it on Gru & Reef, and confirm that the console is locked, by
running "lock" or "help". Try to unlock it with "lock off" and
observe that you have to poke the power button for five minutes
before it unlocks.
Remove the battery and confirm that "lock off" now only requires
a single power button press to take effect.
Build the image with
CR50_DEV=1 make BOARD=cr50
and now the behavior is back to the way it was before this CL.
Change-Id: I9f2cc67a1dd63f260221a8711a8591070018be3b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/389238
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The assumption is that removing the cover and disconnecting the
battery is sufficiently obvious and time-consuming that it's not
necessary to sit there poking the power button repeatedly.
We still erase the NVMEM completely before unlocking, of course.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall; test on Gru
Toggle the Cr50 console with "lock on", then "lock off". Confirm
that the 5-minute process only requires one poke when the battery
cable is disconnected. Also confirm that both ways abort if you don't
press the button at all.
Change-Id: Iaa0f5eb102b914c95f3a34002438cbe80affcfb5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388879
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The Cr50 console provides access to all sorts of dangerous
commands. To protect user secrets, we must erase the persistent
storage before unlocking the console.
Note that this will not powerwash the AP, leaving you with the
impression that you've just forgotten your password. You'll have
to manually powerwash (Ctrl+Alt+Shift+R) afterwards. That will be
addressed in a future CL.
BUG=chrome-os-partner:55728
BRANCH=none
TEST=make buildall, test on Gru
Lock the console if it's not already ("lock enable"), then unlock
it with "lock disable". Confirm that the NVMEM region is erased
following a successful unlock process.
Change-Id: Iebcd69c9f757f5ab5d496218f065197d3f1f746c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382666
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Just a variable & comment renaming. No functional changes.
BUG=none
BRANCH=none
TEST=make buildall; test on Gru
At the console, try "lock on", "lock off". It works the same.
Change-Id: I65381d5550f68855be8d7961abbaa117dc97184b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/389237
Reviewed-by: Randall Spangler <rspangler@chromium.org>
To reset the TPM task, we send it an event so that it will reset
only when it's not busy doing actual TPM stuff that might fiddle
with the stack or shared memory. But that means that we can't
always know when the task finally gets around to resetting
itself.
This CL adds a tpm_reset() function that blocks until the reset
actually occurs. Obviously it can't do that if it's being called
in interrupt context or from the TPM task itself, but otherwise
it does.
BUG=chrome-os-partner:52366
BRANCH=none
CQ-DEPEND=CL:361680
TEST=make buildall, test on Gru, manual tests
In addition to the normal rebooting, logging in/out, and so
forth. I added a temporary console command to call tpm_reset()
and scattered a bunch of ccprintfs around it. When called due to
SYS_RST_L, it didn't block. When invoked with the console
command, it did.
Change-Id: I51e8b1299dbdcd1a12273cf48a890e93ed32a8c8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388125
Reviewed-by: Randall Spangler <rspangler@chromium.org>
1.ANX3429 have CC Rx buffer, when the partner sent one message,ANX3429
received this message into Rx buffer and triggered an interrupt to
inform (TCPM), at this moment Reef sends a CC message before reading
CC Rx buffer. After Reef sends this CC message successfully, it receives
the message the partner sent. So (TCPM) sees an unexpected message was
received, that`s why sends out hard reset.
Root cause:
ANX3429 use a normal R/W register as a interrupt status register.
Between EC read interrupt status and clear interrupt status, if
ANX3429 change interrupt status, it causes interrupt status is
incorrect on EC side.
Solution:
ANX3429 FW use two normal R/W registers for interrupt status reg,
one is for FW interrupt status,other is for EC control register.
Note:
Since cc messages conflict between TCPM and the Partner,ANX3429
shall discard the TCPM message, (TCPM) sometimes send soft reset
depend on the discarded message type.
2. Sometimes TCPM (Reef) does not response GoodCRC for a received mesg.
Root Cause: Reef send message conflict with ANX3429 send auto GoodCRC.
Solution: This is fixed in the 1.5 ANX 3429 firmware.
BUG=chrome-os-partner:53936
BRANCH=none
TEST=On Reef tested with ANX3429 FW v1.5, did not see HARD RST on
ec log with Zinger.
Change-Id: I81da95433e7a0cc71e7ed121b925afccbcd84b06
Signed-off-by: Swang <swang@analogixsemi.com>
Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/381014
Commit-Ready: Kevin K Wong <kevin.k.wong@intel.com>
Tested-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Rather than doing a full cr50 reset when the system reset SYS_RST_L is
asserted, just reset the state of the TPM task and library. Re-clear
.bss for those modules, then re-initialize.
BRANCH=none
BUG=chrome-os-partner:52366
CQ-DEPEND=CL:366792
TEST=make buildall; test on Gru
Trigger a SYS_RST_L by using the AP's reboot command, power
off/on, log in/out/in.
See that the Cr50 does not reboot and the firmware and userspace
are still happy about the TPM.
Change-Id: I32cd2bb72316f68c74db77a20a8d09112b402d4b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361680
This command will be used to perform power validation.
BUG=none
BRANCH=none
TEST=ectool extpwrlimit command can be used to set the max voltage/current
drawn from external charger.
Change-Id: Ic258954c1e3a714be7f648e77234dab594227ce0
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/388843
Reviewed-by: Shawn N <shawnn@chromium.org>
NPCX reboots by triggering the watchdog which in turn causes
the watchdog reset flag to be set as one of the system-wide
reset_flags. However, other software can confuse the presence
of the watchdog reset flag as a panic.
This patch selectively sets the watchdog reset flag only if we're
not explicitly doing a soft or hard reset or waking from hibernate.
Patch created by Mulin Chao <mlchao@nuvoton.com>
BUG=chrome-os-partner:56594
BRANCH=none
TEST=panic reset no longer observed
Change-Id: I016b59ffda4f6334cf41e196960edcbb87f6c049
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388853
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Use the FW reset register rather than the physical reset pin for
bd99955 power-on reset to avoid bad side effects during reset.
BUG=chrome-os-partner:57671
BRANCH=Kevin
TEST=Manual on kevin, do EC cold reset w/ 15V attached to port 0,
peripheral attached to port 1. Verify port 1 stays at <= 5V.
Change-Id: If90d754bf6256a50901132de0b2ccde69aec2ebe
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388757
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
(cherry picked from commit 80291c05a6e96d0042969980ab09b2549cb44a75)
Reviewed-on: https://chromium-review.googlesource.com/388748
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
INT_AP_L is used as a sync trigger to the host during i2cs
transactions. This signal is nominally set high and pulled up to
1.8V. However, when the AP is off, this line won't be pulled up which
would lead to excessive power draw by the Cr50 if this signal remains
driven high.
Added a change to set this signal as an input while the AP is powered
off. When the AP powers back up, it's changed back to an input and
driven high which is the default level.
BRANCH=none
BUG=chrome-os-partner:57733
TEST=manual
Change-Id: I12f175a7899eff6b90acb5a82282e526db3c1b9f
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388799
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
In order to help correlate EC logs with those from the kernel, it was
suggested that the EC could periodically print the RTC time. This
commit prints out the RTC time when changing power states.
BUG=chrome-os-partner:57731
BRANCH=gru
TEST=Build and flash kevin. Boot system up and suspend. Verify that
RTC times are logged to the EC console.
Change-Id: Ia1ee1ec88c6733f863a703fb3f841ab74b80fcb9
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/388802
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
In order to help correlate EC logs with those from the kernel, it was
suggested that the EC could periodically print the RTC time. This
commit prints out the RTC time when a chipset reset is requested.
BUG=chrome-os-partner:57731
BRANCH=gru
TEST=Build and flash kevin. Trigger watchdog from kernel and verify
that RTC time is printed when the chipset is reset.
Change-Id: Idc9a815c3337f720d41d16e0d844b4c1ea6728d8
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/388857
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This commit adds a function that allows the real-time clock to be
printed on the EC console. This could be helpful in trying to correlate
events between the EC's log and the kernel's.
BUG=chrome-os-partner:57731
BRANCH=gru
TEST=make -j buildall
Change-Id: I5e20692a173bddea3dc5c20cc0f2061cc170ce7d
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/388856
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Added i2ctest console command to test the reliability of the I2C.
By reading/writing to the known registers this tests provides the
number of successful read and writes.
BUG=chrome-os-partner:57487
TEST=Enabled the i2ctest config on Reef and tested the
i2c read/writes.
BRANCH=none
Change-Id: I9e27ff96f2b85422933bc590d112a083990e2dfb
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/290427
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The AP UART is used to detect if the device is in s0. When it is cr50
should not be in deep sleep for any reason. This change makes DIOA5 a
wake pin before entering deep sleep.
BUG=chrome-os-partner:56100
BRANCH=none
TEST=make buildall
Change-Id: Icb57824c0ca1421f5f508fce7cf5609010b91e32
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388793
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Added unlocked versions of register access,
modified RMW functions to use unlocked versions
and made them locked themselves.
BRANCH=master
BUG=chrome-os-partner:49182
TEST=DUT boots successfully
Change-Id: Ifd16abc349cc731aeed78b12989595214e65cea2
Signed-off-by: Victor Prupis <vprupis@google.com>
Reviewed-on: https://chromium-review.googlesource.com/377151
Commit-Ready: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This change sets UART_FIFO_RXILVL to 3 for the AP and EC UART. With this
change RXINT will only be triggered when 4 characters are received
instead of for every character.
The change also flushes the RX FIFO whenever console input is received
through usb make sure to the user can see their input as they are typing.
BUG=none
BRANCH=none
TEST=run taskinfo after the system finishes booting.
Before Change the IRQ count for 181 should be around 20000.
After the change it should be around 5000.
Use the AP and EC console over USB and verify there is no
noticeable change in their usability.
Change-Id: I134ea0d2bc254038dad6c341b94f822adb90c000
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/387175
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
BUG=chrome-os-partner:54332
BRANCH=none
TEST=verify only zinger is detected in sink mode (G3/S5), and both
zinger and hoho is detected in dual role mode (S0).
Change-Id: Ifce0009908acc4b1849723ce807ca1b4c8e26020
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/387260
Reviewed-by: Shawn N <shawnn@chromium.org>
