The main CPU might need to know the particular hardware version the
system is running on. This information is available to the EC, this
change adds a mechanism for the main CPU to request this information.
The board version is defined as a flat 16 bit number.
BUG=chrome-os-partner:8722
TEST=manual
. this change was tested in concert with the appropriate coreboot
modification, the proto1 board returns board version of 0. The
code was modified manually to return a one off version - and the
coreboot indeed observed board version of 1
Change-Id: If434d33f43783b18cb202ea15819bd5804694b8e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Sometimes when requesting a sysjump from the AP, the I2C bus gets
wedged. Ensure we restore it in a proper state during the driver
initialization.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865
TEST=On Snow, use flashrom to program the EC.
Change-Id: I6279afba2bdeed4473ace42220a0342c4addaf1d
The size of the RW partition is size of RW-A + size of RW-B.
When B is de-activated, we need to nullify its size to get the correct
total size.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865
TEST=On Snow, flashrom -p internal:bus=lpc -i EC_RW -w ec.bin
Change-Id: Id015af512f072efce5fcafc5a630845c5d9600bb
This adds "ectool vboot", which works like so:
# ./ectool vboot
0x06 image=A fake_dev=1
# ./ectool vboot 0
# ./ectool vboot
0x02 image=A fake_dev=0
# ./ectool vboot ff
# ./ectool vboot
0x06 image=A fake_dev=1
You can set or unset the fake dev-switch, and see which firmware image the
EC is running from.
BUG=chrome-os-partner:8313
TEST=manual
Boot the host, use crossystem to see the devsw_boot state. Change it with
the ectool command, reboot, see that it's changed.
Change-Id: Iaac40267338c6a07bc47b80e925e829bf1e1ae0c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
The Snow board has currently the second RW partition de-activated due to
flash space constraints, we don't want to send false information to the
tools.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865
TEST=on Snow, flashrom -p internal:bus=lpc -i EC_RW -w ec.bin
Change-Id: I6da60028aa69aeb476d5c2d98df5a03ece961891
The warm boot condition was badly detected since we are tweaking the
GPIO enables in board.c. The timer enable (TIM2) is a more reliable
condition.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865
TEST=on Snow, boot Linux then type "sysjump A" in the EC console and see
that AP & Linux are still alive.
Change-Id: If375aa320c140360d313241b5d9219ffa8bcecd7
This makes timestamps much easier to read.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9866
TEST=timerinfo, taskinfo, battery commands have fixed-point numbers,
and timestamps printed in the log look right.
Change-Id: If91c83f725984c8e04bfb7cdcff316d9c3bfe24c
This simplifies the re-flashing for stm32 based platforms.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865
TEST=On Daisy, flashrom -p internal:bus=lpc -w ec.bin
Change-Id: I66860383c34110b1edf852929c244a2b682bc105
On platform where the flash base address is non null (e.g. stm32), we need to
take it into account.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=On Daisy, type "sysjump A" and "version" into the EC console
and observe that the commands succeed.
Change-Id: I95596d45f6970259d19d7063f6794fae0c400ab7
(Touchscreen was already disabled in S5)
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9736
TEST=from console, 'gpioget touchscreen_resetn' in these cases:
1) system is off -> 0
2) system is on with lid open -> 1
3) system is on with lid closed -> 1
4) system is suspended with lid open -> 1
5) system is suspended with lid closed -> 1
6) system is shut back down -> 0
7) suspend system with lid open, THEN close lid -> 0
Change-Id: I5fc80b72ea9dcfbf11f5280d79ae805c2ef1b6df
BUG=chrome-os-partner:9850
TEST=manual
Open the lid. The lightbar should turn on.
Change-Id: I14d1316e6b0cac7a7e2f5b08b7d14b6bbdfa5830
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
The VMA of the .data segment is in RAM, but we actually put it into FLASH.
The linker doesn't notice if it runs out of flash, so it creates an invalid
image.
This adds an explicit check to be sure it all fits. It also refactors the
region declarations to be more explicit. For vboot-enabled configurations,
CONFIG_SECTION_* - describes the extent of flash for one entire image
CONFIG_FW_* - the region within the SECTION for the firmware only
CONFIG_VBLOCK_* - the region within the RW SECTIONs for the vblocks
CONFIG_VBOOT_ROOTKEY - the region within the RO SECTION for the root key
Look at chip/lm4/config.h for the best example.
BUG=chrome-os-partner:9839
TEST=manual
Build it, run it.
Change-Id: I3c652e82d58a5328115cc750c80ecba6a3fd99a3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Don't do anything on write protect until we have properly verify the
current implementation to avoid bricking Daisy and Snow boards.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865 chrome-os-partner:9849
TEST=None
Change-Id: I599a2a733b7304dc17286fae6fd7807fd8f6981c
Implementation of the flash driver for the stm32f100 chip used on Snow board.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865
TEST=On Snow board, use "flashwrite/flasherase" commands from EC console
and verify result with "rw" command.
Change-Id: Ie8b8be3d549ff9ec8c3036d5f4a97480daa5e03e
In order to perform testing across all future boards and enable easier
debugging, we need a host command to read temperature sensor name and
sensor type.
BUG=chrome-os-patner:9836
TEST='ectool tempsinfo 0' shows sensor name and its type.
Change-Id: I06d9c6b045902394179c35e2ee8bc8dc551e8e98
'ectool thermalget' should return error if sensor ID or threshold ID is
out of range. This CL fixes a bug that error codes mismatch.
BUG=chrome-os-partner:9840
TEST='ectool thermalget 0 10' gives error.
Change-Id: I74d0c66044cd31743c4fac0a8dc0431db6259e71
When the flash base address is non null (e.g. stm32), it's nice to have
the full ELF image (including the 3 copies) at the right address.
This doesn't change anything to the final .bin image but allow to load
directly the .obj with tools which handle ELF format.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=Flash ec.obj on a Snow board using the ST-Link JTAG over GDB.
Change-Id: I51a6d9c00b359c6204bd51b30ee7a4fec362d88e
Simulation now simulates the physical signal, so uses the power state machine.
Power state machine now doesn't send a spurious press/release event if
the power button signal glitches and returns to its previous state.
Properly handles powering back on when waking from hibernate, if the
lid is open.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9817
TEST=manual:
All of the following should power on the system:
1) at debug console, powerbtn
2) press power button
3) lid open
4) press power+esc+refresh
5) hibernate 10, then press power button
6) hibernate 10, then open lid
These should leave the system off:
1) press power+esc
2) hibernate 10, then let it wake up on its own
Hold down the power button to power on the system, and keep holding it
down; system should shut back down after 8 sec.
Hold down power+esc+refresh, and keep holding it down; system should
boot and NOT shut down after 8 sec.
Change-Id: I2dde951fe67544b6a24c607f0c4ba415ccd2f82f
Ensure we can jump between EC images without powering down the GAIA AP :
- preserve GPIO state
- go back to "power-on" state if needed in GAIA state machine.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865
TEST=On Daisy, boot Linux, then type "sysjump B" and observed we can
still interact with Linux without any AP reboot.
Change-Id: Ia2bd0f65ea348813b120bcc3a3f3bdfa96a9877a
On chips where CONFIG_FLASH_BASE is not 0 (e.g. stm32), the reset vector
address check in system_run_image_copy would fail because we are
comparing an absolute address against a flash offset.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865
TEST=on Daisy, type "sysjump B" in EC console.
Change-Id: Ib79677fb926a37fcf32f4aac013dc36b086f4464
The stm32 needs to flash half a page (ie 128 bytes),
the current communication protocol is limited to a 64-byte payload for
flash write message.
The workaround buffers the first 64 bytes to be able to flash a full
128-byte half page.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865
TEST=on Daisy, run flashrom -p internal:bus=lpc -w ec.bin
Change-Id: I8036e66d2aa456b3409f4f8c74daa3755e7c9a51
This also updates the communication protocol between the EC and the AP in a
non backward compatible way.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:9614
TEST=on Daisy with updated kernel driver, use the keyboard in ChromeOS
Change-Id: I5a50e9a74b9891153a37ea79318c8a66a1b0c5ca
This cleans up I2C init and debug commands across boards.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=on link and bds:
i2cscan
lightbar run
powerbtn (to power on system)
temps (to read i2c temp sensors)
battery (to read battery)
charger (to read charger)
Change-Id: If3fb0cdb8d3178592bf68cbb2e72bc4b7f71dec5
This was used on the hybrid Badger-Lumpy systems for one-off testing.
It wouldn't necessarily work on a bare Badger board, and maintaining
it resulted in frequent build breaks.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=build link, bds, daisy; boot link and bds
Change-Id: Ib64ccad9f38d76832ab57f7254dbf32f3d5e4a5e
And start wiring to x86_power so it can detect AC state changes
(needed to enable/disable turbo).
*YES*, this compiles for BDS/Daisy now...
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9069
TEST=plug/unplug AC power and look for "x86 AC on" / "x86 AC off" in debug log
Change-Id: I8399fab9637d6635a1c615f07448fd45b86bc25f
The phenomenon is that there is a char on-hold in port 0x60 and the kernel
never picks it up. Hence the keyboard cannnot be recognized after resume.
It comes from multiple reasons:
1. The command I8042_CMD_RESET_BAT(0xff) and I8042_CMD_ENABLE(0xf4) didn't
clean the buffer.
2. clean_underlying_buffer() has clean the queue, but forgot to clean the
TOH (TO Host). Add keyboard_clean_buffer() to clean the TOH (To Host).
3. When KB interrupt is just enabled, the IRQ didn't sent if there is
a char queued in buffer already. keyboard_resume_interrupt() solves
this.
4. Not all keyboard reset should reset the buffer. Only the enable/disble
of controller RAM should NOT reset buffer. Other enable/disable
should clean the buffer.
5. i8042 commands (those commands to port 0x64) should NOT return ACK
even the parameter byte(s) goes to port 0x60.
6. Keyboard was disabled by kernel, but key stroke still sent to host
(this needs the BIOS to fix).
Also fix the minor issues:
1. I8042_CMD_RESEND should not return I8042_RET_ACK.
2. I8042_DIS_KB/I8042_ENA_KB should effect the controller RAM content.
3. only send out the scan code when keyboard is enabled.
4. add kblog command for future debug (disabled by default because it
neeeds 1KB of memory).
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
BUG=chrome-os-partner:9525
TEST=tested on link. Start from S0.
1. Run powerd_suspend.
2. Expect system is in S3.
3. Press any key to wake up system.
4. Expect system is up and keyboard is working.
5. repeat for 20+ times.
Change-Id: I1c48822687d7c1f7ef0e8d8bca54bf9b05fd785f
USB ports are disabled after jumping between firmware copies.
We need to record USB port state and restore them after jumping.
BUG=chrome-os-partner:9692
TEST=Manual
Change-Id: Ic5cb83bdd8e49017457f732d317a1b59ced59ead
