Until HOOK_INIT has completed, do not allow any tasks other than HOOKS
or IDLE to be scheduled. Programmers often make the assumption that
a HOOK_INIT function is guaranteed to be run before task code that depends
on it, so let's make it so.
BUG=chromium:649398
BRANCH=None
TEST=Manual on kevin, compare boot without patch:
...
[0.004 power state 0 = G3, in 0x0008] <-- from chipset task
RTC: 0x00000000 (0.00 s)
[0.004 power state 4 = G3->S5, in 0x0008]
RTC: 0x00000000 (0.00 s)
[0.005 clear MKBP fifo]
[0.006 clear MKBP fifo]
[0.006 KB init state: ... <-- from keyscan task
[0.012 SW 0x05]
[0.155 hash start 0x00020000 0x00019a38]
[0.158 HOOK_INIT DONE!]
... to boot with patch:
...
RTC: 0x58cc614c (1489789260.00 s)
[0.004 clear MKBP fifo]
[0.005 clear MKBP fifo]
[0.010 SW 0x05]
[0.155 hash start 0x00020000 0x000198e0]
[0.157 HOOK_INIT DONE!]
...
Also, verify kevin boots to OS and is generally functional through
sysjump and basic tasks, and verify elm (stm32f0 / cortex-m0) boots.
Change-Id: If56fab05ce9b9650feb93c5cfc2d084aa281e622
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/456628
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This CL implements two methods for hibernating on npcx7 ec. One is using
PSL (Power Switch Logic) circuit to cut off ec's VCC power rail. The
other is turning off the power of all ram blocks except the last code
ram block. In order to make sure hibernate utilities are located in the
last code ram block and work properly, we introduce a new section called
'after_init' in ec.lds.S.
We also moved the hibernate utilities, workarounds for sysjump and so on
which are related to chip family into system-npcx5/7.c. It should be
easier to maintain.
It also includes:
1. Add CONFIG_HIBERNATE_PSL to select which method is used on npcx7 for
hibernating.
2. Add new flag GPIO_HIB_WAKE_HIGH to configure the active priority of
wake-up inputs during hibernating.
3. Add DEVICE_ID for npcx796f.
BRANCH=none
BUG=none
TEST=No build errors for all boards using npcx5 series.
Build poppy board and upload FW to platform. No issues found. Make
sure AC_PRESENT and POWER_BUTTON_L can wake up system from
hibernate. Passed hibernate tests no matter CONFIG_HIBERNATE_PSL is
enabled or not on npcx796f evb.
Change-Id: I4e045ebce4120b6fabaa582ed2ec31b5335dfdc3
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/493006
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Image used size is now part of the image_data struct present in all
images at a fixed offset, so use it rather than scanning from the end of
the image.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that system_get_image_used() returns
the same value as the old implementation, for both RO and RW images.
BRANCH=None
Change-Id: I35f0aa87f5ab1371dbd8b132f22b9d0044358223
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450859
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Store our image size (known at build time) in our version struct (now
renamed to image_data). This will allow us to more efficiently determine
the size of an image in a follow-up CL.
Note that compatibility is broken for old ROs that do not include this
CL.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that stored image size matches
output of system_get_image_used() for both RO and RW images.
BRANCH=None
Change-Id: I7b8dc3ac8cf2df3184d0701a0e0ec8032de8d81b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450858
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
All boards have been transitioned to charge_state_v2.c
So charge_state_v1.c, HOOK_CHARGE_STATE_CHANGE, and
CONFIG_CHARGER_TIMEOUT_HOURS can be removed
BUG=chrome-os-partner:36272
TEST=make -j buildall
BRANCH=none
Change-Id: I3f20c5198ea75185f9894deb792575a1be31432a
Reviewed-on: https://chromium-review.googlesource.com/435467
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Image used size is now part of the image_data struct present in all
images at a fixed offset, so use it rather than scanning from the end of
the image.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that system_get_image_used() returns
the same value as the old implementation, for both RO and RW images.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ic8db5c706d82f7ca2ded2e90129747e7fbefdb38
Reviewed-on: https://chromium-review.googlesource.com/427959
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Store our image size (known at build time) in our version struct (now
renamed to image_data). This will allow us to more efficiently determine
the size of an image in a follow-up CL.
Note that compatibility is broken for old ROs that do not include this
CL.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that stored image size matches
output of system_get_image_used() for both RO and RW images.
BRANCH=None
Change-Id: I49ea5fc27a7f11f66daba485a87d0dfe7d0c770f
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/427408
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Use binary search in host command lookup dispatcher
BUG=chromium:570895
TEST=manual testing on kevin
- Kevin boots
- ectool hello
make buildall -j
Verify *.smap hcmds section is sorted:
BOARD with host commands and private host commands
0004d0ec R __hcmds
0004d0ec R __host_cmd_0x00000x0000
0004d0f8 R __host_cmd_0x00000x0001
0004d104 R __host_cmd_0x00000x0002
0004d110 R __host_cmd_0x00000x0003
0004d11c R __host_cmd_0x00000x0004
0004d128 R __host_cmd_0x00000x0005
0004d134 R __host_cmd_0x00000x0007
0004d140 R __host_cmd_0x00000x0008
0004d14c R __host_cmd_0x00000x000a
0004d158 R __host_cmd_0x00000x000d
0004d164 R __host_cmd_0x00000x0010
0004d170 R __host_cmd_0x00000x0011
0004d17c R __host_cmd_0x00000x0012
0004d188 R __host_cmd_0x00000x0013
0004d194 R __host_cmd_0x00000x0015
0004d1a0 R __host_cmd_0x00000x0016
0004d1ac R __host_cmd_0x00000x0017
0004d1b8 R __host_cmd_0x00000x0087
0004d1c4 R __host_cmd_0x00000x008c
0004d1d0 R __host_cmd_0x00000x008f
0004d1dc R __host_cmd_0x00000x0092
0004d1e8 R __host_cmd_0x00000x0093
0004d1f4 R __host_cmd_0x00000x0097
0004d200 R __host_cmd_0x00000x0098
0004d20c R __host_cmd_0x00000x00b6
0004d218 R __host_cmd_0x00000x00d2
0004d224 R __host_cmd_0x00000x00d3
0004d230 R __host_cmd_0x3E000x0000
0004d23c R __host_cmd_0x3E000x0002
0004d248 R __evt_src_EC_MKBP_EVENT_HOST_EVENT
0004d248 R __hcmds_end
BOARD with host commands only
100bc888 R __hcmds
100bc888 R __host_cmd_0x00000x0000
100bc894 R __host_cmd_0x00000x0001
100bc8a0 R __host_cmd_0x00000x0002
100bc8ac R __host_cmd_0x00000x0003
100bc8b8 R __host_cmd_0x00000x0004
100bc8c4 R __host_cmd_0x00000x0005
100bc8d0 R __host_cmd_0x00000x0006
100bc8dc R __host_cmd_0x00000x0007
100bc8e8 R __host_cmd_0x00000x0008
100bc8f4 R __host_cmd_0x00000x0009
100bc900 R __host_cmd_0x00000x000a
100bc90c R __host_cmd_0x00000x000b
100bc918 R __host_cmd_0x00000x000d
100bc924 R __host_cmd_0x00000x0010
100bc930 R __host_cmd_0x00000x0011
100bc93c R __host_cmd_0x00000x0012
100bc948 R __host_cmd_0x00000x0013
100bc954 R __host_cmd_0x00000x0015
100bc960 R __host_cmd_0x00000x0016
100bc96c R __host_cmd_0x00000x0017
100bc978 R __host_cmd_0x00000x0025
100bc984 R __host_cmd_0x00000x0026
100bc990 R __host_cmd_0x00000x0029
100bc99c R __host_cmd_0x00000x002a
100bc9a8 R __host_cmd_0x00000x002b
100bc9b4 R __host_cmd_0x00000x002c
100bc9c0 R __host_cmd_0x00000x0044
100bc9cc R __host_cmd_0x00000x0045
100bc9d8 R __host_cmd_0x00000x0046
100bc9e4 R __host_cmd_0x00000x0047
100bc9f0 R __host_cmd_0x00000x0061
100bc9fc R __host_cmd_0x00000x0062
100bca08 R __host_cmd_0x00000x0064
100bca14 R __host_cmd_0x00000x0065
100bca20 R __host_cmd_0x00000x0067
100bca2c R __host_cmd_0x00000x0087
100bca38 R __host_cmd_0x00000x008c
100bca44 R __host_cmd_0x00000x008d
100bca50 R __host_cmd_0x00000x008f
100bca5c R __host_cmd_0x00000x0092
100bca68 R __host_cmd_0x00000x0093
100bca74 R __host_cmd_0x00000x0096
100bca80 R __host_cmd_0x00000x0097
100bca8c R __host_cmd_0x00000x0098
100bca98 R __host_cmd_0x00000x0099
100bcaa4 R __host_cmd_0x00000x009e
100bcab0 R __host_cmd_0x00000x00a0
100bcabc R __host_cmd_0x00000x00a1
100bcac8 R __host_cmd_0x00000x00a8
100bcad4 R __host_cmd_0x00000x00a9
100bcae0 R __host_cmd_0x00000x00b6
100bcaec R __host_cmd_0x00000x00b7
100bcaf8 R __host_cmd_0x00000x00d2
100bcb04 R __host_cmd_0x00000x00d3
100bcb10 R __host_cmd_0x00000x00db
100bcb1c R __host_cmd_0x00000x0101
100bcb28 R __host_cmd_0x00000x0102
100bcb34 R __host_cmd_0x00000x0103
100bcb40 R __host_cmd_0x00000x0104
100bcb4c R __host_cmd_0x00000x0110
100bcb58 R __host_cmd_0x00000x0111
100bcb64 R __host_cmd_0x00000x0112
100bcb70 R __host_cmd_0x00000x0113
100bcb7c R __host_cmd_0x00000x0114
100bcb88 R __host_cmd_0x00000x0115
100bcb94 R __host_cmd_0x00000x0116
100bcba0 R __host_cmd_0x00000x0117
100bcbac R __host_cmd_0x00000x0118
100bcbb8 R __host_cmd_0x00000x011a
100bcbc4 R __evt_src_EC_MKBP_EVENT_KEY_MATRIX
100bcbc4 R __hcmds_end
BRANCH=none
Change-Id: I5d13d2a7fe7fa9a0fbeed43177cc612f572a58bb
Reviewed-on: https://chromium-review.googlesource.com/419702
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
If there's a task switching occurred between loading waiter and
unlocking the lock, the task with higher priority won't wake up since
the local variable, waiter, doesn't contain its ID bit before task
switching. In this situation, the higher priority task only can be
awakened when the other tasks execute mutex_unlock() again.
But consider the following conditions: (For example, the driver of
charger bd9995x.)
1. There are more than one mutex for the usage path of i2c port.
2. There are more than one task access this usage path of i2c port and
one of these tasks, task A, met the situation above.
3. The other tasks have no chance to execute mutex_unlock() of i2c since
the task A still occupied the mutex of charger.
All the tasks used the same i2c port or the other hardware will sleep
forever. This CL makes loading waiter and unlocking the lock as atomic
to solve this issue.
BRANCH=none
BUG=chrome-os-partner:60617
TEST=make BOARD=snappy; make BOARD=oak; Executed charger factory test on
4 units of snappy for 3 days and no symptom occurred.
Change-Id: Id976fc47955b33ca83bb2182b197d9f2781c341b
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/423285
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This reverts commit c459c8278e
as the fix is not straightforwad, some host command codes in
private repos are expressed using C preprecessor which
breaks the assumption of this patch that all host commands
are expressed as four digit hex numbers.
Change-Id: I922de9ae8dbab6eef048463c5c09b1f338152083
Reviewed-on: https://chromium-review.googlesource.com/414492
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Use binary search in host command lookup dispatcher
BUG=chrome-os-partner:570895
TEST=manual testing on kevin
- Kevin boots
- ectool hello
make buildall -j
Verify *.smap hcmds section is sorted:
100bca94 R __hcmds
100bca94 R __host_cmd_0x0000
100bcaa0 R __host_cmd_0x0001
100bcaac R __host_cmd_0x0002
100bcab8 R __host_cmd_0x0003
100bcac4 R __host_cmd_0x0004
100bcad0 R __host_cmd_0x0005
100bcadc R __host_cmd_0x0006
100bcae8 R __host_cmd_0x0007
100bcaf4 R __host_cmd_0x0008
100bcb00 R __host_cmd_0x0009
100bcb0c R __host_cmd_0x000a
100bcb18 R __host_cmd_0x000b
100bcb24 R __host_cmd_0x000d
100bcb30 R __host_cmd_0x0010
100bcb3c R __host_cmd_0x0011
100bcb48 R __host_cmd_0x0012
100bcb54 R __host_cmd_0x0013
100bcb60 R __host_cmd_0x0015
100bcb6c R __host_cmd_0x0016
100bcb78 R __host_cmd_0x0017
100bcb84 R __host_cmd_0x0025
100bcb90 R __host_cmd_0x0026
100bcb9c R __host_cmd_0x0029
100bcba8 R __host_cmd_0x002a
100bcbb4 R __host_cmd_0x002b
100bcbc0 R __host_cmd_0x002c
100bcbcc R __host_cmd_0x0044
100bcbd8 R __host_cmd_0x0045
100bcbe4 R __host_cmd_0x0046
100bcbf0 R __host_cmd_0x0047
100bcbfc R __host_cmd_0x0061
100bcc08 R __host_cmd_0x0062
100bcc14 R __host_cmd_0x0064
100bcc20 R __host_cmd_0x0065
100bcc2c R __host_cmd_0x0067
100bcc38 R __host_cmd_0x0087
100bcc44 R __host_cmd_0x008c
100bcc50 R __host_cmd_0x008d
100bcc5c R __host_cmd_0x008f
100bcc68 R __host_cmd_0x0092
100bcc74 R __host_cmd_0x0093
100bcc80 R __host_cmd_0x0096
100bcc8c R __host_cmd_0x0097
100bcc98 R __host_cmd_0x0098
100bcca4 R __host_cmd_0x0099
100bccb0 R __host_cmd_0x009e
100bccbc R __host_cmd_0x00a0
100bccc8 R __host_cmd_0x00a1
100bccd4 R __host_cmd_0x00a8
100bcce0 R __host_cmd_0x00a9
100bccec R __host_cmd_0x00b6
100bccf8 R __host_cmd_0x00b7
100bcd04 R __host_cmd_0x00d2
100bcd10 R __host_cmd_0x00d3
100bcd1c R __host_cmd_0x00db
100bcd28 R __host_cmd_0x0101
100bcd34 R __host_cmd_0x0102
100bcd40 R __host_cmd_0x0103
100bcd4c R __host_cmd_0x0104
100bcd58 R __host_cmd_0x0110
100bcd64 R __host_cmd_0x0111
100bcd70 R __host_cmd_0x0112
100bcd7c R __host_cmd_0x0113
100bcd88 R __host_cmd_0x0114
100bcd94 R __host_cmd_0x0115
100bcda0 R __host_cmd_0x0116
100bcdac R __host_cmd_0x0117
100bcdb8 R __host_cmd_0x0118
100bcdc4 R __host_cmd_0x011a
100bcdd0 R __evt_src_EC_MKBP_EVENT_KEY_MATRIX
100bcdd0 R __hcmds_end
BRANCH=none
Change-Id: Ideb9951b318763f71915e2c4e5052f4b4bfab173
Reviewed-on: https://chromium-review.googlesource.com/405528
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In __wait_evt(), if a timer expiration occurs after we read event
status, before the timer is canceled, then TASK_EVENT_TIMER will be
propagated to the next task wait, likely leading to premature timeout.
Prevent this by clearing TASK_EVENT_TIMER after canceling our timer.
BUG=chrome-os-partner:58658
BRANCH=gru
TEST=Manual on gru, run 'pd # hard' for 12 hours with charger attached,
verify no TCPC I2C read errors occur.
Change-Id: Iac2f05a768b4ef29f82e7c3eb899f4c7dd5c3744
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400968
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
To reset the TPM task, we send it an event so that it will reset
only when it's not busy doing actual TPM stuff that might fiddle
with the stack or shared memory. But that means that we can't
always know when the task finally gets around to resetting
itself.
This CL adds a tpm_reset() function that blocks until the reset
actually occurs. Obviously it can't do that if it's being called
in interrupt context or from the TPM task itself, but otherwise
it does.
BUG=chrome-os-partner:52366
BRANCH=none
CQ-DEPEND=CL:361680
TEST=make buildall, test on Gru, manual tests
In addition to the normal rebooting, logging in/out, and so
forth. I added a temporary console command to call tpm_reset()
and scattered a bunch of ccprintfs around it. When called due to
SYS_RST_L, it didn't block. When invoked with the console
command, it did.
Change-Id: I51e8b1299dbdcd1a12273cf48a890e93ed32a8c8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388125
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Rather than doing a full cr50 reset when the system reset SYS_RST_L is
asserted, just reset the state of the TPM task and library. Re-clear
.bss for those modules, then re-initialize.
BRANCH=none
BUG=chrome-os-partner:52366
CQ-DEPEND=CL:366792
TEST=make buildall; test on Gru
Trigger a SYS_RST_L by using the AP's reboot command, power
off/on, log in/out/in.
See that the Cr50 does not reboot and the firmware and userspace
are still happy about the TPM.
Change-Id: I32cd2bb72316f68c74db77a20a8d09112b402d4b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361680
We found the api utility in ROM doesn't enable burst mode of GDMA. It
influences the performance of FW download a lot. The CL modified GDMA
for moving the code of the other region from flash to ram. And move a
function that kicks off GMDA transactions to suspend ram in case this
utility is erased by itself. This issue will be fixed in our next
generation.
Modified sources:
1. system.c: Implement GDMA bypass.
2. system_chip.h: Import flash addresses for GDMA bypass code.
3. registers.h: Add GDMA register definitions.
4. cortex-m/ec.lds.S: Add lowpower_ram2 section in linker script.
BRANCH=none
BUG=chrome-os-partner:56794
TEST=make BOARD=npcx_evb; test sysjump and measure download time
Change-Id: I8490f8f2e5a8cdcb6fd10511878c4a4af8073bbf
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/381779
Commit-Ready: Shawn N <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a hook to act when the a device is going in tablet mode and back.
BUG=chromium:606718
BRANCH=kevin
TEST=Test with evtest that an event is sent to the AP.
Change-Id: Ic9c3b158f1178504af41abff18b28de8e07fc7a7
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/380412
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Even when CONFIG_RESTRICTED_CONSOLE_COMMANDS is enabled, there
are many commands that can't do anything dangerous. This marks
some of those commands as safe to use, even when restrictions are
enforced.
I'm only marking commands that are used by the Cr50, since that's
the only board that has restrictions.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall, test on Cr50 hardware
Change-Id: I6289d332830175b6adcb6b20cb4c21d01d27a25e
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376188
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Since pretty much always, we've declared console commands to take
a "longhelp" argument with detailed explanations of what the
command does. But since almost as long, we've never actually used
that argument for anything - we just silently throw it away in
the macro. There's only one command (usbchargemode) that even
thinks it defines that argument.
We're never going to use this, let's just get rid of it.
BUG=none
BRANCH=none
CQ-DEPEND=CL:*279060
CQ-DEPEND=CL:*279158
CQ-DEPEND=CL:*279037
TEST=make buildall; tested on Cr50 hardware
Everything builds. Since we never used this arg anyway, there had
better not be any difference in the result.
Change-Id: Id3f71a53d02e3dc625cfcc12aa71ecb50e35eb9f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374163
Reviewed-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add __keep attribute to irqprio entries to ensure they are not dropped
when CONFIG_LTO is enabled.
BUG=chrome-os-partner:55920
BRANCH=None
TEST=Manual on kevin. Check build/RO/ec.RO.map, verify that
.rodata.irqprio section is not empty.
Change-Id: I51ae23556d6f46b2cd7ba098f0e7a785292b2853
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366571
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
cts.tasklist contains tasks run only for CTS. These tasks are added to the
tasks registered in ec.tasklist with higher priority. This design allows
board directories to be free from CTS stuff.
cts.tasklist can be placed in each suite directory (cts/suite/cts.tasklist).
If a suite does not define its own cts.tasklist, the common list is used
(i.e. cts/cts.tasklist).
BUG=chromium:624520
BRANCH=none
TEST=Ran the followings:
make buildall
make CTS_MODULE=gpio BOARD=nucleo-f072rb
make CTS_MODULE=gpio BOARD=stm32l476g-eval
Change-Id: Ibb242297ee10a397a8fcb6ff73d8cbc560daa885
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359445
Reviewed-by: Chris Chen <twothreecc@google.com>
Previously the maximum number of deferred routines was specified by the
the default maximum number of deferred routines you had to override
this, and if you wanted fewer, you still payed the price of having the
defer_until array statically allocated to be the maximum size.
This change removes that define and instead creates the RAM state of
the deferred routine (the time to wait until to call the deferred) when
the deferred is declared.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
manually test on discovery-stm32f072
Change-Id: Id3db84ee1795226b7818c57f68c1f637567831dc
Reviewed-on: https://chromium-review.googlesource.com/335597
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
If OUTDIR brings in a "@", the build breaks because that delimits the
path, leading to invalid file names.
This can happen (and happened) when building on a Jenkins CI instance
which uses jobname@number as path for parallel checkouts on a
single build node.
BRANCH=none
BUG=none
TEST=build with make out=foo@bar ... failed and works now.
Change-Id: Id0594f0d7312419110091443755ec11b5f8ee2d8
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/327110
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Martin Roth <martinroth@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>
There are hooks for chipset power sequencing but not one to indicate
that the system has reset at runtime. Add a hook for this and
implement for lm4 and mec1322. The hook is notified on any platform
reset, including those that happen on the way into S3/S5 state.
There is a new config variable added because the hook is notified in
the interrupt handler and needs a deferrable function that needs to
be added to every board.
BUG=chrome-os-partner:46049
BRANCH=none
TEST=tested on glados and samus
Change-Id: I3be639414e18586344e0ec84632a50dfc1df586b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/315221
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
A typical EC image includes two similar in their functionality
subsections, RO and RW. CR50 has a small RO subsection, all it does -
detects a proper RW image to run and starts it up. To provide for
reliable firmware updates, the CR50 image needs to include two RW
sections, while the code is running from one RW subsection, the other
one can be upgraded.
This patch adds the ability to generate two identical RW sections,
mapped half flash size apart, and include them into the resulting EC
image.
To keep things simple the previously existing RW section's name is not
being changed, while the new (identical) RW section is named RW_B.
Two configuration options need to be defined to enable building of the
new image type: CONFIG_RW_B to enable the feature and
CONFIG_RW_B_MEM_OFF to define where RW_B should be mapped into the
flash.
A new rule added to Makefile.rules allows to generate a different lds
file from the same source (core/cortex-m/ec.lds.S) by defining a
compile time variable to pick a different base address for the
rewritable section, when RW_B is built.
BRANCH=none
BUG=chromium:43025
TEST=as follows:
- make buildall -j still succeeds
- verified that regular CR50 image starts successfully
- modified chip/g/loader/main.c to launch RW_B first, re-built and
re-run the image, observed on the console:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
cr50 bootloader, 20151118_11218@80881, no USB, full crypto
Valid image found at 0x00084000, jumping
--- UART initialized after reboot ---
[Reset cause: power-on]
[Image: unknown, cr50_v1.1.4160-4c8a789-dirty 2015-12-07 18:54:27 vbendeb@eskimo.mtv.corp.google.com]
[0.001148 Inits done]
This FPGA image has no USB support
Console is enabled; type HELP for help.
> [0.002212 task 2 waiting for events...]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(note that the image base address is 0x840000, which is RW_B).
Change-Id: Ia2f90d5e5b7a9f252ea3ecf3ff5babfad8a97444
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/316703
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch introduces a facility which would allow to compile in
callbacks for arbitrary commands passed over various communication
protocols.
Typically this will be used for testing, when various test commands
are multiplexed over an existing protocol.
The callbacks are associated with 16 bit command codes. On input the
callback receives a buffer, containing the command's argument, the
size of the command argument and the maximum size of the buffer. On
output the callback stores processing result in the same buffer and
updates the size to the actual amount of returned data.
Callback descriptors are stored in a dedicated read only section which
is scanned by extension_route_command() to find a callback associated
with a certain command code.
A console channel is also being introduced to allow controlling
console output generated by extension commands handlers.
BRANCH=none
BUG=chrome-os-partner:47524
TEST=none yet
Change-Id: I8ae16a78ca7d72176a5e7f74dd7a232078e7c06c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312586
Reviewed-by: Randall Spangler <rspangler@chromium.org>
With the proper RO in place, RW must be signed in the same manner, as
RO. This patch makes sure that there is room in the RW header for the
signature.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=with the rest of the patches applies the RO successfully boots up
the RW.
Change-Id: I1538195e0181c23c874ddd300887cf5da8c5a867
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311421
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The point at which we reloaded the loader was too early. When items are
placed into .bss.slow via CONFIG_REPLACE_LOADER_WITH_BSS_SLOW, other
tasks could still access their variables that may have been in that
region after we had replaced those contents with the loader. This
commit moves the reloading of the loader to as late as possible once all
tasks have done their HOOK_SYSJUMP work.
Also, fixed a bug with the .bss.slow section. If a board is not using
the config option but items are placed in that section, that part of RAM
would not be cleared out.
BUG=chrome-os-partner:46056
BRANCH=None
TEST=Enable config option on GLaDOS and add a few variables to the
.bss.slow section. 'sysjump' between RO and RW and verify that no data
bus error is encountered.
TEST=make -j buildall tests
Change-Id: I3084700b9d5c144e86e2e408b72d2e3075a67413
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/306173
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Certain ECs which cannot load both the RO and RW images into memory
simultaneously have a little firmware (LFW) loader that is loaded into
the beginning of the program memory. This loader is responsible for
loading the RO/RW images, however once we begin executing code from
main(), the loader has already completed it's purpose. We can reuse
this space by allocating portions of the .bss section here. This
currently saves us 3k for mec1322. This section is .bss.slow.
To use this feature simply define the following config option in
board.h.
#define CONFIG_REPLACE_LOADER_WITH_BSS_SLOW
In some cases, such as the mec1322, this region of RAM is optimized for
code and not data. Therefore, ideally infrequently used data should go
into this region.
BUG=chrome-os-partner:46056
BUG=chrome-os-partner:46063
BRANCH=None
TEST=Flash GLaDOS; sysjump rw; Verify that we are in rw; sysjump ro;
Verify we are back in ro.
TEST=Build GLaDOS, check output memory map for LDR_REGION and .bss.slow
section.
TEST=make -j buildall tests
Change-Id: I5b95cacc211278cf780a857b5a2ecfc1a0a28c45
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/305254
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Code for hard iron calibration: Every seconds (or faster if enough
samples), find a sphere that fit the compass data.
Based on Android code.
BRANCH=smaug
BUG=chrome-os-partner:39900
TEST=Check hard-iron bias is removed. Works better outside.
Change-Id: Iab479d5113b6560b4f01b0fd87373d2eecdb9b54
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/299583
Reviewed-by: Anton Staaf <robotboy@chromium.org>
For signed EC RW images (CONFIG_RWSIG), there's no point in
embedding the public key or signature into the image itself since
it will just be replaced by the signer (either as the next step
in the build process, or after the fact for MP releases). This
takes that out and just points to where the pubkey and signature
will be placed.
BUG=none
BRANCH=none
TEST=make buildall
I also checked the signatures with
futility show -t build/*/ec.bin
They still look good, and the one signed image I booted (Cr50)
works as before.
Change-Id: Ib39b7c508914851f81a1bebb2450e08ef0def76c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302630
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Since CONFIG_RO_SIZE and CONFIG_RW_SIZE now exist (which may
theoretically be different sizes), it is no longer useful to globally
define the size of an image.
BUG=chromium:535027
BRANCH=None
TEST=`make buildall -j`. Also, verify glados / glados_pd continue to
function as expected.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ie29959923bc5d02b4d7d6d507ff2191bcb7d24c8
Reviewed-on: https://chromium-review.googlesource.com/301743
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The board-specific board.h defines things like this:
#define CONFIG_RO_SIZE 1000
#define CONFIG_RW_SIZE 1000
#define CONFIG_SHAREDLIB_SIZE 200
And in the linker scripts we define some preprocessor macros like
so:
#define FW_SIZE_(section) CONFIG_##section##_SIZE
#define FW_SIZE(section) FW_SIZE_(section)
So that we can say things like this:
FLASH (rx) : ORIGIN = FW_OFF(SECTION), LENGTH = FW_SIZE(SECTION)
Note that we have to use FW_SIZE, not FW_SIZE_
The difference is only noticeable when SECTION is #defined. If
${CFLAGS} has
-DSECTION=RW
Then the expansion is this:
FW_SIZE_(SECTION) => CONFIG_SECTION_SIZE
FW_SIZE_(RW) => 1000
There's no difference in the output for this particular CL, but
we should use the correct macro anyway to avoid confusion.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: I61edc76a1aaeb1c675b384371700f37dda39ed47
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302150
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Returns the most significant bit set.
Replace 31 - __builtin_clz(x), so x must be different from 0.
Use get_next_bit when not on the performance path,
on performance path set the bit field just after reading it.
BRANCH=smaug
BUG=none
TEST=compile, check Ryu still works.
Change-Id: Ie1a4cda4188f45b4bf92d0549d5c8fb401a30e5d
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/301300
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>
When we add head room to the RO image, it's generally to provide
a chip-specific boot header of some sort. That header is only
needed for the RO image, not the RW image. The macro name implies
this, but this CL makes it so.
BRANCH=none
BUG=chrome-os-partner:43025, chrome-os-partner:44625
TEST=the cr50 image validates *and jumps to* the RW image at boot.
Change-Id: I0e5b2c32e232418970e01c7409ddcbbabd4786d5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/296451
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Some platforms might expect the header of the image to be a certain
platform specific blob. This patch adds an ability to insert an
arbitrary size header in the binary blob, if so desired, the intention
is to have the platform specific tools to postprocess the image and
replace the header with sensible data.
Ideally we should be able to produce an image which is mapped to start
at an offset to the FLASH_BASE, but the macros in ec.S.lds files are
way too smart for this.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=with this and other changes the latest cr50 image gets signed and
booted properly.
Change-Id: Icabf00c6b90657b0ae3370ddad3567ccedf3ff49
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295200
Reviewed-by: Shawn N <shawnn@chromium.org>
