It's imported from test/hooks.c and adjusted to CTS.
BUG=chromium:624520
BRANCH=none
TEST=make buildall. Test passed on stm32l476-geval and nucleo-f072rb.
Change-Id: I70673f2c0f8316a2b1fd9472eeb7db350fdc2d84
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360631
Reviewed-by: Chris Chen <twothreecc@google.com>
It's imported from test/mutex.c and adjusted to CTS.
BUG=chromium:624520
BRANCH=none
TEST=Test passed on stm32l476-geval and nucleo-f072rb. make -j buildall
Change-Id: I8cab0541ecbb1daa26b4d728fbd3e45e903ee512
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360600
Reviewed-by: Chris Chen <twothreecc@google.com>
Test functions are listed in cts.testlist and shared by th.c and dut.c.
This way, we can gurantee the two files are in sync. Also, cts.testlist
is used to count the number of tests automatically.
This allows us to use a for loop to execute each test.
BUG=none
BRANCH=none
TEST=build buildall
Change-Id: I0c811405134fad04f5c6914b1ac38835e212cbd2
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359619
Contains code for all the gpio tests so far. Code in
cts_task for th and dut is for testing purposes and
test result reporting will be updated in the next
patch.
BRANCH=None
BUG=None
TEST=Manual
- Connect handshake and gpio test lines between th and dut
- Build tests
- run 'cat /dev/ttyACM0' in one terminal
- run 'cat /def/ttyACM1' in another
- Flash boards
- All test results should print either passed or unknown
Change-Id: I7142fb87a6ce0a20c571cde608fbbe60e35898ea
Reviewed-on: https://chromium-review.googlesource.com/359935
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
A new option is being added to the set of command line options, '-s',
once it is specified, the utility tries to update the CR50 using
/dev/tpm0.
BRANCH=none
BUG=chrome-os-partner:54992
TEST=emerge-gru ec-utils, copy /build/kevin/usr/sbin/usb_updater and
~/trunk/src/platform/ec/build/cr50/ec.bin to the DUT, try running
the update command on the DUT:
$ <path to>/usb_updater -s <path to>/ec.bin
observe in the end of the log:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvv
-------
update complete
bye
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
restart the cr50 and verify that it is running the new image.
Change-Id: Idb755328f911f3065f01df420488c7a1b4a32500
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358967
Reviewed-by: Andrey Pronin <apronin@chromium.org>
RDD is working reliably and defaulting to CCD makes it difficult to
display port functionality.
BUG=chrome-os-partner:52281
BRANCH=none
TEST=manual
run 'reboot ap-off' on the EC. Plug in a unreworked suzyq and
verify 'lsusb | grep 5014' doesn't show any devices
run 'powerbtn' on the EC and verify 'lsusb | grep 5014' now
shows a device.
Check that this works on gru, kevin, and reef.
Change-Id: If4a9fc2f8f874e602c28f8e397c9bf8ea6184b59
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360914
Reviewed-by: Bill Richardson <wfrichar@google.com>
Having DIO A4, A8, and A14 connected to the spi master output pads
prevents reef from booting. We need to tristate those pins when spi ccd
is not in use.
This change disconnects those pins from the spi peripheral when spi is
disabled and reconnects them when spi is enabled.
BUG=chrome-os-partner:53582
BRANCH=none
TEST=manual
use 'pinmux' to verify DIOA4, DIOA8, and DIOA14 are set have
GPIO 7, 8, and 9 as their output sources when not using the usb
spi interface.
Check the usb spi interface still works.
Enable usb spi then disable ccd and check that the pins are
connected back to the non-peripheral gpios.
Verify the AP on kevin and reef can be flashed using servo.
Verify the AP boots successfully on both.
Change-Id: I85d70422a30da445076432d2bfc81960aeba8578
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/357883
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When the debug cable is disconnected the a USB suspend interrupt is
triggered and puts the chip to sleep before rdd can detect a change on
the cc lines and disconnect from CCD. This prevents the DEBUG_STATE_MAP
from being reset to detect the debug connect and is left detecting the
disconnect. Since the debug accessory is already disconnected the RDD
interrupt will wake up the chip right after it goes to sleep.
The UTMI and PIN wake source still cause the chip to wake up before the
RDD interrupt, so disable those to test this change.
BUG=chrome-os-partner:54796
BRANCH=none
TEST=Disable wake pin and utmi wake sources. Put cr50 to sleep. Attach a
reworked suzy q and make sure cr50 wakes up. Detach it and check that it
goes back to sleep. Do that a couple of times. Check CCD is still
enabled when the debug accessory is detected and disabled on
disconnect.
Change-Id: I58a012895bc874dcdd512aa84de9a917469f3139
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360234
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Added code to get the VBUS level by reading the charger registers.
BUG=chrome-os-partner:55117
BRANCH=none
TEST=Manually tested on Amenia, VBUS_VAL (5Ch) & VCC_VAL (5Eh)
registers are updated with the correct VBUS value on the
respective ports.
Change-Id: I3b019b2d87e4c347f12596df387a2a659092ae25
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/359416
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>
When the uart rx signal is not externally pulled high by the EC or AP,
the low rx signal triggers thousands of uart interrupts. At
initialization Cr50 does not know the state of those devices. If the
uart is initialized when the device is off these interrupts may prevent
Cr50 from booting on certain boards. This change does not enable the
uart until the device state is know. When the device state monitoring
detects that the AP or EC is powered on it will enable uart 1
or 2 and when it detects that it is powered off then the uart will be
disabled.
BUG=none
BRANCH=none
TEST=UART_CTRL registers are set to 0 for uart 1 and 2, and are changed
to 3 when the device state is on.
Change-Id: I43e847c6abb8507a86de92a5c226a79f3add7f97
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360026
Reviewed-by: Scott Collyer <scollyer@chromium.org>
The bit IRQ11B of register HIIRQC is meaningful only when PM Channel 1
is in PC87570-Compatible. In previous commit, we deprecate use of
PC87570 mode but set the bit unintentionally. This will not cause any
bug but may make confused when reading the code.
Modified sources:
1. lpc.c: CLear IRQ11B in register HIIRQC.
BUG=chrome-os-partner:34346
TEST=make buildall -j; verify on Wheatley
BRANCH=none
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Change-Id: I594222c29557add847a1f689859fdf558d64fdd3
Reviewed-on: https://chromium-review.googlesource.com/358536
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Amit Maoz <Amit.Maoz@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Currently we have EEnoise(Decap Switching Noise) from LCD PWM
Kevin use LCD Backlight Driver IC and PWM Frequency from EC
Current 10kHz frequency can make switching Noise easily.
BUG=chrome-os-partner:55169
BRANCH=None
TEST=measuring noise reduced, verifying there was no influence
to LCD/digitizer/tsp
Change-Id: I1e65e56a19177dadba0110de5678669288a8555a
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/360003
Reviewed-by: Shawn N <shawnn@chromium.org>
We need to (at least) build CTS for all boards & suites supported by CTS.
This will prevent our investment from accidentally being broken.
BUG=chromium:627252
BRANCH=none
TEST=make buildall builds CTS suites
Change-Id: Ib7bceaafd5e27ce9285b9d1bf35339bf6b04ba72
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359947
When cr50 is not trying to do ccd, we dont need to monitor the devices.
Disable device state detection interrupts and the AP and EC UARTs.
BUG=none
BRANCH=none
TEST=gru and kevin monitor devices correctly when ccd is enabled, and
dont monitor anything when it is disabled.
Change-Id: Ic3f5974320486ff6dd0147c490a1c294cc2f6a76
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356770
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
sync() involves 2 gpios on each board, each labeled
GPIO_HANDSHAKE_OUTPUT and GPIO_HANDSHAKE_INPUT on
their respective boards. They both start low,
then the th wiggles his line up and down, waiting
for the dut to mimic it.
BRANCH=None
BUG=None
TEST=manual
- Connect handshake lines to appropriate
pins on each board (pins found
in board's gpio.inc)
- Build tests
- Flash boards
- run 'cat /dev/ttyACM0' in one terminal
- run 'cat /dev/ttyACM1' in another
- They should each have printed
'successful sync'
Change-Id: I61233bca9605ba89c3628c2a65ca9013c56365ea
Reviewed-on: https://chromium-review.googlesource.com/359355
Commit-Ready: Chris Chen <twothreecc@google.com>
Tested-by: Chris Chen <twothreecc@google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
The code reporting the RW version is in fact using a fixed location in
flash memory. This is fine for a single RW image (i.e. the vast
majority of the EC boards), but is wrong for CR50 which can run one of
two RW images.
The fix is to account for this by providing the currently running
image type to the function retrieving the image version.
Note that RW and RW_B versions end up at different offsets into the
image, it is impossible to retrieve the version of the not currently
running RW by just changing the offset into the flash memory.
BRANCH=none
BUG=chrome-os-partner:55145
TEST=as follows:
- build, update and start a cr50
- check the vers. command output, observe that it is running from
RW and reports the correct RW version string:
> vers
Chip: g cr50 B1 0_0
Board: 0
RO:
RW: cr50_v1.1.4856-df14f6a
Build: cr50_v1.1.4856-df14f6a 2016-07-11 11:52:44 vbendeb@eskimo.mtv.corp.google.com
>
- build the image again, update and restart the cr50
- check the vers. command output, observe that it is running from
RW_B and reports the correct RW version string:
> vers
Chip: g cr50 B1 0_0
Board: 0
RO:
RW_B: cr50_v1.1.4856-df14f6a
Build: cr50_v1.1.4856-df14f6a 2016-07-11 11:52:44 vbendeb@eskimo.mtv.corp.google.com
>
- erase the RW space base
flasherase 0x4000 0x20000
- run the vers command again. It was failing before this fix, now
it still shows the proper RW_B version.
Change-Id: Iab8bc0e61b50dd65a9e18a0369b18bdd9cc05421
Reviewed-on: https://chromium-review.googlesource.com/359580
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Soft reset will not power down Cr50, so it wont assert EC_RST_L when it
reboots. This is a short term solution that fixes the cold vs warm reset
issue, but it does not fix the problem with all of all of the other Cr50
functions disappearing during warm reset. We will need to just reset the
TPM functionality on Cr50 to fix those issues.
BUG=chrome-os-partner:52366
BRANCH=none
TEST=Check asserting SYS_RST_L resets Cr50 and the AP and doesn't reset
the EC. Disable the Cr50 reset when SYS_RST_L is asserted, and verify
that the AP doesn't boot after the first reboot. Enable soft reset when
SYS_RST_L is asserted and verify the AP can successfully reboot many
times.
Change-Id: I7c0d0712ee6df59cfadd3975caf3503d44f3eff2
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359342
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The AP no longer uses PHY0 to to interact with Cr50. Cr50 only uses PHY1
so dont switch the PHY when disabling CCD just release the usb.
BUG=none
BRANCH=none
TEST=After running 'ccd disable' the command 'usb' still returns PHY B,
but 'lsusb | grep 5014' on the host doesn't show any devices. When CCD
is enabled 'lsusb | grep 5014' shows a device on the host.
Change-Id: Icec0acc7a0d00f7eb56c6feef3ff4cf5a3f99735
Reviewed-on: https://chromium-review.googlesource.com/359931
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
cts/pingpong/cts.tasklist contains tasks run only for pingpong.
BUG=chromium:624520
BRANCH=none
TEST=Ran the followings:
make buildall
make CTS_MODULE=gpio BOARD=nucleo-f072rb
make CTS_MODULE=pingpong BOARD=nucleo-f072rb
make CTS_MODULE=gpio BOARD=stm32l476g-eval
make CTS_MODULE=pingpong BOARD=stm32l476g-eval
Change-Id: I5180c60aed5f7d41363c502df539ea9b25ff5d13
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359446
Reviewed-by: Chris Chen <twothreecc@google.com>
cts.tasklist contains tasks run only for CTS. These tasks are added to the
tasks registered in ec.tasklist with higher priority. This design allows
board directories to be free from CTS stuff.
cts.tasklist can be placed in each suite directory (cts/suite/cts.tasklist).
If a suite does not define its own cts.tasklist, the common list is used
(i.e. cts/cts.tasklist).
BUG=chromium:624520
BRANCH=none
TEST=Ran the followings:
make buildall
make CTS_MODULE=gpio BOARD=nucleo-f072rb
make CTS_MODULE=gpio BOARD=stm32l476g-eval
Change-Id: Ibb242297ee10a397a8fcb6ff73d8cbc560daa885
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359445
Reviewed-by: Chris Chen <twothreecc@google.com>
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>
