FUSE_CTRL_OVERRIDE overrides all rbox fuse values with the values in
RBOX_DEBUG not just the ones that are explicitly set. This change
removes the override from rbox.
BUG=chrome-os-partner:54238
BRANCH=none
TEST=on gru and kevin check that pressing 'c' registers on the EC.
Change-Id: I655e9ca96e52359a7d36e0d691f838c335df8cb8
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/353033
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: David Schneider <dnschneid@chromium.org>
loader/key_ladder.c depends on debug_printf(). Refactor
the printf function so that key_ladder.c need not depend
on main.c.
This change being made in preparation for a future
change which introduces a dependency between RW and
key_ladder.o
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=build succeeds
Change-Id: I5c9bf7bd6dd9f76ab6410e6e797973bdb072ec16
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/351760
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Add a certificate verifier, so that endorsement
certificates may be verified upon installation.
Doing so allows for catching certificate errors early.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=all tests in test/tpm_test/tpmtest.py pass
Change-Id: I9339a6bc36e4d82ae875ce774e31848ae983fa1f
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/351031
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
State that needs to survive re-flashing
of RO+RW is stored in the INFO bank. An
example of such state is manufacture secrets,
which need to survive reflashing from the
personalize firmware to the initial TPM2
firmware.
This change adds support for writing to
the writeable flash info bank.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=manually verified info1 reads and writes
Signed-off-by: nagendra modadugu <ngm@google.com>
Change-Id: I9226e2161e036d1dacccbe55b67724b449983008
Reviewed-on: https://chromium-review.googlesource.com/351274
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This commit includes changes required for
supporting a hardware based montgomery
modexp (r = a ^ e mod N).
The function bn_is_bit_set() was previously
static, and now added to internal.h, as this
function is used by the hardware implementation.
Add function declarations for new functions
related to the hardware implementation to
chip/g/dcrypto/internal.h
BRANCH=none
CQ-DEPEND=CL:*260618,CL:*260895
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=all tests in test/tpm_test/tpmtest.py pass
Change-Id: I5fe4a6692678b64f27659f42a08d200b6fe6f0cc
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/347462
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Instead of enabling the SOF calibration at usb_init(), enable it
only when the first SOF packet is seen following the usb_init(),
as suggested in the recommendations document linked from the bug
report.
Also fix the code to do the right thing. The original reference
code had errors.
BUG=chrome-os-partner:50800
BRANCH=none
TEST=make buildall; test on Cr50
After adding some instrumentation code, I see the SOF being
detected and the calibration started. It only happens once after
each usb_init() and only when the USB traffic begins.
Change-Id: Id2b9a41d90ce9cc9e467fb759463d69a57bb5540
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/350371
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
While in CCD, cr50 can be used to flash the AP and EC through USB. This
change adds an endpoint that can be used to read, erase, and write to
the AP and EC spi rom.
Currently CCD is not enabled on cr50, so usb_spi access has to be
enabled manually through the cr50 console.
BUG=chrome-os-partner:50701
BRANCH=none
TEST=manual
On EC console run 'flash_tristate true'
On cr50 console run 'usb_spi enable'
Use 'flashrom -p raiden_debug_spi:target=EC' and
'flashrom -p raiden_debug_spi:target=AP' to interact with
the AP and EC flash
CQ-DEPEND=CL:342144
Change-Id: I9c31dab252a8bfbc498eaf64ac5c2f53ec9dde30
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/342511
Port SHA and P256 code to depend on third_party/cryptoc.
Remove config options CONFIG_SHA1, and CONFIG_SHA256 as
these are provided by third_party/cryptoc.
Also remove unused config options CONFIG_SHA384, CONFIG_SHA512.
Crypto functions prefixed by dcrypto_ (declared in internal.h ),
DCRYPTO_ (declared in dcrypto.h) are implemented under
chip/g/dcrypto, and otherwise are implemented under third_party/cryptoc.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524,chrome-os-partner:53782
TEST=all tests in test/tpm_test/tpmtest.py pass
Change-Id: If7da02849aba9703573559370af5fae721d594fc
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/340853
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This could be a pain, but we do no want to keep any state when cr50
firmware is upgraded.
BRANCH=none
BUG=chrome-os-partner:44745, chrome-os-partner:51977
TEST=not much yet, will be tested when debugging cr50 functionality
Change-Id: Ic26d3f9f20c6edb77c76c941d04c31948f02be20
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348292
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This change is motivated by an internal use case.
BRANCH=none
BUG=none
TEST=make buildall -j
Successfully used the exported functions on Cr50.
Change-Id: I5a54b4ea407866c7d7a4bd075d7773ac81e00930
Signed-off-by: Nadim Taha <ntaha@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348215
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This fixes two race conditions that lead to a watchdog timeout:
1) ticks_to_usecs()
common/timer.c:process_timers() wraps its body in a
"while (next.val <= get_time().val)" loop meant to ensure that
it never returns after having scheduled an expired timer
(to address potential __hw_clock_event_set() overflows/underflows).
However get_time() through __hw_clock_source_read() calls ticks_to_usecs()
which "expands" the hw_rollover_count by a truncated clock_div_factor which
causes that loop condition to observe a "current time" that is up to ~15us
in the past (assuming a 24MHz clock). This race arises frequently with
workloads that repeatedly sleep for a short duration.
2) __hw_clock_event_irq()
The HW timer rollover interrupt was configured to be higher priority than
the event timer interrupt (i.e. it can preempt it) which is problematic if:
- There is a scheduled deadline soon after a "clksrc_high / .le.hi" boundary
- An earlier (before the clksrc_high rollover) event timer interrupt kicks in
- After the event timer interrupt handler gets to "now = get_time()"
in common/timer.c:process_timers() the rollover interrupt triggers
incrementing clksrc_high (i.e. the overflow case)
- The rollover interrupt handler arms the event timer to trigger at
that deadline (mentioned in the first bullet) and returns
- The original event timer interrupt handler resumes execution but finds
no events to schedule since the "timer_deadline[tskid].le.hi == now.le.hi"
clause won't evaluate to true. It will then call __hw_clock_event_clear()
before returning causing a watchdog timeout
This commit also contains a fix to properly initialize the HW timer
after a sysjump.
BRANCH=none
BUG=none
TEST=Reproduced both races and successfully tested the fix. The workload I was
using to reproduce (typically within an hour) has been running smoothly
for the past 24 hours.
Change-Id: Ic0b0958e66e701b52481fcfe506745ca1c892dd1
Signed-off-by: Nadim Taha <ntaha@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347465
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When the AP or EC is off, the RX line is low. Holding the UART RX line
low causes an interrupt storm. This change disables the UART TX and RX
on the peripheral when the device is powered off so the interrupts wont
be triggered.
BUG=chrome-os-partner:53514,b:28885578
BRANCH=none
TEST=run taskinfo on cr50 and make sure the IRQ count for 181 is a
reasonable number.
Change-Id: I42c779253860a2b1dd27ab41fb7097c887cc23ff
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347355
Use the power and servo connection states to enable and disable the
EC and AP UART output. Contention between the cr50 and servo
can prevent either uart from working, and possibly damage kevin or
servo. If both UARTs are enabled, then cr50 cant know if servo is
connected, so it is best if the UARTs are disabled before connecting
servo.
If servo is connected or if a device is not powered on then the UART
output wont be enabled. The two UARTs are enabled separately and one can
be enabled without the other. Any disabled UART will be monitored for a
servo connection. If servo is detected, then all UARTs will be disabled.
BUG=chrome-os-partner:52056,chrome-os-partner:52322
BRANCH=none
TEST=manual
Power on the EC only. Check only the EC UART is enabled.
Without disabling the uarts power on the AP and verify both are
now enabled.
Turn of the AP. run 'uart enable. Verify only the EC UART is
enabled. Then attach servo and check that the AP and EC UART
are disabled.
Change-Id: Ife27c9360e91b07f86ff8bfcec7f4fd423c31d25
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/342828
There are a couple of issues that cr50 has when it cannot know the state
of servo, the EC, and the AP. This change adds support so we can detect
when the AP or EC has been powered on and when servo has been connected.
It uses the UART RX signals to monitor the power state of the AP and EC.
The TX signals are used to monitor the state of servo.
BUG=chrome-os-partner:52056,chrome-os-partner:52322
BRANCH=none
TEST=verify device states are correct when the AP and EC are powered on
or off and when Servo is attached or detached
Change-Id: Id0a2281b65cb367ecc8d0ca2f9a576672318a5fb
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/344019
The timer clock nominally requires no firmware settings. It is
tuned in manufacturing to be centered around 24MHz. However, it
will potentially migrate away from 24MHz based upon variations in
temperature and voltage. The variation is approximately
0.1-0.5MHz, based upon functional simulations, and backed up with
observations in the lab. This CL enables a hardware feature to
dynamically tune the timer clock if the device has an active USB
port, by monitoring the SOF (start of frame) USB packets that are
sent by the USB host every milllsecond with 500ppm accuracy.
BUG=chrome-os-partner:50800
BRANCH=none
TEST=make buildall; run on Cr50 hardware
Verified that deep sleep, USB suspend/resume, etc continue to
work with this enabled. Not too surprising, since I've never
encountered a problem without it.
In addition, I monitored XO_CLK_TIMER_CURRENT to see that the
timer adjustments are being made while connecting and
disconnecting from USB, entering andleaving sleep and deep sleep,
etc. They are.
Change-Id: I328b6416bc40ef8718815c5e09cf91ec1c6646f0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/342145
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
BUG=chrome-os-partner:52576
BRANCH=none
TEST=make buildall; try on Cr50
I manually tested both highsec and highperf variants, as well as
forcing the bootrom init to run. All the bank registers were
loaded with meaningful values, and none of the SPI or USB
functionality showed any problems.
Change-Id: Ia91ba98ef4c667aec74195c4a7bbf72a5d1c8b2d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/342030
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
With this new protocol version the target watches the size of the
received messages while reassembling an upgrade block.
If a message of the header size arrives and it is not the last message
of the block, the target considers it a re-start of the block transfer
by the host (presumably because a chunk was lost and the host did not
receive a confirmation of the block transfer in the preceding block
transfer attempt.)
BRANCH=none
BUG=chrome-os-partner:52586
TEST=the upgrade command on the host reports target running protocol
version 2, upgrades on B1 board still run smoothly.
Change-Id: I2e16c1be5135c0b5a4f09ea293f09ecabf59ecb3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341630
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
When a new upgrade block starts, the host sends first a 12 byte
message including the block size and header.
The target must verify that the message is of the proper size and the
contents make sense (the header is not all zeros). It also should
drain the USB queue completely in case it holds a message of a
different size.
BRANCH=none
BUG=chrome-os-partner:52856
TEST=upgrade still works fine on B1
Change-Id: I80538a3a1a5d507a84bd21b868a3db626bc6a4b0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341619
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
When an upgrade transfer starts, the target expects to receive a 12
byte transfer start message from the host, carrying an empty payload
of all zeros.
The target and host can be out of sync for whatever reason, so when
the target is expecting a transfer start message, the host can be
sending a chunk of a code block instead. In this case the target pulls
just 12 bytes off the receive queue, leaving the rest of the chunk
there, which even more complicates error recovery.
This patch makes sure that when expecting the upgrade transfer start
message the target extracts all receive data from the queue, no matter
how many bytes have been received, and then verifies that the size
matches the expected size, and that the payload is all zeros, to
confirm that the message is indeed the transfer start message.
BRANCH=none
BUG=chrome-os-partner:52586
TEST=cr50 firmware upgrade still works fine on B1
Change-Id: If5ec86d0385f97f0f361635b3903cea3a962b707
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341618
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The original version of usb_upgrade does not provide for any error
recovery and also does not support any protocol version notion.
Real life experience has shown that error recovery is essential, it
needs to be introduced as a protocol enhancement. We want to stay
backwards compatible though, so there is a need for protocol
versioning.
In the original version of the protocol target response is always the
same: a 4 byte number which is the error code (and zero means no
error). This patch modifies response to the very first packet from the
host, the startup packet. The startup response is 8 bytes long. The
first 4 bytes is still the same as before, the second 4 bytes carry
the protocol version supported by the target, an integer in network
byte order.
Thus, receiving a 4 byte reply to the startup message tells the host
that the target is running protocol version zero, 8 byte reply carries
the actual version number in the last 4 bytes.
The USB transfer function on the host is enhanced to accept responses
shorter then expected, when allowed.
BRANCH=none
BUG=chrome-os-partner:52856
TEST=usb_updater can successfully update both old and new cr50 images,
properly reporting protocol version as 0 or 1 respectively.
Change-Id: I9920d2708b21f29615282161fc0eb027018f9378
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341617
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
We want to be able to communicate with the chip no matter what the
hardware conditions are, otherwise it is easy to lose the ability to
re-program it from the external connector.
With this patch the chip always comes up with the USB interface
exposed and will stay in this mode until debug cable is pulled out.
After that it will honor subsequent cable plug ins/pull out events as
designed.
BRANCH=none
BUG=chrome-os-partner:52281,chrome-os-partner:50700
TEST=Suzy-q reliably creates serial interfaces when the chip is
programmed with the code including this patch.
Change-Id: I608fb1912f1b2e88f7a207cbfff145760da1a4e4
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341580
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The CPRITS() macro adds newline to all strings, there is no need to
explicitly add newlines.
BRANCH=none
BUG=none
TEST=usb upgrade debug messages do not span two lines any more
Change-Id: I1991214ddaa5945bedba861d67b392973f6a3d0f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341615
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The usb upgrade protocol is very fragile, any error while transferring
data causes the state machine on the target to lock up, and the only
way to resume the upgrade is to power cycle the device.
With this patch USB callbacks which happen more than 5 seconds since
the previous callback would be considered a start of new transfer,
thus allowing to attempt a new upgrade without the power cycle.
BRANCH=none
BUG=chrome-os-partner:52856
TEST=the following script allows to upgrade successfully:
$ while not ./extra/usb_updater/usb_updater build/cr50/ec.bin; do sleep 6; done
Change-Id: Ibe1078cf62073ce89a31416522b0d6917bc923b9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341572
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This change modifies the behavior of RBOX by blocking the key0 and key1
output, when the power button is pressed. It also adds support for
printing debug statements when various RBOX interrupts are triggered.
BUG=none
BRANCH=none
TEST=On cr50 test board verify key0 and key1 out are not asserted unless
the power button is pressed.
Change-Id: I67a3c1b8009279015bdc87bcf0995cffa9ab6f03
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341470
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
A fairly detailed description of the driver is included in the
comments in the file.
As of this submission the setup is fairly brittle, as clock stretching
is not yet enabled, and there is no guarantee that the slave will
prepare the data for the master in time.
More testing will be required and enhancements will be added in the
future.
BRANCH=None
BUG=chrome-os-partner:40397
TEST=with the rest of the patches applied, an i2c app running on the
desktop allows read and write TPM registers using the
USB-FTDI-I2C cable connected to the B1 board.
Change-Id: I46b13d360ca92271702268f9088193b5ada583be
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/340519
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The cr50 SPI master can control the external AP and EC SPI ROM. This
change adds support for doing spi_transactions, but does not use the SPI
transactions for anything except console commands. This support will be
used for flashing the AP and EC through CCD. For now AP and EC flash
select must be done manually using the spi_flash_select console command.
Flash select should be disabled after use, because it will prevent the
system from booting.
BUG=chrome-os-partner:50701
BRANCH=none
TEST=Enable spi_flash commands. Select AP ROM and verify spi_flashinfo,
read, erase, and write commands work properly. Select EC ROM and verify
the same commands.
Change-Id: I16c55015794f8513effe0fa5712488a84bed2627
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/339844
Reviewed-by: Shawn N <shawnn@chromium.org>
Prime generation uses a sieve to amortize division
with small primes. Otherwise this a standard
Miller-Rabin implementation.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests under test/tpm2 pass
Change-Id: I9f84d1f9c911f6146e4bd80296f75157a191552d
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/335222
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
points_mul (variable time) is only necessary for
ECDSA verification, and is not required as part of
the public dcrypto API. Replaced wih (constant time)
point_mul, and add corresponding parameter checks to
the tpm2 interface call _cpri__EccPointMultiply.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests in test/tpm/tpmtest.py pass
Change-Id: I4ec885c147755e8a645c51b9a461b81c3a3b310f
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/338851
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Implement _cpri__TestKeyRSA, which computes
the modulus and private exponent given a
pair of primes, or computes the second prime
and private exponent given the modulus and
one prime.
The _cpri__TestKeyRSA call is used to determine
whether the components of an RSA key match each other.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests in test/tpm/tpmtest.py pass
Change-Id: I2c68d844f4bab207588cbda5c962b09078519a1a
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/330466
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
AES CTR will be necessary to implement hybrid encryption
and hence needs to be a part of the dcrypto library.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests in test/tpm/tpmtest.py pass
Change-Id: I5dffe5d3a15748614db36aebdbcd50bde31bfdb2
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/339561
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Previously the maximum number of deferred routines was specified by the
the default maximum number of deferred routines you had to override
this, and if you wanted fewer, you still payed the price of having the
defer_until array statically allocated to be the maximum size.
This change removes that define and instead creates the RAM state of
the deferred routine (the time to wait until to call the deferred) when
the deferred is declared.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
manually test on discovery-stm32f072
Change-Id: Id3db84ee1795226b7818c57f68c1f637567831dc
Reviewed-on: https://chromium-review.googlesource.com/335597
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Previously calls to hook_call_deferred were passed the function to call,
which was then looked up in the .rodata.deferred section with a linear
search. This linear search can be replaced with a subtract by passing
the pointer to the deferred_data object created when DECLARE_DEFERRED
was invoked.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
CQ-DEPEND=CL:*255812
TEST=make buildall -j
Change-Id: I951dd1541302875b102dd086154cf05591694440
Reviewed-on: https://chromium-review.googlesource.com/334315
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
It was observed that when connecting to the CR50 console over USB,
there the line feed (LF) characters are not supplemented by carriage
return (CR), which causes weird console output.
Detailed examination has shown that uart_putc() does not do the right
thing itself and also bypasses __tx_char() used by uart_puts(), which
does the right thing.
The simplest solution is to have uart_putc() re-use all the smarts of
uart_puts().
BRANCH=none
BUG=none
TEST=verified that usb console output does not suffer from the "lost
CR" syndrome any more.
Change-Id: I2a1f84b2524c41eb6e84186141b0b9ac55e87ee0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/339217
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
In board/*/gpio.inc, we can specify pullups and pulldowns on pads
connected to GPIOs, like so:
GPIO(SOME_BUTTON, PIN(0,0), GPIO_INPUT | GPIO_PULL_UP)
This adds flags to do the same thing for pads that connect to
internal periperals:
PINMUX(FUNC(UART0_RX), A1, DIO_PULL_UP)
BUG=chrome-os-partner:51410
BRANCH=none
TEST=make buildall; manual test on Cr50
I added these flags to the gpio.inc file and tested the result:
PINMUX(FUNC(I2C0_SCL), B0, DIO_INPUT | DIO_PULL_UP)
PINMUX(FUNC(I2C0_SDA), B1, DIO_INPUT | DIO_PULL_DOWN)
The "pinmux" console command showed that the new flags took effect:
Before:
400600a0: DIOB0 0 IN
400600a8: DIOB1 0 IN
After:
400600a0: DIOB0 0 IN PU
400600a8: DIOB1 0 IN PD
Change-Id: I1d212331431ef67b2f1bcece8729d092b9ad5ba8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/339254
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
When the debug cable is plugged in enable the EC and AP UART output.
Disable the output when the cable is disconnected so servo can use the
UARTs.
BUG=chrome-os-partner:52322
BRANCH=none
TEST=Verify commands can be sent to the EC UART through usb when suzy q
is connected. Verify servo can interact with the EC UART when suzy q is
not connected.
Change-Id: I2ce0e9da464b24e295e732aa638bfc32323cc72d
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338858
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The device-specific subclass used for Non-HC firmware updates is
in the spreadsheet now, so we can rename the macros to be
"official".
BUG=chrome-os-partner:49962
BRANCH=none
TEST=make buildall; test on cr50
make BOARD=cr50 (plus whatever signing magic works for you)
make -C extra/usb_updater
./extra/usb_updater/usb_updater build/cr50/ec.bin (sudo if needed)
Note that you may need to rebuild ec.bin in order to see any
difference after the update. If the A & B images are identical,
the RO bootloader always picks A.
Change-Id: I385ce89a9abe2059d52da2d82a0b92b9b3e3c93f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/339220
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add support for SHA256 based HKDF key
derivation as specified in RFC 5869. This
change includes test vectors from the RFC.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests under test/tpm2 pass
Change-Id: I7d0e4e92775b74c41643f45587fc08f56d8916aa
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/336091
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
This adds support for RD Detection on cr50. It can be used to detect a
debug device and signal the controller to switch from the AP PHY to the
to CCD PHY. When RDCC1 and 2 no longer detect the debug device, then
the controller switches back to using the USB to AP PHY.
BUG=chrome-os-partner:50700
BRANCH=none
TEST=change the value on RDCC1 and RDCC1 and check that the usb
controller connects to the right PHY.
Change-Id: Ice01a45a31fe1932945f89df2e3b851f4d287a17
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338454
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
While kevin is still in development default to connecting to the CCD PHY
instead of the AP PHY. This will automatically enable CCD instead of
having to rely on things working to detect the debug accessory and
switch to the proper PHY.
We also disable the TX lines to the AP and EC, in case servo is
connected. To turn them on manually, use these console commands:
rw 0x40060040 74
rw 0x400600c8 78
pinmux
gpiocfg
BUG=chrome-os-partner:50700,chrome-os-partner:52281,http://crosbug.com/p/52322
BRANCH=none
TEST=hook up suzy q to kevin. Run 'lsusb -vd 18d1:5014' and check that a
device appears.
Change-Id: Ic2802430680adc6186982022c995ee6f452b45fd
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338680
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Trybot-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
This enables the Cr50 to accept RW firmware updates over USB.
BUG=chrome-os-partner:50707, chrome-os-partner:50712
BRANCH=none
TEST=make buildall; test on Cr50
Build and run the extra/usb_updater utility. Watch the console,
and observe that the Cr50 updates and reboots into the new image
correctly.
Note that you'll have to rebuild the ec.bin image in order for
the update to take effect. Just reflashing the same image doesn't
cause the bootloader to change its selection.
All the previously existing endpoints continue to function normally.
Change-Id: I7bd22eae803c2ceeb14a767c06d3d5c9f1ac7c7a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338089
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
This adds a standalone linux utility to deliver RW firmware
updates to the Cr50 over USB.
It prepares update blocks required by the firmware upgrader, and then
fragments and transfers the blocks though the USB channel. The blocks
are reassembled on the target and passed to the upgrade module for
integrity verification and programming.
BUG=chrome-os-partner:50712
BRANCH=none
TEST=make buildall; test on Cr50 as follows:
sudo extra/usb_updater/usb_updater build/cr50/ec.bin
The Cr50 doesn't yet accept firmware updates that way,
so there's no functionality to test just yet.
Change-Id: I1c698fd0c553c936d58ff16a2acaa05ae05bc857
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338088
This re-factors the existing firmware upgrade facility, which worked as
a TPM command extension.
The same code processing upgrade blocks prepended by the truncated
SHA1 and the load address is now used by both extended TPM command and
the USB upgrader.
To accommodate USB communications using a smaller message payloads a
reassembly layer is introduced which accumulates short USB payloads
into a single block which can be passed to the firmware upgrade
routine. USB encapsulation adds one 4 byte header at the beginning of
the block to hold the total block size. The reassembly layer keeps
receiving USB messages, concatenating their payloads until the full
block is received.
A config option is added to make sure the module is not compiled when
not needed.
BUG=chrome-os-partner:50707
BRANCH=none
TEST=make buildall; test on Cr50 - with the rest of the patches
applied it is possible to upgrade firmware using the USB utility
on the host..
Change-Id: Ib30b381c4ab196ea9d352f3c6b8f46dc23ddd599
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338087
It's handy to use the usb-stream interfaces to avoid a lot of
typing. But not all the endpoints are traditional serial ports.
This just adds a new macro that lets us specify additional
parameters.
BUG=chrome-os-partner:50707
BRANCH=none
TEST=make buildall; test on Cr50
Verified that all the previous endpoints still work as before.
There are no endpoints that use the new macro yet.
Change-Id: Ia37901cbe3adc4a4650ab91db3596efa15a110de
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338086
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This adds a command to connect or disconnect, and to switch the
PHY between A or B.
BUG=chrome-os-partner:52055
BRANCH=none
TEST=make buildall; test on Cr50
Using a test board with both PHYs plugged in, try the various
commands:
usb off
usb on
usb a
usb b
The on/off option connects and disconnects, the a/b option
switches between PHYs. You can see the state change on the
console, or by running dmesg on the host.
Change-Id: I4c77e9c586ce197dc99b0b50af7396c253a1a377
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/337706
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This change adds support for forwarding the EC console through USB.
BUG=chrome-os-partner:49960
BRANCH=none
TEST=load the google-serial udev rules in extra/usb_serial/, build the
raiden.ko module, and then check that the console can be accessed from
/dev/google/Cr50/serial/Shell
Change-Id: I35e0bb39fdc8f9485a14c03eb3a4d2f024884e17
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/334132
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
