Rather than implementing board version only for Link, implement for each
board which has version strapping.
BUG=chrome-os-partner:20295.
TEST=Manual. Run "ver" command on Peppy, verify correct board version is
returned.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I57656a645c6bcd1fdb2e7e4aba91b4ec4b8ad8ec
Reviewed-on: https://gerrit.chromium.org/gerrit/61186
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
This gets rid of mystery files like "ir357x" and "lp5562". All chip
names are now prefixed with their module type (e.g. "chipset_",
"led_driver_", etc.)
No functional changes; renaming files and CONFIG constants only.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I3227fb0f6b0243bb08a13577cdb0f6def0e15d54
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60922
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>
It's still unclear why the PL6 pin which is used
for RCIN_L does not behave properly when configured
as open drain. Work around the misbehavior by
configuring the PL6 pin as an input. When it is
required to be driven low the pin is reconfigured to
an output and subsequently made an input again.
This provides the open drain semantics that are
required to eliminate leakage.
BUG=chrome-os-partner:19811
BUG=chrome-os-partner:20054
BUG=chrome-os-partner:20173
BUG=chrome-os-partner:20175
BRANCH=None
TEST=manual
'apreset warm' causes reset as expected. The pin is
configured as an input by default without open drain
or a pullup resistor:
> rw 0x40062400 (GPIODIR)
read 0x40062400 = 0x00000000
> rw 0x4006250c (GPIOODR)
read 0x4006250c = 0x00000000
> rw 0x40062510 (GPIOPUR)
read 0x40062510 = 0x00000000
Change-Id: Ia3ad6fa7fec06be1cbff6854d9341722d8617408
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60780
Reviewed-by: Sameer Nanda <snanda@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>
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>
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
WP GPIO is active low on peppy.
TEST="gpioget WP" with hole24 open shows 1, with hole24 shorted shows 0.
BUG=chrome-os-partner:20429.
BRANCH=none.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Idf3de192c500edcb40b37269b1b66e6a5df4dd1f
Reviewed-on: https://gerrit.chromium.org/gerrit/59703
Reviewed-by: Dave Parker <dparker@chromium.org>
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>
BUG=chrome-os-partner:19949
BRANCH=peppy
TEST=Manual. Observe output from "battery" and "charger" on EC console.
No smoke or fire observed (yet).
Signed-off-by: Dave Parker <dparker@chromium.org>
Change-Id: Ibac55bb58ebfc25de5cb625d4f503cf6e3ecec62
Reviewed-on: https://gerrit.chromium.org/gerrit/59624
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
The LPC_CLKRUN_L signal on these boards has an external pull
up to the correct PCH rail. Therefore, configure the pin
controlling LPC_CLKRUN_L as open drain.
BUG=chrome-os-partner:19811
BUG=chrome-os-partner:20331
BRANCH=None
TEST=Built and flashed. Interrogated GPIOODR register for port M:
> rw 0x4006350c
read 0x4006350c = 0x00000004
Change-Id: I50dc90d784bd1d1f318b401e5d7d6e06bf0f1e47
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59416
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Starting DVT, Spring boards have updated hardware to prevent cap ringing
when a charger is plugged.
Adjust T01, T12, T23 and T34 current limit to 87.5% as expected by this
mechanism.
Push all termination voltages to 2.1v as the actual temperature range is
not related to the real charge temperature.
On pre-DVT boards, this will just reduce the max charging rate by 12.5%.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=spring
BUG=chrome-os-partner:18987
TEST=on Spring EVT, use "pmu" command on the EC console and see
registers 0x5 to 0x9 contain : "3e 5e be fe ff"
Original-Change-Id: Ie078a38251cd2cb50ee605c34a6818bf994d148d
Reviewed-on: https://gerrit.chromium.org/gerrit/49484
Commit-Queue: Jon Salz <jsalz@chromium.org>
Reviewed-by: Jon Salz <jsalz@chromium.org>
Tested-by: Jon Salz <jsalz@chromium.org>
(cherry picked from commit 4122b222859db34cb6eee827cba4988df458d916)
Change-Id: I78355651f5f7abc0546fec0c4df8d38ea3549b2d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59197
Reviewed-by: Vincent Palatin <vpalatin@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>
In order not to leak power to the PP3300_PCH rail
mark the PCH_SMI_L as open drain.
BUG=chrome-os-partner:19811
BUG=chrome-os-partner:20175
BUG=chrome-os-partner:20054
BRANCH=None
TEST=Built and booted Faloc. No ill effects.
Change-Id: Ia4071067af177684579e146199f9ea174788b933
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58681
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
It was found that PL6 behaves in an inverted way when it is
configured as open drain. Add notes about determining why this
is. Apparently PL6 is an oddity w.r.t. the other pins.
BUG=chrome-os-partner:19811
BRANCH=None
TEST=built
Change-Id: I2d5b27f49c4e51ba4eb75cda9c798b9a5793f767
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58679
Reviewed-by: Duncan Laurie <dlaurie@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>
The gpio pin used for RCIN# should be configured as open drain as the
rail is pulled up by a non-EC rail. Driving it high would leak power.
BUG=chrome-os-partner:19355,chrome-os-partner:20173
BRANCH=none
TEST=manual: boot on falco without RCIN# causing reset and
the 'apreset warm' EC command works as expected.
Change-Id: I197928fd3cac27db3add9dd842e3171f23c9d71e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58590
Frank's reworks turn AC_PWRBTN_L from a signal which co-mingled
AC-detect and pwower button press to a straight AC detect signal.
Switch from the hacky snow version of extpower to the simple gpio
version.
BUG=chrome-os-partner:20034
BRANCH=none
TEST=manual, using gpioget command
1. With AC plugged in, AC_PRESENT=1
2. Press power button. Still AC_PRESENT=1
3. Unplug AC, AC_PRESENT=0
4. Press power button. Still AC_PRESENT=0
Change-Id: I35df4ba80d0003310f3e01d9815158cfa3d0cb51
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58550
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds the BQ24738 smart battery charger, and a placeholder for the Falco
battery pack. I don't have either documentation or a battery to use to test,
so the battery pack stuff is just a guess (see crosbug.com/p/20142).
BUG=chrome-os-partner:20098
BRANCH=none
TEST=none
Well, if you like, from the EC console, run "charger". It should say
something like this:
> charger
Name : bq24738
Option: 1111100100010010 (0xf912)
Man id: 0x0040
Dev id: 0x000f
V_batt: 0 (1024 - 19200, 16)
I_batt: 0 ( 128 - 8128, 64)
I_in : 3968 ( 128 - 8064, 128)
>
But since I don't have either a battery or a spec, I had to guess at the
battery configuration. To test the charger, we kind of need a battery.
Change-Id: I6e63d6b5aa8be4ba15e2c427d2e86364ef6251b3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58466
This measures the analog voltage from the AC adapater's ID pin. The values
don't seem to match what we expected, so there's more work to come. Still,
here it is.
BUG=chrome-os-partner:19594
BRANCH=none
TEST=manual
From the EC console, run "adc". You should see a line like this:
ADC channel "AdapterIDVoltage" = 553
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Idf84ceb6cd85d66d879f07bf4f26881ec078f638
Reviewed-on: https://gerrit.chromium.org/gerrit/58465
BUG=chrome-os-partner:18788
BRANCH=none
TEST=none
The connection to the LVDS controller is unstuffed, so there's nothing to
test without some soldering.
Change-Id: I5e6d9a3705554335512611b6b463568251b848b6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58268
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
I don't think there are any power-sequencing changes.
BUG=chrome-os-partner:18788
BRANCH=falco
TEST=none
Nothing to test yet.
Change-Id: I2d0b7085fb5a5b853385049b61fe7796709702ae
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56137
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>
This adds the initial support for Slippy's battery. The data I have is
unclear and incomplete, so this is NOT the final form. It seems to work
right now, and hasn't caught fire or anything, but it will need futher
tweaks.
BUG=chrome-os-partner:19976
BRANCH=none
TEST=manual (and watch it!)
Connect the EC console and watch what happens. You should see the battery
charging, discharging, etc. Keep an eye on it, though, and never leave it
unattended when on AC - we don't have the full data sheets available yet.
Change-Id: Id9bf93dc04a1399a9cdbc2156b3fac74be62038f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57814
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This costs 232 bytes RAM; we still have over 6KB free.
BUG=chrome-os-partner:19945
BRANCH=none
TEST=taskinfo shows timing and interrupt counts
Change-Id: I1c4e4eac44b48c66b075b8ea209b4748c55b7fcb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57511
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>
This enables ASSERT() for easier debugging.
BUG=chrome-os-partner:19235
TEST=Add ASSERT(0) in lid_sw test and see error message:
ASSERTION FAIL: test/lid_sw.c:91:run_test - 0
BRANCH=None
Change-Id: I7df7d5984e5d787fdc5ad2b6b24fec669e95c97e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56691
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Falco / Peppy EC builds were previously broken because the board
creation came after I502ab033c3eb36661cc3ee97320874b3fbf6fc0d was put up
for review, but before it landed. Apply the same changes as slippy board
to fix the build.
BUG=chrome-os-partner:15613
BRANCH=none
TEST=emerge-{falco/peppy} chromeos-ec
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I7299343835ef8d08c6a2d2c7b4f797dc968a15d7
Reviewed-on: https://gerrit.chromium.org/gerrit/56668
Reviewed-by: Dave Parker <dparker@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@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>
The gpio pin used for RCIN# should be configured as open drain as the
rail is pulled up by a non-EC rail. Driving it high would leak power.
The current GPIO_HI_Z macro uses GPIO_HIGH as the default state.
However, it has been found that this actually drives the pin to ground.
It is still unclear how Link works or doesn't.
BUG=chrome-os-partner:19355
BRANCH=none
TEST=manual: boot on slippy without RCIN# causing reset and
the 'apreset warm' EC command works as expected.
Change-Id: I71425075f8d77b3d7e576a59fc24f823790e2655
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56269
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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>
Daisy doesn't have a write protect signal, so emulate it as a fake
signal which is always low; this maintains the current behavior on
daisy.
BUG=chrome-os-partner:15613
BRANCH=none
TEST=flashinfo shows gpio not asserted
then short across the WP screw and flashinfo shows it asserted
Change-Id: I329424efe1c3b065976e17395e2bf9588cdce88c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51500
Reviewed-by: Vic Yang <victoryang@chromium.org>
When AP is off, turn off pullup on NSS, and set MISO to an input so
the SPI module won't drive it high if the last sent bit was a 1. This
reduces leakage when the AP is off.
This patch also fixes a bug where gpio_set_alternate_function() set
the wrong pins to normal-mode when func=-1; that didn't hit anything
else because that functionality wasn't used on STM32 until now.
BUG=chrome-os-partner:19304
BRANCH=none
TEST=boot pit
On EC console, with AP on, 'rw 0x40020000' returns
read 0x40020000 = 0x6569aa20 <- must have 0x____aa__
Then 'apshutdown' and 'rw 0x40020000' returns
read 0x40020000 = 0x65690020 <- must have 0x____00__
The 'power on' and AP turns back on. At u-boot prompt,
'sspi 2:0 256 9f00000000' returns
FDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFEEC010001
(some number of 0xFD's followed by FEEC...) This shows SPI
functionality is restored when AP is powered back on, and not
just at init time.
Change-Id: Ia3cd3e0bc222dc663d635509918fa3d383fd7971
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51182
Reviewed-by: Simon Glass <sjg@chromium.org>
The current lm4 pwm module was using board-specific
pins during this configuration. Move the implementation
of configure_fan_gpios() to the board-specific files
so that the pin configuration policy isn't a part of the
common infrastructure.
BUG=chrome-os-partner:19504
BRANCH=none
TEST=successfully booted slippy with backlight turning on in OS.
Change-Id: I325f1ac4639b4a78d8b860df7a8b688ca385b71b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51471
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
When system is locked, the console is disabled. However, we need console
for debugging and testing. This CL uses a bit from back-up register to
indicate if the console should always be enabled. (This bit is currently
used by fake WP, which is removed in this CL.) With this, we can set
this bit with console command 'forceen 1' to ensure console is never
disabled.
To prevent device shipped in this state, the chip name is postfixed with
'-unsafe' so that the device is not able to pass HWID check.
BUG=chrome-os-partner:19293
TEST=Manual
BRANCH=spring
Change-Id: I88556e973ca542c1bdc27ba64988718291e01a26
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51086
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
