Add support for continuously writing ADC samples to a circular buffer.
CONFIG_ADC_PROFILE_FAST_CONTINUOUS should be defined and an
appropriate sized buffer must be passed to adc_read_all_channels().
BUG=chromium:569994
TEST=Manual on snoball. Verify 'adc' continues to function (single
mode). With pending commit, verify that continuous conversion interrupt
is called at appropriate frequency and values look consistent.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I025825d72a698f8f1f4f95a89477df791bd5e67e
Reviewed-on: https://chromium-review.googlesource.com/318505
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Adds the SPI master driver with support for both SPI masters with
support for using GPIOs as chip selects or using the hardware's
dedicated chip selects.
Note this has not been enabled in the cr50 board.
BRANCH=none
BUG=none
TEST=verified through use of the SPI_FLASH module on cr51
Change-Id: I88719f8d03e217ab44249172b1340011fdcfdad5
Signed-off-by: Ewout van Bekkum <ewout@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/317329
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Don't build a table of host / console commands if the HOSTCMD or CONSOLE
task is not present. This saves space in the .hcmds / .cmds section and
allows the linker to prune command handler functions which will never be
called.
BUG=chrome-os-partner:41959
TEST=Verify ec.RO.flat shrinks on snoball and glados_pd, and remains the
same size on chell and samus. Also verify basic functions are still
working on snoball and glados_pd.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I79975c18ec1d87fedda8d1f299f30ffc43c24f69
Reviewed-on: https://chromium-review.googlesource.com/319112
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
A typical EC image includes two similar in their functionality
subsections, RO and RW. CR50 has a small RO subsection, all it does -
detects a proper RW image to run and starts it up. To provide for
reliable firmware updates, the CR50 image needs to include two RW
sections, while the code is running from one RW subsection, the other
one can be upgraded.
This patch adds the ability to generate two identical RW sections,
mapped half flash size apart, and include them into the resulting EC
image.
To keep things simple the previously existing RW section's name is not
being changed, while the new (identical) RW section is named RW_B.
Two configuration options need to be defined to enable building of the
new image type: CONFIG_RW_B to enable the feature and
CONFIG_RW_B_MEM_OFF to define where RW_B should be mapped into the
flash.
A new rule added to Makefile.rules allows to generate a different lds
file from the same source (core/cortex-m/ec.lds.S) by defining a
compile time variable to pick a different base address for the
rewritable section, when RW_B is built.
BRANCH=none
BUG=chromium:43025
TEST=as follows:
- make buildall -j still succeeds
- verified that regular CR50 image starts successfully
- modified chip/g/loader/main.c to launch RW_B first, re-built and
re-run the image, observed on the console:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
cr50 bootloader, 20151118_11218@80881, no USB, full crypto
Valid image found at 0x00084000, jumping
--- UART initialized after reboot ---
[Reset cause: power-on]
[Image: unknown, cr50_v1.1.4160-4c8a789-dirty 2015-12-07 18:54:27 vbendeb@eskimo.mtv.corp.google.com]
[0.001148 Inits done]
This FPGA image has no USB support
Console is enabled; type HELP for help.
> [0.002212 task 2 waiting for events...]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(note that the image base address is 0x840000, which is RW_B).
Change-Id: Ia2f90d5e5b7a9f252ea3ecf3ff5babfad8a97444
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/316703
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Allow boards to customize both the PWM frequency / period and the
enabling of complementary output signals.
BUG=chrome-os-partner:48044
TEST=Manual with snoball w/ subsequent commit. Run `pwm <ch> 50` for
each channel, verify with `adc` that each PD output voltage is
approximately VBUCK / 2.
BRANCH=None
Change-Id: I61cbb4a5b656f41ec7cec59339f5247902256295
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/315141
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Rather than having various PWM module groups initialized from various
HOOK_INIT functions, group them all into a single module and initialize
them all from a common function in pwm.c.
BUG=chromium:563708
TEST=Manual on samus / samus_pd (with CONFIG_ADC enabled). Verify that
samus fan + KB backlight control is functional and samus_pd correctly
sets PWM output.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9f9b09bfa544cd9bc6b7a867e77757dff0505941
Reviewed-on: https://chromium-review.googlesource.com/314882
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
A new extended subcommand code (1) is being added to handle hash
testing.
The new subcommand handler keeps track of multiple sha1 and sha256
contexts the host might want to exercise. The number of available
contexts is limited by the amount of available free memory.
One of four hash operations could be requested by the host: 'Start',
'Continue', 'Finish' - when hashing a single stream over multiple
extended command messages, and 'Single' when the entire message to be
hashed is included in one extended command payload.
The command payload had the following format:
* field | size | note
* ===================================================================
* mode | 1 | 0 - start, 1 - cont., 2 - finish, 3 - single
* hash_mode | 1 | 0 - sha1, 1 - sha256
* handle | 1 | seassion handle, ignored in 'single' mode
* text_len | 2 | size of the text to process, big endian
* text | text_len | text to hash
As soon as the first 'Start' message is encountered, the handler tries
to allocate shared memory to keep track of the test contexts, the
amount of available memory determines how many contexts the handler
can support concurrently.
As soon as the last 'Finish' command is encountered, the handler
returns the shared memory to the 'heap'.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=after adding the host side implementation and fixing a couple of
bugs, hash tests pass (see upcoming patches).
Change-Id: Iae18552d6220d670d1c6f32294f0af1a8d0d5c90
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314692
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Stack space is pretty tight on cr50, and since there is no need to
support SHA digest sizes in excess of 256 bits, the digest buffer size
should be reduced.
This patch makes the maximum expected digest size dependent on the set
of configured hash algorithms, moves hash size related asserts from
run time to compile time, and passes compile time definition to the
TPM2 library to increase its hash state container (it became too small
when SHA384 was disabled).
The sw context requirements should be reduced, but this is a task for
another day. We also do not have to store a local digest copy if the
API allowed reading a partial digest.
CQ-DEPEND=CL:314883
BRANCH=none
BUG=chrome-os-partner:43025, chromium:564862
TEST=all tests pass:
$ ./test/tpm_test/tpmtest.py
Starting MPSSE at 800 kHz
Connected to device vid:did:rid of 1ae0:0028:00
SUCCESS: AES:ECB common
SUCCESS: AES:ECB128 1
SUCCESS: AES:ECB192 1
SUCCESS: AES:ECB256 1
SUCCESS: AES:ECB256 2
SUCCESS: AES:CTR128I 1
SUCCESS: AES:CTR256I 1
SUCCESS: sha1:single 0
SUCCESS: sha256:single 0
/New max timeout: 1 s
SUCCESS: sha256:finish 1
SUCCESS: sha1:finish 3
SUCCESS: sha256:finish 2
Change-Id: Iaef3a230469de129e72418814e1d113b447c0137
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314695
Reviewed-by: Nagendra Modadugu <ngm@google.com>
From the "Device Class Definition for Human Interface Devices" spec:
When a Get_Descriptor(Configuration) request is issued, it
returns the Configuration descriptor, all Interface
descriptors, all Endpoint descriptors, and the HID descriptor
for each interface. It shall not return the String descriptor,
HID Report descriptor or any of the optional HID class
descriptors. The HID descriptor shall be interleaved between
the Interface and Endpoint descriptors for HID Interfaces. That
is, the order shall be:
Configuration descriptor
Interface descriptor (specifying HID Class)
HID descriptor (associated with above Interface)
Endpoint descriptor (for HID Interrupt In Endpoint)
Optional Endpoint descriptor (for HID Interrupt Out Endpoint)
This makes that happen.
BUG=chrome-os-partner:34893
BRANCH=none
TEST=manual
"make buildall" works, this image seems to work on the Cr50.
Also, before this CL, I see this:
0x00060f5c 0x00000000 .rodata g NOTYPE __usb_desc
0x00060f5c 0x00000009 .rodata g OBJECT usb_desc_conf
0x00060f65 0x00000009 .rodata g OBJECT usb_desc_iface0_0iface
0x00060f6e 0x00000007 .rodata g OBJECT usb_desc_iface0_1ep0
0x00060f75 0x00000007 .rodata g OBJECT usb_desc_iface0_1ep1
0x00060f7c 0x00000009 .rodata g OBJECT usb_desc_iface1_0iface
0x00060f85 0x00000007 .rodata g OBJECT usb_desc_iface1_1ep81
0x00060f8c 0x00000009 .rodata g OBJECT usb_desc_iface1_2hid
0x00060f95 0x00000000 .rodata g NOTYPE __usb_desc_end
and after, this:
0x00060f5c 0x00000000 .rodata g NOTYPE __usb_desc
0x00060f5c 0x00000009 .rodata g OBJECT usb_desc_conf
0x00060f65 0x00000009 .rodata g OBJECT usb_desc_iface0_0iface
0x00060f6e 0x00000007 .rodata g OBJECT usb_desc_iface0_2ep0
0x00060f75 0x00000007 .rodata g OBJECT usb_desc_iface0_2ep1
0x00060f7c 0x00000009 .rodata g OBJECT usb_desc_iface1_0iface
0x00060f85 0x00000009 .rodata g OBJECT usb_desc_iface1_1hid
0x00060f8e 0x00000007 .rodata g OBJECT usb_desc_iface1_2ep81
0x00060f95 0x00000000 .rodata g NOTYPE __usb_desc_end
The HID descriptor comes before the endpoint.
Change-Id: I8035a4cc884d8bb900bc1eb25fd3e4e9aba05bf8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314832
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Added new host command to support returning lid angle.
New output from ectool:
System with lid angle support:
------------------------------------------
localhost ~ # ectool motionsense lid_angle
Lid angle: 72
System without lid angle support:
------------------------------------------
localhost ~ # ectool motionsense lid_angle
EC result 3 (INVALID_PARAM)
BUG=none
BRANCH=none
TEST=run "ectool motionsense lid_angle"
verify the value matches the physical lid angle position
Change-Id: I4179172c778f643640561e819216f7adfee679d2
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/313345
Reviewed-by: Shawn N <shawnn@chromium.org>
If multiple TCPCs are present on a system then we may have multiple
alert signals, each of which alerts us to the status of a different
TCPC. Make boards with external non cros-ec TCPCs define
tcpc_get_alert_status, which returns alert status based upon any alert
GPIOs present, and then service only ports which are alerting.
BUG=chromium:551683,chrome-os-partner:47851
TEST=Verify snoball PDCMD task sleeps appropriately when no devices are
inserted, and verify ports go to PD_DISCOVERY state when we attach
samus. Also verify that glados / glados_pd can still negotiate PD.
BRANCH=None
Change-Id: Iae6c4e1ef4d6685cb5bf7feef713505925a07c8c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313209
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This change includes hardware and software support for SHA1/256 on
CR50. When running in the RO image, only hardware sha256 support is
included. When running in the RW image, the code auto-selects between
the software and hardware implementation. Software implementation path
is taken if the hardware is currently in use by some other context.
Refactor the CR50 loader to use this abstraction.
The existing software implementation for SHA1 and SHA256 is used for
the software path.
CQ-DEPEND=CL:*239385
BRANCH=none
TEST=EC shell boots fine (implies that SHA256 works)
BUG=chrome-os-partner:43025
Change-Id: I7bcefc12fcef869dac2e48793bd0cb5ce8e80d5b
Signed-off-by: nagendra modadugu <ngm@google.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313011
This adds a callback for board specific initialization that is called
after the driver init function. This will allow a board to apply
port-specific tuning (such as USB EQ settings) to the mux chip.
BUG=chrome-os-partner:47074
BRANCH=none
TEST=build and boot on chell
Change-Id: Ib162f9a2c5239678c46b80e5517823b336f6b66c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313746
Reviewed-by: Shawn N <shawnn@chromium.org>
On assertion of SLP_S0, EC goes to S0ix while system is in Lucid sleep
and EC is eligable to enter heavy sleep idle task.
Wakeup from S0ix by lid open, any key press, power button or track pad
will be done by PCH block by asserting SLP_S0.
At S0ix, 1 msec pulse will be generated every 8sec and this signal
should be ignored since this is NOT S0ix entry/exit related and defered
interrupt for SLP_S0 were added.
BRANCH=master
BUG=none
TEST=in OS shell, run following commands.
Following command is valid with coreboot with S0ix patches.
"echo freeze > /sys/power/state"
then,
Measure EC power consumption and compare it with one in S0.
And on EC console, there should be NO periodic message, "power
state 4 = S0ix, in 0x001d" every 8 sec.
Change-Id: Ia9cf5256b1ad7234815d4b6dbe2b45788aaf49dd
Signed-off-by: Kyoung Kim <kyoung.il.kim@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/307947
Commit-Ready: Kyoung Il Kim <kyoung.il.kim@intel.com>
Tested-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
Reviewed-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Throughout the code, there are comparison between frequency (in mHz) and
period (in us). To improve readability, append units (_mhz, _us) after
variable names.
BRANCH=smaug
BUG=none
TEST=compile.
Change-Id: Icc9c66d9f06c526fc3b74fd85ca9759b702ee416
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313221
Reviewed-by: Alec Berg <alecaberg@chromium.org>
We need to wake up the main task, even if we disable a sensor. It will
force sending the sensors samples in the FIFO and put a timestamp behind
them.
Also, reduce the interrupt period by 10us to be sure we fire interrupt
to the AP even if there are some variation in the timing calculation.
BUG=b:24367625
BRANCH=smaug
TEST=Run ts.SingleSensorTests overnight.
Change-Id: I6d966d52b5cbb72ba5eb936bc2fad6c06c7d8605
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312986
Reviewed-by: Alec Berg <alecaberg@chromium.org>
To ease finer calculation of ec rate change units from
ms to us.
BRANCH=smaug
BUG=b:24367625
TEST=compile
Change-Id: I52057c8ca1b1180a64b58d1ba0af9ec53f40b026
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312984
This code allows to send extension commands over TPM protocol, no
callbacks have been registered yet.
The same buffer is used as input and output data. The header is
stripped off before the callback is called and then re-added after
processing.
This could be used for testing, for proprietary firmware update
protocol, etc.
BRANCH=none
BUG=chrome-os-partner:47524
TEST=none yet
Change-Id: I91f692cc6e20abe774ee4ef001be28e5af102b2a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312587
This patch introduces a facility which would allow to compile in
callbacks for arbitrary commands passed over various communication
protocols.
Typically this will be used for testing, when various test commands
are multiplexed over an existing protocol.
The callbacks are associated with 16 bit command codes. On input the
callback receives a buffer, containing the command's argument, the
size of the command argument and the maximum size of the buffer. On
output the callback stores processing result in the same buffer and
updates the size to the actual amount of returned data.
Callback descriptors are stored in a dedicated read only section which
is scanned by extension_route_command() to find a callback associated
with a certain command code.
A console channel is also being introduced to allow controlling
console output generated by extension commands handlers.
BRANCH=none
BUG=chrome-os-partner:47524
TEST=none yet
Change-Id: I8ae16a78ca7d72176a5e7f74dd7a232078e7c06c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312586
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Use the previously introduced endian conversion routines in the driver
and the TPM2 library.
Use packed TPM message header structure to make it easy to access
unaligned header fields.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=the tpm startup command still succeeds.
Change-Id: I03078481664858a19617e248f98cb20013c27445
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312585
Support for various communications protocols requires the ability to
convert between big and little endian representation of integers. This
patch moves integer converting functions into the common scope and
uses the built in functions available in ARM architecture.
Since all today's ec platforms are running in little endian mode, the
functions being added assume that the host is little endian.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=none yet
Change-Id: I55ad0c5c3fe9f30cb4ed8ae807b1f5e4a54b8b35
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312584
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Overly complex previous formula could lead the EC to throw all samples
between 2 timestamps and put 2 event within one timestamp.
That would confuse the kernel. If the motion sense task is delayed while
this happen, the delta between the 2 samples could be so long that
CTS test cts.SingleSensorTests would fail.
BRANCH=smaug
BUG=b:24367625
TEST=Loops of cts.SingleSensorTests pass.
Change-Id: I29e6bf354ccb7ecf741a91116854d6abe07558dc
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312364
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The PWM clock on some chips can be configured to use different
sources, which will have a dramatic effect on the actual PWM
frequency. In order to support a variety of devices attached
to PWM outputs add an option to select an alternate source.
This is then implemented on the mec1322 chip to use the 100kHz
clock source for PWM which will allow it to drive a keyboard
backlight at appropriate frequencies.
BUG=chrome-os-partner:47435
BRANCH=none
TEST=verify that kblight brightness can be changed on chell
Change-Id: Ibe93a8e029baae5a2d5f520d590b0cc4ab9a7f93
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312509
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
On Ryu EVT2, where sensors share a 100kb i2c bus with other device,
when the sensors set to their maximal frequency and sampling interval
set to 5ms, the power management task would wait forever for the i2c
lock.
Increase the minimal amount of time the task can wait from 3ms to 8ms in
that case.
This is not an issue for Ryu PVT where the sensors are on a separate SPI
bus. However, on EVT, when setting the accelerometer/gyro over 125Hz, EC
won't be able to deliver the data in non-batched mode.
BRANCH=smaug
BUG=b:25510300
TEST=Without this change, an evt2 board would crash when plugging/unplugging
the charger while the sensors are set with:
echo 200000 > iio:device0/frequency # Accel
echo 5 > iio:device0/sampling_frequency
echo 200000 > iio:device1/frequency # Gyro
echo 25000 > iio:device2/frequency # Mag
Change-Id: Idb30da9ab8da61284388db73365c37be3a250dec
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311755
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Use test_export_static for static variable/function that needs to by
used by tests/motion_lid.c
BRANCH=smaug
BUG=none
TEST=Compile, make buildall -j
Change-Id: I2f3eb72ce319622842885be9125b91e58f47133a
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311754
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This commit introduces a new CONFIG_* option. To utilise the
experimental console, simply define the following config option in the
board's board.h file.
#define CONFIG_EXPERIMENTAL_CONSOLE
This is a temporary option which allows the EC console to be work with
the EC-3PO interactive console interface. When this option is enabled,
the EC expects commands to packed in a particular format. This is for
command integrity and allows the interpreter to perform automatic
command retrying in the event that a character is dropped from the sent
command.
It also removes a lot of the console editing methods since they are now
being served by EC-3PO.
Once the EC-3PO interpreter is pulled into servod, we can enable this
feature by default and the config option can go away.
BUG=chrome-os-partner:46054
BRANCH=None
TEST=make -j buildall tests
TEST=Enable CONFIG_EXPERIMENTAL_CONSOLE on GLaDOS; Flash EC and verify
that console works via the EC-3PO interactive console interface.
TEST=Build and flash on GLaDOS and verify normal console operation on
standard EC UART.
CQ-DEPEND=CL:308615
Change-Id: I5e66eb94e31299b27ce029b7f7ce6ba0a7fb6816
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/309991
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch completes introduction of building of proper RO and RW
images for cr50.
A few small mods were required:
- both RO and RW images have to be signed, using the same dedicated
signer, but with different keys, dev_key.pem is not needed any more.
- the RW image offset is not at the half of available flash, a chip
specific value of 16K is used instead.
The suggested new image layout is as follows:
+----------------------------------------+
| 1KB RO signature header. |
+----------------------------------------+
- -
| 15KB RO image. |
- -
+========================================+
| 1KB RW-A signature header. |
+----------------------------------------+
- -
- -
| 239K RW-A image. |
- -
- -
+========================================+
- -
| 16 KB NVRAM, shared |
- -
+========================================+
| 1KB RW-B signature header. |
+----------------------------------------+
- -
- -
| 239K RW-B image. |
- -
- -
+========================================+
BRANCH=none
BUG=chrome-os-partner:43025
TEST=The combined image (build/cr50/ec.hex) is successfully loaded and
started by the spiflash utility from the latest FPGA tarball.
Corrupting a byte in the generated image in the RW section causes
failure to verify.
Change-Id: I41a05168b0d4e9f88efa1003f261b6dd03972a24
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311422
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The values are there, we just need to be able to access them from the
code to be able to calculate how much of the flash space needs to be
made accessible for the image to run.
BRANCH=none
BUG=none
TEST=used by later patches
Change-Id: I4eb59525a50177cc7cc725871c3eab2ff390667b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311319
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Add HW charge ramping option and enable on glados.
Modify charge_manager to enable/disable HW charge ramping
when option is defined.
Unfortunately, the isl9237 doesn't have a way to determine
what the input current limit has settled on, so the EC will
always report the max input current for that supplier.
BUG=chrome-os-partner:47335
BRANCH=none
TEST=plug in CDP, SDP, DCP, type-C, and PD charger. Make sure
we ramp to a reasonable value for the correct suppliers.
Make sure we don't ramp for type-C and PD chargers.
Change-Id: Ib541fa0be48d8f4d261c71b853b0ee72b2adbf6b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311301
Reviewed-by: Shawn N <shawnn@chromium.org>
Add a new configuration struct tcpc_config_t that initially defines the
i2c host port and i2c slave address of all TCPCs present on the board.
This will allow us to create boards with multiple TCPCs on different i2c
ports, with arbitrary i2c slave addresses.
BUG=chromium:551078
TEST=Manual on glados. Verify PD communication / charging is still
functional on both PD ports.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9b2bde85d7f1642e8727c052e064371be7967619
Reviewed-on: https://chromium-review.googlesource.com/311000
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Some ECs such as the MEC1322 have a data RAM optimized region as well as
a code RAM optimized region. We discovered that we could save quite a
bit more space by reusing the a portion of the code RAM region as an
additional .bss section. However, this region resides in the code RAM
region. If on the same cycle the processor fetches an instruction and
does a load or store to this code RAM region, the data access will be
delayed by one cycle. Hence, the naming of ``.bss.slow" section.
For boards which do not define CONFIG_REUSE_LOADER_WITH_BSS_SLOW, all
objects bearing this tag will be simply appended to the existing .bss
section.
BUG=chrome-os-partner:46056
BUG=chrome-os-partner:46063
BRANCH=None
TEST=make -j buildall tests
CQ-DEPEND=CL:306173
Change-Id: I126fbeee5255732a6dd6fea1d4557fc2b2c62c96
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/311209
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
A previous commit caused ToT to use a not-yet-working bootloader.
This disables that bootloader by default so that the rest of us
can continue to work. ;-)
A configuration option is added to be able to address this issue in
the future with other boards as well.
BRANCH=None
BUG=chrome-os-partner:43025, chromium:551151
TEST=make buildall -j
Also verified that both normal and customized cr50 RO images build
and work as expected.
Change-Id: Ie433b07860cb1b04c12b2609c6fa39025fc0e515
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/310978
Under NVDC, BGATE natively has a body diode. Hence there's a discharging
path if VSYS is lower than VBAT. This change keeps VSYS voltage when
turning off charging.
BRANCH=none
BUG=chrome-os-partner:46698
TEST=manual
make buildall -j
load on boards with isl9237 charger.
charge the battery to full, and check charging voltage and current.
Change-Id: I8a6046444dd40a3b57f034be124b9e8fe281de40
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309289
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Some chips previously defined CONFIG_I2C and others didn't. Standardize
the usage by removing CONFIG_I2C from all config_chip files and force it
to be defined at the board level. Also, make boards define
CONFIG_I2C_MASTER and/or CONFIG_I2C_SLAVE based on the I2C interfaces
they will use - this will assist with some later cleanup.
BUG=chromium:550206
TEST=`make buildall -j`
BRANCH=None
Change-Id: I2f0970e494ea49611abc315587c7c9aa0bc2d14a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/310070
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
I2C1 may be clocked by HSI or SCLK. I2C2 is always clocked by PCLK.
Therefore, apply different timing register values according to the
selected clock source for a port.
BUG=chrome-os-partner:46188
BRANCH=None
TEST=Manual on glados_pd. Verify slave i2c communication is functional.
Change-Id: Icd2306d25d5863b0fc3379e46885a227efb23cca
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309781
Commit-Ready: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Define CONFIG_USB_PD_LOW_POWER by default to save power on both
TCPM and TCPC side by waking PD task less often when possible.
BUG=none
BRANCH=none
TEST=test on glados and samus.
Change-Id: I04441fb8339652cf073689177175a98f28807897
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309311
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Call shutdown() entry point at init() and remove duplicate code.
shutdown would init the sensor so they would be ready if needed.
Set S5 flag to include G3 (hard off) state, not only S5 (soft off).
BUG=chrome-os-partner:45722
BRANCH=smaug
TEST=When doing a RO->RW transition while AP is in G3, check the sensors
are initialized properly. This issue was found while testng the magic
sequence code.
Change-Id: I647f83580240bf5ba0c340fca3184220abe4c12e
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308561
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add support for two new configs to specify critical energy battery
percentage and critical external charger power. When we are under both
thresholds, set the LIMIT_POWER charger parameter to inform the AP that it
should conserve power to avoid brownout, and consider jumping to EC RW
to negotiate PD.
In addition, modify the existing CONFIG_CHARGER_MIN_BAT_PCT_FOR_POWER_ON
to allow power-up regardless of power level if a 15W+ charger is
attached, since there is a reasonable chance it may speak PD and provide
sufficient power to boot the AP.
BUG=chromium:537269
TEST=Manual on Glados. Set CHG_MW thresh to 20000, BAT_PCT to 50. Verify
that LIMIT_POWER charger param is set until Zinger negotiates to 20V. Also
veify that system can boot with Donette.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ic963c82fea4ad10e8a5d7e476c5ce3e5ae525dad
Reviewed-on: https://chromium-review.googlesource.com/306774
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
ARM systems currently use SBS kernel driver which talks to the battery
through I2C passthu in the EC. Instead when asking for battery
information try getting it from the charge state machine first, and
then try the battery if charge state does not have the information.
This reduces latency by cutting out the battery response time.
BUG=chromium:484841
BRANCH=none
TEST=check that power_supply_info works properly on Jerry
Change-Id: If4da15ccabe412adc31fc94b189089ebb3e9265c
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307905
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When ALS is enabled, if light is around one threshold (say 40 lux),
the lightbar will flicker between readings.
Add a histeresis to prevent the flickering.
The current setting is:
setting ^
(dim) 2 | ------+---->---+
1 | +----<---+--->---+
(bright) 0 | +---<---+---------
+-------+--------+-------+--------> lux
20 40 60
BRANCH=smaug
BUG=chrome-os-partner:44400
TEST=check in a dark room (30~40 lux) there is no flickering.
Add unit test.
Change-Id: I4018e2c2ed764abf9c9ed28e2d50a3e94a7d5f75
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308205
On boot, if VBUS is present, then when PD protocol gets to
SNK_DISCOVERY state, if it times out waiting for source cap,
then send attempt to send a soft reset first instead of
directly sending a hard reset. This allows us to not lose
VBUS in the case that we were in a stable contract as a sink
before this boot (for example a sysjump or EC reboot).
BUG=chrome-os-partner:44085, chrome-os-partner:44952
BRANCH=none
TEST=test on glados and samus. test by sysjumping between
RO and RW with zinger plugged in and no battery, and verify
that we don't lose power. also test rebooting with a battery
and verify we don't lose power. also tested with a third
party PD charger.
Change-Id: Ib7ce46d8b9843db66805ba3237d8919d611324e0
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308201
Reviewed-by: Rong Chang <rongchang@chromium.org>
On TCPC startup, set an alert to notify TCPM that we have been
reset. When TCPM gets this notification, it should re-send
initial TCPC parameters. If we were in a stable contract as
a sink, make sure we don't reset connection. If not, then
reset PD protocol state machine to the default state.
This fixes a bug where if the TCPC reboots while the TCPM is
still running, then the TCPC would not get re-initialized and
therefore no PD communication would not work. This also fixes
it such that if we are in a stable contract as a sink and the
TCPC reboots, then we don't lose power.
BUG=chrome-os-partner:46676
BRANCH=none
TEST=tested on glados. reboot PD MCU with and without a charger
plugged in and verify that PD communication works after the
reboot. verify that with a charger, we don't lose power.
also tested with a hoho plugged in during reboot.
Change-Id: I84fec4577b0daf5891bd8461d3f3d925014a5ecf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307187
Reviewed-by: Shawn N <shawnn@chromium.org>
Unless the lid is closed, the ALS is used for lightbar dimming.
Change the google colors depending on the light sensor result.
BUG=chrome-os-partner:44400
BRANCH=smaug
TEST=Check all 3 levels of brightness of the lightbar.
Check value using "adb shell ectool lightbar"
Check double tap color are not affected and is using full brightness.
Change-Id: I7b5e2890c3557f1dd3ae719f5f82ffb5fe7b24fb
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/301216
Reviewed-by: Alec Berg <alecaberg@chromium.org>
