This provides us a way to inject interrupts during a test. If a test has
interrupt_generator() defined, it will run in a separate thread. The
generator can then trigger interrupts when it decides to. The current
running task is suspended while emulator is executing ISR.
Also fixes a bug that tasks run without scheduler notifying them during
emulator start-up.
BUG=chrome-os-partner:19235
TEST=Repeatedly run all tests.
BRANCH=None
Change-Id: I0f921c47c0f848a9626da6272d9040e2b7c5ac86
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/55671
KBD_IRQ_NEW_L (added for Rambi 2.0) has a pull-up resistor and should be
open drain.
TEST=None
BUG=chrome-os-partner:24760
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ibf1beff3306c074f9f135b1bee82e299edf2380b
Reviewed-on: https://chromium-review.googlesource.com/181227
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For AP hang detection, the warm reset must be implemented. Since
the cold reset is easy, implement it at the same time.
BUG=chrome-os-partner:23822, chrome-os-partner:24789, chrome-os-partner:24558
BRANCH=nyan
TEST=on nyan rev 3.12
power on/off --> work as usual
power on, then apreset cold --> system is cold reset (off, then on)
power off, then apreset cold --> nothing happens. this is fine.
power on, then apreset warm --> system is warm reset (power trail is kept).
power off, then apreset warm --> nothing happens. this is fine.
power on --> system is back to normal again.
Change-Id: I010793b7a2d309e5d606fbc5877e9e3b07c8c5f3
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181164
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Old code reset some GPIO configurations with af->flags = 0 while
gpio_config_module(). This is bad because it could lead unexpected
behavior on the bus.
New code accepts GPIO_DEFAULT flag so that it doesn't touch the
GPIO setting while configuring alternate functions. This should not
effect other boards unless the GPIO_DEFAULT is set on that board.
BUG=chrome-os-partner:24607
BRANCH=nyan
TEST=run on nyan rev 3.12. No "SPI rx bad data" at boot. UART and i2c good.
Change-Id: Id451cfae21e1d764452429dc5adfe1317ff5b140
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181135
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Follow up Randall's CL 616e709. Note that the nyan warm reset is in
another CL.
BRANCH=nyan
BUG=chrome-os-partner:24558
TEST=See test procedure and results on comment #7 of issue 24558.
Note that the suspend tests cannot be done because my nyan cannot suspend.
Change-Id: I77c59cab177bc2c6fdf9bb8828937fc7b84e6d76
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181177
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This includes:
- Reference to the boot ROM document
- Update flags usage from the document
- Command line argument support
BUG=chrome-os-partner:24107, chrome-os-partner:24188
TEST=Pack and boot
BRANCH=None
Change-Id: I6f79ca94fbc10448e3a1c884a2d52fdf4abf266d
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180180
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Adding two signing keys:
- A dev key used to sign header. We have confirmation from Microchip
that we can check in this key.
- A key to sign payload. This can actually be an arbitrary key as long
as the header and the payload are in sync. Adding a key here just
for convenience.
BUG=chrome-os-partner:24107
TEST=None
BRANCH=None
Change-Id: I5d7418a926047887c01cd0a334a041b18082f66e
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180835
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
By merging make_all.sh to Makefile, parallel make can be made faster.
Previously, if one does 'util/make_all.sh -j32', most of the time is
spent on waiting for linking. Now that we invoke sub-make, linking an
executable doesn't block the next board.
With '-j32', the new 'make buildall' takes about 7 seconds, while the
original 'util/make_all.sh' takes about 27 seconds.
BUG=None
TEST=make buildall -j32
BRANCH=None
Change-Id: I7c2f0d1e928a9b60a8a9070bdcb71b00a3d534cd
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181091
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The igloo board has a different product ID than bds board. Add the new
product ID to ec_uartd.
BUG=chrome-os-partner:24713
TEST=Run ec_uartd with igloo board
BRANCH=None
Change-Id: Idcbb08072661e12ed744a60fb04a55d4f58cf89b
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181082
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We have three copies of the same pseudo random number generator in our
test codes. Let's consolidate them into a single copy in test_util.
BUG=chrome-os-partner:19235
TEST=Pass all tests
BRANCH=None
Change-Id: I7ea0b3476f3cfe6944855f19861e3c86af35807e
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181085
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
ADC driver for MEC1322 with ADC interrupt support.
BUG=chrome-os-partner:24107
TEST=Read single channel
TEST=Read all channels
BRANCH=None
Change-Id: I89d196c7fd78e736575e2c368b65cfb1ec651004
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180832
We have three duplicated ADC read console command, and we are about to
have the fourth. Let's consolidate them to a single implementation in
common/.
Note that we have to add a simple implementation of
adc_read_all_channels() for LM4.
BUG=chrome-os-partner:18343
TEST=Build all boards
TEST=Read single channel
TEST=Read all channels
BRANCH=None
Change-Id: I079c0b33ab6b81a188f309cf99875eb02e9d78a4
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180831
The first time the PMIC sees power (AC or battery) it needs 200ms
(+/-12% oscillator tolerance) for the RTC startup. In addition
there is a startup time of approx. 0.5msec until V2_5 regulator
starts up.
BUG=None
BRANCH=nyan
TEST=verified on rev 3.12 with AC/battery replug * 10.
Power button on/off and 'power on/off' are not effected.
Change-Id: I706829017a53c549601a925cb18d33b21c50eb76
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180677
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This lowers, the WARN, HIGH, and HALT temp thresholds
for x86 boards to below their CONFIG_PECI_TJMAX value.
Also lowers the FAN_MIN and FAN_MAX temps by 5 degrees on
Haswell boards to compensate for lowering TJ_MAX by 5 degrees
in an earlier patch.
BUG=chrome-os-partner:24455
BRANCH=none
TEST=Manual. Run boards without a fan and without any host-side
throttling. Verify that board either reaches a steady state temp
due to throttling or hits SHUTDOWN and turns off before EC reset
is triggered.
Change-Id: I499baa0b4100201525e69752af3465feb592262c
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179886
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
According to the nVidia power engineer, we shall wait for 40ms to see
XPSHOLD asserted after PMIC_PWRON_L is asserted.
Also change the code since it was obscured. Comments was out-of-sync too.
BUG=None
BRANCH=None
TEST=Verified on rev 3.12.
Change-Id: If479d8398f4008f0b029d450b3d28ac98cdf969f
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180502
Reviewed-by: Randall Spangler <rspangler@chromium.org>
AP throttling in the thermal task ends up calling a pretty deep nested
set of calls, and in the worst case can overflow the stack. Bump up
the stack size for the hook task on x86 platforms to compensate.
BUG=chrome-os-partner:24536
BRANCH=peppy/falco
TEST=taskinfo shows hook task increased from 512 to 640 bytes stack
shmem shows at least 4000 bytes free
Change-Id: I63da7c47b993c935d895f91d787844655071da0d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180684
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
So that Tegra wants to drive the PMIC_WARM_RESET_L low it will not be
fighting the EC.
BUG=None
BRANCH=None
TEST=Verified on the board rev 3.12
Change-Id: I5980a3ba096c152a4ccc28ad64e675c53b7cb337
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180520
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This make minor syntactic changes and renames some camel-cased symbols
to keep checkpatch from complaining. The goal is to reduce the
temptation to use 'repo upload --no-verify'.
This is a big furball of find/replace, but no functional changes.
BUG=chromium:322144
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I0269b7dd95836ef9a6e33f88c003ab0f24f842a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180495
We've had uppercase macros (BOARD_FOO) for a week for
PROJECT_
BOARD_
CORE_
CHIP_
CHIP_FAMILY_
CHIP_VARIANT_
and I've just made a pass to fix the last leftover mixed-case usage
from changes that were in flight when I made the initial cleanup. It
is now time to remove the old mixed-case macros (BOARD_foo).
BUG=chromium:322144
BRANCH=none
TEST=Build all boards. Diff build/$(BOARD)/ec.RO.map before and after
this change. Should be no changes - indicating that the same code
was compiled before and after.
Change-Id: Ic5a1e83d31be4b8e9fdbacc3eb10176fd126d84a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180384
All macros are now uppercase.
BUG=chromium:322144
BRANCH=none
TEST=Build all boards. Also, "git grep 'BOARD_[a-z]'" should return no
results (similarly for CHIP, CORE, TEST, CHIP_FAMILY, CHIP_VARIANT.)
Change-Id: I04850e569b3950bb88f9dff107de06dfa49b04fc
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180430
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When a GPIO signal is defined by GPIO_SIGNAL_NOT_IMPLEMENTED, it should
still be able to call various GPIO methods on that GPIO signal. Since
__builtin_clz dies when the value passed in is zero, we need to check
this before calling __builtin_clz.
BUG=chrome-os-partner:24107
TEST='sysjump RW' and the system doesn't crash
BRANCH=None
Change-Id: I5025a2f218d549316fe096c07bd3c7207fe9dbc2
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180183
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This implements i8042 keyboard interface at LPC 0x60/0x64.
BUG=chrome-os-partner:21407
TEST=Enable keyboard and keystroke from host ACPI commands. Short KSO
pins and KSI pins, and read different key codes from host.
BRANCH=None
Change-Id: Ie4e5e236bdeefd7e44974f92fcbafab5e4af2b30
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179940
The spec does not mandate any way to read back the threshold settings
themselves, but when a threshold is crossed the AP needs a way to determine
which sensor(s) are responsible. Each reading of the EC_ACPI_MEM_TEMP_ID
register clears and returns one sensor ID that has crossed one of its
thresholds (in either direction) since the last read. A value of 0xFF means
"no new thresholds have tripped". Changing or enabling the thresholds for
any sensor will clear the unread event count for that sensor.
BUG=chrome-os-partner:23970
BRANCH=none
TEST=manual
On the host, set a couple of thresholds to low values so they trip
immediately (I'm testing on Link):
# dptf() {
[ "$#" -eq "2" ] || return;
iotools io_write8 0x66 0x81
iotools io_write8 0x62 $1
iotools io_write8 0x62 $2
}
#
# dptf 5 0
# dptf 6 10
# dptf 7 3
# dptf 5 2
# dptf 6 10
# dptf 7 2
On the EC console, see that two thresholds have triggered, and that there
are two bits set in the AP seen mask:
[45.755365 DPTF sensor 0, threshold -63 C, index 1, enabled]
[45.768940 DPTF sensor 2, threshold -63 C, index 0, enabled]
[46.169490 DPTF over threshold [0][1]
[46.169820 DPTF over threshold [2][0]
> dptftemp
sensor thresh0 thresh1
0 --- 210* I2C-USB C-Die
1 --- --- I2C-USB C-Object
2 210* --- I2C-PCH D-Die
3 --- --- I2C-PCH D-Object
4 --- --- I2C-Hinge C-Die
5 --- --- I2C-Hinge C-Object
6 --- --- I2C-Charger D-Die
7 --- --- I2C-Charger D-Object
8 --- --- ECInternal
9 --- --- PECI
AP seen mask: 0x00000005
>
Read the EC_ACPI_MEM_TEMP_ID register from the host, to get the two active
sensor IDs (0 and 2), then 0xff when those are seen.
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 5; iotools io_read8 0x62
0x00
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 5; iotools io_read8 0x62
0x02
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 5; iotools io_read8 0x62
0xff
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 5; iotools io_read8 0x62
0xff
#
Change-Id: I8f047a517357617f18ad59d21fa13409bc81821b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180224
Reviewed-by: Randall Spangler <rspangler@chromium.org>
SOC_OVERRIDE now drives a FET, so the signal is inverted (high=active,
not low). EC must drive it push-pull because there is no
pullup/pulldown on the input to the FET.
BUG=chrome-os-partner:24118
BRANCH=none
TEST='gpioget' shows signal is 0 by default, not 1.
Change-Id: I8a86587c7fad8bf5a583cd3976bd6ed3069f2975
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180287
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Proto 2.0 makes these changes:
KBD_IRQ# moves from PM4 to PM3.
EC_PWROK moves from PH2 to PJ1.
Since PM3 and PJ1 are unused on proto 1.5, it's harmless to duplicate
the current functionality on those outputs. We can remove the old
outputs when we deprecate the 1.5 boards.
BUG=chrome-os-partner:24424
BRANCH=none
TEST=boot rambi
Change-Id: Iff77651ef575a8405878fe75f025a0507b02b771
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180081
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This renames constants used in compiler conditionals to uppercase.
BOARD_foo
CHIP_foo
CHIP_FAMILY_foo
CHIP_VARIANT_foo
CORE_foo
Mixed-case constants are still defined by the makefile, but are now no
longer used. I will make one more pass in a week or so to catch any
that are part of someone else's CL, since otherwise this change might
silently merge correctly but result in incorrect compilation. Then I
will remove defining the mixed-case constants.
BUG=chromium:322144
BRANCH=none
TEST=Build all boards. Also, "git grep 'BOARD_[a-z]'" should return no
results (similarly for CHIP, CORE, etc.)
Change-Id: I6418412e9f7ec604a35c2d426d12475dd83e7076
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179206
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This wires 0x62/0x66 to ACPI module and also implements the host event
functions.
BUG=chrome-os-partner:24107
TEST=ACPI memory test and compliment memory test.
TEST=Set SCI mask and host event to trigger SCI. Check SCI pin pulse
low.
TEST=Query host event from ACPI.
BRANCH=None
Change-Id: Ib1f557e995a861c92a603491229ad361e17d2129
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179942
Reviewed-by: Randall Spangler <rspangler@chromium.org>
New boards (rev >= 2.2) are not affected since chipset_force_shutdown()
is called. On old boards the power rails of old boards are not removed
completely. This CL ensures the AP is warm-reset after EC is reset.
BUG=None
BRANCH=nyan
TEST=nVidia verified on old boards.
Change-Id: Ia2c2b243534d8a73b9b4d5320aad4664b1ac8b12
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179521
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The macros must be defined prior to evaluating config.h, since
test_config.h needs them.
Also define an uppercase version of the PROJECT variable, so that we
define TEST_FOO in addition to TEST_foo.
BUG=chromium:322144
BRANCH=none (but might need it if you later cherry-pick something with
an uppercase #ifdef BOARD_FOO
TEST=Build each board with V=1 option: 'make V=1 BOARD=foo all tests'.
Check that the compile command line has both mixed-case and
uppercase defines. Check that per-board tests from test/build.mk
were built (for example, BOARD_PIT should compile kb_scan and
stress, and BOARD_SAMUS should build none of them).
Change-Id: I029552cfdf90a4191cf7a61cdcc65fe75d3ca86c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179902
Reviewed-by: Vic Yang <victoryang@chromium.org>
Any of the EC's temp sensors can have up to two independent thresholds
attached to them. When the temperature crosses the threshold (rising or
falling), a EC_HOST_EVENT_THERMAL_THRESHOLD event is sent to the AP. It's up
to the AP to read the sensor values and figure out why the event was sent.
The thresholds are set and enabled with ACPI writes to three registers in
the EC interface space: EC_ACPI_MEM_TEMP_ID, EC_ACPI_MEM_TEMP_THRESHOLD, and
EC_ACPI_MEM_TEMP_COMMIT. Refer to the comments in ec_commands.h for details
on their use.
ACPI does not provide any means to read the threshold settings (the AP will
just have to remember), but there is an EC console command "dptftemp", that
can be used to examine the current settings.
BUG=chrome-os-partner:23970
BRANCH=none
TEST=manual
On the EC console, check the current threshold settings and temperatures:
> dptftemp
sensor thresh0 thresh1
0 --- --- PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
3 --- --- I2C-Charger-Object
4 --- --- I2C-CPU-Die
5 --- --- I2C-CPU-Object
6 --- --- I2C-Left C-Die
7 --- --- I2C-Left C-Object
8 --- --- I2C-Right C-Die
9 --- --- I2C-Right C-Object
10 --- --- I2C-Right D-Die
11 --- --- I2C-Right D-Object
12 --- --- I2C-Left D-Die
13 --- --- I2C-Left D-Object
>
> temps
PECI : 318 K = 45 C
ECInternal : 306 K = 33 C
I2C-Charger-Die : 309 K = 36 C
I2C-Charger-Object : Not calibrated
I2C-CPU-Die : 309 K = 36 C
I2C-CPU-Object : Not calibrated
I2C-Left C-Die : 306 K = 33 C
I2C-Left C-Object : Not calibrated
I2C-Right C-Die : 307 K = 34 C
I2C-Right C-Object : Not calibrated
I2C-Right D-Die : 307 K = 34 C
I2C-Right D-Object : Not calibrated
I2C-Left D-Die : 306 K = 33 C
I2C-Left D-Object : Not calibrated
>
In this case, the PECI temp is 318 K, so let's set a threshold at 322 K. On
the AP:
[ "$#" -eq "2" ] || return;
iotools io_write8 0x66 0x81
iotools io_write8 0x62 $1
iotools io_write8 0x62 $2
}
Back on the EC console, we see that the threshold has been set:
[768.176648 DPTF sensor 0, threshold 49 C, index 1, enabled]
> dptftemp
sensor thresh0 thresh1
0 --- 322 PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
...
Now do something on the AP to increase the temperature (webgl aquarium,
etc). When the temp goes above 322 K, the EC console reports it and sends a
host event, and the "dptftemp" command indicates the over-temp condition:
[815.367442 DPTF over threshold [0][1]
[815.367878 event set 0x00000100]
[815.368069 sci 0x00000100]
[815.368619 event clear 0x00000100]
> dptftemp
sensor thresh0 thresh1
0 --- 322* PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
...
Log out and wait for the temp to drop. You'll see that trigger a host event
as well:
[854.375713 DPTF under threshold [0][1]
[854.376147 event set 0x00000100]
[[854.376396 event clear 0x00000100]
> dptftemp
sensor thresh0 thresh1
0 --- 322 PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
...
Change-Id: I6bb34c615f37477ccf37163caaa94737baed8dae
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179962
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Since some folks are still using old boards (rev <= 2.0), bring this back
so that they can reset system gracefully.
BUG=None
BRANCH=nyan
TEST=tested on rev 2.0
reboot // EC and AP are rebooted
reset button on board // EC and AP are reset
power off // AP (rev 2.0) is expected NOT powered off.
power on
Change-Id: I35dbc5648b092c892dc06ce5676e1e68c695d477
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179851
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds keyboard scan module driver. Keyboard scan task is not enabled
yet as the LPC layer is not finished and thus i8042 protocol cannot be
enabled.
Since KSO00-KSO03 are used as JTAG, we use KSO04-KSO16 so as to preserve
JTAG functionality. Unfortunately we don't have enough KSO pins, so
trace debug port must be disabled, as done in this CL.
BUG=chrome-os-partner:24107
TEST=Set 'ksstate on'. Short KSI pins and KSO pins, and see
corresponding key shown as pressed.
TEST=Check keypress is detected when console shows 'KB wait'.
BRANCH=None
Change-Id: I366a27453ef95030d251e525313eb4627eb4340f
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179319
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds three new registers to the ACPI->EC interface, which will allow
the AP to set/clear two DPTF thermal threshold points for each temp sensor.
The registers are
EC_ACPI_MEM_TEMP_ID 0x05
EC_ACPI_MEM_TEMP_THRESHOLD 0x06
EC_ACPI_MEM_TEMP_COMMIT 0x07
It doesn't actually do anything yet, but the AP can now write those values.
BUG=chrome-os-partner:23970
BRANCH=none
TEST=manual
On the host:
dptf() {
[ "$#" -eq "2" ] || return;
iotools io_write8 0x66 0x81
iotools io_write8 0x62 $1
iotools io_write8 0x62 $2
}
Now watch the EC console while running on the host:
dptf 5 1
dptf 6 80
dptf 7 2
dptf 7 3
The EC should say
DPTF sensor 1, threshold 7 C, index 0, enabled
DPTF sensor 1, threshold 7 C, index 1, enabled
Change-Id: I71fa57e3ca7c7b5bb8892e63212bf294b44dece5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179778
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:24455
BRANCH=none
TEST=Manual: Verify that CONIFG_PECI_TJMAX set per-board matches
the value queried over the PECI bus with the restricted
"peciprobe" command.
Change-Id: I8e99a23a66f26d6101e01cc751d0a8ca79686321
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179682
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Modified the commond timer module to expire timers as soon as time matches
the deadline instead of only after the deadline is passed.
BRANCH=none
BUG=chrome-os-partner:24490
TEST=On a peppy:
- Run EC tests on host.
- Run all EC tests on the target.
- Keep the system on for days and occasionally verify that system is up and the keyboard is working.
On a spring:
- Run all EC tests on the target.
Change-Id: Ieabfb769cf22ff8b04ca6d0a306312b90ea20ff3
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179460
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On older boards (< Rev2.2), AP_RESET_L was connecting to PMIC reset pin.
However, after 2.2 we use the PMIC_THERM pin instead. Thus, change this
pin to pull high for old boards. T\Otherwise cannot boot up.
BUG=None
BRANCH=nyan
TEST=verified on old board by nvidia.
Change-Id: If4dccaf0bd0671c55b0d703d4d4b16a2b9c4f543
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179377
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is the first step of tegra power state re-factoring. Move the
power button logic to common/power_button.c.
Also, the GPIO KB_PWR_ON_L is renamed to POWER_BUTTON_L.
BUG=None
BRANCH=nyan
TEST=tested on nyan rev 3.12,
reboot: PASS, power on 2
power off / power on: PASS, power on 5
lid close / power off / lid open: PASS, power on 3
button on / off: PASS, ending loop 3, power on 4
power off / button on: PASS, ending loop 4, power on 4
button off / power on: PASS, ending loop 3, power on 5
button off / lid open: PASS, ending loop 3, power on 3
Change-Id: If07806b9c11cdba2b478a9a74d2b75be1d9f7acf
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179451
Sometimes the toolchain tries to put a relocation which is not suitable
to access variables in a read-only section.
The nds32 gcc uses GP-relative signed 17-bit relocation to access
variables stored in .rodata (eg lwi.gp $r0, [ +gp ])
That's wrong since $gp is pointing in the middle of .data and .bss in
the SRAM, while .rodata is sitting in flash.
Since on IT8380, the flash is at 0x00000 and the SRAM is at 0x80000
(512kB further), the linker will fail trying to create the signed 17-bit
relocation (it detect that it needs to truncate it)
Force the compiler to put another relocation as a workaround for now.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:24378
TEST=./util/make_all.sh ; make BOARD=it8380dev
check "version" and "gpioget" on spring, link and it8380dev.
Change-Id: Ife50adf3a26be28f113292f73a1a70e8d74b5d8c
Reviewed-on: https://chromium-review.googlesource.com/176913
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
When we are detecting Apple charger type, we disable TSU6721 interrupt.
This, however, doesn't create a race condition, because any pending
interrupt fires immediately after we re-enable TSU6721 interrupt, and in
turns schedules charger task. As a result, charger task gets waken right
after it finishes its current iteration.
As for overcurrent detection, the current algorithm seems to do a good
enough job.
BUG=chrome-os-partner:23743, chrome-os-partner:23744
TEST=None
BRANCH=None
Change-Id: Ib3a6d562a305020ef5413e2a493e4163a6e70954
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179303
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The "kbpress" command had a few issues if you wanted to reliably use
it for automation. Specifically it was not possible to guarantee how
much time would pass between the press of a key and the release of a
key. Sometimes you might press and release before the key was
officially "there" and sometimes you might get a press and hold of a
key.
Fix this:
1. Make it so that kbpress with no press/release parameter gives a
press and release (and guarantees that the press / release will
actually take effect).
2. Make it so that kbpress guarantees that when it finishes that the
key has actually been pressed or released.
BRANCH=pit
BUG=chrome-os-partner:24249
TEST=kbtype is (https://chromium-review.googlesource.com/178680) reliable
TEST=make -j32 BOARD=bds tests && make BOARD=bds runtests
TEST=Pick Ibe00a796bde7d06416889b621359671a2f68e162 and test.
Change-Id: Ia213ab2e8d8da273e3ac4876d97d5452df88f47d
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178983
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 247650ecc90385417f5dcb2d60bb6ae1e5cfa32f)
Reviewed-on: https://chromium-review.googlesource.com/179325
Reviewed-by: Randall Spangler <rspangler@chromium.org>
It worked on Link because the fan number and the fan channel were both 0.
Samus has two fans, connected to different GPIOs.
In the EC's ACPI interface block, register 0x04 is used to get and set the
fan's target duty cycle, as a percentage value. Writing a 0 to this register
will set the target duty cycle to 0, writing a 100 (0x64) will set it to
100%. Writing any other value will return the fan control to the EC, rather
than driving it manually from the host.
Likewise, reading from this register returns the current fan target duty
cycle, as a percentage. If the EC is controlling the fan automatically, the
returned value will be 0xFF.
BUG=chrome-os-partner:23972
BRANCH=samus
TEST=manual
You can monitor the fan state from the EC console with the "faninfo"
command. From the host side, test this interface from a root shell.
Read fan duty:
iotools io_write8 0x66 0x80
iotools io_write8 0x62 4
iotools io_read8 0x62
Set fan duty to 100%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 100
Set fan duty to 50%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 50
Set fan duty to 0%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 0
Set fan control back to automatic:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 -1
Change-Id: I3a133b0b16e2a5e1ce04b16cb2bf035a04a83daf
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179373
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This fixes a rare problem in which the EC could shutdown due to
a false over-temperature when entering S0 on Haswell architectures.
The fix involves requiring two valid reads of the temperature
sensor (out of the last 4 readings) in order to report it.
BUG=chrome-os-partner:24204
BRANCH=none
TEST=See bug report for a patch that recreates the bug at a
significantly higher rate then it would occur on its own. Using
that patch, I implemented this fix, and made sure that there
were no false over-temperatures reported.
Change-Id: I0454eca1b96fd2fa1833b080026ed8f1caeeddc4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177963
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Currently, per-board defines use mixed case (BOARD_pit). This causes
the presubmit script to complain because that's a style violation.
Using --no-verify to bypass that also allows other style violations to
creep in.
This change adds uppercase variants (BOARD_PIT). It also adds a CORE_
define with '-' changed to '_', since CORE_cortex-m isn't a valid
symbol but CORE_CORTEX_M is (so now we can #ifdef CORE_CORTEX_M).
This does not remove the old mixed-case defines yet, nor does it
find/replace them in the C source files. This is intentional, so this
change can be cherry-picked into branches without needing to change
files in the branch that may have picked up new #ifdefs.
I will rename the constants in the C source files and remove the old
mixed-case defines in a follow-on CL, which should not need to get
picked into existing branches.
BUG=chromium:322144
BRANCH=none (but might need it if you later cherry-pick something with
an uppercase #ifdef BOARD_FOO
TEST=Build each board with V=1 option: 'make V=1 BOARD=foo all tests'.
Check that the compile command line has both mixed-case and
uppercase defines. Check that per-board tests from test/build.mk
were built (for example, BOARD_PIT should compile kb_scan and
stress, and BOARD_SAMUS should build none of them).
Change-Id: I5eb0d1fe57f1c694d7449e5f148e2f13fb290a39
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179205
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
BRANCH=None
TEST=Manual. Run the following console commands:
g781 - verify temps and status look sane.
temps - verify local and remote values for the 781 are listed
g781 settemp 0x05 80 - verify local high alarm set to 80C
g781 setbyte 0x09 0x80 - verify config register is 1000 0000
Change-Id: Ia437647fd052295dfd8901c2ef241ff69c0d950e
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179152
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The samus lightbar uses different LEDs from Link. Adjust the per-color
current limits accordingly. Also swizzle the layout, since LEDs 0/1 and 2/3
are swapped.
BUG=chrome-os-partner:24405
BRANCH=samus
TEST=manual
The colors were ugly and weird. Now they should be pretty and Googley.
Change-Id: I19f317243ff46852628b8b28f2bf6f5e02c6e631
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179160
Reviewed-by: Randall Spangler <rspangler@chromium.org>
