Latest GCC gives compiler error:
util/iteflash.c: In function verify_flash:
util/iteflash.c:927:9: error: res may be used uninitialized in
this function [-Werror=maybe-uninitialized]
return res;
^
BUG=None
TEST=`make buildall -j` outside chroot
BRANCH=None
Change-Id: I184d8673020552797fd54bb98ee582a63debbf16
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/330873
Reviewed-by: Shawn N <shawnn@chromium.org>
In order to support 256 KB ram version of npcx ec, we add CHIP_VARIANT
variant to distinguish which verson ec is.
In config_chip.h, we use CHIP_VARIANT to specify the size and start address
of program memory. Ecst tool also needs a chip parameter to make sure
the address range checking of entry pointer won't fail.
Modified sources:
1. config_chip.h: Use CHIP_VARIANT to specify the different hardware spec
of npcx ec.
2. config_flash_layout.h: Replace constant value with
CONFIG_PROGRAM_MEMORY_SIZE for CONFIG_RO_SIZE.
3. build.mk: Add -chip parameter for ecst tool to check entry address.
4. npcx_evb\build.mk: Add CHIP_VARIANT definition (npcx5m5g).
5. npcx_evb_arm\build.mk: Add CHIP_VARIANT definition (npcx5m5g).
6. wheatley\build.mk: Add CHIP_VARIANT definition (npcx5m5g).
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I1b8b9b9d0a59bdc01210f498ac67e4a342743b47
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/330072
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 1.8V IO support for some GPIOs and I2C pins. We use a array
(gpio_lvol_table) to confine which IO pins can switch to 1.8V. Before
setting it to support low voltage level, FW should set IO pin's type to
open-drain and disable internal pulling up or down.
We also add examples in gpio.inc of npcx_evb and npcx_evb_arm to indicate
how to set GPIO & I2C pins to 1.8V if user adds CONFIG_TEST_1P8V definition
in board.h.
In i2c.c driver, this version removes the internal pull-up feature of
i2c ports since the driving force is too weak. (about 30K ohm)
Modified sources:
1. gpio.c: Add 1.8V IO support for some GPIOs and I2C pins.
2. i2c.c: Remove internal pull-ups feature for i2c pins and move 1.8V
support to gpio.c.
3. register.h: Modified NPCX_LV_GPIO_CTL register & bits definitions.
4. npcx_evb\gpio.inc: Add examples of 1.8V IO.
5. npcx_evb_arm\gpio.inc: Add examples of 1.8V IO.
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I73a840ae321820212e50d609dab17576117a7d64
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/330037
Reviewed-by: Shawn N <shawnn@chromium.org>
The base accelerometer on oak rev5 needs to be rotated 180 degrees
along the z-axis to match the standard reference frame.
BUG=chrome-os-partner:50312
BRANCH=none
TEST=manually rotate my oak rev5 and verify that `ectool motionsense`
reports correct accelerometer readings
Change-Id: I05a377b5f0827e2aad47d388dc3264d451580989
Signed-off-by: Ricky Liang <jcliang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/330484
Reviewed-by: Rong Chang <rongchang@chromium.org>
led_color_names[] should have EC_LED_COLOR_COUNT numbers of data.
A missing data cause strcasecmp() compare argv[] with NULL in
find_led_color_by_name(), that results in Bundle Image test error
BUG=chrome-os-partner:50612
BRANCH=lars
TEST=`make -j buildall`, `ectool led power blue=255` with homemade ectool.
Signed-off-by: Ryan Zhang <Ryan.Zhang@quantatw.com>
Change-Id: I2132775f9d4a074517f9a98b81919dd77bc86102
Reviewed-on: https://chromium-review.googlesource.com/330075
Commit-Ready: David Wu <david_wu@quantatw.com>
Tested-by: Ryan Zhang <Ryan.Zhang@quantatw.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The default target hardware is rev5. This is a maintainess change for
old and deprecated HW.
BRANCH=none
BUG=chrome-os-partner:49114
BUG=chrome-os-partner:50720
TEST=manual
for N=1,5 do
make BOARD=oak clean && make BOARD=oak EXTRA_CFLAGS="-DBOARD_REV=$N" -j
Signed-off-by: Rong chang <rongchang@chromium.org>
Change-Id: Ibb4ebf9fab429964ace7c3e548598f0fb08e7dea
Reviewed-on: https://chromium-review.googlesource.com/330065
Commit-Ready: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org>
Flash writes must have starting offsets and byte lengths that are
multiples of 4 bytes. This requirement is already covered. One
additional requirement is that a batch write not cross a flash
block boundary. Added a check in flash_physical_write() to check
if this boundary would be crossed and if so to reduce the write
size so that it ends at the block boundary.
BUG=chrome-os-partner:44745
BRANCH=none
TEST=manual
Used the TPM NVMem section and executed flash writes/reads using
a console command utility that I created to test NVMem accesses.
Note that the console output only exists in the console command
related functions.
This test has the offset 12 bytes from the block boundary and
64 bytes long. The counting pattern shows that the write fills the
last 12 bytes, then moves to the next block as expected.
> nvmem wr 0xff4 0x40 3
nvmem wr: o = ff4, s = 64|0x40
start = 0xff4, end = 0x1034
block 0: block_offset = 0x40800
Call Erase(0x80800, 0x800)
block 1: block_offset = 0x41000
Call Erase(0x81000, 0x800)
Nvmem: writing 64 bytes, start = 0x80ff4
> nvmem rd 0xfe0 0x80
nvmem rd: o = fe0, s = 128|0x80
0x80fe0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x80ff0: ff ff ff ff 00 01 02 03 04 05 06 07 08 09 0a 0b
0x81000: 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b
0x81010: 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b
0x81020: 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b
0x81030: 3c 3d 3e 3f ff ff ff ff ff ff ff ff ff ff ff ff
Also tested the case where a write should end exactly at
the block boundary.
> nvmem wr 0xff0 16 3
nvmem wr: o = ff0, s = 16|0x10
start = 0xff0, end = 0x1000
block 0: block_offset = 0x40800
Call Erase(0x80800, 0x800)
Nvmem: writing 16 bytes, start = 0x80ff0
>
> nvmem rd 0xfe0 0x80
nvmem rd: o = fe0, s = 128|0x80
0x80fe0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x80ff0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0x81000: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0x81010: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
Change-Id: Icbe66d3f79d84ed29ecc6207537ea0bf42781f3c
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/330175
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
A single erase host command may erase an arbitrarily large region of
storage, which may lead to our watchdog firing.
BUG=chrome-os-partner:50587
BRANCH=glados
TEST=Manual on glados, flash RW EC / PD FW while plugging + unplugging
zinger. Verify that watchdog doesn't fire.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I90dc85306aec43326c11c794861f68c6e12686e4
Reviewed-on: https://chromium-review.googlesource.com/329987
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This function should not be part of the public GPIO API. It is only
available and used in the STM32 implementation. This moves the
prototype to a chip specific gpio.h that is used within the STM32 chip
directoy.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Manually verify GPIO functionality on discovery board
Change-Id: If9c97f8038b26815318652ca62c1132c95519fa2
Reviewed-on: https://chromium-review.googlesource.com/329968
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously a bogus rx_count value from the USB hardware could have
caused a buffer overflow while copying from the packet ram to the DMA
bounce buffer. I'm not sure if it is possible to cause the hardware
to generate a bogus rx_count, I doubt it, but this is now nicely
paranoid
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Test SPI bridge functionality on discover board
Change-Id: I080ba1c1f05c2b0a86a4c6eb89e8c1387827466e
Reviewed-on: https://chromium-review.googlesource.com/329849
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Nick Sanders <nsanders@google.com>
The Filesystem Hierarchy Standard version 3.0* specifies that /run
should be used for runtime variables such as locks.
The rationale for switching to use /run instead of /var/run was
because /var might not be available at early boot. Since /run is
implemented as a tmpfs and doesn't require /var to be mounted first
it can be made available earlier.
*http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
BUG=chromium:591366
BRANCH=none
TEST=none
Change-Id: Ic0b5ff336c1c258db8891c0a17c836497d9793c5
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/330123
Reviewed-by: Shawn N <shawnn@chromium.org>
These commands, like other users of GPIOs should be able to use the
public GPIO API, and thus do not need to be coupled directly to the
GPIO common code.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Manually verified console commands on discovery board
Change-Id: I6e38b9d103590d4f7c72813a33437067716a858c
Reviewed-on: https://chromium-review.googlesource.com/329992
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This change enables lid angle update that turns off keyboard scan in
tablet mode.
BRANCH=none
BUG=chrome-os-partner:49114
TEST=make BOARD=oak runtests
make BOARD=oak -j && make BOARD=oak_pd -j
load on oak and boot to vt2 console.
flip lid to disable range, type keyboard and check.
Signed-off-by: Rong Chang <rongchang@chromium.org>
Change-Id: Ibd2f0d6ae33a95380c9fc52a7568166a04c119e9
Reviewed-on: https://chromium-review.googlesource.com/328884
Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org>
Previously the keyboard row and column pins could not use the GPIO
alternate function mechanism because their DEVALT bits were inverted
with respect to all of the others, making it impossible to correctly
configure them. With the refactor of the GPIO driver we can now add
the keyboard DEVALT entries to the gpio_alt_table, and use the
ALTERNATE macro and associated APIs to control the keyboard pin states.
The Wheatley RO firmware image is still 320 bytes smaller than before
the GPIO refactor.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Ran on Wheatley, manually verified keyboard functionality
Change-Id: Id04bc010834b5d95050b03ace6b0e1c5690757bf
Reviewed-on: https://chromium-review.googlesource.com/329762
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Body 5678901234567890123456789012345678901234567890123456789012345678901
Previously the GPIO driver used quite redundant encodings for its WUI
and DEVALT mapping tables. This refactor compresses those tables
significantly, while adding the ability to represent an inverted DEVALT
bit. The resulting RO firmware image for Wheatley is 384 bytes smaller.
This commit also corrects the interpretation of the func parameter to
gpio_set_alternate_function. Any non-negative func should be
interpreted as a request to switch a pin to an alternate mode.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Ran on Wheatley, manually verified basic functionality
Change-Id: I3a56a4b56d13a70a30c388e7e2c77dd7acd3838a
Reviewed-on: https://chromium-review.googlesource.com/329761
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
PI3USB9281 may not assert the interrupt line if device is detached
and reading the interrupt register simultaneously. And it is not
necessary to check the interrupt status when vbus change event
happens. To prevent losing the detach interrupt during vbus change
event happens, only check the interrupt status only if receiving
the USB_CHG_EVENT_INTR event.
BUG=chrome-os-partner:48797
BRANCH=none
TEST=Plug/Unplug PD charger 20 times, UI should not display
"Low power charger" warning message each time during the PD charger
is unplugged.
Change-Id: I51fe68732ece882029f1503294c2122cfbb00c34
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/328897
Reviewed-by: Shawn N <shawnn@chromium.org>
Some systems, such as Android, do not support SysV semaphore locks.
This implements an alternative file lock mechanism using flock().
flock() was chosen because it's pretty straight forward. It's known to
be broken when using NFS, but I doubt we'll ever store our lock on an
NFS volume.
CQ-DEPEND=CL:327407,CL:325609
BUG=chrome-os-partner:49527
BRANCH=none
TEST=tested on Smaug by running mosys and ectool while reading
firmware ROM with flashrom, all three utilities eventually
ran successfully.
Change-Id: Ic73fe0281fbc1dfaae1bb03e5683774a0c04ae5b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329430
Reviewed-by: Shawn N <shawnn@chromium.org>
1. Muxer of USB C1 port changes to Parade PS8740.
2. Add control of DP switch TS3USB3000RSER, using for switch DP to port 0/1
(same as rev2).
3. LED control logic is same as rev2.
4. Updates GPIO setting for rev5 pinouts.
BUG=chrome-os-partner:49375
BRANCH=none
TEST=build -j buildall tests
Change-Id: Ifc45ac30be8d46caa1cdb032ccce7569e5a14b99
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/321024
Commit-Ready: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
refer to commit d341615383,
adds the base accelerometer as well as the gyroscope to the list of
motion sensors on the board, connect with SPI bus. They are currently
wrapped behind an ifdef for HAS_TASK_MOTIONSENSE and OAK_REV5.
BUG=chrome-os-partner:50312
BRANCH=none
TEST=Build Oak EC with driver enabled and verify that we can calcuate
a valid lid angle.
TEST=Verify that signs of accelerometer conform to those shown in the
Chrome/Android/HTML5 doc/spec. See description in accelerometer_types.h
TEST=Verify that signs of gyroscope conform to those shown in the
"Sysfs interface to EC accelerometers" document.
TEST=make buildall tests
Change-Id: I4d900bc6bd7329db6ea53660fae86e5e2bbe9028
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/319295
Commit-Ready: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
refer to commit 574c806571,
adds the lid accelerometer to the list of motion sensors on the rev5.
Since commit bc404c94b4,
math_util.c is no longer to include "math.h" header file.
BUG=chrome-os-partner:50312
BRANCH=none
TEST=Build Oak EC with driver enabled and verify that valid
accelerometer data is read, and that range, resolution, and odr can all
be modified.
TEST=Verified that signs of accelerometer data conform to those shown in
the doc.
TEST=make buildall tests
Change-Id: I8df1b2331a1fbea82015b97985541e2ebc393d10
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/319332
Commit-Ready: Rong Chang <rongchang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
This adds a couple of helper functions for working within Android:
- in_android(): Crude test that uses getenv() to see if an Android-
specific environment variable is defined.
- android_tmpdir_path(): Android doesn't have the usual locations for
temporary file storage such as /tmp or even /var/run/locks. And to
make matters worse, there isn't even a standard location for
temporary files so it must be determined at run time.
This will be used in a follow-up patch.
BUG=chrome-os-partner:49527
BRANCH=none
TEST=tested on smaug
Change-Id: Ifb5fb4067fffb7c8cb2d4350ca4a223e884d3aa5
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329299
Reviewed-by: Shawn N <shawnn@chromium.org>
Except for the console UART TX and the SPI slave MISO, this CL
configures all the formerly output GPIOs as inputs. The Cr50
firmware at this point doesn't actually DO anything useful with
the GPIOs that would normally be outputs on the Kevin board (we
don't assert SYS_RESET, or EC_FLASH_SELECT, for example), and the
board *should* be designed so that no important signals like
those just float.
By using this configuration, we're trying to limit the potential
harm done by unexpected schematic changes. Once the system boots,
we should be able to use the SPI bus to update Cr50 to add more
features, such as testing Cr50 GPIOs individually.
BUG=chrome-os-partner:49952
BRANCH=none
TEST=make buildall, run on Cr50 board
Change-Id: I1f0a164e2cd3e4f632b862e33dba69f0dc944322
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329557
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The new signer command line option should be used by some boards, not
all of them. Add it for cr50 for now.
BRANCH=none
BUG=none
TEST=verified that --cros is added to the command line when cr50 blobs
are signed, and that the signed blob boots fine on b1.
Change-Id: Ibc38cc6233b57838129ae7d554921c1bae0e6b8c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329595
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This change just copies files shared between two repositories which
have changed since the last sync up. This time it is as of @CL85098.
BRANCH=none
BUG=none
TEST=the signed image boots fine on the b1 board.
Change-Id: I7a1d1b344119e6f6729a38bbea04da75f2d3371c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329407
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds two debugging commands to decode the PINMUX and GPIO
routings without having to look at a bunch of hex values.
They can easily be removed to save space, but they're kind of
handy for now.
BUG=chrome-os-partner:49952
BRANCH=none
TEST=make buildall, and test on Cr50
Run the "pinmux" and "gpiocfg" commands. Verify that the output
reflects the desired configs found in gpio.inc
I get this:
> pinmux
40060000: DIOM0 5 IN GPIO0_GPIO4
40060008: DIOM1 6 IN GPIO0_GPIO5
40060010: DIOM2 0 IN PU
40060028: DIOA0 70 UART0_TX
40060030: DIOA1 0 IN
40060038: DIOA2 0 IN
40060040: DIOA3 2 IN GPIO0_GPIO1
40060050: DIOA5 0 IN
40060058: DIOA6 0 IN
40060060: DIOA7 3 IN GPIO0_GPIO2
40060088: DIOA12 0 IN
400600a0: DIOB0 33 IN
400600a8: DIOB1 34 IN
400600b0: DIOB2 0 IN
400600b8: DIOB3 74 UART1_TX
400600c0: DIOB4 0 IN PD
400600c8: DIOB5 78 UART2_TX
400600d0: DIOB6 0 IN
400600d8: DIOB7 1 IN GPIO0_GPIO0
400600f8: GPIO0_GPIO0 3 DIOB7
400600fc: GPIO0_GPIO1 22 DIOA3
40060100: GPIO0_GPIO2 18 DIOA7
40060104: GPIO0_GPIO3 20 DIOA5
40060108: GPIO0_GPIO4 30 DIOM0
4006010c: GPIO0_GPIO5 29 DIOM1
40060110: GPIO0_GPIO6 28 DIOM2
40060208: UART0_RX 24 DIOA1
40060218: UART1_RX 8 DIOB2
40060228: UART2_RX 4 DIOB6
> gpiocfg
GPIO0_GPIO0: read 0 drive 1
GPIO0_GPIO1: read 0 drive 0
GPIO0_GPIO2: read 0 drive 0
GPIO0_GPIO4: read 0 drive 0
GPIO0_GPIO5: read 0 drive 0
>
Note that we skip GPIO0_GPIO3 and GPIO0_GPIO6 because they're
neither outputs nor interrupts. All the GPIOs can do that.
Change-Id: I93b881bfd93dc100096bbd005a6c31b2669eda2f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329527
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
BUG=chrome-os-partner:49952
BRANCH=none
TEST=make buildall, run on Cr50 board
It's kind of hard to test GPIOs that aren't attached to anything,
but I've examined all the PINMUX controls and ARM GPIO settings,
and I *think* they're right.
Change-Id: I66ae94118f73c41193c6ca5c0af9708f6cc8a3e8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329526
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Removing a declaration for a function that no longer exists, and
deleting some extra PINMUX config that is also (and correctly)
being done in the module that uses it (chip/g/sps.c).
BUG=none
BRANCH=none
TEST=make buildall and test image on Cr50
Change-Id: Ie381862cfcd3c043ebf78171d18a51593b3677f7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329525
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Use built-in USB periperal to detect BC1.2 suppliers and update the
charge manager.
BUG=chrome-os-partner:48658
BRANCH=None
TEST=manual for lucid. Use a samus as the supplier, and insert the
charger into Lucid. Verify that it identifies it as SDP. Use a wall
charger and verify that Lucid identifies it as DCP.
Change-Id: I7842e9f75874f727837df5bfc28690662caf821c
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329236
Reviewed-by: Shawn N <shawnn@chromium.org>
Future glados-derived boards are adding a WP_L GPIO input. Add support
for this input, which will apply only if CONFIG_SYSTEM_UNLOCKED is not
defined. Undefining CONFIG_SYSTEM_UNLOCKED will result in unpredictable
WP GPIO behavior for all boards that currently exist, so it should only
be undef'd right before MP FW is released.
BUG=chrome-os-partner:50518, chrome-os-partner:50519
BRANCH=glados
TEST=Verify 'ectool gpioget A13 --dev=1' always indicates a GPIO state
'1' on an old chell_pd without WP_L input.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Id50a13cce54bc2013d83613ce5599ffde6a6837b
Reviewed-on: https://chromium-review.googlesource.com/329370
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
With commit e9883124ff, a GPIO_INT macro was added. That change
also required that all instances of GPIO_INT in a board's
gpio.inc file come before any GPIO macros, or the interrupt
handler wouldn't work properly.
This CL just adds a warning comment about requirement to all
gpio.inc files.
BUG=chromium:471331
BRANCH=none
TEST=make buildall, test image on Cr50
This is a change to comments only. There is no new behavior to
verify, although I did run try out one new image just to be sure
nothing stupid happened.
Change-Id: I83f7819929a53bce3a8bae04d15b3ee3bda11738
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329334
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Let's just get rid of the old GPIOs before configuring the new
ones.
BUG=chrome-os-partner:49952
BRANCH=none
TEST=make buildall, test on Cr50 B1 boards
None of the FPGA buttons or LEDs are present on the B1 board, so
there's no visisble difference between talking to non-existent
components and NOT talking to non-existent components.
Change-Id: I839982ac06a983879f0240635442b51f794daffb
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329267
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Just a bit of refactoring. This cleans up some macro definitions
and error checking, and removes a duplicate list of GPIO signal
names.
BUG=none
BRANCH=none
TEST=make buildall, test on Cr50
No functional changes, so nothing new to test.
Change-Id: Iecacc5a0b7da02aa9d0b94f171c70f0b73e8edd5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329303
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
port80 activity usually comes in bursts during AP boot and then goes
quiet. For power savings, turn off the port80 interrupt and timer after
no activity is seen for 30 seconds.
BUG=chrome-os-partner:50175
TEST=Boot chell, verify port80 prints are seen. Verify timer +
interrupts are disabled ~30 seconds later. Power down, power up, and
verify port80 prints are seen once again.
BRANCH=glados
Change-Id: Iea091d73aa0c6e9cfb36240d68e31a20425cea45
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327256
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Icarus W Sparry <icarus.w.sparry@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This cleans up a great deal of flakiness that we've seen on the
USB for a long time. I was misinterpreting and/or misimplementing
some of the documentation. This seems to make all the difference.
BUG=chrome-os-partner:50370
BRANCH=none
CQ-DEPEND=CL:328979,CL:*249229
TEST=make buildall, and test on Cr50
Before this CL, the USB connection would only work on USB2.0
buses, connected directly to my workstation. With this CL, it
works on USB2.0, USB3.0, through hubs, etc. Yay!
Change-Id: Icfa1910bf34f73332e2f8fc4f0d6789541549493
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329262
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Now that the pinmux information isn't packed into the GPIO alternate
function table, we can expand it a bit and give the fields nice names,
making the code easier to read and removing a number of bit packing
macros defined in registers.h.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verified on cr50 hardware
CQ-DEPEND=CL:*249229
Change-Id: I9984bc37faf69b1ba9f1ba66a49596dd22e3b601
Reviewed-on: https://chromium-review.googlesource.com/328979
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This commits adds support for the auto interrogation mode. The auto
mode continually scans across the console output looking for a string
that is printed upon reboot. The string is:
Console is enabled; type HELP for help
When the EC-3PO interactive console sees this string, it knows that the
current EC image is not enhanced and therefore no longer needs to
perform an interrogation after every command. Additionally, the
enhanced EC images will print a slightly different string than from
above so that the console can detect enhanced EC images as well.
By default, the console interpreter will now start up in the 'auto' mode
instead of the 'always' mode that it used to. This removes the 300ms
delay after each console command.
BUG=chromium:588611
BRANCH=None
TEST=./util/ec3po/run_tests.sh
TEST=cros lint --debug util/ec3po/console.py
TEST=cros lint --debug util/ec3po/console_unittest.py
Change-Id: Iec7ebd437ee363c2fc01b8b1adade485a0bff7a9
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/329054
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Found out that the string that is printed from console_init() doesn't
show up on the EC console for jerry. It seems that perhaps due to the
priority of the console task and the numerous prints during boot, that
print never makes it to the TX buffer. Currently, there's about 7200
bytes available in the shared memory region, which indicates that
there's still a lot of free space. Therefore, increase the UART TX
buffer size.
BUG=None
BRANCH=None
TEST=Flash jerry and verify that 'console is enabled' string shows up on
the EC console.
TEST=make -j buildall tests
Change-Id: Id0603a3b758b5c600d0b59f27040ead2ce48bbaf
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/329180
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For enhanced EC images, change the string telling the user that the
console is enabled. This is such that EC-3PO can distinguish between
non-enhanced ECs and enhanced ECs during EC boot.
BUG=chromium:588611
BRANCH=None
TEST=Build for chell with CONFIG_EXPERIMENTAL_CONSOLE and verify that
the new string is printed.
TEST=Repeat above test but without the config option and verify that the
old string is printed.
TEST=make -j buildall tests
Change-Id: Ic8ed0a028ecb701b999fa6c6a376704f375dbc62
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/329161
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When forcing a sink role (eg. on transition from S3->S5), make sure
we're not sourcing VBUS. Otherwise, if a power source is attached, we
will fail to charge from it, due to the inability to sink and source
VBUS simultaneously.
BUG=chrome-os-partner:49544 chrome-os-partner:50343
TEST=Boot chell, attach USB-C peripheral, then power down chell. Remove
USB-C peripheral, attach zinger, and verify PD negotiation + charging
succeeds.
BRANCH=glados
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5fb9b0eb26e61daa93a167d6a3e9aaf4e4eeed39
Reviewed-on: https://chromium-review.googlesource.com/327727
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Divagar Mohandass <divagar.mohandass@intel.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Debug messages generated by the firmware upgrade extension command
show flash offsets (the values used when calling flash API), but the
user is more interested in absolute addresses, as they are reported by
some other debug printouts.
Change fw_upgrade_command_handler() debug output to report absolute
flash addresses.
BRANCH=none
BUG=chrome-os-partner:37754
TEST=ran upgrade test, observed proper addresses reported:
fw_upgrade_command_handler: programming at address 0x84000
fw_upgrade_command_handler: programming at address 0x84400
...
Change-Id: I8a6cd6020e5ddcbf41f5931cf7632fc598d4745e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/328810
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The api _cpri__AESDecryptCFB is expected to
support in-place decryption, which the previous
implementation did not support (i.e. part of
the input was was written to prior to being read).
Switch to CTR mode to ECB mode in order to support
in-place decrypt.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=corresponding TPM2 test suite command passes
Change-Id: I8a096bdab7a1ca130a07d992c9fce3fc19016e17
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/328761
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
It was observed that the b1 test board falls into bootstrap mode once
the reset button is pressed after a firmware upgrade.
The reason turns out to be that the wrong lead was considered to be
the reset pin, the BIO4, responsible for bootstrapping, was used
instead of the reset pin.
Come to think of it, there is no need to reset the device each time
the FTDI SPI interface is initialized. Let's just drive the bootsrtap
pin to the correct level and not generate the reset pulse at all.
BRANCH=none
BUG=chrome-os-partner:37754
TEST=pressing the reset button on the b1 board now properly restarts
the device.
Change-Id: I123dad8043807c8ff01e12254f9efc2f0d1aaa13
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/328811
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Now that the cr50 no longer uses this array to store its pinmux config
we can move it out of the header file, removing it from the public
interface for GPIO code. This allows us to start modifying this struct
more easily.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I9b4ca8b678b102bb9b63ccffe23bf2dc87aeb44a
Reviewed-on: https://chromium-review.googlesource.com/328824
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Previously the g chip and cr50 board abused the ALTERNATE macro to
encode the pinmux configuration. This switches them over to using a
PINMUX macro that is designed for this purpose.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I5c1f70b7aa92d87cc105e672aa66aee7f267c9a2
Reviewed-on: https://chromium-review.googlesource.com/328823
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
