Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8971
TEST=manual
waitms 1500
(see watchdog trace)
waitms 1500
(should see watchdog trace again)
waitms 3000
(should see trace, then system should reboot)
Change-Id: Ieb5009d7a7bc9e1ed795e58efb0cb44a1eeb2706
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8967
TEST=manual
While ssh'd into the device:
1) Create a test image:
Extracting to: /tmp/ecup
132+1 records in
132+1 records out
136132 bytes (136 kB) copied, 0.000550122 s, 247 MB/s
2) Force the EC into its RO image:
done.
3) Erase the A and B images, then reprogram them:
Erasing 163840 bytes at offset 81920...
done.
Reading 136132 bytes from /home/chronos/user/ecb.bin...
Writing to offset 81920...
done.
4) Repeat step 3 about 10 times while monitoring the EC debug console.
Commands should complete successfully all the time. (Note that during
the flashwrite, there's a ton of debug output; what you should NOT see
is something like this:
WATCHDOG PC=00002104 / LR=0000597f / pSP=200013a0
Change-Id: I2f1f05eb19abcd6e19c6364f6d4ac785cca6a4c6
This situation occurs during USB download - the EC resets itself which
causes USB programming to generally fail.
Is this the correct fix?
BUG=none
TEST=build on daisy and discovery; run on daisy
$ cros_bundle_firmware -b daisy -w usb
See that it now succeeds
Change-Id: I293e85d08d3c488d5b6bebe3379deb949f211986
Signed-off-by: Simon Glass <sjg@chromium.org>
We want the Chrome EC message to be the first one produced after
start-up, so remove the message for the keyboard:
[kbscan keyboard_scan_init()] initializing keyboard...
BUG=none
TEST=build on daisy and discovery; run on daisy
Change-Id: I264450036145406e2d3bc39171ba672984f7dc99
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a function which is called when keyboard scan data is ready,
and make it do the right thing.
BUG=chromium-os:28925
TEST=build on daisy and discovery; run on daisy
Signed-off-by: Simon Glass <sjg@chromium.org>
Change-Id: I0089a7ff78ba035ba6648220ae2e03a958d444d8
Provide the required plumbing for the stm32 keyboard scan code so that
the message layer will pick up keyboard scans.
The design is as follows:
- When a change in keyboard state is detected, the keyboard matrix
scanning code will call the board-specific board_keyboard_scan_ready()
function to interrupt the AP.
- The AP will initiate a CMDC_KEY_STATE transaction over SPI or I2C
- The SPI or I2C driver will call message_process_cmd() to process the
command
- This in turn will call keyboard_get_scan() to get the latest scan data
For SPI:
- The AP will initiate an 20-byte (or longer) SPI transaction
- The EC will see the command, and provide the keyboard state in response,
with the response being part of the same transaction
For I2C:
- The AP will initiate a 1-byte write to set the EC mode.
- The AP will then initiate an 18-byte read, and the EC will send the
message including keyboard state
BUG=chromium-os:28925
TEST=build on daisy and discovery; run on daisy
Change-Id: I905ef9d567e43d85fb851052f67586eff58e1167
Signed-off-by: Simon Glass <sjg@chromium.org>
Whatever means is used to talk to the AP there is no justifcation for
putting message processing directly in drivers. Create a suitable
header file to define the interface, and provide a processing function
which can provide responses to incoming messages.
BUG=chromium-os:28925
TEST=build on daisy and discovery; run on daisy
Change-Id: If09ea3e30d42d8c5f226dc4421d4895adc54f937
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to use this for drivers, so start it up on boot.
BUG=chromium-os:28925
TEST=build on daisy and discovery; run on daisy
Change-Id: Ie69fb9d6df75150dd3903fe37a9b72c0a663f045
Signed-off-by: Simon Glass <sjg@chromium.org>
Add some basic functions to start DMA operations for transmit and
receive.
BUG=chromium-os:28925
TEST=build on daisy and discovery; run on daisy
Change-Id: Ifceeed2af80cf5f00e1ce1a49b1139a76585b0bf
Signed-off-by: Simon Glass <sjg@chromium.org>
If we include a header file within board/daisy/board.h then the code in the
top-level Makefile which transforms the configuration into make variables
cannot locate the header file. We get a warning:
$ make BOARD=daisy clean
board/daisy/board.h:11:20: fatal error: common.h: No such file or directory
compilation terminated.
To fix this, pass the include directories to the preprocessor also.
BUG=none
TEST=manual:
add common.h header to board/daisy/board.h; make BOARD=daisy clean;
see that no warning is issued
Change-Id: I04b718e014490a3f6008b7d03afce4d79a38eb56
Signed-off-by: Simon Glass <sjg@chromium.org>
Fix some mistakes in previous commit. Modified some comments and moved
guard value initialization to a more readable place.
Signed-off-by: Vic Yang <victoryang@google.com>
BUG=chrome-os-partner:8069
TEST=Compile with detection enabled. Cause a task to overflow and see
device halted. Hook gdb and see it stopped at the assertion.
Change-Id: I608ee9aec3fda8c3945e1874d4bbb2c4ae1fc6dd
Now Link has 256kB parts, we can restore the third partition and use 80kB partitions.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=on Link proto-1, try to use RO/A/B images (sysjump B, then boot).
Change-Id: I9b7e4cae1504e86a62643db4d035cc9f3de0af52
(cherry picked from commit cefaf59328e4b91308d0347cc1f55861e93db480)
Use guard value to detect stack overflow
Signed-off-by: Vic Yang <victoryang@google.com>
BUG=chrome-os-partner:8069
TEST=Compile with detection enabled. Cause a task to overflow and see
device halted. Hook gdb and see it stopped at the assertion.
Change-Id: I3417cca8edf4e1291ccb7848bd564b631a9ce463
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8662
TEST=manual
Plug in a fully-discharged system. Run 'charger' and 'battery'
commands to see that it's requesting a really small current. See that
we're now feeding it a larger current.
Change-Id: I4312e2976b4f39d093deb73f665f8fbaba72d7c8
Add nopll command to turn off the PLL, reducing the system clock to 16Mhz.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8798
TEST=manual
boot system
press power button to boot x86
temps // should print all temperatures
timerinfo
timerinfo
timerinfo // convince yourself this is counting up at about 1MHz
nopll // this drops the system clock to 16MHz
temps // should still print all temperatures
timerinfo
timerinfo
timerinfo // should still be counting up at about 1MHz
Change-Id: Ie29ceb17af348148bffadf63d60c1b731f4c3f6d
- The max IO buffer size in ACPI is 255/0xFF bytes.
- The ACPI ASL code in coreboot is pre-processed to handle
constant #defines, but the IASL compiler cannot handle any
actual C code so add an __ACPI__ guard.
BUG=chrome-os-partner:7734
TEST=include this header in coreboot and compile successfully
Change-Id: Ife61935cec1a39f072625c2788f70487c3559060
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Add a host command returning chip information. The interface is in common/
while the implementations are in chip-specific code (note: added simple
value for stm).
BUG=chrome-os-partner:8567
TEST=on board
% ectool chipinfo
Chip info:
vendor: xx
name: yyyy
revision: zzzzz
Change-Id: I5030a03a6fcfbfc080d5acd8efb763fde7eefde5
This has been useful for me to be able to test lid behavior remotely
since it is not available via servo.
This also has a minor change to send a task message after sending
the power button pulse so the state machine behaves properly.
BUG=none
TEST=Execute 'lidclose' and 'lidopen' commands via ec uart and
see the appropriate events set and wake behavior when the system
is off. With a (not yet published) coreboot I am able to handle
lid close events to enter suspend.
Change-Id: Iec1c68121d42b66305ba5dfd20e81453538a97e2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
The SCI pin is not connected to a GPIO and it uses a different
method to trigger a pulse via LPC0SCI.
The ACPI specification requires SCI for 3 conditions:
- SCI event pending
- Input Buffer Empty
- Output Buffer Full
The buffer full/empty SCIs are used to nudge the kernel driver
along so it does not have to poll for a potential slow EC to
be ready. This only really makes sense for the kernel channel
so they are only generated there.
BUG=chrome-os-partner:8277
TEST=using (unreleased) coreboot BIOS to test that the kernel
can receive SCI events and the ACPI method is successfully run.
Change-Id: I6b3717fcad6569bda4482d9aaa37d45b4cf36335
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
This data is used to populate the _BIF/_BIX packages in ACPI
but it currently needs an EC command to retrieve that isn't
easy to query in ACPI since it isn't using standard EC RAM.
1) Export these additional fields in init() state:
- Design Capacity of Full
- Design Voltage
- Last Full Charge Capacity
- Cycle Count
- Manufacturer String
- Model String
- Serial Number String
2) Fix an issue where battery current was not reported when
the battery was charging.
3) Remove the command interface so there is no duplication.
BUG=chrome-os-partner:7734
TEST=using (not yet published) coreboot to read battery status
via ACPI and verify that battery removal/insertion events
are properly handled.
Change-Id: If337aad3255e5b1a0f85168838f1dd86a32bbeb3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7461
TEST=manual
make BOARD={bds,link,daisy}
make tests
flash link system and make sure it boots
Change-Id: I1241a1895c083e387e38ddab01ac346ca4474eb9
Factor out fan speed control for easier adjusting fan speed stepping.
Also increase number of fan speed steps from 2 to 5.
Signed-off-by: Vic Yang <victoryang@google.com>
BUG=chrome-os-partner:8466
TEST=Manual test.
Change-Id: I0ff601c0a4f2ed2a4867bdc6e550eb2827404754
On Power+ESC -> ignore the power button being down until it's
released; system stays powered down.
On Power+ESC+Refresh -> send a power button pulse to the PCH. Ignore
the power button until after both the pulse has finished and the power
button is released.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8723
TEST=manual
Reboot system.
Press power.
System powers on normally.
Hold down ESC, tap power very quickly.
System resets and stays off.
Hold down ESC and power for several seconds.
System resets and stays off.
Hold down ESC and refresh and tap power very quickly.
System powers on; EC console indicates it's in RO.
Hold down ESC and refresh and press power for ~100ms
System powers on; EC console indicates it's in RO.
Hold down ESC and refresh and press power for several seconds.
System powers on; EC console indicates it's in RO.
Hold down ESC and refresh and press power for at least 10 seconds.
System powers on; EC console indicates it's in RO.
Change-Id: Idf9619da54ab299b0c65e6d68abb5e35e2ce9c79
BUG=chrome-os-partner:8728
TEST=manual
I don't have a system that has both an EC and a lightsaber, so I can't be
certain this works, but I *think* it will.
I do have a Link proto 0.5. With that, you can say
ectool lightbar test
and the EC console says it's poking at the lightbar, but of course there's
nothing there. If there was, it *should* flash in pretty colors. I have a
lightsaber attached to a BDS, and from the EC console running "lightsaber
test" does make it blink.
Change-Id: Ib6021ad8e53959de52b12efda376254071e5fb4b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8573
TEST=manual
1) Hold down refresh key and type 'reboot' from EC console. Console
should not show "[KB recovery key pressed at init!]"
2) Press power+esc+refresh. Console SHOULD show the message.
3) Press power+esc. Console should NOT show the message.
Change-Id: I642a7667b81c8d90c9490b23ce0f3519364427e4
This reverts commit dfe22b2b1e.
We seem to have solved I2C block issue. Reverting the workaround LPC
command and ectool command.
Signed-off-by: Vic Yang <victoryang@google.com>
BUG=chrome-os-partner:8239
TEST=Compilation succeed. Manually tested temperature polling still
works.
Change-Id: I0acb567a138282479c7cc07cbfa723c439d04cd7
De-assert the lightbar reset GPIO to be able to access its registers.
According to the HW guys, it will consume less power in standby than in
reset due the pull-up on the reset line.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
BUG=None
TEST=manual
On Link proto-1, type "lightbar test" in the EC console and see it blink.
On BDS, just build it. Nothing actually changes for BDS.
Change-Id: I9ec612c80f48d41ccf779f0962fc047966d4b7ba
Servo2 can set the write protect signal
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8580
TEST=manual
From chroot:
dut-control fw_wp_en:on
dut-control mfg_mode:on
Then from EC console:
gpioget WRITE_PROTECTn
0 WRITE_PROTECTn
From chroot:
dut-control fw_wp_en:on
dut-control mfg_mode:off
Then from EC console:
gpioget WRITE_PROTECTn
1* WRITE_PROTECTn
Change-Id: I9976cd6f114c8dae75434adf99d9409107b6ada0
In addition, it's not necessary for VGFX_CORE to be enabled for the
system to be in S0; just CPU_CORE is sufficient.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8725
TEST=boot system via power button; should boot normally
Change-Id: Iea32837b698845355f7fa6bd2eaca9fd95f6726b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8724
TEST=if timestamps show up in the debug output, it works
Change-Id: I5264a3a40a07a824cc15b39a7bd81f2db02a3c13
