For simplicity of the code, we don't allow (head == tail) when the queue
is full. But currently we are wasting the size of a single unit, while
we can actually just waste 1 byte. Let's fix this.
BUG=None
TEST=Pass the unit test.
BRANCH=None
Change-Id: Id09c20a9345ebb3ec0cad659afe36e25b422e688
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58058
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
Current implementation of queue_has_space doesn't handle the case where
queue tail has wrapped around the end. This CL fixes the bug.
BUG=None
TEST=Pass the test in the following CL.
BRANCH=link
Change-Id: I774f388081af50f0e930a6cbc3a723da1c8283b0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58031
Reviewed-by: Yung-Chieh Lo <yjlou@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>
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>
The sbc command can be used to get/set registers from the smart battery
controller. The sb command already does that for the smart battery itself.
BUG=none
BRANCH=none
TEST=manual
Try it out.
Change-Id: Idaea451e58988ab2d6bc40164721cb5577d903af
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57813
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is very similar to the BQ24725. There are just enough differences to
require a separate file.
BUG=chrome-os-partner:19976
BRANCH=none
TEST=none
Nothing to test until it's enabled.
Change-Id: I3247fcfde93ac75f5f9790acadc7feca28038608
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57811
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Just tweaking the build.mk file so that other batteries can be specified
for use by the same charging logic.
BUG=none
BRANCH=none
TEST=none
Change-Id: I01b39a6ffc4091b9b7824cf1759b36168f6f5701
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57810
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>
This is preparation for the common userspace EC interface. If/when that
appears, this will be ready.
BUG=chromium:239197
BRANCH=all
TEST=manual
Build, install, run it. Shouldn't be any change.
Change-Id: I9fa78515ec5443ba659f10a66bbaadcb7f4802b0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56131
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>
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 two I2C commands for battery cut-off must be sent out back to back.
Thus we need to guard them with I2C port lock to prevent being
preempted.
BUG=chrome-os-partner:19901
TEST=Check battery cutoff still works.
BRANCH=spring
Change-Id: Iac51037432b108d4cac29d5c73cafa9ce2310b12
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57598
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On Spring, we now have commands 'i2c' and 'i2cscan'. Currently if we
type 'i2c', it's rejected as it's also the prefix of 'i2cscan'. Since
'i2c' is a full match of a legal command, we should accept it.
BUG=None
TEST=On Spring, check 'i2c' invokes 'i2c' command, and 'i2cs'/'i2cscan'
invokes 'i2cscan' command. Also check 'i2' is still rejected.
BRANCH=all
Change-Id: I65c4c148a5a3e9b025554fa8165ba76da7bc312f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57576
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Sometimes TSU6721 falls into a weird state where video dongle is
recognized as non-standard charger. Let's reset TSU6721 when EC boots,
so that we are guaranteed to have a clean state after initialization.
BUG=None
TEST=Keep doing Power+F3 reset. Doesn't see weird state anymore.
BRANCH=spring
Change-Id: Id09bb1721ae79804dc9b3300a2f3def850c2f70a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57575
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is needed to properly notify kernel of power changes.
BUG=chrome-os-partner:19925
TEST=Attach/remove power from video dongle, and see device type changes.
BRANCH=spring
Change-Id: Ic91ad43ed934be021689c4c4557914e6163e06f8
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57569
Reviewed-by: Vincent Palatin <vpalatin@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>
Hard-reset triggers a pulse on the PMIC_RESET pin but this is hard to
see when debugging. By printing error message explicitly before
resetting the board, it's easier to tell why the board is resetting.
BUG=chrome-os-partner:19778
TEST=Trivial change. Build and boot on Spring. Make sure system is
alive.
BRANCH=spring
Change-Id: I26b749af2f8760339373c3e4db46c59d7b0d039e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57101
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If EC-RO protects itself via the WRPx option bytes, flash_ec will fail
to reprogram it. And if EC-RO is broken/unbootable, it won't be able
to clear the WRPx option bytes itself when it sees the write protect
GPIO is not asserted.
Add the -u flag to stm32mon so that it will automatically attempt to
unprotect the flash via the option bytes.
BUG=chrome-os-partner:19723
BRANCH=none
TEST=enable write protect GPIO. Then from console, 'flashwp enable'.
Then from the chroot:
./util/flash_ec --board=pit --ro --image=build/pit/ec.RO.flat
That should successfully reflash the board.
Change-Id: Ic356d29104294d04d5e2a36dc75fd0206b89bd34
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56659
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
This adds the option to specify which LED to control as well as the
ability to query the supported LED color on the board.
BUG=chrome-os-partner:19745
TEST=On Spring:
- ectool led 0 query -> See the max value for R, G, Y is 0x80.
- ectool led 1 query -> See error message.
- ectool led 0 yellow -> See LED turns yellow.
- ectool led 0 green=0x40 red=0x40 -> See green and red lit up.
- ectool led 0 auto -> See LED turns off (without charger.)
BRANCH=spring
Change-Id: Ibdde2f7450122f59383dad1030a0a2a985386f73
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56877
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
If the user plug in the charger really slowly, VBUS and GND will make
contact before ID pin. Currently timer is set to fire in 0.6 seconds,
which means ID pin need to make contact within 0.6 seconds after VBUS
make contact. This is causing chargers to be recognized as non-standard
charger. Let's extend this to 3.6 seconds.
BUG=chrome-os-partner:19765
TEST=Plug in a charger half-way through and see device type 0x20000.
Wait for 3.6 seconds, and see it changes to 0x60000.
TEST=Plug in a charger half-way through, wait for 2 seconds, and then
plug it in all the way. See device type 0x20010.
TEST=Plug in a charger to the end. See device type 0x20010 immediately.
BRANCH=spring
Change-Id: I46c408e7bc733fe4f3655db253f4065a4f12ee1a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56772
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If the AP is already on, the kernel should handle low-power event. We
shouldn't power off the system on sysjump.
BUG=chrome-os-partner:18318
TEST=None
BRANCH=spring
Change-Id: I4e80c61a25d2fa503d0c97e22dc2f4ad9c44f716
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56706
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When emulator exits with reboot exit code, we should run the emulator
again.
BUG=chrome-os-partner:19235
TEST=Enable flash test on emulator. See it reboots.
BRANCH=None
Change-Id: Id0b4c21c1be7ae978be8b336a3498181d881c715
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56701
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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 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>
We are now using solid yellow for both charging and battery assist mode.
No need to use breathing yellow effect anymore.
BUG=chrome-os-partner:19747
TEST=Manual
BRANCH=spring
Change-Id: I9574ac7ef7137fc1d0ebe84316756fa28e9a84aa
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56732
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When we use about the same amount of power as what the charger provides,
we sometimes show green LED. We should avoid this when the battery is
not full.
BUG=chrome-os-partner:19746
TEST=Manual
BRANCH=spring
Change-Id: Id31762aefe22535de64f63a023c35995a3725ef8
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56724
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This provides a way to control LED color with ectool. We can either set
the color or switch back to automatic control.
BUG=chrome-os-partner:19745
TEST=ectool led red -> LED turns red.
ectool led green -> LED turns green.
Unplug charger -> LED turns off.
ectool led green -> LED turns of and shows green.
ectool led auto -> LED back to normal.
BRANCH=spring
Change-Id: I0b455f34cea448660fe44a5fecaac1cb084f8144
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56721
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When we try to set LP5562 LED to the same color as it is currently, we
should just skip the I2C commands. Let's cache its current color so that
we don't waste time on unnecessary I2C transactions.
BUG=chrome-os-partner:19705
TEST=Set LED color manually on spring and doesn't see it change. Unplug
and plug in the charger, and see LED goes back to yellow after few
seconds.
BRANCH=spring
Change-Id: I87e3cf7d53bccc45048ea64dad9925a362cddab7
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56716
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
While in fast mode, we step on the same PWM duty cycle which caused
over-current. We should avoid this.
BUG=chrome-os-partner:18301
TEST=None
BRANCH=spring
Change-Id: Ib22eb7244d1f6173d4486dce7b85a55678318490
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56674
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 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
The "dumb" port power code was setting ports to enabled on S5
when it should be setting them to disabled. This changes it
to match the behavior of the "smart" port power code and its
own comment.
BUG=chrome-os-partner:19398
BRANCH=none
TEST=manual: poweroff slippy and watch USB ports get disabled
Change-Id: Ibc68450a973477341d9ca096ac5a6ddd08cef273
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56262
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
