It previously relied on the switch module to enable/disable the
keyboard backlight when the lid changed position. It can do that itself now.
BUG=chrome-os-partner:20743
BRANCH=none
TEST=Boot link in a dark room where the keyboard backlight is on. Briefly run
a magnet over the lid switch and see the keyboard backlight blink off and
then back on.
Change-Id: Iadf02b780a4990db25b6f0b3e1e0692f49c5488d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61194
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Instead of #if defined(BOARD_foo) for all new boards, flip around the
No functional changes, just rearranging code.
BUG=chrome-os-partner:20529
BRANCH=none
TEST=keyboard LED still blinks in suspend on pit
Change-Id: I185d642a5f412c8b4b0d16e62373c6b2bba71b0f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61108
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
STM32L erases flash to 0, not 1, so we need a config value to indicate
that. This speeds up flash erase on STM32L by not re-erasing
already-erased blocks.
BUG=chrome-os-partner:13066
BRANCH=none
TEST=manual - hack flash_physical_erase() to print something just after
flash_is_erased() check.
1. flasherase 0x1f800 0x800
2. flashwrite 0x1fa00 0x100
3. flasherase 0x1f800 0x800 -> only re-erases 0x1fa00
Change-Id: I4d726caf0605e7815b9360bb2d44bdfdd757b4a2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61110
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Flash writes must be done from 32-bit-aligned source buffers. Force
the protcol buffer to be aligned like we do for the lpc interface.
BUG=chrome-os-partner:20571
BRANCH=none
TEST=ectool flashread 0x1f800 0x800 /tmp/foo
ectool flasherase 0x1f800 0x800
ectool flashwrite 0x1f800 /tmp/foo
Change-Id: Icaa3259bcbc36be49345da5e19ad8a0790b73923
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60892
These constants are scattered around the various interface
implementations and should be in one place. This will also clean up
the u-boot side when ec_commands.h is copied there.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=build link, spring, pit; test 'ectool hello'
Change-Id: Ib1425db00ec8220538d8c5c65107ac9548009516
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60810
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
As different boards can use the same EC but use different
pins for the same functionality it is required to properly
abstract out the bank and pin used for the one wire interface.
Provide this ability.
BUG=chrome-os-partner:20372
BRANCH=None
TEST=built for failure and success on link
Change-Id: Ie20f2319d9cd6f5ec63b4178ecebc45a90a51042
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60798
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is necessary to support larger packet sizes for host protocol
ver.3. The host previously didn't have any way to know how big a
packet the EC could accept / respond with (except on LPC, where the
size is determined by the I/O window).
BUG=chrome-os-partner:20257
BRANCH=none
TEST='ectool protoinfo' returns good info; on link,
Protocol info:
protocol versions: 2 3
max request: 256 bytes
max response: 256 bytes
flags: 0x00000000
and on pit,
Protocol info:
protocol versions: 2 3
max request: 544 bytes
max response: 544 bytes
flags: 0x00000001
Change-Id: Ic1e3831d9b4a96ffbf365c0d09b6023472de39a9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60703
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
No functional changes, just cleanup.
BUG=chrome-os-partner:20529
BRANCH=none
TEST='waitms 2000' reboots the system with a watchdog reset cause
Change-Id: I8fcee92476a287e6cb81bf9012f29c87d2aca0ba
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60680
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Previously, code which needed to work on all STM32F platforms needed
to specify them by name (CHIP_VARIANT_stm32f100 ||
CHIP_VARIANT_stm32f10x), and we needed extra symlinks in the
chip/stm32/ directory to allow the build system to find
family-specific files.
Add a CHIP_FAMILY level of abstraction, so that things which are
common across all STM32F platforms don't need to specify every STM32F
variant. Make the chip build look for family-specific filenames
instead of variant-specific filenames (except for config*.h, which is
actually variant specific).
In the few places where things actually are variant-specific, keep
using the existing CHIP_VARIANT defines.
Code refactoring only; no functional changes.
BUG=chrome-os-partner:20567
BRANCH=none
TEST=build all platforms
Change-Id: I1da831aadabf8b8dd9dfde423cac13c9f43eb953
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60247
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Bitfields are now in registers.h where they belong.
BUG=chrome-os-partner:20529
BRANCH=none
TEST='crosec test' from u-boot still works
Change-Id: I726550a32b61111c906c1b10c628c5e47eff74fb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60179
Bitfields are now in registers.h where they belong.
BUG=chrome-os-partner:20529
BRANCH=none
TEST='crosec test' from u-boot still works
Change-Id: If0d79a66a90665c8ea336a006d76ccbc00a927ec
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60139
Reviewed-by: Vic Yang <victoryang@chromium.org>
When TOT link moved to 128KB images, I missed two references to 80KB.
Fix those, so TOT now builds 128KB images for all lm4-based platforms.
BUG=chromium:252584
BRANCH=none (link branch will stay at 80KB images)
TEST=sysjump rw doesn't crash
Change-Id: I5f25cf97ec706374d03ce8ecff6572c1c84242b5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60153
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The maximum packet length for LPC is limited by the I/O space window
size. But that's not the case for SPI or LPC. Rename LPC constant
before adding a SPI constant.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=build link
Change-Id: I088327a11eff18d401c773db953700a36f9c1bb4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59959
Explicitly use enum for dma_channel, instead of ints (since channel is
1-based in the docs and 0-based in the enum). Add enum values for
other channels like USART.
Use volatile structs instead of typecasting through REG32().
Other assorted code cleanup.
Remove DMA2 partial support, since neither STM32F100R8 nor STM32L151x
has hardware support for it and it cluttered the code.
No functional changes.
BUG=chrome-os-partner:20485
BRANCH=none
TEST=from pit root shell, 'ectool version' still works
Change-Id: Ifdd62fb287c608a684ba8fa16934dfcab83ee609
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59949
Power LED PWM now uses the same functions as the hardware timer.
BUG=chrome-os-partner:20414
BRANCH=none
TEST=Suspend system. Power button LED pulses smoothly still.
Change-Id: Ib5ca6655d815462baaf68600ad14c4c0c680a6af
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59838
Automatically drop the clock speed to 1 MHz MSI, then disable HSI and
move to lower-power flash mode. This cuts power from 2400uA to 150uA.
Note that at 1 MHz, we drop received characters on the UART if you
type too fast (or copy/paste, or use arrow keys). Clock speed can be
manually overridden back to 16 MHz via 'clock hsi'.
BUG=chrome-os-partner:20414
BRANCH=none
TEST=with AP on, 'clock' reports 16 MHz.
with AP off, 'clock' reports 1 MHz.
Change-Id: I070c80db0aa5f3a98a7bad6050890bcc2fe008d6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59832
Modules which care about system clock frequency now hook HOOK_FREQ_CHANGE.
- hwtimer
- i2c
- uart (which is now also smart enough to use x8 oversampling instead of
x16 when the system clock is too slow to support x16)
Added 'clock' debug command to set system clock frequency.
STM32F platforms don't change clock frequency; on those platforms,
clock_get_freq() simply returns CPU_CLOCK, so behavior of those
platforms is unchanged.
BUG=chrome-os-partner:20414
BRANCH=none
TEST=from EC console:
- reboot ap-off -> to make sure AP is off during testing
- clock msi2 -> reports 2MHz clock
- battery -> reports battery info
- clock msi1 -> reports 1MHz clock
- battery -> reports battery info
- clock hsi -> reports 16MHz clock
- battery -> reports battery info
- power on -> AP powers on and host commands succeed
Change-Id: Ib8276bf124727e4fb502297ca8b3d6d4b6170241
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59645
Clean up timer initialization code to be more general, so that we can
use timer 9 for the LSB on STM32L. Then use timer 4 for the watchdog
helper.
BUG=chrome-os-partner:18781
BRANCH=none
TEST=From EC console:
timerinfo -> current time still counts up properly
waitms 2000 -> prints watchdog info before rebooting
Change-Id: Ib0ba496b0eadb93756dcd1841857546910baf2a9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59612
Reviewed-by: Simon Glass <sjg@chromium.org>
This fixes the problem where the EC consumes too much power during suspend.
BUG=chrome-os-partner:20223
BRANCH=none
TEST=from root shell, 'powerd_suspend'. 1.8V_MICOM should not go up.
after resume, 'ectool hello' should still work.
Change-Id: I93b781e96bea633419e923a83f1f6d7300ae8c54
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59474
Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
This will fix EC flash commands on pit, once the host side (u-boot and
cros_ec driver) are upgraded to match.
This change is backwards-compatible the EC still supports the existing
version 2 protocols for talking to existing AP/kernel/ectool.
Once the AP-side supports version 3 for SPI (and existing systems are
upgraded), we will remove older SPI support since we haven't shipped a
product which uses SPI.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=disable cros_ec driver support in ectool; 'ectool hello' works on link
And with an old ectool which predates this CL, 'ectool hello' also works.
On pit, from u-boot prompt, 'crosec test' and 'crosec version' work, and
keyboard works.
Change-Id: I01f193e316e9aa442fe50d632dc8a4681723e282
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58908
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Read the value of the WP GPIO correctly.
BUG=chrome-os-partner:20091
BRANCH=none
TEST=manual
On the EC console, run
gpioget WP_L
Short the WP pin, run it again. You should see it change.
Change-Id: Id85c1d69c88ea3df4e529e844aa2455643f1a41b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58948
Reviewed-by: Randall Spangler <rspangler@chromium.org>
It's not used by the host command module or handlers, so shouldn't be exposed to them.
BUG=chrome-os-partner:20185
BRANCH=none
TEST='ectool hello' still works
Change-Id: I0122bd9ef33e71afab7e5cc035fb3b9d220334c6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58632
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The flags are specific to the LPC interface and not used by the host
command module, so shouldn't be present at that level.
BUG=chrome-os-partner:20185
BRANCH=none
TEST='ectool hello' still works
Change-Id: I6b2c3208fc398ea40d9e7cc7bf5ec206b3e317d8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58631
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
GPIO_HI_Z was a bit misleading (it's high impedance by default, but it's
actually an output not an input), but when we added GPIO_HI_Z_OPEN to mean
"open-drain output, pulled low by default", it got too confusing.
This renames those macros to:
#define GPIO_ODR_HIGH (GPIO_OUTPUT | GPIO_OPEN_DRAIN | GPIO_HIGH)
#define GPIO_ODR_LOW (GPIO_OUTPUT | GPIO_OPEN_DRAIN | GPIO_LOW)
BUG=chrome-os-partner:18788
BRANCH=none
TEST=none
No functional change, just renaming some macros. If it compiles, it should
be unchanged in behavior.
Change-Id: Ic84d7be8531f2b240a8eca4f6cfe5291ebd2d5ef
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58596
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Implement the EC hibernate mode by using the stm32f100 standby low power
mode.
As we cannot de-activate the watchdog during long hibernation, the
following workaround is implemented:
we are woken-up once by the watchdog and go back to hibernate if we
detect that condition.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=spring
BUG=chrome-os-partner:19595
TEST=on Spring with rework on the EC wake-up pin,
type "hibernate 10" and see the EC console going blank for 10s, then
booting with reset cause equals to "hibernate".
Press Alt+VolUp+H, then wake-up the system by pressing power key.
Change-Id: I28150e69817ae80314f52977ec6b62750017c2c4
Reviewed-on: https://gerrit.chromium.org/gerrit/58086
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
This creates a separate thread that keeps reading characters from stdin
and feed to UART process.
BUG=chrome-os-partner:19235
TEST=Start up a emulator and type 'help'. See command list.
TEST=Pass all tests for 300 times.
BRANCH=None
Change-Id: I190c1d939b0b4ad0f8f0517d8d7b06f2f3df3832
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57866
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Currently, we need to have #ifdefs everywhere watchdog_reload() is
called. With this fix we don't.
Also don't bother including unused hardware timer watchdog code if the
watchdog isn't defined.
No change when CONFIG_WATCHDOG is defined (which it is for all normal builds).
BUG=chrome-os-partner:20056
BRANCH=none
TEST=build all platforms with CONFIG_WATCHDOG commented out in config.h
Change-Id: Id3ce33af1a497eda127a4892e13651d9d2534d92
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58094
Reviewed-by: Simon Glass <sjg@chromium.org>
The IOUT pin of the smart battery charger can be used to monitor the AC
adapter current (default) or the battery charging current.
BUG=none
BRANCH=none
TEST=manual
Discharge the battery a bit, and connect to the EC console. With the AC
power plugged in, the "battery" command should show charging status,
including current.
The "adc" command will display the A-D converters, including the current
measurement. For example:
> battery
Temp: 0x0b88 = 295.2 K (22.1 C)
Manuf: SMP-COS20
Device: OC2
Chem: LION
Serial: 0x0005
V: 0x4130 = 16688 mV
V-desired: 0x41a0 = 16800 mV
V-design: 0x39d0 = 14800 mV
I: 0x008e = 142 mA(CHG)
I-desired: 0x0080 = 128 mA
Mode: 0x6001
Charge: 98 %
Abs: 94 %
Remaining: 1871 mAh
Cap-full: 1923 mAh
Design: 2000 mAh
Time-full: 0h:23
Empty: 0h:0
>
> adc
ADC channel "ECTemp" = 317
ADC channel "ChargerCurrent" = 455
>
That current is significantly higher than the "I:" reported by the "battery"
command. But look at the charger options:
> sbc 0x12
0x7904 (30980)
>
Bit 5 controls the IOUT Selection. When clear, it monitors the current from
the AC adapter. Set bit 5 to monitor the current provided to the battery:
> sbc 0x12 0x7924
> adc
ADC channel "ECTemp" = 318
ADC channel "ChargerCurrent" = 128
>
That matches what the smart battery sees.
Change-Id: I2fe351304421dfb22d83ef13d416aa44c9f56e8a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57940
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The ADC pins were being misconfigured for quite a while now. Let's fix 'em.
BUG=none
BRANCH=link
TEST=none
The effect was that the adc values that measure GPIO pins were less
accurate. Since no one noticed, there's probably not much that can
be done to test it.
Change-Id: I9def4eb95c89f72e5df0721e6153c8caa3ef8e2a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57939
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reading from a nonexistant/nonresponsive smart battery fails (as it should).
But then it leaves the i2c clock line low, so that subsequent i2cscan
commands fail too.
This change just sends a STOP to clear the bus when an i2c error occurs.
BUG=chromium:247037
BRANCH=none
TEST=none
Change-Id: I599bed7149ed3dd3748f1a939c2ea8fdf65e3d72
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57808
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Leaving the PLL turned off saves about 0.5 mW (and also presumably
speeds up boot a tiny amount, since we don't need to wait for the PLL
to lock).
BUG=chrome-os-partner:19951
BRANCH=none
TEST=system boots normally. power consumption on P1.8V_MICOM rail is lower.
Change-Id: I93dc1efabbf6c6b0b5a43ffebe1068d18c689bef
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57645
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The WAKE# pin was being driven low when the power button was
pressed and no other events were occuring. This causes a PCIE
wake event to be observed on the host. This is incorrect. Therefore
only assert the WAKE# pin when any other event but the power button
has occured.
The implementation introduces a board-specific callback,
board_process_wake_events(), which handles the specific logic
for the wake events.
BUG=chrome-os-partner:19810
BRANCH=None
TEST=Manual. Both power button wakeup and lid events were tested. The
presence of PCIE Wake no longer exists for S5->S0 transitions.
Change-Id: If1311ccc36629b04d2d9e021c3e103e379836a3a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56970
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The firmware defines had two almost-identical sets. Coalesce into one
consistent set.
Link had 256 KB flash, but only allowed 2 80KB images. Future
LM4-based platforms (slippy/peppy/falco/etc) will now use the entire
flash, with RO=124KB, pstate=4KB, RW=128KB. This matches what the
STM32 platforms do, where pstate is contiguous with the RO firmware.
No functional change to STM32-based platforms.
BUG=chrome-os-partner:19176
BRANCH=none
TEST=build all platforms and dump_fmap ec.bin.
- stm32-based platforms should report RO=61440@0, RW=65536@0x10000
- link should report RO=81920@0, RW=81920@0x14000
- slippy should report RO=129024@0, RW=131072@0x20000
Change-Id: I20b1d95c16250d9a5d228ead06eef03d96548823
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56655
Haswell devices have EC control of the WWAN power rail.
Expose a new wireless switch enable flag for this under
the existing wirless enable command.
This change also abstracts the wireless enable function
to call a per-board handler so the different boards can
do the right thing based on their GPIO setup.
The haswell boards will switch WLAN radio and WWAN power
rails based on the switch inputs. These boards do not have
EC control of bluetooth radio/rail power.
WLAN (power and radio) still defaults to enabled. Disabling
with ectool will turn off the radio but keep the power enabled
in order to prevent the PCIe device from disappearing.
WWAN (power) still defaults to disabled. Disabling with
ectool will turn off the power rail.
BUG=chrome-os-partner:19871
BRANCH=none
TEST=manual: boot on slippy
DEFAULT:
> ectool gpioget pp3300_wlan_en
GPIO pp3300_wlan_en = 1
> ectool gpioget wlan_off_l
GPIO wlan_off_l = 1
> ectool gpioget pp3300_lte_en
GPIO pp3300_lte_en = 0
ENABLE WWAN:
> ectool wireless 0x7
Success.
> ectool gpioget pp3300_lte_en
GPIO pp3300_lte_en = 1
DISABLE WLAN (radio):
> ectool wireless 0x7
Success.
> ectool gpioget pp3300_wlan_en
GPIO pp3300_wlan_en = 1
> ectool gpioget wlan_off_l
GPIO wlan_off_l = 0
Change-Id: I6f760b8cf5ab47d8f7f0dd8cd4d3e6563464043e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57215
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These were tested to make sure they are not responsible for
bricking boards.
The flash code is necessary for software sync, and it is
essential to be able to update boards without servo.
The hibernate setup code was breaking jumping between images
and the passing of data between the images -- needed for
SW SYNC but also needed for things like "reboot ap-off".
BUG=chrome-os-partner:19366
BRANCH=none
TEST=manual: emerge-slippy chromeos-ec, flash+boot, update again via SW Sync
Change-Id: Ib1363b353f18b21e0cad3209783e1e0b4ff24e86
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56820
The path string is not terminated properly, causing occasional crashes.
BUG=chrome-os-partner:19235
TEST=Dump the path and check it's correct.
BRANCH=None
Change-Id: I9ccbd565ce68ffdad98f2dd90ecf19edf9805ec0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56700
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This was left over from ancient code where host commands only had a
64-byte payload, and page writes need to happen in 128-byte
increments. This is no longer an issue with SPI host interface.
Also added capability for word writes, since that'll be necessary for
writing pstate (in the next CL).
BUG=chrome-os-partner:9526
BRANCH=none
TEST=hack flashwrite command in flash_common.c to allow write size = 4 bytes
flasherase 0x1fc00 0x400
flashwrite 0x1fc00 0x100 -> success; uses fast path
flashwrite 0x1fd00 4 -> success; uses word-write path
Change-Id: I61434d8f714ea46deb65cadd82c45a61ad0ce68b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56627
Reviewed-by: Simon Glass <sjg@chromium.org>
This change copies the slippy board configuration as a starting
point for peppy. This change is essentially the same as
https://gerrit.chromium.org/gerrit/55820
BUG=chrome-os-partner:19640
BRANCH=none
TEST=manual
Tested on slippy as there are no peppy-specific changes yet.
cros_workon --board peppy start chromeos-ec
emerge-peppy chromeos-ec
~/trunk/src/platform/ec/util/flash_ec --board peppy
Signed-off-by: Dave Parker <dparker@chromium.org>
Change-Id: I4c5f7a77fa55a6364effe838f7a656d56bfad9fb
Reviewed-on: https://gerrit.chromium.org/gerrit/56332
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Dave Parker <dparker@chromium.org>
Tested-by: Dave Parker <dparker@chromium.org>
Write protect signal naming is now consistent across boards.
New CONFIG_WP_ACTIVE_HIGH is present on systems where the write
protect signal is active-high (e.g. Link). This will be used in the
next CL, which moves flash_get_protect() to flash_common.c
BUG=chrome-os-partner:15613
BRANCH=none
TEST=flashinfo properly reports WP signal status
Change-Id: I502ab033c3eb36661cc3ee97320874b3fbf6fc0d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56087
Reviewed-by: Vic Yang <victoryang@chromium.org>
Persistent state is needed by all platforms to hold the
protect-ro-at-boot flag. STM32F100 and LM4 implementations were
near-identical, and are now common code (with one #ifdef to handle the
single place where they weren't).
STM32L doesn't use pstate yet, but it'll need to. I can't simply
store the protect-ro-at-boot flag inside the WRP registers themselves
because they're still writable in EC-RW. The change to STM32L to use
pstate is coming next.
BUG=chrome-os-partner:15613
BRANCH=none
TEST=build pit, link, spring; on link and spring, do
- flashinfo -> (no flags)
- enable WP (via screw or dut-control)
- flashinfo -> wp_gpio_asserted
- flashwp enable
- flashinfo -> wp_gpio_asserted ro_at_boot
- flashwp now
- flashinfo -> wp_gpio_asserted ro_at_boot all_now (and possibly ro_now)
- flashwp disable -> fails
- flashinfo -> wp_gpio_asserted ro_at_boot all_now
- reboot ap-off
- flashinfo -> wp_gpio_asserted ro_at_boot ro_now
- disable WP (via screw or dut-control)
- reboot
- flashinfo -> ro_at_boot
- flashwp disable
- flashinfo -> (no flags)
(Note that on Spring you'll need to 'forceen on' before enabling WP,
or the console will be disabled once you enable ro_at_boot and reboot.)
Change-Id: I415388b98ec8bf1d149803aaaa7fe8c7f3076c36
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56064
No functional changes, just renaming and defining a few additional regs.
BUG=chrome-os-partner:15613
BRANCH=none
TEST=build pit
Change-Id: I67b2a96608431ffc418e6d4c81009d497f34568b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55813
This adds support for write protecting the RO code at boot, and the
entire flash on demand.
Implementation if WP# is not asserted is currently a little different
than STM32F and LM4; RO is still protected at boot if ro_at_boot, but
can be unprotected and the change will commit on the next reboot.
This saves the bank of flash which we use for pstate on LM4 and
STM32F. I think I can use one of the unused option bits (WRP2 bit 0)
to hold the RO-at-boot flag, in which case I can more closely match
the behavior of the other chips, but I'd like to do that (or give up
and implement pstate) in a separate CL so it's clearer what I'm doing.
BUG=chrome-os-partner:15613
BRANCH=none
TEST=manual
- flashinfo -> (no flags)
- enable WP (via screw or dut-control)
- flashinfo -> wp_gpio_asserted
- flashwp enable
- flashinfo -> wp_gpio_asserted ro_at_boot
- flashwp now
- flashinfo -> wp_gpio_asserted ro_at_boot all_now
- flashwp disable -> fails
- flashinfo -> wp_gpio_asserted ro_at_boot all_now
- flasherase 0x1fc00 0x400 -> fails
- reboot
- flashinfo -> wp_gpio_asserted ro_at_boot ro_now
- flasherase 0xfc00 0x400 -> fails
- flasherase 0x1fc00 0x400 -> succeeds
- disable WP (via screw or dut-control)
- reboot
- flashinfo -> ro_at_boot ro_now
- flashwp disable
- flashinfo -> ro_now
- reboot
- flashinfo -> (no flags)
- flasherase 0xfc00 0x400 -> succeeds
- flasherase 0x1fc00 0x400 -> succeeds
Change-Id: Id1b6b099a44a1985a5ab9387feb882a8f26e3aa1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55594
This change just copies slippy and tweaks a few things that were
slippy-specific instead of not-link-specific (there are still bugs
open for those things).
BUG=chrome-os-partner:18788
BRANCH=none
TEST=manual
Since there are no Falco-specific changes yet (just slippy with another
name), I can try it on Slippy:
cros_workon --board falco start chromeos-ec
emerge-falco chromeos-ec
~/trunk/src/platform/ec/util/flash_ec --board falco
I also built and tested Link EC, to make sure nothing broke there either.
Change-Id: I9b3682032bd51adab4450520dfe52e3036750ef9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55820
Reviewed-by: Randall Spangler <rspangler@chromium.org>
