If the UART0 RX pad is not pulled up, cr50 will get held up on all of
the interrupts triggered by the low signal. This causes cr50 to reboot
continuously. UART0 RX was moved to DIOA13, which does not have an
internal pull up. This means we have to rely on an external pull up.
Because not having an external pull up on DIOA13 could prevent the
system from booting and UART0 RX is only used as an alternate debugging
mechanism from suzyq, we decided it is best for UART0 RX to be disabled
by default.
BUG=none
BRANCH=none
TEST=Connect UART1_RX to DIOA1 and test that it still accepts input.
Disconnect it from any pads. Verify the system boots normally and
console input from DIOA1 no longer works but the suzyq shell still does.
Change-Id: I68988c59cfce610cc6c360bf8dd9685e98ab12ff
Reviewed-on: https://chromium-review.googlesource.com/357881
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
The firmware needs to talk to the EC while the power button is pressed.
If the EC did not even leave the S5->S3 state this is not possible.
Seems like the piece of code is not even necessary, check_for_power_off_event
will catch the long press asynchronously later on anyway.
BRANCH=none
BUG=chrome-os-partner:54781
TEST=power up by power button and hold it, there should be
no error logs during EC sync, and screen turns on for a short time
then off
Change-Id: Ic0cccb6cfc5ddd389c1111a77ec06530a9e429ef
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/359152
Reviewed-by: Rong Chang <rongchang@chromium.org>
If wait_us < 0, comparison against motion_min_interval actually fails,
and this negative wait_us causes task_wait_event() never returns if we
are not using any motion task event except the timer. The motion task
will then stop running and sensor data stay unchanged.
BRANCH=none
BUG=chrome-os-partner:54092
TEST=hardcode wait_us to a negative value before motion_min_interval check,
and see motion task is still running by EC console cmd timerinfo
Change-Id: Ic1e7ffeeb9d2ec1f5c5beb4387294014298123af
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/358332
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
The first time you use this with a particular th,
connect only th and run ./cts.py --th
Then connect both boards and you can run
./cts.py to build/flash both boards.
BRANCH=None
BUG=None
TEST=manual
- Enter chroot
- Navigate to ec/cts
- Connect only th
- 'sudo ./cts.py --th'
- './cts.py -b'
- Exit chroot
- Connect both boards
- './cts.py -f'
Each board should flash successfully
Change-Id: Ib14fccabcd9fdad04f9b92817da597bc0dcb3d89
Reviewed-on: https://chromium-review.googlesource.com/358100
Commit-Ready: Chris Chen <twothreecc@google.com>
Tested-by: Chris Chen <twothreecc@google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
If the EC has CONFIG_HOSTCMD_RTC set to 'y', then export this via the
features host command. The kernel can then use this feature to expose
an RTC device under /dev/rtc*.
Signed-off-by: Stephen Barber <smbarber@chromium.org>
BRANCH=none
BUG=chrome-os-partner:54639
TEST=`ectool inventory` shows RTC on kevin
Change-Id: I644c8e61c4d9f691cc6ca94ef60bee4384c21660
Reviewed-on: https://chromium-review.googlesource.com/359414
Commit-Ready: Stephen Barber <smbarber@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This feature is inconsistent. Not all boards have such a symlink
(for a obvious reason).
This feature is fragile. It's most likely not tested and going to be
broken if not already. Developers won't like it if they have to test
two different ways to build boards before submitting patches.
This feature is not necessary. If you build EC in the standard way
(e.g. make BOARD=samus), these symlinks are not needed.
This feature is wasteful. Extra disk spaces are used and extra lines
are added to Makefile (increasing code complexity slightly).
BUG=chromium:626776
BRANCH=none
TEST=make buildall
Change-Id: Id5444284d773cb0e9225f39abd877441b8f61440
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359321
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We have more than enough memory for that, and it makes it possible
to poll the logs from AP much more unfrequently.
BRANCH=oak
BUG=chromium:527904
TEST=make buildall -j
TEST=Boot elm, cat /sys/kernel/debug/cros_ec/console_log does not
miss any data.
Change-Id: I8cce88e39d00a94397b6fc852a371b4595870b24
Reviewed-on: https://chromium-review.googlesource.com/358181
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
elm EC console output is very spammy, as EC_CMD_MOTION_SENSE_CMD
is called every 100ms. Even when hcdebug is set to off, we still
get command errors.
BRANCH=oak
BUG=chrome-os-partner:55001
TEST=make buildall -j
TEST=Flash elm EC, see that output is fairly quiet.
Change-Id: I0a5ab2950911648e2e34f4ab1b6886e3e4bff774
Reviewed-on: https://chromium-review.googlesource.com/358438
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
elm EC console output is very spammy, as EC_CMD_MOTION_SENSE_CMD
is called every 100ms, so we want to set "hcdebug" to "off" as
the default (which still includes errors, but no "normal"
commands).
BRANCH=none
BUG=chrome-os-partner:55001
TEST=make buildall -j
TEST=Flash elm EC, see that output is fairly quiet.
Change-Id: I70d91c291d934b4f032e5c57f3c333e2c10b93bc
Reviewed-on: https://chromium-review.googlesource.com/359112
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
The EC asserts system reset on init, and Cr50 asserts ec_rst when it is
rebooted. Having the EC and Cr50 keep resetting each other prevents the
system from booting. We only care that Cr50 is restarted when the system
is restarted, so if it gets a system reset call when it is still
initializing everything it is okay to ignore it.
This change expects the EC to do a system reset on init, so it ignores
the first system reset. It will automatically enable the hard resets
two seconds after the board is initialized if it doesn't detect the
initial system reset.
BUG=none
BRANCH=none
TEST=reef and kevin can boot normally. Verify asserting sys_rst_l after
boot resets Cr50 and the rest of the system.
Change-Id: I198208950c526efd3ee0171812de3052785555f2
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358943
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This just adds a print statement to display board version at the
EC console the first time board_get_version() is called.
BUG=none
BRANCH=none
TEST=print shows up as expected with follow-up patches applied.
Change-Id: Ib7eae79a90bdaa58165aa5b102bc446f21a98963
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358910
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Proto had two pins for PROCHOT# - One to monitor and one to override.
Newer boards have only one pin that serves both purposes.
BUG=chrome-os-partner:54953
BRANCH=none
TEST=built and booted on reef
Change-Id: Ida4bc2766caf15562c26e7a4b792a07604361da2
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358940
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
While the proper manufacturing initialization is in the works, we need
to be able to initialized the device, but do not want to run
manufacturing process on every reboot.
Let's store the state in the lowest location of the NVRAM, this patch
will be reverted when the proper initialization procedure is in place.
BRANCH=none
BUG=chrome-os-partner:50115
TEST=used the device in Kevin. Observed that factory initialization
sequence was invoked only on the first boot, the following boots
had no problems reading rollback counters.
Change-Id: I812cbad4d91db47de76ecfa5a14c56ae9c0efdab
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358680
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
This makes corrections to the board ID values and also adds a small
multiplier to allow for higher-than-ideal voltages to match.
Currently we see values that are below the ideal value by about
2.5%, so it seems like a good idea to also allow slightly above ideal
voltage to account for variations in Vref or PP3300_EC that could
cause the calculated value to become higher than expected.
BUG=none
BRANCH=none
TEST=none
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ia091fbbad7ffce2da9a04c48c7676ad9b4a08dea
Reviewed-on: https://chromium-review.googlesource.com/358614
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
The ADC multiplier and divider factors were lazily set to 1 when
the board support was first added, so the value was not scaled
properly.
The conversion formula is: Vi = CHNnDAT * (Vfs / 1024) where
Vfs = Vref = 2.816V for Reef.
BUG=none
BRANCH=none
TEST=added debug print and reading now approximately matches
what the voltmeter reads.
Change-Id: Ic60a8bc1d84c4f9a7b5664e9daddfa331b6a890c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358613
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Rename from V5A_EN to PMIC_EN.
The name V5A_EN came from Amenia where it controls both
5V_A-Rail and PMIC_EN.
Reef has a separate 5V_A-Rail control (EN_PP5000) and
an another GPIO pin for PMIC_EN.
BUG=chrome-os-partner:53666
BRANCH=none
TEST=buildall pass
Change-Id: Ic5e39b9811a6cf0e968c1d6262b9b9f849268ed4
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/354767
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Board initialization function configures certain RBOX registers, but
RBOX initialization runs at the same priority as board initialization,
and as such is not guaranteed to run in time.
Reducing RBOX initialization priority guarantees that RBOX is
initialized by the time board init function needs to access it.
BRANCH=none
BUG=chrome-os-partner:49959
TEST=the AP_WP_L signal now reports the expected value:
> gpioget AP_WP_L
1 AP_WP_L
>
Change-Id: I9c29451a08fc47d3409031bda1a936de243c0c70
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358169
Tested-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Since we are targeting a 45W solution, set max power to 45W.
BRANCH=none
BUG=chrome-os-partner:54519
TEST=Plug in Zinger and make sure 20V/2.25A is used instead of 20V/3A
Change-Id: Ie57a1df39f0cc642fe3644535aa1b5aa92f1ff35
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/358320
Reviewed-by: Rong Chang <rongchang@chromium.org>
In some rare instances the learn bit gets inadvertently set in the
charger which disables charging. Disable it in charger_set_mode unless
its been set intentionally.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=none
BUG=chrome-os-partner:51196
BUG=chrome-os-partner:54484
TEST=manual,
on Chell w/ charger attached and charging
- force learn on manually, see charging stop
i2cxfer w16 4 0x12 0x3c 0x1000
- wait a second, see charging restored
- check learn has been disabled
i2cxfer r16 4 0x12 0x3
0x0000
- set learn on explicitly
ectool chargecontrol off
- see charging remain disabled
- check learn has been enabled
i2cxfer r16 4 0x12 0x3
0x1000
ectool chargecontrol normal
Change-Id: I26f1e855dcad1aa41530d06555a9be7956fdf435
Reviewed-on: https://chromium-review.googlesource.com/353530
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This patch replaces a long standing stub. When the EC asserts this
signal, the CR50 must reset.
But this signal could be driven by CR50 itself as well, and in that
case the signal's assertion should not be causing the CR50 reset.
Ideally it should be possible to tell if the pin is configured as
output and ignore its assertion in that case. But there is no API for
checking the pin configuration settings at this time. An API function
is added to check if the AP Flash is being programmed, the GPIO
configuration access API is left for future enhancements.
BRANCH=none
BUG=chrome-os-partner:52366, chrome-os-partner:54982
TEST=issue 'reboot' command from the bash command line.
- verify on the cr50 console that it reboots along with the rest of
the device
- observe that reading of the NVRam spaces is still fully
functional, and Kevin can boot all the way up to the login
screen.
- try flashing AP firmware through CR50, verify that it succeed.
Change-Id: Ie4506238dc8b158b32121719a2db7fd232fd7d6c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/357967
Reviewed-by: Shawn N <shawnn@chromium.org>
In NPCX5m5g/NPCX5m6g, PM channel 1 can support both
PC87570-Compatible and enhcnced mode. In next generation of chip,
only enhanced mode will be supported. Set the enhanced mode as
default in the firmware to support all gereration of chips.
BUG=chrome-os-partner:34346
TEST=make buildall -j; verify on Wheatley
BRANCH=none
Change-Id: Ide9e17a1fe8a0d2bfdc33efe2336a10702660679
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/357752
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Currently, it is assumed the host will sooner or later retrieve the
events from the sensor ring: It is only used by Android and the sensor
HAL is enabling the ring buffer at boot.
But if nobody processes the ring, and the ring is almost full, the EC will
generate interrupt for every new events.
This can happen with ARC, where events generated for ChromeOS
will be in the ring but nobody will process them until Android is
started.
Add a command to allow sending ring MKBP events. It will be used when
the IIO ring buffer is enabled / disabled.
It also can be used for preventing raising interrupt when the device is
about to go to sleep.
BRANCH=ryu,cyan
BUG=b:25425420,b:27849483
TEST=Check with fiforead that no events are queued when IIO ring
buffer is disabled.
Check with ectool and androsensor that interrupt generation stops.
Change-Id: Ibc85eed2e0eae3a9ec07d191e692118bc2fd0dab
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356689
Allow at least 10ms for the 'version' cap to charge in order to have a
voltage on the ADC pin that reflects our voltage divider circuit.
BUG=chrome-os-partner:54768
BRANCH=None
TEST=Manual on kevin. Run 'ver', verify that rev3 board is recognized as
version 3.
Change-Id: I1f3326f4c99a165d77363834d5671aa357a89007
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/357970
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
For certain board configurations, KSI2 will be stuck asserted for all
scan columns if the power button is held. We must be aware of this case
in order to correctly handle recovery mode key combinations.
BUG=chrome-os-partner:54602
BRANCH=None
TEST=Manual on gru. Do three-key salute, verify EC detects recovery mode.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I03d76e1121107484f79520745858388f6cae096c
Reviewed-on: https://chromium-review.googlesource.com/357590
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The fix for SPI bus base address missed the tpm test driver, this patch
fixes the issue.
BRANCH=none
BUG=chrome-os-partner:54720
TEST=tpmtest.py connects over ftdi & tests pass
Change-Id: I5a59a6e089aee5a7c25466e0d183f3647c67343a
Signed-off-by: nagendra modadugu <ngm@google.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356556
The motion sensor drivers used to rely on #defines indicating I2C or
SPI port to tell which to use. However, these days the drivers get
that info passed in via the motion_sensor_t struct. Now this #define
simply decides whether to compile in SPI or I2C wrapper code. We
should eventually make it less confusing, but that's beyond the scope
for now.
BUG=none
BRANCH=none
TEST=reef motion sensor init works now
Change-Id: Ic38c57a6c070af391d2d4e2ec1a68ac90a377688
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356822
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The modexp implementation occasionally produces
a result larger than the modulus, in which case a
single final reduce is required. The software
based implementation already has this check.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tpmtest.py passes
Change-Id: I0a830781e2a109963394d0702cbc2ca6457c410c
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/357010
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This handles the case where we wish to disable the mux.
Without this the "else" case will return EC_ERROR_UNIMPLEMENTED
when we transition to the PD_STATE_SRC_DISCONNECTED state, and
the EC console shows "Error setting mux port(0)."
BUG=none
BRANCH=none
TEST=no longer see "Error setting mux port(0)" on Reef EC console
Change-Id: I97f35775a5c92636ede1b32293b3a4d01e002dc0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/354680
Tested-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Add a test that verifies RSA keygen from a fixed seed and
template from the TCG EK Credential Profile spec.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests under test/tpmtest pass
Change-Id: I2f1cfb8460a0497c93079b89b9ff4e031eaff358
Reviewed-on: https://chromium-review.googlesource.com/356561
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
SHI_OBUF_VALID_OFFSET may wrap on buffer full, leaving us with an
incorrect tally of bytes transmitted. Always assume the worst case, that
SHI_OBUF_VALID_OFFSET is at maximum, when deciding to apply 256B bypass.
BUG=chrome-os-partner:54566
BRANCH=None
TEST=Manual on gru. Verify 'flashrom -p ec -r read.bin' does not produce
CRC errors.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I7c0ccc1b555838854584a3be8ced50057eaea961
Reviewed-on: https://chromium-review.googlesource.com/356771
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shelley Chen <shchen@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
When verifying RW using rwsig, we need to be able to erase the RW
signature to remain in RO. This change excludes the RW signature from
the area protected by system_unsafe_to_overwrite, so flash write can be
used to overwrite the RW signature while still in the RW system image.
BUG=none
BRANCH=lucid
TEST="ectool flashwrite 0x1ff00 corrupt_sig" runs successfully, and on
reboot the EC firmware verification fails.
Change-Id: I7e234664ae564eef30a8b021ea0539b6c0ae898e
Reviewed-on: https://chromium-review.googlesource.com/356810
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
To achieve higher power efficiency, we want the input voltage to be as
low as possible. If the PD source advertise several choices over
PD_MAX_POWER_MW, choose the one with the lowest voltage.
BRANCH=none
BUG=chrome-os-partner:54519
TEST=Plug in Liteon charger and make sure 15V/3A is selected
Change-Id: I6157eb94a1cb45cd537acc79c377db2cff09d922
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/356317
Reviewed-by: Rong Chang <rongchang@chromium.org>
If set_cc() is called, our toggle interrupt may still be active. Since
alert() is called from the pdcmd task and set_cc() is called from the
pd tasks, an unwanted interrupt may fire and override our desired CC
settings.
BUG=chrome-os-partner:54786
BRANCH=None
TEST=Manual on gru. Rapidly attach + detach DP dongle, verify we don't
get stuck in SNK_DISCONNECTED_DEBOUNCE.
Change-Id: Ib60123c45d9a3a78243a3347377fb2190cbdf94b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356513
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Joe Bauman <joe.bauman@fairchildsemi.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Changes were submitted for ec_commands.h but only in the braswell tree.
Merge in ToT for future reference.
BRANCH=none
BUG=chrome-os-partner:50627
TEST=compile.
Change-Id: I74f6ce3c5fd2a628879593a65506d10c44ee574d
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356551
If SHI finds itself in an unexpected state, we may try to print an error
message for each IBF / IBHF interrupt, which is excessively spammy and
may even lead to EC watchdog. Avoid console spam by not duplicating IBF
/ IBHF / IBEOR error prints, if our state doesn't change.
BUG=chrome-os-partner:54502
BRANCH=None
TEST=Manual on gru. Verify only one print is seen when SHI fails due to
missed initialization.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I331c64c24fa3a68d7c17e052240691076d3532cc
Reviewed-on: https://chromium-review.googlesource.com/356239
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The CR50 RO version is identified not just by the git hash, but also
by the fuse settings and keys used for signing. The first four bytes
of the entire RO image's hash are saved in the image header. Adding
these four bytes to the version string reported to the host allows to
uniquely identify both RO and RW firmware versions.
BRANCH=none
BUG=none
TEST=verified that the appropriate string is showing up:
localhost ~ # grep cr50 /sys/firmware/log
Firmware version: RO: 97594095 RW: cr50_v1.1.4803-dcac93a-dirty
localhost ~ #
Change-Id: I30a21fad15d99523b1edfa1baa32d80b44e7d0df
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356735
Reviewed-by: Scott Collyer <scollyer@chromium.org>
If the battery is not yet ready to provide the power or battery is
not present and the charging current is set to 64mA then the charger
voltage regulation is transient. ROHM recommended 512mA of minimum
charging current for this issue, hence changed the minimum charging
current from 64mA to 512mA.
BUG=chrome-os-partner:54821
BRANCH=none
TEST=Manually tested on Amenia.
a. Until the battery is initialized from cut-off mode, charging
voltage doesn't drop below battery voltage max.
b. With 15W charger (5V, 3A) without the battery, charger voltage
is regulated to battery voltage max.
Change-Id: I44172d4e9152b699976137bf070d618097c8cef7
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/356570
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
