Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9049
TEST=manual
sysjump ro
version
sysjump a
version
sysjump b
version
All should return versions for RO, RW-A, RW-B.
Change-Id: Ie189d2d777a4743460e2edec65750e563bc69354
This patch adds explicit handling of open-drain outputs
and adds Hi-Z for high-impedence state (floating) outputs.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
TEST=compile tested
Change-Id: I1a0c2e8366f6a82cd9cd7e83e57122944f2bdc2d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=power system on; should still boot
Change-Id: I2e6c1f1cb4ffabf37d3113faca900da17c1353e9
(Derived from Vincent's original I2C slave CL)
This configures I2C port 2 as a slave device at 8-bit address 0xEC
(7-bit address is 0x76).
This CL only implements single-byte read and write transactions.
A master-initiated write will set EC mode, and a master-initiated read
will send bytes back depending on the mode.
BUG=chromium-os:28925
TEST=build on daisy and discovery; run on daisy
Change-Id: I1e9f28feb99e25bb7656b6e9ae8643d3ae285a28
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that we have a SPI driver, we must init it when we start up.
BUG=chromium-os:28925
TEST=build on daisy and discovery; run on daisy
Change-Id: I84b458d3ebc3fed9368dce8e06d040dbfc4e9125
Signed-off-by: Simon Glass <sjg@chromium.org>
This adds support for setting up the SPI pins and driver, as well as the
required SPI work task.
BUG=chromium-os:28925
TEST=build on daisy and discovery; run on daisy
Change-Id: Ie73560356fc8e4fcec0773c4692ecd6a7ba7affa
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7832
TEST=manual
1. Power on system
2. From ec console: kblight 100
3. Use a magnet next to the left shift key to trigger the lid switch. Screen and keyboard should go dark.
4. Remove the magnet and they should light up again.
Change-Id: I298ea94930976153d8dcd102316b010ee28cd747
When we are in interrupt context and doing a task_set_event,
if we are interrupted by a timer interrupt firing, we might end
resetting the runnable bit added by the expiration of a timer (when
finishing the interrupted read-modify-write to tasks_ready).
So we need to have an atomic access there.
We don't need to atomic primitives (and the associated overhead) on other
tasks_ready accesses because there are always done at the highest
priority.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8721
TEST=from Linux, run "ectool lightbar test" several times and see that
the keyboard task no longer ends up stuck with a timer event set and no
runnable bit.
Change-Id: Ied45ee33cb6aba4549626d35d694f1c259f2400c
Add a SPI driver which can receive and process commands, and provide
responses using the message interface.
BUG=chromium-os:28925
TEST=build on daisy and discovery; run on daisy
Change-Id: I286da803b85640525607de6c4d41f0629f7006dc
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8981
TEST=manual
Turn system on
Hold power button for 5 sec
Let go
System should stay off
Change-Id: I4660108972795d631b7c33926df58513ee09e1c7
This inner loop was used to detect single changes for use by the
i8042 keyboard interface code used on LM4. Since we only send
the entire matrix state, we do not need this particular bit of
code.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
TEST=tested on daisy
Change-Id: I4d36a7db77d20ace29f534c9e12f7ed9558c953d
Tweak some of the original keyboard_scan delays for better responsiveness
now that we have real hardware to test on.
BUG=chromium-os:28925
TEST=build on daisy and discovery; run on daisy
Change-Id: Ib2f5418c624bb0b7a0009d01ab669299607c1a59
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
I need to clean up the console commands and provide the same functionality
via ectool, but this is a good starting point.
BUG=chrome-os-partner:7839
TEST=manual
Power up the CPU. The lights should blink.
Change-Id: Ic05a171d2b647551f1cfc7d6b2fd101088cac137
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
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>
