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>
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>
On mutex contention, call task_wait_event_mask(), which will wait for
a mutex event without clearing other pending events.
BUG=chrome-os-partner:47918,chromium:435611,chromium:435612
BRANCH=None
TEST=Manual on snoball. Verify samus can successfully negotiate PD power
contract when attached to snoball.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I85cd32f2670246da9e4787025390aba2c93f9c36
Reviewed-on: https://chromium-review.googlesource.com/314492
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@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>
The .bss.slow input section needs to be included before __bss_end,
otherwise it won't get cleared to zero.
BUG=None
BRANCH=None
TEST=Build jerry. Verify that __bss_end is at the end of the .bss.slow
section.
TEST=make -j buildall tests
Change-Id: I41d028ee166d05b34a889499cdcb0254341be1b6
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/312404
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
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
One more register constaint needed to be added to the cortex-m0 atomic
inline assembly. Vincent fixed all the others. The requirement for
ARMv6-m includes that the target load register be one of the low
registers as well.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: Ie44e824cafcc9b862ade664e3016cc34886cdf6e
Reviewed-on: https://chromium-review.googlesource.com/292435
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
The atomic_* functions are often used in contexts where the data they
will operate on are volatile (due to being shared between tasks or a
task and an interrupt handler). Adding volatile here makes using the
atomic_* functions a little easier in those cases and removes a cast
from the call sites (which could be obscuring a bug, if for instance
the variable was modified to be a uint16_t).
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I71356eb3cf2c0506df38532eee767c7d78f9240e
Reviewed-on: https://chromium-review.googlesource.com/287516
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
This commit introduces the build infrastructure changes needed for
creating a shared RO library. (libsharedobjs). The end goal is for the
library to contain various objects that can be shared with both the RO
and RW EC images.
Now, there are 3 make goals: ro, rw, and libsharedobjs.
In order for changes that are only specific to a single image (ie: RW
only) to be applied correctly, the object files are now built separately
for the RO, RW, shared objects library targets.
NOTE: Certain EC targets are incompatible with this model due to the
fact that only one image is present within flash at a time.
BRANCH=none
BUG=None
TEST=make -j buildall tests
TEST=make -j BOARD=cr50 xrefs
TEST=make BOARD=samus dis
TEST=Built samus EC image and compared that the final EC image was
identical to the upstream version (except for the git SHAs & version
strings).
CQ-DEPEND=CL:285934
Change-Id: I8e67f089710be9c6d7017718109262394bdad2f5
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/274079
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
This commit changes the way in which tasks are started. Instead of
having all tasks marked as ready to run upon initialization, only the
hooks task is marked as ready to run. HOOK_INITs are now run at the
beginning of the hooks task. After the HOOK_INITs, the hooks task calls
back to enable the rest of the tasks, reschedules, and proceeds as
usual. This also allows the removal of checks for task_start_called().
BUG=chrome-os-partner:27226
BRANCH=None
TEST=Built and flash EC image for samus and verified that EC boot was
successful as well as AP boot. Additionally, verified that charging,
keyboard, tap-for-battery were all still functional.
TEST=make -j buildall tests
Change-Id: Iea53670222c803c2985e9c86c96974386888a4fe
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/283657
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
This unifies all the EC header files to use __CROS_EC_FILENAME_H
as the include guard. Well, except for test/ util/ and extra/
which use __TEST_ __UTIL_ and __EXTRA_ prefixes respectively.
BUG=chromium:496895
BRANCH=none
TEST=make buildall -j
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Iea71b3a08bdec94a11239de810a2b2e152b15029
Reviewed-on: https://chromium-review.googlesource.com/278121
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If task_get_current() is called early during initialization when we have
not yet done a context switch, our current_task pointer is invalid. Add
an assert to detect this case and put it behind CONFIG_DEBUG_BRINGUP, a
new config that's intended to enable possibly-costly pre-production
debugging.
BUG=chrome-os-partner:40677
TEST=Manual on glados. Define CONFIG_DEBUG_BRINGUP, then call i2c_write from
board_init and verify the new assert fails. Remove the i2c_write and verify
the new assert passes.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6014ccf739dcc4c8f4f960be2b89f01e423b65b5
Reviewed-on: https://chromium-review.googlesource.com/273541
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add task_wait_event_mask() function to core/cortex-m0, core/host
and board/zinger/runtime in order to delay a task until a specific
event occurs.
BUG=none
BRANCH=smaug
TEST=make -j buildall
Change-Id: Ic89487fcae5352eec53b745179c7f0d5893ad3e0
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/276744
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Our USB buffers are just arrays of uint8_t in program RAM, so
let's treat them that way. The DMA descriptors are in normal RAM,
too.
BUG=chrome-os-partner:40693
BRANCH=none
TEST=make buildall
Change-Id: Ibafe1a557a328bbf8cf37ce113675fcd35bad376
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/273918
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add CONFIG_LTO to use GCC Link-Time Optimizations to try to reduce the
flash footprint of the firmware.
Add additional protection to some functions/data to avoid removal by the
linker when their usage is not obvious.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall (with and without LTO enable on all boards)
Change-Id: I586b8c1eda4592b416c85383b65153c1d5ab0059
Reviewed-on: https://chromium-review.googlesource.com/271291
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Rename image geometry configs with a uniform naming scheme to make their
purposes more clear.
CONFIG_RO_MEM_OFF (was CONFIG_FW_RO_OFF) - RO image offset in program memory
CONFIG_RO_STORAGE_OFF (was CONFIG_RO_SPI_OFF) - RO image offset on storage
CONFIG_RO_SIZE (was CONFIG_FW_RO_SIZE) - Size of RO image
CONFIG_RW_MEM_OFF (was CONFIG_FW_RW_OFF) - RW image offset in program memory
CONFIG_RW_STORAGE_OFF (was CONFIG_RW_SPI_OFF) - RW image offset on storage
CONFIG_RW_SIZE (was CONFIG_FW_RW_SIZE) - Size of RW image
CONFIG_WP_OFF (was CONFIG_FW_WP_RO_OFF) - Offset of WP region on storage
CONFIG_WP_SIZE (was CONFIG_FW_WP_RO_SIZE) - Size of WP region on storage
BUG=chrome-os-partner:39741,chrome-os-partner:23796
TEST=Set date / version strings to constants then `make buildall -j`.
Verify that each ec.bin image is identical pre- and post-change.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6ea0a4e456dae71c266fa917a309b9f6fa4b50cd
Reviewed-on: https://chromium-review.googlesource.com/270189
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Currently, ECs with internal flash store the write protect state for
RO in a separate write/erase block of flash. This is wasteful on
chips where there are not many blocks of flash.
Add a new CONFIG_FLASH_PSTATE_IN_BANK option which is defined by
default. This is the old behavior, for compatibility. (And we're
calling it 'bank' because that's what the existing code does, even if
the terminology is somewhat etymologically... bankrupt.)
If that config is #undef'd, then store the write protect flag directly
inside the RO image. This uses only 4 bytes of the RO image, instead
of an entire erase block. The magic numbers for the pstate values are
chosen such that when protecting RO, bits are only transitioned away
from their erased state. Unprotecting RO once it's protected requires
reflashing RO; it's no longer possible to 'flashwp disable'. But
that's ok, because realistically, the only reason to unprotect RO is
if you're about to flash the RO firmware anyway.
BUG=chromium:476659
BRANCH=none
TEST=Without undefining CONFIG_FLASH_PSTATE_IN_BANK, make sure everything
still works on samus and samus_pd. This ensures we didn't break the
existing functionality:
flashinfo -> no flags
flashwp enable
flashinfo -> ro_at_boot
reboot
flashinfo -> ro_at_boot
flashwp disable
flashinfo -> no flags
Then recompile with #undef CONFIG_FLASH_PSTATE_IN_BANK and test:
flashinfo -> no flags
flashwp enable
flashinfo -> ro_at_boot
reboot
flashinfo -> ro_at_boot
flashwp disable -> fails with access denied
flashinfo -> ro_at_boot
Then reflash to verify that clears the ro_at_boot flag:
flashinfo -> no flags
Change-Id: Ie794b8cfed2a10c50b0e36dcf185884070b04666
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266095
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
On hard reset / hibernate, RAM will be erased and panic data will
normally be lost. When software panic data saving is enabled, try to
save this data just before hard reset and restore it when we come back
up.
BUG=chrome-os-partner:37380
TEST=Manual on Samus with WP + SW sync enabled. Boot AP, then run "crash
divzero" on console. After hard reset, verify that "panicinfo" dumps
data and shows divzero exception code.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9516dd4b6db12ef35e512cc4710f9b97d7e663cb
Reviewed-on: https://chromium-review.googlesource.com/255912
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We put each assembly function in its own section. So the sections for
64-bit signed and unsigned divide end up too far apart for b<cond>
(8-bit delta) or b (11-bit delta). Instead, use bl, which has no such
limit. This is a little less efficient in the case where numerator
and denominator are both positive, but equivalent if either or both is
negative, and is far outweighed by the cost of the unsigned divide
itself.
The other alternative would be to put both uldivmod and ldivmod in the
same section. However, we're often tight on code size on cortex-M0
parts, so that's less desirable.
BUG=chrome-os-partner:26126
BRANCH=minnie
TEST=add the following function
static int command_divtest(int argc, char **argv)
{
int64_t a, b, c;
char *e;
if (argc < 2)
return EC_ERROR_PARAM_COUNT;
a = strtoi(argv[1], &e, 0);
b = strtoi(argv[2], &e, 0);
c = a / b;
ccprintf("%d / %d = %d\n", (int)a, (int)b, (int)c);
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(dt, command_divtest,
"a b",
"Divide test",
NULL);
and test with divides in all 4 quadrants (+/- 20 divided by +/- 5,
for example)
Change-Id: I2a5e49c4534044c2f509e325f8dd6bdf10b544c4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252243
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Make non-exception "software" panics such as stack overflow and assert
failure save a panic log. Log the panic type in r4, and misc. panic data
in r5 so that panic reasons can be distinguished.
BUG=chrome-os-partner:36744
TEST=Manual on samus_pd. Run 'crash divzero' then 'panicinfo' after
reboot. Verify that panic info is printed with "r4 :dead6660". Trigger
stack overflow, verify that panic info is printed with "r4 :dead6661".
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5f7a8eb0a5c2ac5799d29bb241deb24fabf38f68
Reviewed-on: https://chromium-review.googlesource.com/249912
Tested-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If 2 interrupts happen at the same time, there is a chance that the nested
interrupt will not call svc_handler when it needs to. In extreme cases this
could lead to tasks not getting woken up when they're supposed to and watchdog
resetting.
The reason stuff worked was because there were enough other interrupts
around to eventually call the scheduler and switch to the ready task.
This change modifies the interrupt calls to not call the scheduler directly
(because in nested interrupt situation this causes problems), but defer the
call to scheduling until after the irq finishes by triggering a low priority
interrupt which will for sure call svc_host at the end. The PendSV irq was
used for this purpose.
BUG=chrome-os-partner:36193
TEST=No more SPI errors caused by scheduler problems
TEST=usleeps now are more accurate, they're guaranteed to not take forever now
BRANCH=veyron
Change-Id: I42acde6b3eb7be2540a0de9a8562dee2ea2be7ab
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248902
Tested-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Divide-by-0 was jumping to a missing __aeabi_ldiv0 label. Add it,
equivalent to the cortex-m code.
BUG=chrome-os-partner:36126
BRANCH=minnie
TEST=hack into main():
volatile uint64_t a = 1, b = 2;
a /= b;
and see that code compiles.
Change-Id: I93884c6e41c8a3c5f47c141c323860efbfbc9ba9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248640
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
These are needed for fixed-point math calculations.
Taken from the same public repo where we got the 32-bit divide
routines for Cortex-M0. With minor modifications to match changes
we've made so far for the existing divide routines (put each function
in its own section, delete dead code, etc.)
BUG=chrome-os-partner:36126
BRANCH=minnie
TEST=hack in a debug console command to allow arbitrary int64 divide, see that
it works as expected
Change-Id: I987dbca7c806c71bc38fa816971ac3a54c1641a5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244501
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add hook for battery state of charge change. Hook will be used
to cleanup the samus charging workarounds to follow.
BUG=none
BRANCH=samus
TEST=make -j buildall
Change-Id: I99cbb8264783802139cac689804b056623063695
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245252
Reviewed-by: Shawn N <shawnn@chromium.org>
Put each assembly helper function in its own .text.__funcname__ section,
so the linker can remove the unused ones.
Also remove a few entrypoints used only by deprecated ABIs.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=make buildall
check the firmware size and see we are saving 88 bytes on Zinger.
Change-Id: I6714da671c3449220652780d47993d6c919c331c
Reviewed-on: https://chromium-review.googlesource.com/240582
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
We actually need to care about x, the PRI register is actually a list of
registers (and we have code that uses some of the later ones).
BUG=None, discovered while chrome-os-partner:33451
TEST=Change priorities of irqs(like UART over GPIO(spi_event)), note how they
actually work and override each other as told
BRANCH=None
Change-Id: I9f5bf7ba9d4211f782ff260fbce17deb7c53a31f
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236087
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Cortex-m0 we supports 2 bit priorities for the NVIC, yet we clear with 0x7 (3
bits). Change so we now clear with 0x3
Also limited priority to the max available (so we don't set extra bits we don't
want or modulus the priority, otherwise setting priority 8 will actual give you
priority 0) in both cortex-m and cortex-m0.
BUG=None, discovered while looking at the code
TEST=Should be no functional change, NVIC priorities should still work the same.
BRANCH=None
Change-Id: I31ba041449cae96983753b297e2631c310a406c4
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236086
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When another task is holding the lock, mutex_lock() should call
task_wait_event_mask() to wait only for TASK_EVENT_MUTEX events.
If it calls task_wait_event(), any pending events are silently
discarded while its waiting for the the lock.
BUG=chromium:435611
BRANCH=ToT,samus
TEST=make buildall -j, and:
Before this change, I watched the EC console while shutting down
and rebooting Samus. I saw the request event arrive:
[37.576295 LB lightbar_resume() requests 5 S3S0]
[46.055725 LB_version]
But the lightbar task never saw it. Adding a bunch of debug
messages showed that it was being lost in mutex_lock().
After this change, the event is delivered:
[30.167670 LB lightbar_resume() requests 5 S3S0]
[30.171009 LB cur_seq 2 S3 returned pending msg 5 S3S0]
[30.173816 LB running cur_seq 5 S3S0. prev_seq 2 S3]
[32.410073 LB cur_seq 5 S3S0 returned value 0]
[32.410865 LB running cur_seq 3 S0. prev_seq 2 S3]
[39.938388 LB_version]
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I011838538960cc57171f0a3c4cdee113d156e9ff
Reviewed-on: https://chromium-review.googlesource.com/231370
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Allow to use larger RSA keys by setting CONFIG_RSA_KEY_SIZE to 4096 or
8192 rather than using the default 2048-bit size.
It's mainly for benchmarking purpose right now as we don't have the RAM
to store the 3x key size buffer and the flash space for the public key
structure.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=build Zinger with CONFIG_RSA_KEY_SIZE equals to 4096 and run it.
Change-Id: I9839121bf158d0a30dde1e48d875f345191bfec2
Reviewed-on: https://chromium-review.googlesource.com/228925
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Previously the USB RAM size was off by a factor of two
for chips that required 32-bit alignment of accesses,
even though the underlying memory was 16-bits in size.
This change adds an additional configuration for the
access size (it still assumes that the underlying memory
is 16-bits in size) and uses that to adjust the USB_RAM
memory section in the linker scripts.
This change also removes the default values for the USB
RAM from stm32/config_chip.h because they mask issues
when new chips are added. It is better for a new chip
to fail to compile until these values are provided.
Finally, this change introduces a common USB API header
so that common code doesn't need to include the STM32
specific header.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Enable console on ryu_p2 and discovery-stm32f072 board
Verify that it works on both
Change-Id: Id118627f53e9e8ff1bd09fb51f1f9634ff495d19
Reviewed-on: https://chromium-review.googlesource.com/228833
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
This implements a new API for EC modules to define MKBP event sources
and send MKBP event to the AP. Also, a new host command
EC_CMD_GET_NEXT_EVENT is added for the AP to query the pending MKBP
events. Each event type may have custom event data sent along with the
event.
BRANCH=None
BUG=chrome-os-partner:33194
TEST=Enable MKBP event on Ryu. Set a host event from EC console, run
'ectool nextevent', and see MKBP event 0x01 (HOST_EVENT) and the set
host event.
Signed-off-by: Vic Yang <victoryang@chromium.org>
Change-Id: I28a1b7e826bcc102bbe39016c9bb3e37d125664c
Reviewed-on: https://chromium-review.googlesource.com/224905
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We already have interrupt handlers for channel 4 to 7. We need channel 3
for the new Ryu boards. Add the handlers for channel 1 to 3. Also,
instead of copy-pasting interrupt handlers, define a macro and declare
interrupt handlers with it.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=make buildall
TEST=Check PD communication on the new Ryu board (with other CLs to
enable the new boards.)
Change-Id: I51d6bd16739f31a7efbeb4ec19bb91a1546fe21d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224175
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Do not allow rescheduling tasks if task_start() has not been called.
This fixes a bug in which if console input occurs between uart_init()
and task_start(), the MCU crashes because uart_init() enables uart
interrupts which attempts to wake up the console task when RX data
is received, which then tries to task switch before we initialized
task scheduling.
BUG=chrome-os-partner:32561
BRANCH=samus
TEST=add while(1) loop to adc_init() to simulate stalled ADC
initialization. When stalled, send console character and observe
that without this CL MCU crashes, and with this CL the MCU does
not crash.
Change-Id: I34418e88ebe0063acf1cc55ab5a57b5fddcd9d23
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221599
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The Zinger RW is now signed with 2048-bit RSA key (using SHA-256 as
digest).
This CL implements the verification mechanism.
note: the RSA key used for signing must be provided as a .pem file.
The path to .pem file must be provided in the PEM environment variable.
By default, it's using the dev key stored in zinger_dev_key.pem.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:28336
TEST=on Zinger, run with properly signed RW firmware and corrupted
firmware and check the serial traces.
Change-Id: Ia58482458904a3ed72d6b0e95996cae86a0ead83
Reviewed-on: https://chromium-review.googlesource.com/220178
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
'powerindebug' is only used when there is a problem with power
sequencing. 'taskready' is rarely used and the same info can be
retrieved by 'taskinfo'.
Put both behind config flags and disable 'taskready' by default. Also
disable 'powerindebug' for Ryu.
BUG=chrome-os-partner:32203
TEST=Build Ryu and check flash space used.
BRANCH=None
Change-Id: I753a1f5411d6e840a80aba03afc94f9640d381a8
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219490
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Currently, on stm32f cortex-m0 systems, interrupts are always being
directed to the RO vector table. This can cause strange problems when
running RW software because it is still calling IRQ handlers in the RO
code.
Unfortunately, on cortex-m0 the ability to specify the vector table
location in flash (VTOR register) is optional, and stm32f0 parts do not
have it. Instead, in order to run RW IRQ handlers, at init time, this
CL copies the vector table from flash to the base address of SRAM
(0x20000000), and then selects SRAM to be mapped to 0x00000000 where
the core looks to find the vector table.
BUG=none
BRANCH=none
TEST=Tested on zinger.
- Verified that vector table is copied to SRAM by printing out 48 words
from SRAM base address 0x20000000 in main() and verifying that it matches
the vector table in flash in the disassembly.
- Verified the vector table at SRAM 0x20000000 points to the RW handlers
when in RW and the RO handlers when in RO.
- Also printed out PC in one IRQ handler and verified it was in the
appropriate section of code.
Also, ran on samus_pd and did a sysjump RW to make sure at least one other
system works.
Change-Id: I22aff1b5e0de9b23fd3324f0cbe4f6c45a81967e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210063
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Import code to do 64-bit multiplication on Cortex-M0 core without SMULL
instruction.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
add a 64-bit multiplication and see it compiled properly.
verify in .map files that the code is discarded for cortex-M0 based
platforms not using the 64-bit multiplication.
Change-Id: I0a91b3502f4bee4bb79b193fe0854e56a7d498f7
Reviewed-on: https://chromium-review.googlesource.com/207132
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
On panic, reboot properly the CPU rather than just jumping to the reset
vector as that might lead to some incorrect initializations.
Properly plug the div by 0 to the panic handling.
Add a small trace if the debug output is activated.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:29840
TEST=add adhoc code triggering a data abort and see the firmware
printing a trace, then rebooting immediatly in a working state.
Change-Id: I1d5a98d9113c8ae08e05588a40f941d1ed22cebe
Reviewed-on: https://chromium-review.googlesource.com/206268
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Enough USB support to be able to enumerate the device and use bulk or
interrupt endpoints.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28295
TEST=with the following USB console CL, connect a Fruitpie through USB
and use its console over USB.
Change-Id: I37b7f3b6a754cb82ab5f940ea20122d2e16b3b5b
Reviewed-on: https://chromium-review.googlesource.com/193983
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Our code base contains a lot of debug messages in this pattern:
CPRINTF("[%T xxx]\n") or ccprintf("[%T xxx]\n")
The strings are taking up spaces in the EC binaries, so let's refactor
this by adding cprints() and ccprints().
cprints() is just like cprintf(), except that it adds the brackets
and the timestamp. ccprints() is equivalent to cprints(CC_CONSOLE, ...)
This saves us hundreds of bytes in EC binaries.
BUG=chromium:374575
TEST=Build and check flash size
BRANCH=None
Change-Id: Ifafe8dc1b80e698b28ed42b70518c7917b49ee51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200490
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is another patch to fix the bug which causes a HardFault exception
at the "svc" instruction in __wait_evt().
The HardFault is due to a priority escalation problem in which "svc"
is called when the PRIMASK is high, meaning interrupts are disabled.
The issue was that an interrupt can occur just before the "svc"
instruction, and when an interrupt fires that performs a context switch,
the IRQ handler disables interrupts setting the PRIMASK reg high.
The arm v6 reference manual specifies that "PRIMASK unchanged on
exception exit". So, therefore, we must clear PRIMASK by running "cpsie"
before exiting IRQ handler.
BRANCH=none
BUG=chrome-os-partner:28296
TEST=
Reproduce the problem on a fruitpie by inserting dummy for loop in
__wait_evt() before "svc" call:
asm volatile("isb");
for (i = 0; i < 250; i++) ;
__schedule(1, resched);
Then, when running pd dev, the system gets the HardFault exception
within a few minutes because there is more time for an interrupt
to occur and disable interrupts right before call to "svc".
After applying this patch, the code has run for > 3 hours without
a HardFault.
Change-Id: Ic50252b09c40c7d76975ff7f16d799c9eae2bde6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197839
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
