CR50 will need three serial endpoints for the streaming AP and EC UART
and exporting its own console through USB. This change adds a macro to
create endpoints that can be recognized by the usb_serial driver.
BUG=chrome-os-partner:50702
BRANCH=none
TEST=Verify "/dev/google/Cr50*/serial/Blob" prints capital letters when
lower case letters are input.
Change-Id: Iddf2c957a00dc3cd5448a6a00de2cf61ef5dd84c
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336441
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds (and uses) some additional flags for gpio.inc's
PINMUX() macro, to configure specific pads as wake sources when
the SoC is sleeping.
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
The sleep/deep sleep behavior is unchanged. This just replaces
hard-coded wake sources with pads configured in gpio.inc and the
chip/g/sps.c module. Tests from previous CLs still pass.
Change-Id: I6608dc959524f42fd589feb804fa06f29cfd9b9c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336838
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
This adds support for the "sleep" low-power mode. It consumes
less power than simply waiting, but doesn't require a full warm
boot to resume.
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
Configure the Cr50 to sleep when idle (refer to previous commit
messages for the setup required).
On the console, use the "idle" command to test the three
different modes:
idle w - wfi, wakes instantly
idle s - sleep, wakes slowly but without rebooting
idle d - deep sleep, wakes via warm boot
You can tell the difference between wfi and sleep by observing
that the first character is lost when typing on the serial
console while in sleep (remember that it will wait at least 10
seconds after the last console input before sleeping).
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Ib2584aa44ab885f0c8369ec938ee17b935aa0898
Reviewed-on: https://chromium-review.googlesource.com/336836
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
Wait at least 10 seconds after the last console input before
invoking sleep or deep sleep.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; test on Cr50
Use the "idle d" console command to put the Cr50 into deep sleep
when idle (refer to previous commit messages for the setup
required).
Wake it up, then let it sleep again. It should go back to sleep
quickly when woken via USB, but should take much longer when
awakened by typing on the serial console.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I7a2b840565f5d82e0dbdf8a3e75061a69cb9e405
Reviewed-on: https://chromium-review.googlesource.com/336835
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
This preserves the selected idle action (wfi, sleep, deep sleep)
across soft reboots, which includes deep sleep. Hard reboots will
restore the default which is to not sleep at all.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; test on Cr50
Use the "idle d" console command to put the Cr50 into deep sleep
when idle (refer to previous commit messages for the setup
required).
Wake it up, then let it sleep again. It should go back to the
deep sleep state.
Change-Id: Iaad82b725d2b32a19205fa403dbaab9a31c35630
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336834
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This adds the SPI slave bus and TPM task to the things that
can prevent deep sleep. Even when things are quiet, we wait at
least a second
With this CL, it will wait at least one second after the last SPS
transaction before sleeping. Since most TPM-protocol commands are
built up of a number of back-to-back SPS messages, if we don't
wait we'll keep trying to sleep in the middle of active commands.
Even if everything is quiet, we wait 0.2 seconds anyway to give
the UART buffers time to drain.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; extensive tests on Cr50
Testing is a pain.
In addition to ALL the steps listed in commit
d917d3f1867e96369ff25bf6906043a5f488a6fb, loading the firmware
with the spiflash tool leaves SPS_CS_L low, so you have to drive
it high manually. The easiest way is to build and run
test/tpm_test/tpmtest.py for a few seconds then interrupt it with
Ctrl-C.
Note that because the system wakes from deep sleep when it sees
SPS_CS_L go low but it can't get ready fast enough to capture the
incoming bits, that first SPI transaction will be garbled or
lost. You'll have to either retry it, or wake the system another
way first.
Change-Id: Iae2fe5ef33869c48e98a3afecd6b98991a51a488
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336690
Reviewed-by: Randall Spangler <rspangler@chromium.org>
cr50 has three UARTs that it will be using. This change modifies the
uart api to specify which uart to use.
BUG=chrome-os-partner:50702
BRANCH=none
TEST=change the interrupts and CONFIG_UART_CONSOLE to see that the
different UARTs can be used.
Change-Id: I754a69159103b48bc3f2f8ab1b9c8b86cea6bea5
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/333402
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is still in testing mode, so you have to take special steps
to enable it (keep reading). But if you do the right dance, it
does go into deep sleep for USB suspend, and resumes correctly.
However, it doesn't yet wake for any other reason. That's coming next.
Normal sleep is not yet supported, either.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; extensive tests on Cr50
Testing is a pain.
First, you can't print anything in the idle task, because that
just makes it stop being idle, so the only way to detect when
it's triggered is by wiring up a GPIO and instrumenting things.
Second, you have to manually reenable USB suspend on the host
every time the Cr50 boots with
echo auto > /sys/bus/usb/devices/<BLEH>/power/control
where <BLEH> is the correct device.
Third, for reasons probably related to the mysteries of HID
devices combined with crbug.com/431886, you have to build the
firmware without CONFIG_USB_HID (and the related items in
board.h)
Finally, because it's still a work in progress, you have to type
idle d
at the serial console after every boot (or resume) to reenable
deep sleep in the idle task.
If you do all that, then you'll see that it does go into deep
sleep. Ping it again with "lsusb -v -d 18d1:5014" or
./test/usb_test/device_configuration, and it wakes up and
responds!
If you disconnect the USB while it's in deep sleep, it stays
asleep. When you plug it in again, it wakes up, but it correctly
recognizes that it shouldn't resume and does a normal reset
instead.
Change-Id: I3cc66e48ce671142a4d12edbe0eb9fdacecea0d9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336279
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
NULL padding (aka vanilla RSA) support is required by
the TPM2 test suite (referred to as TPM_ALG_NULL in the
tpm2 source).
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests under test/tpm2 pass
Change-Id: I9848fad3b44add05a04810ecd178fbad20ae92cc
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/328830
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Some of the reset causes are found in another register when
resuming from a low-power state. We know we'll need to
distinguish among them eventually, so we might as well decode
them now.
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
I forced the system into deep sleep and observed that the reset
cause is accurately recorded on resume. Doing that requires a
fair amount of hacks and manual effort, and can't happen by
accident. Future CLs will make use of this.
The current, normal behavior is completely unaffected.
Change-Id: I5a7b19dee8bff1ff1703fbbcc84cff4e374cf872
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336314
Reviewed-by: Randall Spangler <rspangler@chromium.org>
A resume from deep sleep looks a lot like a cold boot, but there
are some registers that need updating quickly. We need to disable
the settings that triggered deep sleep so that it isn't
accidentally invoked again, and we need to unfreeze any modules
or pins that were frozen during the deep sleep.
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
Since we aren't yet triggering deep sleep, this doesn't do
anything noticeable, which is the point. It shouldn't have any
effect unless we are entering deep sleep and DON'T do this when
it resumes. FWIW, I have tested that too, but it's coming in a
later CL.
Change-Id: I4b32fd2e24fe089d3f659154df26d275b41b4c1b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336450
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This just adds the framework to use for implementing sleep and
deep-sleep. This provides a custom idle task, and a new "idle"
console command to control what that task should do (nothing,
yet).
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
Other than the new idle command which does nothing, there is no
visible change. This is just a stub.
Change-Id: I8a9b82ca68dd6d1e3e7275f4f6753a23a7448f1d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336420
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds USB support to Set and Get the Device Configuration.
These control transfers are standard device requests that need to
be added in order to behave properly for USB suspend/resume (and
in general). Before this CL, the Get command always failed and
the Set command had no effect internally. With this CL it works.
Note that this particular change only supports ONE configuration
for the Cr50. If/when we add additional configuration
descriptors, we'll need to update it again.
BUG=chrome-os-partner:50721
BRANCH=none
TEST=make buildall; manual tests on Cr50
This CL includes a test program. Connect the Cr50 to the build
host, and use that program to read and change the configuration.
cd test/usb_test
make
./device_configuration
./device_configuration 0
./device_configuration 1
./device_configuration 2
You may need to use sudo if your device permissions aren't sufficient.
Change-Id: Id65e70265f0760b1b374005dfcddc88e66a933f6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/335878
Reviewed-by: Scott Collyer <scollyer@chromium.org>
We clear global NAKs by writing bits in the USB_DCTL register.
However, prior to this CL we were overwriting the entire
register, not just touching individual bits.
Since we've never actually set any global NAKs, this mistake
didn't have any noticeable effects. But we should still do the
right thing in case we need it later.
BUG=chrome-os-partner:50721
BRANCH=none
TEST=make buildall; test on Cr50
No visible change; everything continues to work.
Change-Id: Ia25d95dc6211e5460132622ac005723f43b00e24
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/335190
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We were referring to unhandled USB control messages as errors,
but they aren't necessarily. Sometimes they're optional things
that aren't fatal. We should still address them, but we don't
have to freak out.
BUG=none
BRANCH=none
TEST=make buildall; test on Cr50
Change-Id: I892acec2d89b8ec95353cdc09f3e49aa78b1704d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/335200
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There were some unnecessary shifts and conditionals. This just
makes the code a little more readable.
BUG=none
BRANCH=none
TEST=make buildall; test on Cr50 hw
Change-Id: I084f191675d1b51101e9dc55c2e5a12b0b345d33
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/334870
Reviewed-by: Scott Collyer <scollyer@chromium.org>
This config option allowed us to disable the TPM protocol on the
SPI slave bus and replace it with our EC-style host command
protocol. We only used this for early testing and don't need it
anymore, so we can get rid of it completely for this SoC.
BUG=none
BRANCH=none
TEST=make buildall; test on cr50
Change-Id: I2126537e8bcc78e583cf426a3a83962c9ff1a121
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/334762
Reviewed-by: Scott Collyer <scollyer@chromium.org>
It turns out TRNG could turn idle under certain circumstances, and
needs to be restarted in that case. This code adds a check for the
idle state and necessary recovery.
BRANCH=none
BUG=b:27646393
TEST=none yet
Change-Id: Ibd0a13f40f5ce081d4211b2c0f1026468967f826
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/332573
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
reverse() swaps the endian-ness of a buffer of
specified length. This change moves the implementation
to a common location.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=compilation succeeds
Change-Id: If8c97f53cc199d63c1caebbd999e1c099814387e
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/331333
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Flash writes must have starting offsets and byte lengths that are
multiples of 4 bytes. This requirement is already covered. One
additional requirement is that a batch write not cross a flash
block boundary. Added a check in flash_physical_write() to check
if this boundary would be crossed and if so to reduce the write
size so that it ends at the block boundary.
BUG=chrome-os-partner:44745
BRANCH=none
TEST=manual
Used the TPM NVMem section and executed flash writes/reads using
a console command utility that I created to test NVMem accesses.
Note that the console output only exists in the console command
related functions.
This test has the offset 12 bytes from the block boundary and
64 bytes long. The counting pattern shows that the write fills the
last 12 bytes, then moves to the next block as expected.
> nvmem wr 0xff4 0x40 3
nvmem wr: o = ff4, s = 64|0x40
start = 0xff4, end = 0x1034
block 0: block_offset = 0x40800
Call Erase(0x80800, 0x800)
block 1: block_offset = 0x41000
Call Erase(0x81000, 0x800)
Nvmem: writing 64 bytes, start = 0x80ff4
> nvmem rd 0xfe0 0x80
nvmem rd: o = fe0, s = 128|0x80
0x80fe0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x80ff0: ff ff ff ff 00 01 02 03 04 05 06 07 08 09 0a 0b
0x81000: 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b
0x81010: 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b
0x81020: 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b
0x81030: 3c 3d 3e 3f ff ff ff ff ff ff ff ff ff ff ff ff
Also tested the case where a write should end exactly at
the block boundary.
> nvmem wr 0xff0 16 3
nvmem wr: o = ff0, s = 16|0x10
start = 0xff0, end = 0x1000
block 0: block_offset = 0x40800
Call Erase(0x80800, 0x800)
Nvmem: writing 16 bytes, start = 0x80ff0
>
> nvmem rd 0xfe0 0x80
nvmem rd: o = fe0, s = 128|0x80
0x80fe0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x80ff0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0x81000: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0x81010: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
Change-Id: Icbe66d3f79d84ed29ecc6207537ea0bf42781f3c
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/330175
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This adds two debugging commands to decode the PINMUX and GPIO
routings without having to look at a bunch of hex values.
They can easily be removed to save space, but they're kind of
handy for now.
BUG=chrome-os-partner:49952
BRANCH=none
TEST=make buildall, and test on Cr50
Run the "pinmux" and "gpiocfg" commands. Verify that the output
reflects the desired configs found in gpio.inc
I get this:
> pinmux
40060000: DIOM0 5 IN GPIO0_GPIO4
40060008: DIOM1 6 IN GPIO0_GPIO5
40060010: DIOM2 0 IN PU
40060028: DIOA0 70 UART0_TX
40060030: DIOA1 0 IN
40060038: DIOA2 0 IN
40060040: DIOA3 2 IN GPIO0_GPIO1
40060050: DIOA5 0 IN
40060058: DIOA6 0 IN
40060060: DIOA7 3 IN GPIO0_GPIO2
40060088: DIOA12 0 IN
400600a0: DIOB0 33 IN
400600a8: DIOB1 34 IN
400600b0: DIOB2 0 IN
400600b8: DIOB3 74 UART1_TX
400600c0: DIOB4 0 IN PD
400600c8: DIOB5 78 UART2_TX
400600d0: DIOB6 0 IN
400600d8: DIOB7 1 IN GPIO0_GPIO0
400600f8: GPIO0_GPIO0 3 DIOB7
400600fc: GPIO0_GPIO1 22 DIOA3
40060100: GPIO0_GPIO2 18 DIOA7
40060104: GPIO0_GPIO3 20 DIOA5
40060108: GPIO0_GPIO4 30 DIOM0
4006010c: GPIO0_GPIO5 29 DIOM1
40060110: GPIO0_GPIO6 28 DIOM2
40060208: UART0_RX 24 DIOA1
40060218: UART1_RX 8 DIOB2
40060228: UART2_RX 4 DIOB6
> gpiocfg
GPIO0_GPIO0: read 0 drive 1
GPIO0_GPIO1: read 0 drive 0
GPIO0_GPIO2: read 0 drive 0
GPIO0_GPIO4: read 0 drive 0
GPIO0_GPIO5: read 0 drive 0
>
Note that we skip GPIO0_GPIO3 and GPIO0_GPIO6 because they're
neither outputs nor interrupts. All the GPIOs can do that.
Change-Id: I93b881bfd93dc100096bbd005a6c31b2669eda2f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329527
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
BUG=chrome-os-partner:49952
BRANCH=none
TEST=make buildall, run on Cr50 board
It's kind of hard to test GPIOs that aren't attached to anything,
but I've examined all the PINMUX controls and ARM GPIO settings,
and I *think* they're right.
Change-Id: I66ae94118f73c41193c6ca5c0af9708f6cc8a3e8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329526
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Just a bit of refactoring. This cleans up some macro definitions
and error checking, and removes a duplicate list of GPIO signal
names.
BUG=none
BRANCH=none
TEST=make buildall, test on Cr50
No functional changes, so nothing new to test.
Change-Id: Iecacc5a0b7da02aa9d0b94f171c70f0b73e8edd5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329303
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This cleans up a great deal of flakiness that we've seen on the
USB for a long time. I was misinterpreting and/or misimplementing
some of the documentation. This seems to make all the difference.
BUG=chrome-os-partner:50370
BRANCH=none
CQ-DEPEND=CL:328979,CL:*249229
TEST=make buildall, and test on Cr50
Before this CL, the USB connection would only work on USB2.0
buses, connected directly to my workstation. With this CL, it
works on USB2.0, USB3.0, through hubs, etc. Yay!
Change-Id: Icfa1910bf34f73332e2f8fc4f0d6789541549493
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329262
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Now that the pinmux information isn't packed into the GPIO alternate
function table, we can expand it a bit and give the fields nice names,
making the code easier to read and removing a number of bit packing
macros defined in registers.h.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verified on cr50 hardware
CQ-DEPEND=CL:*249229
Change-Id: I9984bc37faf69b1ba9f1ba66a49596dd22e3b601
Reviewed-on: https://chromium-review.googlesource.com/328979
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Previously the g chip and cr50 board abused the ALTERNATE macro to
encode the pinmux configuration. This switches them over to using a
PINMUX macro that is designed for this purpose.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I5c1f70b7aa92d87cc105e672aa66aee7f267c9a2
Reviewed-on: https://chromium-review.googlesource.com/328823
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Change the report_error() macro that we use to indicate unhandled
conditions so that it can take an integer argument. Sometimes
that's useful.
BUG=none
BRANCH=none
TEST=make buildall, try some USB stuff, everything still works
No functional difference, console error output only.
Change-Id: Icdfd1f9162bb5e557c711b6363b73ef55fbc272d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/328490
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The g chip is used in multiple designs, likely to have different flash
memory layout and access permissions.
This patch introduces a mechanism which allows the board layer to
provide flash configuration information to the flash driver.
The flash region which is going to be enabled for write access depends
on the area the code is executing from. If running from the bottom
half (A), the whole top half should be writeable (this includes both
NVRAM area and the B code space). If running from B, the writeable
area starts on top of RO and extends to the end of NVRAM.
CQ-DEPEND=CL:*248190
BRANCH=none
BUG=chrome-os-partner:37754
TEST=with the rest of the patches applied verified that software
update can happen in both spaces, A and B.
Change-Id: Iab1c1a2766ae9bcfe04ff170c010f180cd1f770f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327412
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Nadim Taha <ntaha@chromium.org>
It is difficult to tell what went wrong if a flash operation failed.
This patch adds printouts in cases of failure. The extension command
console channel is used.
BRANCH=none
BUG=chrome-os-partner:37754
TEST=observed error messages reported while debugging firmware update
code.
Change-Id: I73d509ac5088249e8d34e32e760f3d2f063c91cd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327411
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When deciding which of the two images to start, A or B - consider the
image timestamp if everything else is equal. The later image should
take precedence.
Also, simplify the existing logic, and consider image A to be 'newer'
if both copies are the same otherwise.
BRANCH=none
BUG=chrome-os-partner:37754
TEST=with the rest of the patches applied, verified that the newer
image of the two gets started
Change-Id: I2c7a50ecfc8d254498c8e96f8651b8d53005897c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327414
Reviewed-by: Marius Schilder <mschilder@chromium.org>
The launcher should explicitly disable writes to the code space where
the loaded code is going to be running from.
BRANCH=None
BUG=chrome-os-partner:37554
TEST=with the rest of the patches applied firmware updates work as
expected.
Change-Id: I744f7016e4427188f53e8fa3302e8c06cf836e2e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327413
Reviewed-by: Marius Schilder <mschilder@chromium.org>
The output enable bit was being set before the output value was
initialized.
BRANCH=none
BUG=none
TEST=Confirmed the fix with a logic analyzer
Change-Id: If8228d716b4924b5fd65b8f59436f4b37f05644e
Signed-off-by: Nadim Taha <ntaha@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327212
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The required output length is not known until padding
verification completes (this check is already done
in the appropriate padding check functions).
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests under test/tpm2/ pass.
Change-Id: I452244d052b7f334a6907bd653645671033a0890
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/327074
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
If a label is specified, then the NUL terminating
character is considered part of the label per the
TPM2 implementation.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests under test/tpm2/ pass.
Change-Id: If5fccc293f7ab52fd6c33e2f3c38695c2921d919
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/326910
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
The new register definitions file has been supplied, it is not
defining some fields which were present only in FPGA. Some tweaks are
required to accommodate this.
BRANCH=none
BUG=chrome-os-partner:50141
TEST=new code successfully boots on the evaluation board
Change-Id: Ie4158554e0aaf039d59669558861a763a23f0ceb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/326803
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The TPM2 api does not require keys to be word-aligned,
so have the compiler generate alignment-safe reads where
necessary.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests under test/tpm2/ pass, more TCG tests pass.
Change-Id: I247e29f2bec139ab7ed4010ffb58cdae77ba9e0b
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/326201
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Creating bootloader for the chip involves signing the image with an
'air gap' - some physical presence action is required. We don't want
this to be required when the builder is building cr50 for test
purposes.
The solution is to keep using the dummy private key when building by
default, and invoking make differently when building an image which
would be accepted by the hardware.
Setting CR50_RO_KEY variable in the environment or in the make command
line will cause the signer use the value of this variable as the name
of the file containing the key to use for signing the RO image.
Should this file be a public key, the signer will stop and look for a
fob containing the matching private key, and will stream the RO image
through the fob for signing.
Using the fob requires that the signer runs under sudo, but we do not
want the generated files to belong to root, some more code is added to
change the generated files' ownership to user running the make.
BRANCH=none
BUG=chrome-os-partner:49950
TEST=ran the following tests:
- verified that the build still succeeds by default.
- invoked make as follows:
CR50_RO_KEY=cr50_rom0-dev-blsign.pem.pub make BOARD=cr50
observed the signer stop to wait for the user to interact with the
USB fob and proceed. Made sure that the generated image runs
successfully on the evaluation board.
- verified that 'make BOARD=cr50 clean' still works (i.e. none of the
generated files is owned by root).
Change-Id: I733ec6386c1dfd838d83d22fb589fa64e5eeaced
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/326484
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
With transitioning to silicon there is no need to check if the
hardware includes USB subsystem or not.
BRANCH=none
BUG=chrome-os-partner:50141
TEST=the cr50 image successfully boots to the ec prompt
Change-Id: I593205cf307e0fce5e74ea695ed1cf5bfea8fde4
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/326482
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The max retry counts are based on the TSMC specification. This is a necessary
change given that we're using their smart program/erase algorithms.
BRANCH=none
BUG=chrome-os-partner:45366
TEST=Tested RW updates.
Change-Id: I18ca09e54ce13f2cf75dac32fb2457d5963ca040
Signed-off-by: Nadim Taha <ntaha@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/325535
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This patch introduces HOST_CPPFLAGS to be used for all
objects being compiled with HOSTCC rather then the target
compiler.
Since glibc is not linked into the EC, no glibc include files
should be included in the EC code base. Hence, create local
definitions for clock_t and wchar_t that match what the glibc
include would have done, and remove some unneeded includes.
Due to very eager optimization, we have to give gcc a little
notch to not kick out memset.
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
BUG=chrome-os-partner:43025
BUG=chrome-os-partner:49517
BRANCH=none
TEST=compile tested
Change-Id: Idf3a2881fa8352756b0927b09c6a97473358f239
Reviewed-on: https://chromium-review.googlesource.com/322435
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
The makefile is missing an explicit dependency which ensures that the
signer utility is available by the time the RW_B image is built. This
works most of the time, but once in a while RW_B gets ahead in the
race and the build fails.
Adding explicit dependency will prevent this from happening.
BRANCH=none
BUG=chromium:578761
TEST=make buildall -j still succeeds.
Change-Id: I7f5223f51e71b1d78de012bf5d934f1a17c86cc0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/325031
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The implementation for sha256_hash() copied
and incorrect number of bytes to the output.
This change provides a fix and a test.
TEST=added test case
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
Change-Id: I74e98c6f5005a14dd5c0ca19ea7540622dd6c7d7
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/324391
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Adds the the code necessary to support muxed inout peripherals on
cr50 like SPS and SPI0 by adding a new signnal to pin connection
flag. Note these are for direct wired peripherals where no muxing
is necessary, the input pads just need to be enabled.
BRANCH=none
BUG=none
TEST=verified pinmux registers through m3
Change-Id: I1a375a3a14fb44fc4f9ced764fd2c54bb2b91e22
Signed-off-by: Ewout van Bekkum <ewout@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/323848
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
of the two RW images if set.
Imported the Haven "signed_header.h" file into chip/g and fixed prior
references to the util/ copy.
BUG=none
BRANCH=none
TEST=Went through a full update. Simulated a botched update.
Change-Id: I1e4c006ef391270a7e350fea6f43cc1a1b057d0e
Signed-off-by: Nadim Taha <ntaha@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/324109
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
