When you run a test suite, cts will now save your
results for the suite/dut combo as a basic html page
BRANCH=None
BUG=None
TEST=Manual
- Connect dut, th
- Build/flash desired test suite
- Run './cts -r' to run tests
- Open /tmp/cts_results/<board_name>/<test_suite>.html
- You should see a table with test names/results
Change-Id: Id3de3bd7833be1bc5dde437c516db411aac47579
Reviewed-on: https://chromium-review.googlesource.com/362091
Commit-Ready: Chris Chen <twothreecc@google.com>
Tested-by: Chris Chen <twothreecc@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added in classes for Board (parent), DeviceUnderTest,
and TestHarness. Reading, etc. should be easier now
BRANCH=None
BUG=None
TEST=Manual
- Build default
- Flash default
- Run
- Open /tmp/cts_results/nucleo-f072rb/gpio.html
- Should see a clean results page
Change-Id: Ide3f75281f0b5b8b40dabd36f8c239737dc527d6
Reviewed-on: https://chromium-review.googlesource.com/364236
Commit-Ready: Chris Chen <twothreecc@google.com>
Tested-by: Chris Chen <twothreecc@google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This change disables sleep only when a cable is actually detected.
Before it would disable sleep no matter what and if a debug cable was
not plugged in and then deteached then it would never enable it.
BUG=none
BRANCH=none
TEST=manual
update cr50
unplug suzyq
boot to kernel
verify cr50 is asleep
run 'powerd_dbus_suspend'
cr50 will wake up for like a second then go back to sleep
run 'apreset' on EC console
boot to kernel
verify cr50 is asleep
run 'powerd_dbus_suspend'
cr50 will wake up for like a second then go back to sleep
Change-Id: I8337f694853b7840ef932b38bd0fa6453d31cb3d
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366861
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Add a case statement to handle HCI commands.
Add a test commands.
Try to match the hcitool syntax, so the same commands
can be executed on a Linux host.
Added lcmd (long cmd) to pass more parameters in fewer arguments
BUG=None
BRANCH=None
TEST=Use HCI commands to configure an advertiser and listen for
it using `hcitool lescan` on the host.
Change-Id: Ie28038847c9549eb1c27a605aa0fbad5efd3b2c7
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362145
Commit-Ready: Dan Shi <dshi@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
I keep thinking this refers to "Embedded Controller" instead of
"Elliptic Curve Cryptography". Make it clearer.
There's no functional change, I'm just renaming a constant.
BUG=none
BRANCH=none
TEST=make buildall; run tests on Cr50 dev board
make -C test/tpm_test && sudo ./test/tpm_test/tpmtest.py
Change-Id: Iaf2e2839e88fdbbcb1a712934be56a0dd47e4a70
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366752
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Our UART interrupt must be able to preempt our SHI_CS interrupt,
otherwise console input may be lost. Adjust our relative IRQ priorities
to accommodate this.
BUG=chrome-os-partner:55920
BRANCH=None
TEST=Run `echo "kbpress 11 4 1" > /dev/pts/17` on kevin 200 times from
the recovery screen, verify that all input is received by the EC.
Change-Id: I36203511f5883272287ac22d0704098fbd933758
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366622
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Add __keep attribute to irqprio entries to ensure they are not dropped
when CONFIG_LTO is enabled.
BUG=chrome-os-partner:55920
BRANCH=None
TEST=Manual on kevin. Check build/RO/ec.RO.map, verify that
.rodata.irqprio section is not empty.
Change-Id: I51ae23556d6f46b2cd7ba098f0e7a785292b2853
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366571
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
KSI2 get stuck when Refresh+Pwrbtn is used to reset EC,
so it was not able to detect the Esc key if it is also
pressed to enter recovery mode.
BUG=chrome-os-partner:55548
BRANCH=none
TEST=Reef EVT is able to enter recovery mode with Esc+Refresh+Pwrbtn
Change-Id: I0539e8fad9980cb563de94417079fe763c311887
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/366411
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Previously, the strapping configuration pins were only being
read following a POR reset event. In all other cases, the
strapping configuration was presumed to be stored in a long
life register. An issue with this method is that when Cr50
FW is upgraded (via Suzyq), there is no POR reset event until
either the battery becomes fully discharged, or the battery
is manually disconnected. Without a POR, following a FW upgrade,
the long life register will contain 0 and so neither the SPI
interface (on Kevin/Gru) or I2C interface (on Reef) will be
properly initialized.
Come to think of it, the contents of the scratch register should never
be zero unless this is a power on event, or a restart after migration
from the version not setting the scratch register.
Let's read the scratch register always if its contents are zero.
BRANCH=none
BUG=chrome-os-partner:50728
TEST=manual
Via the Cr50 console, cleared the long life register with
temp console command. Then executed a FW upgrade with Suzyq
and verified that the strapping pins are read and the correct
value is stored in the long life register. Note that 'reboot'
commands from either the Cr50 or EC console do not cause
a hard reboot.
Change-Id: I1b3aa92552b14bde9bda848aa3dc4c8221ce73a9
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366390
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
The input should be active low, not active high.
BUG=chrome-os-partner:49959
BRANCH=none
TEST=manual
Remove and reattach the battery. "gpioget BATT_PRES_L" shows the
GPIO value changing appropriately.
Change-Id: I7d513471f6ab5e7e8cd0e601148915697fa9162a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366134
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
There are few reasons why the SoC may reboot which we haven't
been reporting (they just show up as "[Reset cause: other]").
This adds a bit of decoding to explain some of those "other"
reasons.
BUG=none
BRANCH=none
TEST=make buildall; try on Cr50
I tested one of the new reasons using "crash hang". It shows up
correctly as "{Reset cause: security]". I haven't specifically
tested all of the new reasons, but since this is basically just a
change to console message they should work too. I'll double-check
those cases once some blocking bugs are fixed.
Change-Id: I46daed29d7e37bda9034a3486127bed0ea25f803
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366400
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The crash command is used to intentionally invoke various failure
modes in a running system. This adds one more (and cleans up the
command slightly). The "crash hang" command does the same thing
as "crash watchdog", except that it disables interrupts first.
Some SoCs may require special handling to recover from that case.
BUG=none
BRANCH=none
TEST=make buildall; run on Cr50 hardware
Invoked all the options to the crash command, observed that the
appropriate response occurred in each case (a stack trace if
possible, followed by a reboot).
Change-Id: I18897cfc04726e6aeda59f4c6e742d7a0037cf80
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366127
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
This change fixes two issues. The first issue is that during rdd_init
debug_detect is set to the value of DEBUG_STATE_MAP. Debug_detect should
be the default map value of 0x420 which triggers an rdd interrupt when
cc1 and cc2 both have a value of 011 or 001. This will detect when a
debug cable is attached. ~debug_detect should detect when the cable is
detached.
The issue is after a soft reset DEBUG_STATE_MAP is not reset to the
default value so on the next rdd_init debug_detect was set to whatever
was DEBUG_STATE_MAP was last set to. If the debug cable is detected
before the soft reset then DEBUG_STATE_MAP will have a value of
~debug_detect and when rdd_init is called then debug_detect will be
initialized to that value of ~0x420. Now debug_detect does the opposite
of what we expect it to do. debug_detect detects when the cable is
detached and ~debug_detect detects when it is attached.
rdd_interrupt is called cr50 reads cc1 and cc2 and sees that a debug
accessory is attached so it sets DEBUG_STATE_MAP to ~debug_detect.
Because debug_detect does the opposite of what is expected then it will
trigger an interrupt when it detects a debug accessory. The debug
accessory is already attached so an interrupt is triggered. It reads cc1
and cc2 sees the debug_accessory attached resets the map to
~debug_detect. This cycle continues until the watchdog resets the
system. After this reset rdd_init reads the map to get debug_detect and
it is 0x420 because that is how it was last set and then rdd works
again.
This change fixes this issue by defining DEBUG_DETECT to be 0x420 and
not using the STATE_MAP value to do it.
It also looks like when the EC is off and we change the value of the
debug map, another RDD interrupt is triggered. Then it reads the debug
state and resets the map again another interrupt is triggered. It
continuously does this.
This change adds a check to see that the RDD was trying to detect the
state it currently senses before doing anything so the second interrupt
will be ignored.
BUG=chrome-os-partner:55793
BRANCH=none
TEST=manual
plug in a reworked suzyq
Flash the EC
verify a bunch of RDD interrupts aren't triggered and the
reworked suzyq can be used.
plug it in and out a couple of times to make sure everything
works.
Change-Id: I6f4e7b15cf9c53b965533df7fe23fae5b340f70d
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364724
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This reverts commit 25f19f5bbd, which was
causing host command issues after sysjump. IBUFSTAT seems to behave
strangely. Additional investigation is required.
BUG=chrome-os-partner:55710,chrome-os-partner:55795
BRANCH=None
TEST=Verify host commands continue to work after sysjump.
Change-Id: Id94a9c4677bcae597b9353e081418e649e823564
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366173
Reviewed-by: Randall Spangler <rspangler@chromium.org>
when the daughter board is not connected, TCPC1 INT# (USB_C1_PD_INT_ODL)
will be floating since the external pull-up is located on the daughter
board as well, and this floating signal will cause an interrupt storm
and eventually cause a watchdog.
BUG=chrome-os-partner:55488
BRANCH=none
TEST=verify board no longer has watchdog reset when daughter baord
is not connected.
Change-Id: If1d73fa7d90f6ac52fd1ab0ac563a6bf5fd10dc0
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/365499
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reef doesn't have the battery temperature sense pin connected to
the charger, hence reading the battery temperature from the battery
registers.
BUG=chrome-os-partner:55834
BRANCH=none
TEST=Using 'battery' & 'temps' console command verified,
temperature readings are same from both the commands.
Change-Id: I897e453296151f31344f3e0434202baa67c7025d
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/365970
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
There is just one version of Cr50 firmware for all boards
that it's used on. However, on some boards the AP communicates
to the TPM via a SPI interface (i.e. Kevin) and on others, the
AP communicates via an I2C interface (i.e. Reef). In order to
dynamically discover which interface to configure, there are
strapping resistors added to the board which enables the Cr50
to detect which configuration to implement.
This CL is a first pass and is only looking at DIOA1 which is
pulled high for SPI and pulled low for I2C configurations.
The strapping resistor should be read when the AP is in reset
prior to it attempting to drive any of the lines used for
strapping. To ensure this condition is met, Cr50 will only
check the strapping options following a POR (power on reset).
Once the configuration type is discovered, a 'long_life'
register is used to hold the result so that the result can
always be available. The long_life register contents remain
unchanged until a subsequent power down event.
BRANCH=none
BUG=chrome-os-partner:50728
TEST=manual
Tested on Kevin and Reef. Verfifed by reading the stored value
that the SPI configuraiton is detected for Kevin and the I2C
interface is detected on Reef. In addition, verified on Kevin
that the Cr50 FW version is correctly reported to the AP which
means that TPM register reads via the slave SPI are functioning.
Change-Id: Ibd7624ad8e3b4126f6346dce0bc72f62a3cc6d18
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363014
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Watchdog events are delivered as internal ARM interrupts, so we
can print a crash dump and then reboot. However, if interrupts
are disabled when the watchdog triggers, it just hangs forever.
This CL configures the watchdog and processor lockup events to
trigger a hard reboot through a security alert. This is the only
way to make these events non-maskable.
BUG=chrome-os-partner:52597
BRANCH=none
TEST=manual
I added this console command:
static int command_hang(int argc, char **argv)
{
interrupt_disable();
while (1)
;
return EC_ERROR_UNKNOWN; /* Not reached */
}
DECLARE_CONSOLE_COMMAND(hang, command_hang, NULL, "Hang", NULL);
Without this CL, that command locked the SoC up until it was
reset from outside. With this CL, it reboots after a couple of
seconds.
Change-Id: I773c0138fd2243cdbcdd86b2c7138520155d7920
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365531
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
RADIO_STATE is broken: remove it.
Build on the geneneric radio support to send and receive
Bluetooth LE packets.
Add macros in registers.h to configure PCNF0 and PCNF1.
BUG=None
BRANCH=None
TEST=Send advertisements with console commands
ble_adv type length [interval_us]
for example: ble_adv 2 8
Advertisements should be received by other devices
The Bluetooth Address has the form C5:A4:A3:A2:A1:A*
The device name is a substring of ABCDEFGH...
ABCDEFGH @ C5:A4:A3:A2:A1:A2 (name length is 8, type is 2)
ABCDEFGH @ C5:A4:A3:A2:A1:A2 (name length is 8, type is 2)
ABCDEF @ C5:A4:A3:A2:A1:A6 (name length is 6, type is 6)
TEST=Listen for advertisements with console commands
ble_adv_scan chan [num] [addr0]
for example: ble_scan 37
Example output:
BLE packet @ 20000448: type 2, len 33,
5c.f3.70.6b.65.d2 AdvA
20000454: 02 01 08 17 09 43 68 72
2000045c: 6f 6d 65 62 6f 78 20 66
20000464: 6f 72 20 4d 65 65 74 69
2000046c: 6e 46 16
02 01 08 = 2 bytes, Flags, LE and BR capable
17 09 43... = 23 bytes, Name, "Chromebox for Meetings"
Change-Id: I2bd3f1d87acb069da0b56c1d7878e7d4fd6a06f3
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361960
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Levi Oliver <levio@google.com>
This adds a hook that will run every second and complain if the EC
firmware was built for the wrong board.
BUG=chrome-os-partner:54947
BRANCH=none
TEST=tested on proto and EVT units
Change-Id: I9799249f74f3cea9a3f6b66b2441af8f16be7e01
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365505
Reviewed-by: Martin Roth <martinroth@chromium.org>
ESC+F3+Power+AC removal puts the battery into a soft-disconnect state
where is stops supplying current. Revive batteries in this state by
supplying a precharge current.
BUG=chrome-os-partner:55858
BRANCH=None
TEST=Manual on reef. Put battery into soft-disconnect state. Attach
charger and verify EC doesn't lose power and battery again supplies
current.
Change-Id: I9a772bf02a8bd40edc1db51de66de135f7299212
Signed-off-by: Rachel Nancollas <rachelsn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365495
Commit-Ready: Rachel Nancollas <rachelsn@google.com>
Tested-by: Rachel Nancollas <rachelsn@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Default to set DUT_CC1 to RD to enable USB and indicate
USB SS orientation. Add ADC entries for SBU detect.
BUG=chromium:571476
TEST=check that ADC maps to the right pins, check that usb3 initializes.
BRANCH=None
Change-Id: Ic9f7c6d1506b9ef83ed3b93a98516ab10b1a471c
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364301
Reviewed-by: Todd Broch <tbroch@chromium.org>
Only report alert status if the PD chip is not being held in reset.
(idea borrowed from Amenia's implementation)
BUG=none
BRANCH=none
TEST=built and booted on reef
Change-Id: Ic637b1ab4e20527c806311a45c149b9ea5f64362
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360020
Reviewed-by: Martin Roth <martinroth@chromium.org>
Proto brought up 5V, 3.3V, and PMIC very early in the EC boot process
due to dependencies in the power topology. This had some other side-
effects, for example, a lot of the power rails would already be up by
the time the EC got around to processing the power state machine thus
leaving it waiting for signal changes that were supposed to come
later but had already occurred instead.
This patch updates the nominal codepath for rail and PMIC init on EVT
while using IS_PROTO to retain the Proto sequence if desired.
BUG=chrome-os-partner:54962
BRANCH=none
TEST=built and booted on proto and evt boards with subsequent patches
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: If9ddd41044f132e719b0b7f0ab80ed908ddb1d9b
Reviewed-on: https://chromium-review.googlesource.com/358913
Reviewed-by: Martin Roth <martinroth@chromium.org>
This removes write-protect ranges that are unnecessary so
that we save a bit of space.
BUG=chromium:633431
BRANCH=none
TEST=compiled only.
Change-Id: Ib34c6a125b001fc92a21f795ac3d922e77143342
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365210
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Print the reply bytes, be more consistent between %d and %x.
BUG=none
BRANCH=none
TEST=manual
Build debug version, verify that it prints more stuff.
Change-Id: I8c8a983360f4895ccc72b73ed67ce2d45a461bad
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365120
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
The kernel DP driver do not support hpd gpio detect, it use
EXTCON_DISP_DP cable state to decide power on/off DP PHY. Hence, do not
change GPIO_USB_DP_HPD level, but set or clear the TYPEC_MUX_DP when hpd
level changing in attention.
BUG=chrome-os-partner:52872
BRANCH=none
TEST=keep Type-C Dock inserted
1. plug HDMI cable, check with "ectool usbpdmuxinfo"
Port 0: USB DP
2. unplug HDMI cable, check with "ectool usbpdmuxinfo"
Port 0: USB
Change-Id: I369a92135bf0ca177e81eab6385980d51d863172
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/364401
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The chip revision and board version show up on the second line of
the returned string, immediately before the build info.
BRANCH=none
BUG=chrome-os-partner:55558
TEST=Queried version string using tpm_test
make -C test/tpm_test && sudo ./test/tpm_test/tpmtest.py
Starting MPSSE at 800 kHz
Connected to device vid:did:rid of 1ae0:0028:00
RO_A:* 0.0.2/d0c9abe3 RO_B: 0.0.2/13eda43f RW_A: cr50_ [...]
B2:0 cr50_v1.1.5013-ab0e228+ [...]
^^^^
Change-Id: Iaa1efe5dca441aca24f281f76c1f218e24c844be
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365421
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
Enable the SHI interrupt only after we have received and begun
processing our host command. Disable the SHI interrupt once our
transaction is complete (with either success or error status). This will
prevent the SHI interrupt from being asserted at the same time as the CS
interrupt, which can lead to the SHI interrupt being serviced first.
Also, it avoids needless, non-useful SHI interrupts during error
transactions.
BUG=chrome-os-partner:55710,chrome-os-partner:55795
BRANCH=None
TEST=Manual on gru. Stress test flashrom w/ unpowered Donette attached
(for host command spam), verify no errors encountered after 100 minutes.
Change-Id: I0ab20b0202ebcfe15c04b272ec67001a6a358dad
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364698
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Add functions to initialize and disable the radio.
Add packet definitions.
Update the spelling of the FICR_OVERRIDEEN register.
BUG=None
BRANCH=None
TEST=make buildall -j
Change-Id: I3a9e500d0f177b6ce77a3b6ed6a42acd4f49eb7e
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362175
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Levi Oliver <levio@google.com>
Image sizes must be aligned to block erase size to ensure that the host
can erase the entire image and nothing but the image.
BUG=chrome-os-partner:55828
BRANCH=None
TEST=Manual on kevin, rebuild FW with new EC, rebuild + flash EC once
again, verify that SW sync completes and unit boots to OS.
Change-Id: If6110f39869d6421038a3fe7afdc7d918323249e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365142
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Both build string (which includes status of all firmware components of
the running image) and the firmware version string (which show
versions of various objects in the flash) are important to the user.
Let's include both of these strings into the TPM_FW_VER register
output. Buffer storing the string needs to be increased accordingly.
BRANCH=none
BUG=chrome-os-partner:55558
TEST=verified the contents of the AP firmware console log:
localhost ~ # grep cr50 /sys/firmware/log
Firmware version: RO_A: 0.0.1/84e2dde7 RO_B:* 0.0.2/13eda43f RW_A: ...
cr50_v1.1.5003-af11829+ private-cr51:v0.0.66-bd9a0fe tpm2:v0.0.259-8f3d735...
Change-Id: I67df3e810bd07053d0b7d8b6fac350253ca06bb0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364830
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Cr50 cant retain the TPM state in deep sleep so it wont be enabled until
it knows that the AP is off. If the AP is off it wont be asserting
SPS_CS_L, but it may be low because the AP isn't pulling it up.
This change disables it as a wake source in deep sleep.
BUG=chrome-os-partner:54796
BRANCH=none
TEST=run 'idle d'. Make sure cr50 goes into deep sleep and only resumes
due to a rdd event or when sys_rst_l is asserted.
Change-Id: Idf3ded6b439b71a27ac7eb4682a65dcdd6342cb9
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364864
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The existing algorithm makes several assumptions for a particular
thermistor circuit. This patch introduces a more generic version
that can be used for multiple thermistors on a single board.
The idea is to approximate a curve produced by solving for voltage
measued by an ADC using the Steinhart-Hart equation. For a straight
line one only needs two data points. For a steady curve data
points can be distributed evenly. For the most part, though, data
points should be provided after a significant change in slope.
More data points give more accuracy at the expense of memory, and
we mostly only care about accuracy in the range between "warm"
and "too hot" so only a few data points should be used.
BUG=chrome-os-partner:54818
BRANCH=none
TEST=added unit test, needs real testing
Change-Id: I046e61dbfd1e8c26c2a533777f222f5413938556
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/344781
Reviewed-by: Shawn N <shawnn@chromium.org>
Increasing the USB console TX buffer size allows to see pretty much
all early startup messages generated before USB console is
initialized.
There is still plenty of room left in SRAM, 23K on cr50, much more on
all other g based boards.
BRANCH=none
BUG=none
TEST=observed better USB console output on cr50 restarts.
Change-Id: I82f37ee7f3aecd8b7e95f3d421789c11375b2fd4
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364811
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Nadim Taha <ntaha@chromium.org>
As the version string grows longer, reading it in 4 byte chunks
becomes more and more expensive, the overhead of setting up a separate
SPI transaction per very chunk is just too much.
There is no reason not to allow the host to read as many bytes at a
time as it requires (limiting it by the maximum version string buffer
size of course).
BRANCH=none
BUG=chrome-os-partner:55558
TEST=verified that the version string is still read properly by the
TPM driver on Kevin
Change-Id: Ib76cd151e8dc32374f87135af36266b4ec725a56
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364831
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The only place where two separate buffers for the RO version strings
is required is the tpm_registers.c:set_version_string() function.
In preparation of reporting the build string along with the version
string, let's rearrange the function not to require separate buffers
for the RO versions.
BRANCH=none
BUG=chrome-os-partner:55558
TEST=verified that version reported by the TPM driver on Kevin is
still correct:
localhost ~ # grep cr50 /sys/firmware/log
Firmware version: RO_A: 0.0.1/84e2dde7 RO_B:* 0.0.2/13eda43f RW_A:*...
Change-Id: I8924ac48bd838851670f0d659e95aa92a8524665
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364587
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Some boards now provide very long build version strings including
version strings of multiple subcomponents.
Let the version command split those long lines printing each
subcomponent's version string in a separate line.
BRANCH=none
BUG=chrome-os-partner:55373
TEST=verified on cr50:
> vers
Chip: g cr50 B2
Board: 0
RO_A: 0.0.1/84e2dde7
RO_B: * 0.0.2/13eda43f
RW_A: * cr50_v1.1.4980-2b9f3e1
RW_B: cr50_v1.1.4979-8cec36d+
Build: cr50_v1.1.4980-2b9f3e1
private-cr51:v0.0.66-bd9a0fe
tpm2:v0.0.259-2b12863
cryptoc:v0.0.4-5319e83
2016-07-28 20:40:55 vbendeb@kvasha
Change-Id: Ie14af3aa9febd5a3b02b273a7ab6302e74777e43
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364491
