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
I2C is not necessarily _that_ slow, especially when using 1Mhz clock
speed, and, looking at traces from userspace, there are large gaps
(150us) between bytes (while the bytes themselves only take ~10us).
At 400kHz and higher bus speed, busy-loop for the duration of 2 bytes,
before sleeping (and yielding to other tasks) for 100us between each
attempt.
BRANCH=None
BUG=chrome-os-partner:50381
TEST=i2cget, look at Logic 16 traces: no gaps between address and bytes
Change-Id: If47f0f8e55be37002361800d35f71c945863d42d
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346670
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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
Only way to set alarm previously was through
rtcalarm command on EC console. Implemented
interface through ectool so that the AP can set
it as well.
BUG=chrome-os-partner:52218
BRANCH=None
TEST=from AP console, run ectool rtcalarm <sec>
Should see [event set 0x02000000] from EC
console in approximately <sec> seconds.
Change-Id: I3202b826cb994dbca456b8b9c22bbca4dbe2766a
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347493
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Full implementation of NvMem read, write, and commit functions.
Includes partition definitions, shared memory allocation, and
initialization function.
Includes a set of unit tests located in ec/test/nvmem.c which
verify functionality.
This module is required by Cr50, however this CL does not
include any Cr50 specific code.
BUG=chrome-os-partner:44745
BRANCH=none
TEST=manual
make runtests TEST_LIST_HOST=nvmem and verify that all tests pass
Change-Id: I515b094f2179dbcb75dd11ab5b14434caad37edd
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/345632
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This change provides a console command for setting,
and loading a usb serial number from flash. This
feature adds CONFIG_USB_SERIALNO, and currently only
has a useful implementation when PSTATE is present.
BUG=chromium:571477
TEST=serialno set abcdef; serialno load; reboot
BRANCH=none
Change-Id: I3b24cfa2d52d54118bc3fd54b276e3d95412d245
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/337359
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The console adc command prints adc values in the
order they appear in hardware, however they are lableled
in the order they are enumerated in board.h, which is not
necessarily the same.
This prints the correct name and value pairs, and removes
the adc_read_all_channels function which is not otherwise
used.
BUG=chromium:571476
BRANCH=None
TEST="adc" command associates correct values with names now.
Change-Id: I688641953d20082224b4120eaefe0d634ad4c74c
Signed-off-by: Nick Sanders <nsanders@google.com>
Reviewed-on: https://chromium-review.googlesource.com/340892
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Before the change was made, the EC clock will be changed to 16MHz
when wake up from sleep mode, but we need it to keep at 8MHz.
This issue only occurs when EC sleep mode is implemented.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=The 'IT83XX_ECPM_SCDCR3' register keeps default setting.
Change-Id: I206c5e657aba296684d60d6b30ed4071798dd96a
Reviewed-on: https://chromium-review.googlesource.com/345737
Commit-Ready: Dino Li <Dino.Li@ite.com.tw>
Tested-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-by: Randall Spangler <rspangler@google.com>
The 144-pins package IC(IT8320) supports these two GPIO groups.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=1. Declare GPIO groups K/L in gpio.inc and using console commands
'gpioget'/'gpioset' to read/set GPIOs.
2. Choose four GPIO pins(GPIOK.0/1 and GPIOL.0/1)
and test interrupt functionally.
Change-Id: Ia618c314eeca1d061ffe172da762865f5df9b5c6
Reviewed-on: https://chromium-review.googlesource.com/345776
Commit-Ready: Dino Li <Dino.Li@ite.com.tw>
Tested-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-by: Randall Spangler <rspangler@google.com>
Enabled CONFIG_CMD_RTC_ALARM. EC_HOST_EVENT_RTC
is enabled when the rtc_alarm goes off,
alerting the AP to transition from S3->S0.
BUG=chrome-os-partner:52218
BRANCH=None
TEST=rtc_alarm <num> and see event set in ec console
after <num> seconds. Also, check if new bit set
through hostevent command in ec before/after
rtc_alarm goes off.
Change-Id: I53b1705ce0925000f35b9f80752035d198db3310
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/345474
Reviewed-by: Shawn N <shawnn@chromium.org>
LPC access interrupt only enabled when EC entering deep doze mode. This
will reduce interrupt of LPC access. Also, this interrupt is always
enabled for LPC platform to support "CONFIG_LOW_POWER_S0".
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=Tested ectool command 'version' x 10000.
Change-Id: I9053c4018b38a8a852c3c6254e1fcde625f3fa3a
Reviewed-on: https://chromium-review.googlesource.com/336112
Commit-Ready: Dino Li <dino0303@gmail.com>
Tested-by: Dino Li <dino0303@gmail.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Setting NVIC_EN register is not a suitable method if you want to turn
on/off one GPIO's interrupt. Since there're eight sources belong to
the same interrupt, using MIWU_EN register which bit belongs to one
MIWU's source is a better way.
Modified sources:
1. gpio.c: Replace accessing NVIC_EN register with MIWU_EN in gpio's
interrupt utilities.
BRANCH=none
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
Change-Id: I282a45f5a3ab7cb032b2282cf7e92cacc5e706b6
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/342122
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The EC code expects console commands to be no longer than 14
characters, otherwise the alignment of the help command output breaks.
This patch replaces flash_spi_sel_lock with flash_spi_lock and
fake_disconnect with fakedisconnect to make sure the command names
fit.
BRANCH=none
BUG=none
TEST=the 'help' command output is not misaligned any more
Change-Id: Ia65f1535850a07adccbef0812c8a0922c0264cea
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/345570
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
The NPCX_SMBCTL1_ACK bit (which tells the I2C master to produce a NACK
rather than ACK) can be set but not cleared by SW -- it can only be
cleared automatically after actually generating a NACK. During i2cscan,
we want to NACK the first byte returned, but we won't actually produce a
NACK unless the slave ACKs our scanned address. Therefore, we must wait
until the slave ACKs its address before setting NPCX_SMBCTL1_ACK -- use
the NPCX_SMBCTL1_STASTRE / stall interrupt to do so.
BUG=chrome-os-partner:53323
BRANCH=None
TEST=Manual on kevin. Verify faulty temperature sensor reads are not
seen after `i2cscan` and verify i2c otherwise functions normally.
Change-Id: I080d8804adb246129aaebbfbf5ad862e9513da3b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromioum.org>
Reviewed-on: https://chromium-review.googlesource.com/344818
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
There are more EC interrupts available.
Also, update interrupts that should be reserved.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=Use 'task_enable_irq()' to enable new-added interrupts and
corresponding bit of interrupt enable register are set properly.
Change-Id: If1aecec7e208782b4580e33efb968095f30794fe
Reviewed-on: https://chromium-review.googlesource.com/344822
Commit-Ready: Dino Li <Dino.Li@ite.com.tw>
Tested-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Performance in our baseline 4.4 kernel is much worse than previous test
kernels and CS-to-first-byte delay is frequently > 500us. Allow up to
10ms to receive a data byte after CS to reduce the possibility of failed
host commands.
BUG=chrome-os-partner:53181
TEST=Manual on kevin w/ chromeos-kernel-4_4. Verify that "ERR-GTH" rate
is much reduced while spamming "ectool version".
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I92880ccf83a77ee9bdd3d85813e341105857ca4c
Reviewed-on: https://chromium-review.googlesource.com/344410
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In rare case, FW read the unexpected counter value of timer which source
clock is 32K (Watchdog timer and ITIM16/32 which use 32K source clock).
The root cause is the clocks between reading registers and timer's are
asynchronous. It has a chance to get invalid counter value when timer is
under transaction edge. The solution is using two consecutive equal
readings to make sure the counter value is valid.
Beside different source clocks of timer, we also found there's chip's bug
which causes unexpected value of timer. If an interrupt that occurs very
shortly before entering deep idle with instant wakeup, it might result in
disruptive execution (such as skipping some instructions or hard fault)
after "wfi". The workaround is adding the same bypass for idle in deep
idle section.
Modified sources:
1. clock.c: Add bypass for instant wakeup from deep sleep.
2. hwtimer.c: Add consecutive reading function for event timer.
3. watchdog.c: Add consecutive reading function for watchdog timer.
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I7c9f1fb9618a3c29826d8f4599864a8dac4203bf
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/327356
Reviewed-by: Shawn N <shawnn@chromium.org>
- For REBOOT_EC and several other host commands, send_response may be
called multiple times (once for early success notification, one for
actual notification, if the handler exits cleanly). Ignore calls after
the first.
- During reboot / sysjump, we're not equipped to handle host commands, so
disable the SHI interface altogether.
BUG=chrome-os-partner:52878
TEST=Manual on kevin. Verify "ectool reboot_ec RO" (RO to RO = NOP)
succeeds without error messages on EC console. Verify "ectool reboot_ec
RW" causes sysjump without AP going down.
BRANCH=None
Change-Id: Iae83084e4f8d5218600be2a9da7f71dd7872d569
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/342622
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Kevin is code space constrained, so use RAM normally used for data
instead for code.
BUG=chrome-os-partner:52876
BRANCH=None
TEST=Verify free code RAM becomes 5732 bytes (was 1636) and free data
RAM becomes 3072 bytes (was 7168 bytes) (measured with pending changes
to add sensor task). Also, verify kevin continues to boot + power sequence.
Change-Id: Ia6470a76f95e87d6cda1bf7273deaab6344f8ee9
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/343191
Commit-Ready: Wonjoon Lee <woojoo.lee@samsung.com>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
We have two port(as is FALSH_, ACCEL_) on SPI defines
Let's prevent build error so that We can use particular
enable/disable port
BUG=None
TEST=Buildall is OK
Change-Id: Ib6fe14c4edd91947bde0a2da1c889da31db291a4
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/341576
Reviewed-by: Shawn N <shawnn@chromium.org>
Using HOOK_PRIO_DEFAULT for peripheral initialization necessitates using
HOOK_PRIO_DEFAULT+1 for board-level code. Instead, use a
higher-than-default relative priority for peripheral initialization
outside of board.
BUG=None
TEST=Verify PWM and ADC are functional on kevin.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ia8e90a7a866bdb0a661099dd458e3dfcaaa3f6bb
Reviewed-on: https://chromium-review.googlesource.com/342171
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
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>
add optional chipset specific function to check if PLTRST# is valid
BUG=chrome-os-partner:52656
BRANCH=none
TEST=make buildall, able to boot to OS on amenia
Change-Id: I7a2747c4f77f50393c3250c2ab0e1625e64e5a41
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/341732
Reviewed-by: Shawn N <shawnn@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>
This patch adds HSE and PLL as a system clock oscillator for STM32L4.
This allows us to drive the chip at a higher frequency (up to 80 MHz),
which is necessary to big-bang GPIO ports accurately.
BUG=none
BRANCH=tot
TEST=make buildall. Verified console works on STM32L476G-Eval using HSE,
PLL-HSE, PLL-HSI, PLL-MSI as an oscillator. Verified console runs soundly
with different frequencies from 20 Mhz to 80 Mhz. Verified frequencies
using oscilloscope on MCO (Microcontroller Clock Output) port up to 50 MHz.
Change-Id: I493cdb6c323eb4e6a1560f6d030935c1950b1a2a
Reviewed-on: https://chromium-review.googlesource.com/341275
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Since uart_freq_change assumes we drive UARTs at system clock, we need to
set UARTs clock sources accordingly. This will allow us to clock up the
chip without worrying about prescaler values set for HCLK and PCLK or the
on/off status of HSI.
BUG=none
BRANCH=tot
TEST=make buildall. Verified LPUART on stm32l476g-eval.
Change-Id: I02898921e31b68cacbc2235a29c47a212c350afe
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341260
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add PWM_CONFIG_DSLEEP PWM config flag, which can be set to keep a
channel active during low-power idle / deep sleep. Currently it's
supported by npcx and mec1322.
BUG=chrome-os-partner:52783
BRANCH=glados
TEST=Manual on chell w/ subsequent commit + CONFIG_LOW_POWER_S0. Verify
KB backlight does not flicker during idle.
Change-Id: Ib9df5879aaa7dfa5764de1583496de84d40d2bb5
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341002
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@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>
