Currently, the power LED pulses in sleep state on Pantheon. This patch
makes it blink with 25% duty. That is, the LED turns on for 1 sec then
turns off for 3 sec.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=b:79733195
BRANCH=none
TEST=make BOARD=nami
Change-Id: I0ebd2778b9b6551f2313ea8f8648c69324e02368
Reviewed-on: https://chromium-review.googlesource.com/1069337
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Split battery info between baseboard and board, following the
Octopus example. This will allow Grunt and Careena to define their
own lists of supported battery types.
This also adds CONFIG_BATTERY_REVIVE_DISCONNECT support, and
checks the charge/discharge FET status.
BUG=b:79704826,b:74018100
BRANCH=none
TEST=Grunt still boots ok.
Change-Id: I6e82ac5e48f9aabf59b63add253108513f0a6b60
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1072039
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
The default setting of the ROP PMIC's V085A output voltage is incorrect
for our application. This commit changes the output voltage to actually
be 0.85V.
BUG=b:80271678
BRANCH=poppy
TEST=Flash nocturne and verify that V085A is ~0.85V.
Change-Id: I3c6c7396bc8b896620aab7e4719f8a14b4a46e4a
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1077085
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
An ADC conversion requires ~10 msec. However, if the bq25703 is in low
power mode, then this conversion time jumps to ~55 msec. This CL adds
a method to exit/enter low power mode and adds a call to exit low
power mode prior to starting the ADC conversion. Following the
conversion, low power mode is entered again.
BRANCH=none
BUG=b:79771760
TEST=Connected AC power and verified that EC console error message
'Could not read input current limit ADC' is no longer shown. In
addition, had instrumented this the ADC conversion with GPIO signals
and verified the conversion times before/after exiting low power mode.
Change-Id: I13f36e6261e219adbc8624f71bf7916bbc631b10
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1069768
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
We added a cr50 vendor command to control factory mode. This change adds
gsctool support for using the command.
gsctool -F [enable|disable] can be used to set factory mode. You can't
use it to get the factory mode setting, because factory mode is
indistinguishable from other forms of ccd. The regular ccd info can be
used instead gsctool -I.
BUG=b:77543904
BRANCH=cr50
TEST=none
Change-Id: I715e296c323be20bab0b54a2f94a380b61f74cd2
Signed-off-by: Mary Ruthven <mruthven@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1069370
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The factory reset command can be used to enable ccd factory mode. The
command can open ccd if write protect is removed and ccd hasn't been
restricted. Right now we check FWMP and the ccd password before allowing
factory reset. Factory reset cannot be used to get around anything that
disables ccd.
This adds 72 bytes.
BUG=b:77543904
BRANCH=cr50
TEST=Try enabling factory mode using factory reset. Verify setting write
protect, setting the FWMP disable ccd bit, or setting a ccd password
prevents factory reset from enabling factory mode.
Change-Id: I6e203bf6068250f009881aa95c13bc56cb2aa9e7
Signed-off-by: Mary Ruthven <mruthven@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1069369
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Currently, console_init calls cflush() twice, once before
"Console is enabled" string is printed, once afterwards.
The reason is that firmware_ECBootTime looks for that string,
and it may get corrupted/interleaved with others if the EC
is busy during initialization.
The problem here is that the CONSOLE task may have higher
priority than other tasks (for good reasons), but, on boot,
there are other more critical tasks that need to run (e.g.
RW image verification), rather than busy-looping waiting for
the console to be flushed.
By fixing firmware_ECBootTime to not look for the string anymore,
we do not need those 2 console flush.
BRANCH=poppy
BUG=b:35647963
BUG=chromium:687228
CQ-DEPEND=CL:1075832
TEST=Flash staff, see that RW verification starts at 0.001037
instead of 0.028087 (=> 27 ms faster).
TEST=test_that -b $BOARD $IP firmware_ECBootTime
Change-Id: I794e48eb69cc647c4595fd80265adee4a434d566
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1073180
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We need to control the console channels for cr50 testing, so we need
access to chan even if the console is restricted. Make chan a safe
command so it is always accessible.
BUG=b:80319784
BRANCH=cr50
TEST=on cr50 make sure the command is accessible no matter the console
state
Change-Id: Ia392f32c319c1acf9bb97b97d7f72c7e56427ce3
Signed-off-by: Mary Ruthven <mruthven@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1079452
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch makes Sona follow the standard LED pattern for single LED
systems. Sona has two LEDs but both are connected to the same pin.
This increases userbility because LEDs are visible from each side
and users don't have to learn two different sets of patterns (i.e.
one for left LED and onother for right LED).
* Charging Amber on (S0/S3/S5)
* Charging (full) White on (S0/S3/S5)
* Discharge in S0 White on
* Discharge in S3/S0ix Alternate pulse (up-down-off-off)
* Discharge in S5 Off
* Battery Error Amber on 1sec off 1sec
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=b:80135370,b:74940319
BRANCH=none
TEST=Verified LED behaviors in S3, S0, charge, discharge on Sona
Change-Id: I1bd53c7c60529a8b813eabc338876af6d089ec82
Reviewed-on: https://chromium-review.googlesource.com/1074226
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Jack Huang <jachuang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Grunt and Careena hardware does not support sourcing 3A over USB-C
so reduce what we advertise to 1.5A.
BUG=b:78908554
BRANCH=none
TEST=Grunt advertises 1.5A Source Cap on both ports
Change-Id: Ifd3ddf45445ae69c5988dee4f66f21056b4b0f96
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1077096
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
We're doing a bit of refactoring to break out factory mode into its own
file. Now factory reset and rma reset will be two methods of entering
factory mode. Factory mode can be disabled with the disable_factory
vendor command.
Factory mode means all ccd capabilities are set to Always and WP is
permanently disabled. When factory mode is disabled, all capabilities
are reset to Default and WP is reset to follow battery presence.
This adds 56 bytes.
BUG=none
BRANCH=cr50
TEST=verify rma reset will enable factory mode.
Change-Id: I21c6f7b4341e3a18e213e438bbd17c67739b85fa
Signed-off-by: Mary Ruthven <mruthven@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1069789
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Using the p256 curve is beneficial, because RMA feature is currently
the only user of the x25519 curve in Cr50, whereas p256 support is
required by other subsystems and its implementation is based on
dcrypto.
The p256 public key is 65 bytes in size, appropriate adjustments are
being made for the structure storing the server public key and the key
ID.
The compact representation of the p256 public key requires 33 bytes,
including the X coordinate and one extra byte used to communicate if
the omitted Y coordinate is odd or even.
The challenge structure communicated to the RMA server allows exactly
32 bytes for the public key. To comply, the generated ephemeral public
key is used in compressed form (only the X coordinate is used).
For the server to properly uncompress the public key one extra bit is
required, to indicate if the original key's Y coordinate is odd or
even. Since there is no room for the extra bit in the challenge
structure, a convention is used where the generated ephemeral public
key is guaranteed to have an odd Y coordinate.
When generating the ephemeral key, the Y coordinate is checked, and if
it is even, generation attempt is repeated.
Some clean up is also included: even with debug enabled, generated
challenge is displayed only once as a long string, convenient for
copying and pasting.
The new feature is not yet enabled, p256 support on the RMA server
side is not yet available.
Enabling p256 curve for RMA authentication saves 5336 bytes of the
flash space.
BRANCH=cr50, cr50-mp
BUG=b:73296606
TEST=enabled CONFIG_RMA_AUTH_USE_P256 in board.h, generated challenge
and verified matching auth code generated by the rma_reset
utility.
Change-Id: I857543c89a7c33c6fc2dc00e142fe9fa6fc642cf
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1074743
Reviewed-by: Randall Spangler <rspangler@chromium.org>
ID pins are considered additional KSOs while keycode scanning works
for the existing KSI0 ~ KSI7. While diriving ID pins, the state of
interconnection between ID pins and KSI pins could be used for
identifiers to tell keyboard itself. (e.g. US, Japan,and UK keyboard)
BRANCH=master
BUG=b:80168723
TEST="make -j buildall"
TEST=Verified 5 distinct keyboard samples w/ different Language ID values
on the same reworked Coral, which VOL_UP and VOL_DOWN were reworked
for ID pins. crrev.com/c/1053617 is my experimental patch on top of
this for further verification
Change-Id: I1d6e647df74c50d60bc1264c045b2587d0bf23d8
Signed-off-by: paris_yeh <pyeh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1068951
Commit-Ready: Paris Yeh <pyeh@chromium.org>
Tested-by: Paris Yeh <pyeh@chromium.org>
Reviewed-by: Paris Yeh <pyeh@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The ec_boot_mode is used for flashing EC on STM32 and NPCX chips.
The ec_boot_mode pin is an open-drain GPIO. Doing save/restore is
destructive. For example, if DUT is unpowered (ec_boot_mode is "on"),
doing save/restore will force it outputting to "on". We should not
put it to the save/restore list. Instead, set it back to "off" on
exit.
BRANCH=none
BUG=b:80305869
TEST=Ran flash_ec when DUT is unpowered -> failed as expected.
Reran again when powered. Checked EC UART showed-up afterward.
Change-Id: Iecf4b663fe9ae75a673a29a66505a4121d29888c
Signed-off-by: Wai-Hong Tam <waihong@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1073646
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We have determined the checks to run for board_is_first_factory_boot.
This change updates cr50 to check for those conditions and enable ccd
when the system determines that it is first boot in the factory. This
will check that the board id is erased and the inactive image is a GUC
image.
The factory updates Cr50 from the GUC image, because those GUC images
don't have support for everything they need to do in the factory. To
determine that cr50 just recovered from that factory update, it will
check that the GUC image is still in the inactive region and no board id
is set.
There are 2 images installed in GUC 0.0.13 and 0.0.22, so cr50 will
check these versions. Future GUC images will have a field in the header
declaring that they are a GUC image. I still need to create the GUC
field in the header and check that in inactive_image_is_guc_image.
Factory mode can't be enabled on deep sleep resume. It is only enabled
after power-on reset or hard reset.
This change also moves factory stuff into a factory_mode file instead of
keeping it in board.c
This adds 200 bytes.
BUG=b:77543904
BRANCH=cr50
TEST=Verify factory mode is only enabled when cr50 recovered from
reboot not deep sleep resume, 0.0.13 or 0.0.22 are in the inactive
region, and the board id is erased.
Change-Id: Ibece878049658493e8ad159121ada63d7a6f6b79
Signed-off-by: Mary Ruthven <mruthven@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1059864
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
There is a potential loop:
(1) We throttle AP when we see under-voltage.
(2) VBAT bumps because throttling starts. From our experiment,
AP throttling saves ~1A, and thus VBAT increases by ~80mV.
(3) VBAT hasn't hit BAT_LOW_VOLTAGE_THRESH for BAT_UVP_TIMEOUT_US,
so we stop throttling.
(4) VBAT again drops below BAT_LOW_VOLTAGE_THRESH.
(5) Go back to (1).
So let's introduce a hysteresis to under-voltage throttling.
We stop throttling only when we are confident that even if we stop
throttling, the battery voltage will stay above BAT_LOW_VOLTAGE_THRESH.
BUG=b:73050145, chromium:838754
BRANCH=scarlet
TEST=manually test on scarlet
Change-Id: Ic0c17a7d37d5d6ee38c7b19f9b65d17421e55cbc
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1070568
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
we normally try to find out a few things about a battery (like charge
level) before actaully applying charging power to it. when the
battery is completely discharged, the controller on the battery can't
respond as it is not self-powered. so, we have to avoid all
operations that depend on the battery responding in the battery
discovery/initialization path.
as long as we report that a battery is present and it is not
responsive, the charger task will enter ST_PRECHARGE which means it'll
provide a "precharge" current to the battery to try to talk to it.
this allows the battery's controller to report battery parameters
allowing our charger task can do the right thing.
BUG=b:79354967
BRANCH=none
TEST=atlas now discovers the discharged battery reliably
Change-Id: I5e5a3abda07508eb791b712fb2f9b9f5fe383e07
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1065492
Commit-Ready: Caveh Jalali <caveh@google.com>
Tested-by: Caveh Jalali <caveh@google.com>
Reviewed-by: Caveh Jalali <caveh@google.com>
Use a queue now for sync events, this will allow multiple interrupts to be
called before the motion sense task executes. The events (including
timestamps) get stored in a small queue. 8 events for the queue size should
be plenty, most applications will have latency concerns anyway once we
get a couple of queued up events.
Also changed the init function to be a little bit more robust to race
conditions. Added count argument to the "sync" simulation command to test
the queue behavior.
BRANCH=master
BUG=b:73551961, b:67743747
TEST="sync 4" yields 4 events on the AP, whereas before it would only
give the AP the last event.
Change-Id: I9fcb1fb8b35eb5f8ffcc21afbfcb0f0d9bc33804
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1065149
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Decreases verification time from 923ms to 785ms.
Optimized version do not really help in RW, as they just increase
the image size (which also increases verification time).
BRANCH=fizz
BUG=b:77608104
TEST=make BOARD=fizz -j, flash fizz, check timing.
Change-Id: Ia8c36c35c0321c1995dc1cede7b27f7636037795
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1075908
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Some devices have GPIO pins that control USB port power connected to
the EC, so they cannot be toggled by ACPI. This patch adds a memory
map between the EC and ACPI that can be used on such devices. It can
hold the power state of up to 8 USB ports. Currently, only dumb power
ports are supported.
BUG=chromium:833436
BRANCH=fizz
TEST=On a fizz that runs BIOS with EC_ACPI_MEM_USB_PORT_POWER mapped,
check that both reads and writes are propagated.
Change-Id: I413defcb9e4d234fea7f54d46b6b8a1a10efa31e
Signed-off-by: Emil Lundmark <lndmrk@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1069273
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Since the PS8751 is now driving the EN_SNK GPIO on the PPC, we cannot
reset without a battery otherwise we will brown out the board.
BRANCH=none
BUG=b:78896495,b:78021059
TEST=verified with reworked board.
Change-Id: Ibadf46de922c49f5fdd08c43991e71f852ff7600
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1067711
In RSA, we often need to actually compute (a*b)+c+d: provide some
assembly optimized functions for that.
With -O3, 3072-bit exponent, lower verification time from 104 ms to
88 ms on STM32F072 @48Mhz.
BRANCH=poppy
BUG=b:35647963
BUG=b:77608104
TEST=On staff, flash, verification successful
TEST=make test-rsa, make test-rsa3
TEST=make BOARD=hammer test-utils test-rsa3, test on board
Change-Id: I80e8a7258d091e4f6adea11797729ac657dfd85d
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1071411
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Dumb USB ports do not have the same notion of charge mode as smart
ports. However, the header common/usb_charge.h declares a function for
changing charge mode that the dumb USB port power implementation does
not define. Instead, it defines a similar function with a different
name, albeit with other allowed values for its second parameter.
This patch makes the names the same so the function can be used by
simply including the aforementioned header file.
BUG=none
BRANCH=fizz
TEST=emerge-fizz chromeos-ec
Change-Id: I87863f87f32f538cc1c723d9299afcc7353e1852
Signed-off-by: Emil Lundmark <lndmrk@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1069272
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This will be called after touchpad firmware is updated. "Full
initialization" will trigger auto tuning.
This function can also be called by console command `touchpad_st
calibrate`.
BRANCH=none
BUG=b:70482333
BUG=b:78483107
TEST=manual
Signed-off-by: Wei-Han Chen <stimim@chromium.org>
Change-Id: I336dfa79ae5133750dc90ba07cbe9fc81318e84e
Reviewed-on: https://chromium-review.googlesource.com/1049765
Commit-Ready: Wei-Han Chen <stimim@chromium.org>
Tested-by: Wei-Han Chen <stimim@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
tcpm_get_chip_info does not modify the parameter info if the
function is not implemented on the given chip.
This has a interesting side effect on Kevin, where, for whatever
reason, info's value ends up being 1, and causes unaligned access
exception:
[0.039 TCPC p0 init ready]
=== PROCESS EXCEPTION: 06 ====== xPSR: 61000000 ===
r0 :00000000 r1 :28000000 r2 :00000001 r3 :00000000
r4 :00000000 r5 :00000000 r6 :00000000 r7 :00000000
r8 :200c60f4 r9 :00000000 r10:100c0c3c r11:00000000
r12:200c52ed sp :200c5320 lr :100a9c71 pc :100abd5a
Unaligned
mmfs = 1000000, shcsr = 70008, hfsr = 0, dfsr = 0
BRANCH=none
BUG=none
TEST=On ToT make BOARD=kevin -j; flash, kevin boots
Change-Id: Ie7e758d5fb8c31180f36b073b635e54cc720a8a0
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1073179
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We multiply 2 32-bit numbers (and not 64-bit numbers), and then add
another 32-bit number, which makes it possible to optimize the
assembly and save a few instructions.
With -O3, 3072-bit exponent, lower verification time from 122 ms to
104 ms on STM32F072 @48Mhz.
Optimized mac function from Dmitry Grinberg <dmitrygr@google.com>.
BRANCH=poppy
BUG=b:35647963
BUG=b:77608104
TEST=On staff, flash, verification successful
TEST=make test-rsa, make test-rsa3
TEST=Flash test-utils and test-rsa to hammer => pass
Change-Id: I584c54c631a3f59f691849a279b308e8d4b4b22d
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/449024
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This patch adds RMA shared secret generation support using the p256
curve. It is not a simple shoe in replacement for the x25519 because
of a different key representations. This new code uses openssl library
for all calculations.
A new option is being added to indicate that p256 is supposed to be
used, the new server Key ID value is used for p256, which allows to
pick the correct curve when parsing the previously generated
challenge.
BRANCH=none
BUG=b:73296606
TEST=verified that the same secret value is generated on the client
and server side when using either x25519 or p256 curves.
./rma_reset -t
./rma_reset -c <challenge generated by the previous command>
./rma_reset -t -p
./rma_reset -c <challenge generated by the previous command>
Change-Id: I9b21b5ae389480d92f0f663fbb846b0f27b15de1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1073757
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Saves another ~1300 bytes of flash size, as the touchpad
hashes can now be computed in blocks of 4K, instead of 1K.
This costs 3K of SRAM, which we would not otherwise need on
hammer.
wand can only fit 2k PDU, so let's stick to that.
Also, make sure that util/gen_touchpad_fw is regenerated when the
configuration option changes (touchpad FW size, PDU size). Sadly,
this will still break bisection from commit after this CL, to
before this CL.
BRANCH=poppy
BUG=b:80167548
TEST=make buildall -j
TEST=make BOARD=hammer/staff/wand/whiskers all tests -j
TEST=Copy new staff image with old touchpad FW to DUT, verify that
FW can be updated.
Change-Id: Ic1763684da730dc986bbbcb3312088c8208c84b5
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1070953
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Some tests cannot be built on some boards (not enough SRAM,
unusual configuration, etc.). Instead of the long list of
exceptions in test/build.mk that we currently use, allow
each board (or chip) build.mk to set test-list-y, and
only use the default list if it is unset.
BRANCH=poppy
BUG=b:80167548
TEST=make buildalltests -j
Change-Id: I803c691f419451aad4396529302a4805cbe3f9b5
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1074572
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
memchr does not take into account end of string, so the test
`memchr("123", '4', 8)` actually does a buffer overflow. On some
boards, a '4' might be found in the 4 bytes that follow "123", and
the test might fail.
Fix another potential overflow as well.
BRANCH=none
BUG=none
TEST=Flash test-utils to hammer, test passes
Change-Id: I53755c0855bbd5b180801e4198341de1cec7b425
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1071409
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is mostly a clean up and refactoring change, which will make it
easier to extend rma_reset to supporting more EC curves.
BRANCH=none
BUG=b:73296606
TEST=verified that the same secret value is generated on the client
and server side by running
./rma_reset -t
./rma_reset -c <challenge generated by the previous command>
Change-Id: I15c010a4a62306bfaa56b97936318854b28a4945
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1073756
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When invoking make with DEBUG=1 add '-g -O0' to the compiler
invocation to facilitate debugging with gdb.
BRANCH=none
BUG=b:73296606
TEST=verified that building with DEBUG=1 adds '-g -O0' to the compiler
invocation.
Change-Id: Idd80bd481091b91683200c78fe49dc7e9783a730
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1073755
Reviewed-by: Randall Spangler <rspangler@chromium.org>
