The auto mode keeps the read buffer full and thus interfere with the
next transaction. We need to disable it when we are done with the
current transaction.
BUG=chrome-os-partner:29805
TEST=Read from SPI flash multiple times
BRANCH=None
Change-Id: I624299aae29fecde03e41228a694550f1deafd2a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205799
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This allows us to use the two SPI ports as SPI master. Also, to save CPU
time on reading large amount of data, let's add an async interface for
SPI transaction.
BUG=chrome-os-partner:29805
TEST=Read manufacturer ID from SPI flash with sync/async interface
BRANCH=None
Change-Id: I427f4215602cccc55c4151f4116226b1e0ccc15e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204719
This implements the DMA driver using the same DMA interface we are using
now.
BUG=chrome-os-partner:29805
TEST=Along with the following SPI driver, read manufacturer ID from SPI
flash.
BRANCH=None
Change-Id: Ife3c0c8b414568ff1cab7d072901ba2d11142a17
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205067
Reviewed-by: Randall Spangler <rspangler@chromium.org>
It would be really nice to be guaranteed to see watchdog warnings
before we actually hit a watchdog reset even if something strange is
going on with the CPU. Let's increase the margin between the timer
and the independent so that the hardware watchdog is really hit as a
last resort.
It seems like a 1.6 second hardware watchdog wouldn't be the end of
the world so let's bump that way rather than increasing the number of
warnings.
BRANCH=ToT
BUG=chrome-os-partner:29162
TEST="waitms 1000" on EC console no longer ever reboots and "waitms
2000" usually does.
Change-Id: Ic5e5ddec22fb8484cc7c552b19d3f2043c105d0c
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204895
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On stm32 we were programming the WATCHDOG_HELP timer with the same
value as the independent watchdog (which automatically resets the
CPU). That means we weren't guaranteed to see the WATCHDOG_HELP. It
happened to work most of the time due to the the LSI oscillator fudge
(we assumed the watchdog was on a 56 kHz oscillator when it was
probably on a 38 kHz one), but let's give ourselves a guaranteed gap.
It's unlikely that this extra gap will actually help on most machines
(if we're running at 53 kHz or lower we already had this much margin),
but it's nice to be safe.
BRANCH=ToT
BUG=chrome-os-partner:29162
TEST=Increase margin to 400 (instead of 50) and type "waitms 300".
Sometimes hit watchdog warning.
Change-Id: I7f876757c15d7775116720c408a4127b4b94adfa
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204894
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Fix bug and actually increase watchdog timeout to 1.8s.
BUG=none
BRANCH=none
TEST=put a 3 second blocking delay in pd_task and make
sure watchdog reboots. set blocking delay to 1.5seconds
and make sure no reboot.
Change-Id: Ie66621a3bd98354f9fd22b9b10a866d004277340
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204471
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This adds back DECLARE_IRQ() support when building without common
runtime. With this, we can enable only a subset of IRQs and avoid
linking in other unused IRQ handlers.
Note that after this change, all boards without common runtime need to
have a ec.irqlist file.
BUG=None
TEST=Build Keyborg and check it still works.
TEST=make buildall
BRANCH=None
Change-Id: If68062a803b9a78f383027a1625cf99eb3370d3f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203264
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Enough USB support to be able to enumerate the device and use bulk or
interrupt endpoints.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28295
TEST=with the following USB console CL, connect a Fruitpie through USB
and use its console over USB.
Change-Id: I37b7f3b6a754cb82ab5f940ea20122d2e16b3b5b
Reviewed-on: https://chromium-review.googlesource.com/193983
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Created a new smaller task size, 384, for tasks that don't need much
stack space including PDCMD and ALS tasks.
BUG=none
BRANCH=none
TEST=loaded on samus, ran taskinfo, made sure we were comfortbaly
under the smaller task size for those tasks that changed.
Change-Id: Icfa26eeaeed26171ec8b2d888e1190be32f688d1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202719
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The i2c timeout on lm4 is currently 1 second, which is very long.
This changes it to 100ms. Note, the biggest transfer we might
every do is probably ~256 bytes to do a flash program using a host
command over i2c. And the slowest bus speed is ~100kHz. So, worst
case, the transaction shouldn't be more than about 25ms.
Decreasing the timeout is useful when peripherals are not plugged
in. For example, the ALS is sampled in the hooks task every second.
We don't want the ALS sampling to be delayed for a second because
it will throw off all of our other hooks.
BUG=chrome-os-partner:29003
BRANCH=none
TEST=ran on a samus and tested i2c commands to various peripherals
Change-Id: I5e1b6d0f8b100cbcb6cd9209c6198e31d99bb085
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202515
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Support bist carrier mode 2 - continuously transmit alternating
1's and 0's, and check for bit errors on receive side. note
that once the test is started the only way to stop is to hard
reboot the devices involved.
BUG=none
BRANCH=none
TEST=connect two fruitpies together. set one to be source:
> pd charger
and then start the bist
> pd bist
start receiving data:
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa - incorrect bits: 0 / 0
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 - incorrect bits: 0 / 0
Change-Id: Id920f6b7177a418a80e1ce325042243cd633cec6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202187
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
refactor existing code in usb_pd_phy.c to use new register definitions
BRANCH=none
BUG=none
TEST=manually verify macro substitutions produce same value
Change-Id: Ia0cd815164b0262640425abd6da973c170163f2f
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202392
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Our code base contains a lot of debug messages in this pattern:
CPRINTF("[%T xxx]\n") or ccprintf("[%T xxx]\n")
The strings are taking up spaces in the EC binaries, so let's refactor
this by adding cprints() and ccprints().
cprints() is just like cprintf(), except that it adds the brackets
and the timestamp. ccprints() is equivalent to cprints(CC_CONSOLE, ...)
This saves us hundreds of bytes in EC binaries.
BUG=chromium:374575
TEST=Build and check flash size
BRANCH=None
Change-Id: Ifafe8dc1b80e698b28ed42b70518c7917b49ee51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200490
Reviewed-by: Randall Spangler <rspangler@chromium.org>
After clearing the TC flag, we should re-enable TCIE so that when
the DMA transfer is done we re-interrupt and allow
uart_process_output() to continue printing whatever is in the
circular buffer (in the case of wrap-around) or finish gracefully
if there is nothing left in the buffer.
BUG=chrome-os-partner:28837
BRANCH=nyan
TEST=Commands now reliably print full output whereas before they
might appear truncated until another interrupt was triggered to
finish printing the buffer.
Change-Id: I0a4236139f57812f384e2b99af45195537201a04
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200499
If we sysjump to EC-RW, that sets enabled=0. enabled is only set back
to 1 when the chipset resumes. But on an AP-requested sysjump, the
chipset is already on, and so the resume hook never gets called.
So, in spi init, check if the AP is already on. If it is, enable spi
transfers right away.
This probably also affects Pit/Pi. That may need an additional fix in
power/gaia.c, if it returns an incorrect chipset state after a sysjump
(I didn't test that.)
BUG=chrome-os-partner:28249
BRANCH=nyan,pit
TEST=Power+Refresh boot system with RONormal disabled, so that the AP
tells the EC to jump to EC-RW. Confirm EC communication still works
after that.
Change-Id: I588ef6d841040cf05d5527f645f122d5708b16ad
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198869
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This may not contain all. I filtered out possible code by the
following command:
find . -name "*.h*" -o -name "*.c*" | xargs grep -n CPRINTF | \
grep -v "\[" | grep -v define | less
BUG=none
BRANCH=none
TEST=make buildall tuntests
Change-Id: I674f84f5966b34aeb8d4321d22629b450627a120
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197997
We found some cases where the battery can flip out and get confused
and hold the i2c lines. Since the battery is actually smbus it will
give up after 25ms. Increase our timeout to 30ms so that the next
trasaction will work OK.
BRANCH=ToT
BUG=chrome-os-partner:28425
TEST=Revert (1cd618e Wait for battery boot-up) and use a problematic
battery; see boot works OK.
Change-Id: Ife051220cbbbd49d7bc9c8607ba177cd9582fe58
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198212
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Ensure that we finish reception if and only if we started it
whatever other events happened.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28332
TEST=Connect Zinger to Firefly, request higher voltage and ensure that
Firefly was still getting the Pings after several hours.
Change-Id: Ie99984aeb4c565be39d349457dbd2813203b3f5b
Reviewed-on: https://chromium-review.googlesource.com/197946
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
With change b610695b61, we fixed a problem
with the number of FP regs that were being saved on the stack. That change
decreased the required stack size for non-FP tasks by 64 bytes, but
increased the size needed for FP tasks (such as the lightbar).
The lightbar task was previously using within 64 bytes of its alloted stack,
so handling the task switching correctly meant that it now overflowed.
The hooks task had the same problem, but was hidden by the lightbar task.
This CL bumps the LARGER_TASK_STACK_SIZE up a bit, and switches the lightbar
task to use it instead of the default size.
BUG=chrome-os-partner:27971, chrome-os-partner:28407
BRANCH=ToT
TEST=Try it on both Link and Samus.
Before this change, the Samus lightbar was overflowing its stack every time
the AP booted (causing the lightbar to do things). With this change, it
doesn't. Here are typical stack sizes after this CL:
Task Ready Name Events Time (s) StkUsed
0 R << idle >> 00000000 28.394913 328/512
1 HOOKS 00000000 0.534085 640/768
2 R LIGHTBAR 10000000 5.359356 520/768
3 CHARGER 00000000 0.094674 384/512
4 CHIPSET 00000000 0.003353 320/512
5 KEYPROTO 00000000 0.002814 312/512
6 HOSTCMD 00000000 0.002942 244/512
7 R CONSOLE 00000000 0.193776 340/768
8 POWERBTN 00000000 0.000392 248/512
9 KEYSCAN 00000000 0.409337 332/512
Change-Id: Ica93608c8adb225410a62ec3a0a27944c479270a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197733
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In some cases, the system will boot to S0 from the point of view of
the EC, but PLTRST# will never deassert. Work around this by waiting
50 ms for PLTRST# to deassert. If it doesn't, force the chipset all
the way down by deasserting RSMRST#, then pulse the power button to
turn it back on.
Also add a powerfail debug command to simulate this failure event, so
that the recovery process can be tested.
Add API to the LPC module to get the state of PLTRST#, and to the
power button state machine to force it released when we shut down the
chipset and and force another power button pulse as we reset the
chipset.
BUG=chrome-os-partner:28422
BRANCH=baytrail
TEST=1. Boot system. Should boot normally. Shut system down.
2. powerfail
3. Boot system. On the EC console, should see the system come up,
go back down through G3S5, then come back up. From the user's
point of view, it just boots.
1. Boot system. Should boot normally. (That is, powerfail is not sticky)
Change-Id: Ia57f196606f79b9f2fce7d9cd109ab932c3571aa
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197523
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This implements dual chip matrix scanning. Now the scan result is only
dumped to debug output.
BUG=None
TEST=Put a finger on the panel and see its shape.
BRANCH=None
Change-Id: I015c901b42e24fe4a6249c12c37bc5bfcb308c9f
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196468
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Use the plug polarity detected by the ADCs to do the PD communication on
the right CCx line.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28339
TEST=make buildall
on Firefly, plug Zinger connector in both direction and see it can
control it either way.
on Fruitpie, use CC1 or CC2 and see it can communicate on both.
Change-Id: I81cb00f164cb8194fba73b383014e81c37d975e2
Reviewed-on: https://chromium-review.googlesource.com/197520
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Slightly modify interfaces for better sink-only devices implementation
(eg Firefly)
update the host mode management and the voltage selection
and add a hook for board checks.
Simplify the reception timeout and fix other timeout detections.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
and use with the follow-up firefly board configuration CL.
Change-Id: I0240295764c8605793dc80a2fc21357af1740744
Reviewed-on: https://chromium-review.googlesource.com/195585
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Added config option CONFIG_USB_PD_TX_USES_SPI_MASTER which switches
to use SPI master for PD transmit. The advantage of SPI master mode
is at the end of the tranmission, we don't have to send any dummy 0
bits. When the option is set, the CPU_CLOCK must be set to 38.4MHz,
so that the SPI master can generate the correct clock frequency.
BUG=chrome-os-partner:28309
BRANCH=none
TEST=Tested by connecting two fruitpies together across CC1. One
fruitpie has been modified such that the MISO and MOSI lines are
swapped and is running PD TX in SPI master mode with 38.4MHz clock,
while the other is running PD TX in SPI slave mode. On EC console
ran pd charger on one board and pd dev on other board. Verified
that communication works with no errors. Ran for 10 minutes in each
configuration.
Change-Id: Ib24030d34d95d59f4ac6c2dae98bf7adda1ada01
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197215
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The external interrupts above 15 are not used for GPIO IRQ handling, but
for special purpose interrupts from internal peripherals (e.g. RTC,
comparator, wake-up ...). When processing the GPIO interrupts, we should
explicitly skip those interrupts, else if a GPIO interrupt happens
first followed by another EXTINT, the loop in gpio_interrupt() will try
to process it and do an out-of-bound read of the exti_events array.
This will retrieve a garbage handler triggering a memory fault.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28296
TEST=on Firefly, press the buttons to trigger GPIO interrupts while
there are a bunch of comparator interrupt on EXTIN21 (due to on-going
USB PD communication). I no longer see HardFaults.
Change-Id: Id90fab30215b0f7f8060c19de63a7ca8418b7b3c
Reviewed-on: https://chromium-review.googlesource.com/197019
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
This implements a simple SPI driver for the two chips to exchange
packets.
There are both sync interface and async interface. Sync interface is
easier to use, and async interface frees the CPU while the DMA takes
care of the communication.
BUG=None
TEST=Hello test passed
BRANCH=None
Change-Id: I9823bad5cae6d1fa8f3658d17af4b998d3735a3e
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195533
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This chip got small flash and RAM, so the common runtime is disabled.
Now the code only boots and print something every second to check debug
console and timer are good.
BUG=None
TEST=Boot and see console output
TEST=make buildall
BRANCH=None
Change-Id: I01150e8250a404628d1a3b81e677ac4c29782d7f
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195382
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previously, you could use EC_CMD_ACPI_QUERY_EVENT to read events that
were masked off (that is, events which would not generate SCI/SMI/wake
signals). The handlers for those signals on the host would still act
on the masked-off events - for example, causing unwanted power button
keypresses/releases.
Now, EC_CMD_ACPI_QUERY_EVENT will only return events which are unmasked.
This does not affect storing of events at event generation time.
Events are still queued; they won't be dropped until the host attempts
to read the next event. This gives the host a chance to set a mask
later in boot (but before querying any events) to capture events which
happened early in the boot process.
BUG=chrome-os-partner:26574
BRANCH=rambi
TEST=At EC console, type 'hostevent set 0x80' but don't press enter.
Hold down the power button; UI starts fading to white.
Press enter at the EC console to issue the hostevent command.
System should continue shutting down, not fade back as if the
power button were released.
Change-Id: Id2cb14b0979f49cdd42424b9a61b310a2bb506f5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194935
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The KBD_IRQ#, SMI#, and SCI# lines on the host are sensitive to
falling edges. When generating an interrupt, wait long enough to make
sure the lines are high before pulling them low, so that it reliably
generates a falling edge. This solves a problem where calling the
IRQ-generation function twice in rapid succession could cause two low
pulses without an intervening logic-high as seen by the host (and thus
not a falling edge as seen by the host).
This is most visible on the keyboard line, because it can generate
back-to-back events on multi-byte scan codes. Once the keyboard
mailbox is full, the EC will never attempt to fill it, and thus it
also won't attempt to generate another keyboard IRQ. And since the
host missed the IRQ, it doesn't know it needs to empty the mailbox.
It could theoretically happen for the other lines, so fix them now
just to be safe.
This change should be low-impact and free from side effects. 4 usec
is a very small additional delay. Even 65 usec added delay for
SCI/SMI is small, given that SCI/SMI events are typically much less
frequent (if they're happening very frequently, something else is
tragically wrong with the system...)
BUG=chrome-os-partner:27222
BRANCH=rambi
TEST=Bang on the keyboard like a monkey. Keyboard shouldn't get stuck.
Orig-Change-Id: Id4e6de793b1f007f713bac8aa195ddd78feeea3e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193173
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
(cherry picked from commit 569651b82e309ddd86b9c165d131e34cb7f7b2b5)
Change-Id: I62a9ad0fa85121b3345c057f0e3fc6b3cc29e97e
Reviewed-on: https://chromium-review.googlesource.com/193174
Commit-Queue: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
add support for CRC-32, it's using the USB variant for the constants and
bit ordering (same polynom as Ethernet).
This code is using an (evil) "stateful" design to be compatible with the
hardware CRC controller : you should NOT do concurrent accesses without
external locking (but it's good enough and ligthweight for current
usage)
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run interoperability testing against other 3rd parties USB
implementations.
Change-Id: I1a07b2c4e2e71e15f9d257611652061bcfb0de9c
Reviewed-on: https://chromium-review.googlesource.com/189865
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
This prevents other task events from continuing the ADC
conversion prematurely; potentially leading to a panic
if the conversion interrupt occurs after the ADC has
been powered down.
BUG=chrome-os-partner:26919
BRANCH=rambi
TEST=Perform ADC conversions while running a deferred function
calling itself on a 10mSec delay. Verify no panics after ~6 hours.
Change-Id: Ic3894849c154b3f058e812b2da816e7cffb12cbf
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191302
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add STM32F03x as part of the STM32F0 family.
STM32F031 will be used for devices requiring low-end parts.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=along with the following CLs, run on STM32F051 Discovery with
limited RAM and Flash to mimic STM32F031.
Change-Id: Ie95303eaf00ce53fe7c8d2ac84c19a983aadbf0d
Reviewed-on: https://chromium-review.googlesource.com/189404
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
In order to achieve really tiny firmwares, make our runtime (tasks,
hooks, muxed timers, GPIO abstraction ...) optional.
Add 2 new build options for it : CONFIG_COMMON_RUNTIME and
CONFIG_COMMON_GPIO which are enabled by default, and ensure all the
source files are built according to the right configuration variable.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
build a minimal board with no runtime.
Change-Id: Icb621cbe0a75b3a320cb53c3267d6e578cd3c32f
Reviewed-on: https://chromium-review.googlesource.com/189403
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Replace the stubs by an actual implementation for ADC and Analog
watchdog support on STM32F0xx chips.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=manually read ADC values on STM32F072B discovery.
TEST=read all ADC values at once.
TEST=Enable watchdog and check it fires when the voltage goes out of
range.
TEST=read ADC value(s) while watchdog is enabled.
TEST=Disable watchdog and check it's actually disabled.
Change-Id: Ie6fbd1aa95a3d76394fa47803e8cfc24bf5e4562
Reviewed-on: https://chromium-review.googlesource.com/190710
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Some section(entry point, interrupt vector, e-flash signature
and so on) of linker script file are not linked.
The start address of e-flash signature should always at 00000080h.
Default firmware treats VCC logic high to prevent pin 11 logic low
but use following functions.
(EC2I, KBC, SWUC, PMC, CIR, SSPI, UART, BRAM, and PECI)
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=Firmware can startup on IT8380 emulation board.
Change-Id: I9860ac5b99dcc6e9e00dbc9d1e79a141237b7789
Reviewed-on: https://chromium-review.googlesource.com/190008
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Dino Li <dino.li@ite.com.tw>
Commit-Queue: Dino Li <dino.li@ite.com.tw>
Some STM32 variants have a 32-bit timer in addition the bunch of 16-bit
timers.
Add the option to use the 32-bit timer as the system clock source to
lower the overhead of the timer code compared to a pair of 16-bit
timers.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run the EC on STM32F072 Discovery board with 32-bit TIM2 as the
clock source.
Change-Id: If55c4e23a3f68dd8f6ca32e93f3a27c1743c767b
Reviewed-on: https://chromium-review.googlesource.com/189861
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
After Alex's CL 8a9817a, the i2c driver no longer hardcodes the
I2C port pin (Ya!). Remove the conflict pin setting in board files.
BRANCH=nyan,big
BUG=chrome-os-partner:26620
TEST=build and run on nyan board. Everything looks good.
Change-Id: Iee2c5f10f642da7ad00f503b6e615cb6aa472459
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189245
Reviewed-by: Alec Berg <alecaberg@chromium.org>
