This commit adds a function that allows the real-time clock to be
printed on the EC console. This could be helpful in trying to correlate
events between the EC's log and the kernel's.
BUG=chrome-os-partner:57731
BRANCH=gru
TEST=make -j buildall
Change-Id: I5e20692a173bddea3dc5c20cc0f2061cc170ce7d
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/388856
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
For TPM operation with Intel chipset APs, the signal PLT_RST_L needs
to trigger a TPM reset. For current Reef boards, this signal is
connected to DIOA13. The next version will have it on DIOM3.
This CL adds support for platform reset connected on DIOA13 and uses a
new board property so that it doesn't affect Kevin/Gru.
BRANCH=none
BUG=chrome-os-partner:55115
TEST=manual
Used H1 dev board configured as Reef. Created high to low transisition
on to verify that platform reset was detected. Tested on Kevin to
ensure that resets were not occurring.
Change-Id: I58f02b7ffa644a9197f4303ae6e640df181040bd
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/380336
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
There is leakage on SYS_RST_ODL from the internal pullup cr50 has on
DIOM0. This change removes the internal pullup on reef.
On Kevin there is a bug preventing the EC from being able to pull
sys_rst_l up high enoug for cr50 to detect that it is pulled high. This
change adds an internal pullup back when cr50 detects that it is on a
kevin or gru.
BUG=chrome-os-partner:56945
BUG=chrome-os-partner:53544
BRANCH=none
TEST=On gru and kevin remove servo verify when apreset is run on the EC
it resets cr50 and the AP. Run pinmux and check that there is a pullup
on diom0 on kevin but not on gru.
Change-Id: Ica4f557745967b93e0bd9c8462916b1f735756ac
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/381322
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
There is no point in waiting for a reset to clear the fallback
counter, it can be cleared as soon as USB update is finished.
BRANCH=none
BUG=chrome-os-partner:56864
TEST=on a kevin-tpm2 device: set the reset counter to 7 by running
> rw 0x40000128 1
> rw 0x4000012c 7
on the cr50 console. Then try uploading a new RW image over Suzy-Q
and verify that it is running after reset.
Then verify that cr50 can still be updated
Change-Id: I098a87c48b2fe864143715b1e90d4bb2409b9eae
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/383077
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
There is now a call to reset the retry counter before the hard reset
after an update. Cr50 will use the updated image for the next 5 boots,
but on the 6th it sees the retry counter is greater than 5 and then
jumps back to the old image. Cr50 needs to call
system_process_retry_counter to reset the counter and corrupt the old
image header to prevent falling back to the old image.
Normally the reset counter would be processed after it receives a TPM
command. Reef does not have Cr50 TPM support. Until Cr50 has TPM
support for Reef, Cr50 should have a different point to know when the
update is good. This change adds a board property to mark the process
the reset counter once the Cr50 USB controller receives a set address
request from the host. On Reef the controller defaults to the AP PHY
when suzyq is not connected, so it should have a connection to the AP
or through suzyq after boot.
The board property is only added to Reef. Behavior on Kevin and Gru is
unchanged.
BUG=chrome-os-partner:56864
BRANCH=none
TEST=update reef. Wait until Cr50 prints 'SETAD' then run 'rw
0x4000012c' and verify it is reset to 0.
Change-Id: If517202f25a694cd70550e3be047ea502e7c5383
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/380354
UART0 RX only needs to be disabled on reef. This change uses a system
property instead of a #define to disable UART0 RX that way it can just
be done on Reef not Gru or the dev board.
BUG=chrome-os-partner:55510
BRANCH=none
TEST=manual
rw 0x4060000c shows a value of 1 for reef and 3 for gru
gru kevin and reef still boot.
Connect DIOA13 to DIOA1 on the dev board and verify the console
can be used.
Change-Id: I5ee3559c2b35f959c0d67f233d1dfa40743b4064
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/378336
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Cr50 needs to connect to the AP phy when not in ccd so cr50 can be
updated and used as a gnubby. This change uses the strapping options
to detect when it is on reef and modifies the ccd behavior to
initialize usb on the AP phy when ccd is disabled. On gru the cr50
behavior is unchanged.
In RDD this change removes the checks that the current_map is the
correct one based on the detected debug state. rdd_init calls
rdd_interrupt to set up the usb and ccd state correctly. Having that
check prevents that initial rdd_interrupt from calling rdd_detached.
Before rdd_detached just disabled usb and we knew during init it
would already be disabled. Now we want to make sure it is called if a
debug accessory is not attached to initialize usb on the AP PHY.
BUG=chrome-os-partner:56098
BRANCH=none
TEST=manual
verify ccd still works on gru
disconnect suzyq and reset reef.
run lsusb on the AP and verify it shows cr50 as a device.
connect suzyq and check that the AP no longer sees cr50.
disconnect suzyq and verify the AP sees it again
Change-Id: I3c1ccc54895835bce12302f3ea43fc2e751b4c97
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/372920
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Nothing has used this config option since Spring and Skate, back
in early 2014. There's nothing in ToT that uses it at all. I want
to add something similar for other purposes, and having two
similar-sounding options will just cause confusion.
NOTE: Although the comments in include/system.h said that the two
functions
system_get_console_force_enabled()
system_set_console_force_enabled()
were only useful when CONFIG_CONSOLE_RESTRICTED_INPUT is defined,
they were being used in chip/stm32/system.c. But since the
bkpdata registers are only accessible to the EC, there was no way
to initialize or modify the one relevant bit that those functions
cared about, so they almost certainly had no effect.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall
Change-Id: Id41541193d4559f5c507bdd0268b049166af4497
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374525
Sometimes a perfectly sane image enters rolling reboot mode in case
some data change triggered a bug which prevents the normal startup and
causes a reset.
The most likely task causing in in case of cr50 would be the tpm task.
Let's add another check of the restart counter: should it reach the
value of 50, do not start the TPM task.
BRANCH=none
BUG=chrome-os-partner:55708
TEST=with this code plus an unaligned access introduced in tpm
initialization sequence in both RW_A and RW_B, program the full
image on the dev board.
Observe the device reset 50 time is rapid succession and then
stop with the following message on the console:
Bldr |511709
retry|50
Himg =4F992103..408D193E
Hfss =384E4655..EE13EBD0
Hinf =44D21600..B70529BD
jump @00044000
--- UART initialized after reboot ---
[Reset cause: rtc-alarm]
[Image: RW, cr50_v1.1.5044-8d6f7a2+ private-cr51:v0.0.68-633229c ...
+ cryptoc:v0.0.4-5319e83 2016-08-07 19:37:16 vbendeb@kvasha]
[0.004130 Inits done]
[0.006919 Active NVram partition set to 0]
Console is enabled; type HELP for help.
> system_rolling_reboot_suspected: roling reboots suspected. Try \
powercycling to clear
this condition.
[0.010502 Task 2 (TPM) exited!]
Change-Id: I6b08c5c1a02da9edf9bdf394e57cc56d2e595ad1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366892
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
There are few reasons why the SoC may reboot which we haven't
been reporting (they just show up as "[Reset cause: other]").
This adds a bit of decoding to explain some of those "other"
reasons.
BUG=none
BRANCH=none
TEST=make buildall; try on Cr50
I tested one of the new reasons using "crash hang". It shows up
correctly as "{Reset cause: security]". I haven't specifically
tested all of the new reasons, but since this is basically just a
change to console message they should work too. I'll double-check
those cases once some blocking bugs are fixed.
Change-Id: I46daed29d7e37bda9034a3486127bed0ea25f803
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366400
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
There is just one version of Cr50 firmware for all boards
that it's used on. However, on some boards the AP communicates
to the TPM via a SPI interface (i.e. Kevin) and on others, the
AP communicates via an I2C interface (i.e. Reef). In order to
dynamically discover which interface to configure, there are
strapping resistors added to the board which enables the Cr50
to detect which configuration to implement.
This CL is a first pass and is only looking at DIOA1 which is
pulled high for SPI and pulled low for I2C configurations.
The strapping resistor should be read when the AP is in reset
prior to it attempting to drive any of the lines used for
strapping. To ensure this condition is met, Cr50 will only
check the strapping options following a POR (power on reset).
Once the configuration type is discovered, a 'long_life'
register is used to hold the result so that the result can
always be available. The long_life register contents remain
unchanged until a subsequent power down event.
BRANCH=none
BUG=chrome-os-partner:50728
TEST=manual
Tested on Kevin and Reef. Verfifed by reading the stored value
that the SPI configuraiton is detected for Kevin and the I2C
interface is detected on Reef. In addition, verified on Kevin
that the Cr50 FW version is correctly reported to the AP which
means that TPM register reads via the slave SPI are functioning.
Change-Id: Ibd7624ad8e3b4126f6346dce0bc72f62a3cc6d18
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363014
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
As a temp measure until a proper solution is implemented, reset the
restart counter when the PCR_Read command is issued by the host.
This is a good indication that Chrome OS is through the boot process,
as PCR value is used to determine the boot mode.
BRANCH=none
BUG=chrome-os-partner:55667
TEST=installed the new image on a Kevin cr50 and rebooted it in normal
and recovery modes, observed on the cr50 console the message like
> system_process_retry_counter:retry counter 1
Change-Id: Ib55e161d5edbf8f6e2d387fd756b94aa53c20ed8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364311
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The SoC looks for two RO images at reset, and is typically
configured for two RW images as well. This CL reports version
strings for all those images, as well as identifying the active
RO and RW copies.
Since the RO image doesn't contain a version string, we create
one using the epoch_, major_, minor_, and img_chk_ members of its
signed header.
BUG=chrome-os-partner:55558
BRANCH=none
TEST=make buildall; run on Cr50 hardware
The "version" command now includes information like this:
RO_A: * 0.0.2/a3c3d5ea
RO_B: 0.0.2/8895c9eb
RW_A: cr50_v1.1.4965-a6c1c73-dirty
RW_B: * cr50_v1.1.4959-2f49d5c
The '*' indicates the active image.
The test/tpm_test/tpmtest.py program has been updated to request
the version information at startup, and it also now reports
similar information, just all on one line:
RO_A:* 0.0.2/a3c3d5ea RO_B: 0.0.2/8895c9eb RW_A: cr50_v1.1 ...
The active images are marked with a '*' following the ':', so
that the same regexp can match either format:
($ro, $rw) = m/RO_[AB]:\s*\*\s+(\S+).*RW_[AB]:\s*\*\s+(\S+)/s;
Change-Id: Ic27e295d9122045b2ec5a638933924b65ecc8e43
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362861
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When the debug cable is disconnected the a USB suspend interrupt is
triggered and puts the chip to sleep before rdd can detect a change on
the cc lines and disconnect from CCD. This prevents the DEBUG_STATE_MAP
from being reset to detect the debug connect and is left detecting the
disconnect. Since the debug accessory is already disconnected the RDD
interrupt will wake up the chip right after it goes to sleep.
The UTMI and PIN wake source still cause the chip to wake up before the
RDD interrupt, so disable those to test this change.
BUG=chrome-os-partner:54796
BRANCH=none
TEST=Disable wake pin and utmi wake sources. Put cr50 to sleep. Attach a
reworked suzy q and make sure cr50 wakes up. Detach it and check that it
goes back to sleep. Do that a couple of times. Check CCD is still
enabled when the debug accessory is detected and disabled on
disconnect.
Change-Id: I58a012895bc874dcdd512aa84de9a917469f3139
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360234
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
If we #define CONFIG_RW_B, the firmware image can have two RW
components. This CL expands the "sysinfo" command so that we can
see which image we're running from when RW_B is also a
possibility.
BUG=chrome-os-partner:50701
BRANCH=none
TEST=make buildall; test RW update on Cr50
Using test/tpm_test/tpmtest.py, update the RW firmware and reboot
several times to switch between RW_A and RW_B. Note that the
"sysjump" command reports the correct image each time.
Change-Id: Iba3778579587f6df198728d3783cb848b4fd199d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/337664
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds the SPI slave bus and TPM task to the things that
can prevent deep sleep. Even when things are quiet, we wait at
least a second
With this CL, it will wait at least one second after the last SPS
transaction before sleeping. Since most TPM-protocol commands are
built up of a number of back-to-back SPS messages, if we don't
wait we'll keep trying to sleep in the middle of active commands.
Even if everything is quiet, we wait 0.2 seconds anyway to give
the UART buffers time to drain.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; extensive tests on Cr50
Testing is a pain.
In addition to ALL the steps listed in commit
d917d3f1867e96369ff25bf6906043a5f488a6fb, loading the firmware
with the spiflash tool leaves SPS_CS_L low, so you have to drive
it high manually. The easiest way is to build and run
test/tpm_test/tpmtest.py for a few seconds then interrupt it with
Ctrl-C.
Note that because the system wakes from deep sleep when it sees
SPS_CS_L go low but it can't get ready fast enough to capture the
incoming bits, that first SPI transaction will be garbled or
lost. You'll have to either retry it, or wake the system another
way first.
Change-Id: Iae2fe5ef33869c48e98a3afecd6b98991a51a488
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336690
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is still in testing mode, so you have to take special steps
to enable it (keep reading). But if you do the right dance, it
does go into deep sleep for USB suspend, and resumes correctly.
However, it doesn't yet wake for any other reason. That's coming next.
Normal sleep is not yet supported, either.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; extensive tests on Cr50
Testing is a pain.
First, you can't print anything in the idle task, because that
just makes it stop being idle, so the only way to detect when
it's triggered is by wiring up a GPIO and instrumenting things.
Second, you have to manually reenable USB suspend on the host
every time the Cr50 boots with
echo auto > /sys/bus/usb/devices/<BLEH>/power/control
where <BLEH> is the correct device.
Third, for reasons probably related to the mysteries of HID
devices combined with crbug.com/431886, you have to build the
firmware without CONFIG_USB_HID (and the related items in
board.h)
Finally, because it's still a work in progress, you have to type
idle d
at the serial console after every boot (or resume) to reenable
deep sleep in the idle task.
If you do all that, then you'll see that it does go into deep
sleep. Ping it again with "lsusb -v -d 18d1:5014" or
./test/usb_test/device_configuration, and it wakes up and
responds!
If you disconnect the USB while it's in deep sleep, it stays
asleep. When you plug it in again, it wakes up, but it correctly
recognizes that it shouldn't resume and does a normal reset
instead.
Change-Id: I3cc66e48ce671142a4d12edbe0eb9fdacecea0d9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336279
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
Some of the reset causes are found in another register when
resuming from a low-power state. We know we'll need to
distinguish among them eventually, so we might as well decode
them now.
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
I forced the system into deep sleep and observed that the reset
cause is accurately recorded on resume. Doing that requires a
fair amount of hacks and manual effort, and can't happen by
accident. Future CLs will make use of this.
The current, normal behavior is completely unaffected.
Change-Id: I5a7b19dee8bff1ff1703fbbcc84cff4e374cf872
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336314
Reviewed-by: Randall Spangler <rspangler@chromium.org>
To get better power consumption in S0, we add FW support for
CONFIG_LOW_POWER_S0.
Before entering deep idle in S0, we must enable Host interrupt to wake up
EC if it needs to service LPC bus.
This version also add a new bit of sleep_mask (SLEEP_MASK_FAN) in system.h
to prevent EC enter deep idle if fan's duty isn't zero. Normally, the freq of
PWM fan is 25 kHz. It means we must select apb2 clock as the source clock of
PWM fan. Or fan would stop when ec enters deep idle because of no PWM signal.
In hwtimer.c, we reset the preload counter to maximum value in ITEI32's ISR
since preload counter is changed by __hw_clock_source_set all the time.
We also found there're no event set if it's deadline is over 32 bits but
current source clock isn't. To prevent ec doesn't wake-up in deep-idle even if
ITIM32 expires, FW set an event for ITIM32 after process_timers().
Modified sources:
1. wheatley/board.h: Add CONFIG_LOW_POWER_S0 definition.
2. clock.c: Enable Host interrupt for LPC.
3. clock.c: Disable LP_WK_CTL for better power consumption.
4. gpio.c: Add ISR for Host interrupt.
5. uart.c: Introduce bit 6 of USTAT to make sure transmitting is completed.
6. register.h: Add uart_clear_pending_wakeup function.
7. hwtimer.c: Fixed watchdog issue when ITIM32 is closed to overflow.
8. fan.c: Enable deep sleep if duty cycle is zero.
9. include/system.h: Add SLEEP_MASK_FAN for fan control loop.
10. core/cortex-m/task.c: Add "isb" to flash the garbage data in the
instruction pipeline.
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: Ibe3630d0d68cf3f32206adb2afa1b5958916a2be
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/324651
Reviewed-by: Shawn N <shawnn@chromium.org>
Allow boards to take action (such as entering a custom low-power
hibernate-like state) before putting the chip into hibernate state.
BUG=chrome-os-partner:48835
BRANCH=glados
TEST=Manual with subsequent commit on chell. Verify board-level
hibernate callback is called when "hibernate" is run on EC console.
Change-Id: Ie1da044037a74ff8bce5c822f28ce837c62ceec0
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/324086
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
CDRAM / CODERAM configs were previously used for chips which copied code
from external SPI to program memory prior to execution, and were used
inconsistently between npcx and mec1322.
These CONFIGs are now completely redundant given new configs like
CONFIG_MAPPED_STORAGE_BASE and CONFIG_EXTERNAL_STORAGE.
BRANCH=None
BUG=chrome-os-partner:23796
TEST=With entire patch series, on both Samus and Glados:
- Verify 'version' EC console command is correct
- Verify 'flashrom -p ec -r read.bin' reads back EC image
- Verify software sync correctly flashes both EC and PD RW images
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I0e054ab4c939f9dcf54abee8e5ebd9b2e42fe9c4
Reviewed-on: https://chromium-review.googlesource.com/297804
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Certain boards may need to handle fixing up the RESET_FLAG_s
because of the boards' designs. Provide an optional per-chip
implementation to save the reset flags. Note that this
function is not protected by a CONFIG_ option as it can just
be implemented by the chip if a board requires it. Lastly,
implement chip_save_reset_flags() for mec1322 for future use.
BUG=chrome-os-partner:44527
BRANCH=None
TEST=Built and booted on glados.
Change-Id: I604fe4e6a069f31727bab52288595a349e3dbe72
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295115
Reviewed-by: Robbie Zhang <robbie.zhang@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
1. Add flash control module for emulation board.
2. Fix system jump for Andes core.
3. Change the physical size of the flash on the chip to 256KB.
note:
1. Only IT839x series supports flash write protect by registers.
2. Static DMA method of flash code only for IT839x series and IT838x Dx.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=1. console command flashwp and flashinfo
1-a. flashwp enable
1-b. WP asserted and reboot
1-c. flashinfo RO protected now
1-d. WP deasserted and reboot
1-e. No protected
1-f. flashwp disable
1-g. WP asserted and reboot
1-h. No protected
2. console sysjump and sysinfo
2-a. sysjump rw
2-b. jumping to image RW
2-c. sysinfo, Copy : RW, Jumped : yes
2-d. sysjump ro
2-e. jumping to image RO
2-f. sysinfo, Copy : RO, Jumped : yes
3. RO/RW firmware image test
3-a. sysjump rw
3-b. use console command "eflash" to erase RO region,
erase OK and system still work.
3-c. reflash firmware
3-d. sysjump rw, sysjump ro
3-e. use console command "eflash" to erase RW region,
erase OK and system still work.
Change-Id: I7666a095e73026a02fb812e5143bc5172ab713e8
Reviewed-on: https://chromium-review.googlesource.com/271390
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Dino Li <dino.li@ite.com.tw>
Tested-by: Dino Li <dino.li@ite.com.tw>
changes added to support flashrom are:
sysjump support to be able to copy the RO/RW image
and jump to it without causing AP to reboot while
its alreday ON.
LPC init should be reinitialized on sysjump
corrected gpio_set_flags_by_mask to make sure we
update the register only for GPIO_LOW condition and not
all else conditions.
BUG=chrome-os-partner:38103
TEST=commands : flashrom -p ec -w ec.bin
flashrom -p ec -r ec.bin
BRANCH=none
Change-Id: I23892f0378d756052030e73034c3acdd41477e34
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/272000
Reviewed-by: Shawn N <shawnn@chromium.org>
Add npcx_evb in board folder for testing
Add shared-spi arch support in common layer.
Modified drivers for
1. Fan.c: console command “pwmduty”.
2. Pwm.c: for the issue when set duty to 0.
3. System.c: for hw reset only during system reset.
4. Flash.c: Fixed access denied bug of the flash driver for host command.
5. Comments from Patch Set 1
6. Comments from Patch Set 3 (except sha256.c)
7. Add openocd and flash_ec support for npcx_evb
8. Add little FW and spi-flash upload FW in chip folder
9. Add optional make rules for PROJECT_EXTRA
10.Replace CONFIG_SHRSPI_ARCH with CONFIG_CODERAM_ARCH and remove changes
in common layer sources for shared-spi arch. (except sysjump)
11.Find the root cause of JTAG issue and use workaround method
with SUPPORT_JTAG in clock.c
12 Execute hibernate in low power RAM for better power consumption
13 Add workaround method for version console command
14 Modified coding style issues by checkpatch.pl tool
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I5e383420642de1643e2bead837a55c8c58481786
Signed-off-by: Ian Chao <mlchao@nuvoton.com>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233742
This conversion is needed in files outside of system.c, so add a new
function.
BUG=chrome-os-partner:34599
TEST=Manual on samus_pd. Run "pd 0 info" and verify "Image RW" is
printed.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ia905ba9cf985f3714fa75c81670b8a39e9608f3d
Reviewed-on: https://chromium-review.googlesource.com/236980
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Enabled deep sleeping during S0. This was previously inhibited by
SLEEP_MASK_AP_RUN but the new config option (CONFIG_LOW_POWER_S0) will ignore it.
SPI needed a sleep mask, it essentially gets enabled and disabled whenever the
CS changes. Warning: waking up when the CS falls takes a little time, if the AP
sends fast data before the 48MHz clock is enabled characters will get corrupted;
leave about 30uS time for the clock to start.
CQ-DEPEND=CL:219997
CQ-DEPEND=CL:220243
CQ-DEPEND=CL:220461
BUG=chrome-os-partner:32223
BRANCH=none
TEST=load onto pinky, boot the AP(S0), use idlestats command to verify
that we are going into deep sleep (STOP mode). Verify that everything works
normally during S0(SPI, keyboard, anything that requires the EC to wakeup).
Change-Id: I81c4fa472332f1ad8ad93301089a99dcdb108948
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219555
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Enable low power idle for samus_pd. Low power idle is only
entered when no USB PD device is connected.
BUG=chrome-os-partner:31226
BRANCH=none
TEST=load onto samus_pd, use idlestats command to verify
that we are going into deep sleep (STOP mode). Run 30 min.
and verify no watchdog reboots or anything out of ordinary.
Also, verify that host commands from EC work when going into
deep sleep by sending host commands on the EC console with
pdcmd 0 0.
Change-Id: I3e2e04e6c4c0a84e291286dbed90945847e0dfdd
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218957
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
That way all the users of jump tags don't need to know about the
padding requirements.
BUG=chrome-os-partner:23851
BRANCH=none
TEST=enable CONFIG_CMD_JUMPTAGS, then 'jumptags'. Output should be
something like this:
20007fbc: 0x5550 UP.1 2
20007fc4: 0x4b42 KB.2 3
20007fcc: 0x4c50 LP.1 12
20007fdc: 0x4d54 MT.1 8
All the addresses in the first column should be word-aligned. The
sizes in the last column don't need to be a multiple of 4.
Change-Id: I91f9c29701a007ef8a56b5b7e0ea09930dfbea31
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175591
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Changed the low power idle task to use the low speed clock in deep
sleep. The low power idle task is currently only enabled for Peppy,
Slippy, and Falco. This change decreases power consumption when
the AP is not running.
Note that the low speed clock is slow enough that the JTAG cannot be
used and the EC console UART cannot be used. To work around that,
this commit detects when the JTAG is in use and when the EC console
is in use, and will not use the low speed clock if either is in use.
The JTAG in use never clears after being set and the console in use
clears after a fixed timeout period.
BUG=None
BRANCH=None
TEST=Passes all unit tests.
Tested that the EC console works when in deep sleep.
Tested that it is possible to run flash_ec when in deep sleep and
using the low speed clock.
Change-Id: Ia65997eb8e607a5df9b2c7d68e4826bfb1e0194c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173326
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
First implementation of a low power idle task for the LM4 chip. The
low power mode is selected by defining CONFIG_LOW_POWER_IDLE in a
board.h file. This commit turns it on for Peppy, Slippy, and Falco
only because those are the only boards tested.
When using the low power idle task, the chip goes in to deep sleep
when it can. Deep sleep disables clocks to most peripherals and puts
the onboard flash and RAM into a low power mode. The chip is woken
out of deep sleep using the RTC in the hibernate module. Increased
the idle task stack size to handle more involved idle task.
In board.c, the array of GPIO info can be used to select which GPIO
points can wake up the EC from deep sleep. Currenlty selected are
the power button, lid open, AC present, PCH_SLP_S3, and PCH_SLP_S5.
Additionally the port with the KB scan row GPIO point is also
enabled to wake up the EC from deep sleep.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
BUG=None
BRANCH=none
TEST=Passes all unit tests. Runs on slippy, peppy, and falco with no
noticeable side affects. Verified that the power consumed by the EC
is lower when in S3, S5 and G3 by scoping the sense resistor
powering the chip.
Change-Id: I83fa9a159a4b79201b99f2c32678dc4fc8921726
Reviewed-on: https://chromium-review.googlesource.com/172183
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
These were briefly used on link, and are not used by any other
platform. The values for those platforms are almost certainly wrong,
and incorrect information is worse than no information.
This does not remove reading the stuffing resistors - it just removes
the assumption that they map to PROTO1 and EVT.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=compile all platforms
Change-Id: I2ba19fd52660559bfd1d8e3b8a9949e9b8abbddf
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61929
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>
Perviously we use uint32_t for this, but this doesn't compile for 64-bit
environment (and likely doesn't for 16-bit either.) Use uintptr_t so that
we don't get size mismatch errors.
BUG=chrome-os-partner:19257
TEST=Run host emulated tests
BRANCH=None
Change-Id: I3cd66a745fa171c41a5f142514284ec106586acb
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50358
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We have a common chipset interface for performing a warm reset of the
AP, so move the implementation from system_warm_reboot() there. (It
was never a system function anyway; system = EC+AP; chipset = AP)
No functional change; just renaming functions.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build daisy,snow,spring,mccroskey
Change-Id: Ibc2c5efced5660c4335cd1868470184397800acd
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45891
No functional changes. (it might look like
SYSTEM_HIB_MINIMUM_DURATION is a change, but it's not used at present)
BUG=chrome-os-partner:15579
BRANCH=none
TEST=version; chip info should print successfully
Change-Id: Idd7f60a29528e9f6af4f91cd5a556e7336acee9f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36599
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This would improve boot speed when compared to storing in eMMC because
initialing eMMC is slow.
So far other platforms do not have this need because CMOS is quite
efficient; thus it is left unimplemented in lm4.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:10660,13094
TEST=On Snow, see VbNvContext is preserved across power cycles (you have
to patch U-Boot to test this)
Change-Id: If5072c678b87bc47a3a82a1dff2afa3896304f36
Reviewed-on: https://gerrit.chromium.org/gerrit/31832
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Added a warm reboot function that reboots the AP while preserving
RAM contents. This will be helpful in debugging AP/OS hard hangs since
in conjunction with PSTORE_CONSOLE in the kernel, the kernel log messages
from the previous boot will be preserved.
BUG=chrome-os-partner:13249
TEST=1. From EC console issue the "warm_reboot" command. Upon rebooting
"cat /dev/pstore/console-ramoops" and ensure that the contents are dmesg
of previous boot.
2. Reboot the system using alt-volume_up-r key combination. Upon
rebooting, check pstore contents in the same manner as case#1 above.
BRANCH=snow
Change-Id: Ic8f0415da6182f4c1bc2d35b91302ceda5c19569
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31523
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
system_hibernate(0, 0) now hibernates until a wake pin assert, with no
RTC wake.
BUG=none
TEST=manual
command -> expected reset flags from 'sysinfo'
1. reboot -> soft
2. reboot hard -> power-on hard
3. hibernate (and press power button) -> power-on wake-pin
4. hibernate 3 (and wait for timeout) -> power-on rtc-alarm
5. hibernate 10 (and press power button before 10 sec) -> power-on wake-pin
hibdelay 10
then shut system down and run on battery
10 sec later, system should hibernate.
Change-Id: I399413d265f6fcf808adf9ed1db7b812a1b12fc2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29923
Reviewed-by: Vic Yang <victoryang@chromium.org>
No need to hash a bunch of 0xff's at the end. We explicitly set a
0xea byte after the end of the code in firmware_image.lds.S.
BUG=chrome-os-partner:11087
TEST=look for the hash start line in the EC debug output:
[0.011543 hash start 0x00014000 0x00011590]
The second number is the code size. It should be the same size as
ec.RW.bin, instead of 0x14000.
Change-Id: Ibc94851dc1a09eb46cad46bb97dc5762f9c521f0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28300
BUG=chrome-os-partner:11149
TEST=make link, snow, bds; on reboot,
sysjump rw
sysinfo <- should indicate current image is rw
Then on root shell,
ectool version <- should indicate rw
Change-Id: I833fcb814165379dd044e4cb46ae338e5da81212
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27660
This is needed for flash pre-init to be able to hard reset to clear
uncommitted write protect flags without losing the reset flags.
BUG=chrome-os-partner:11368
TEST=manual
Use reboot and sysinfo commands...
1. reset with keyboard. flags -> reset-pin
2. 'reboot soft preserve' flags -> soft reset-pin power-on
3. 'reboot hard preserve' flags -> hard soft reset-pin power-on
4. 'reboot soft'. flags -> soft
5. 'reboot hard'. flags -> hard power-on
Change-Id: I6164a78d99c5c10330f90f651148c5795e7afdda
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27418
Reasons are really bitflags, not a single reason. This will make it
easier to implement flash protection on LM4, where hibernate is a
subset of power-on reasons.
Also added some additional flags we pass in a hibernate register so...
1) We don't recognize spurious RTC wake reasons
2) Hard reset via system_reset(1) is detected as a hard reset, not a RTC wake
BUG=chrome-os-partner:11368
TEST=manual
1. Keyboard reset = power-on reset-pin
2. Pull battery = power-on
3. reboot = soft
4. reboot hard = power-on rtc-alarm
5. hibernate 10 then push power button = power-on wake-pin
6. reboot 3 sec later = soft
7. hibernate 1 = power-on rtc-alarm
Change-Id: Icbbdbcf6dfd13c8a6a4f80a23f64cebebbfba26e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27417
Also removes unused recovery request, since AP handles that internally now.
BUG=chrome-os-partner:10685
TEST=manual. From root shell,
ectool reboot_ec RO -> EC reboots to RO, AP stays up
ectool reboot_ec A -> EC reboots to A, AP stays up
ectool reboot_ec cold -> EC reboots, AP shuts down
ectool reboot_ec cold at-shutdown -> (EC stores request, but doesn't reboot)
shutdown -P now -> EC reboots when AP shuts down
ectool reboot_ec cold at-shutdown -> (EC stores request, but doesn't reboot)
ectool reboot_ec cancel -> (EC stores cancel-request)
shutdown -P now -> AP shuts down, but EC doesn't reboot
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I51bbf997f6b7f94fe61f06a8a1804c3cc5c319b8
Reviewed-on: https://gerrit.chromium.org/gerrit/25791
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
