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>
The code in core/cortex-m/init.S limits the number of installed
vectors to CONFIG_IRQ_COUNT. But the DECLARE_IRQ macro installing
interrupt servicing routines does not care about this limitation. This
results in corrupted interrupt configuration, which is hard to debug.
This patch makes sure that there is a compilation error in case
DECLARE_IRQ is passed interrupt number which out of bounds.
A similar change needs to be introduced for cortex-m0.
BRANCH=none
BUG=chromium:518898
TEST=tried building cr50 with one of interrupt numbers exceeding
CONFIG_IRQ_COUNT, observed a compilation error.
Change-Id: Ie7bc623da6bf7371579b2242064f81a83053df17
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/291843
Reviewed-by: Randall Spangler <rspangler@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>
Add ECST tool to modify the header used by npcx booter.
Modified drivers:
1. i2c.c: Modify for i2c_port design.
2. i2c.c: Fixed bugs when mutil-tasks use the same i2c port and pull-up issue.
3. hwtimer.c: Fixed bug whcih event expired time is behide current timer.
4. lpc.c: Add intializing host settings after pltrst is deasserted.
5. uart.c/clock.c/register.h: Fixed bug which cannot enter deep-idle
when gpio is any-edge trigger mode.
6. task.c: Add workaround method for hard fault issue.
7. keyboard_raw.c: Modified for support CONFIG_KEYBOARD_KSO_BASE
8. lpc.c: Modified for support CONFIG_KEYBOARD_IRQ_GPIO
9. lpc.c: fixed obe interrupt bug during 8042 initialization
10.Adjust path of flat files for new Makefile rules
11.Fixed build error on lpc.c without CONFIG_KEYBOARD_IRQ_GPIO
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: Icf9494174b245b4026e396be877d578f36b6f6a5
Signed-off-by: Ian Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/284036
Reviewed-by: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Shawn N <shawnn@chromium.org>
Implemented mec1322's heavysleep in idle task to
reduce further EC power down on S3.
MEC1322 needs sleep-enabled for all blocks to
acheive max power down including UART.
Real heavysleep will be effective only when
console/uart is not active.
To enable this commit, board-specific commit is required.
For example, check commit, "Enabling heavysleep idle task at S3".
Test:
1. Put device into S3 mode by typing 'powerd_dbus_suspend" in Linux
shell.
2. wait at least 1 min till EC console sleeps
3. measure EC power.
Since idle task is continuously scheduled, EC will enters/exits
to/from heavy sleep mode frequently in S3 and power consumption
will be changed dynamically.
For acurate power measurement, high-sampling-rate measurement
system might be required and using DMM might not give accurate
number.
BUG=None
TEST=Tested on evt1p0/evt1p7/DVT
BRANCH=None
Change-Id: I435ca347cab2f4d51cefeee802c3bf30fb393fa1
Signed-off-by: Kyoung Kim <kyoung.il.kim@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/283603
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@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>
Add npcx_evb_arm board-level driver for arm-based platform.
Add header.c: for booting from NPCX5M5G A3 Booter.
Remove lfw folder due to those functionalitie have been replaced with Booter
Modified drivers for
Patch Set 1:
1. flash.c: Implement UMA lock, tri-state and selection register lock functionalities
2. hwtimer.c: Add ITIM32 for hwtimer
3. lpc.c: Add checking for LRESET
4. system.c: Modified CODERAM_ARCH functions for NPCX5M5G A3 Booter.
5. uart.c: Add support for module 2
Patch Set 2:
6. lpc.c: Modified lpc_get_pltrst_asserted() func
Patch Set 3:
7. minimize the changes for CONFIG_CODERAM_ARCH in common layer
8. comments of Patch Set1/2
Patch Set 4:
9. Modified CONFIG_RO_MEM_OFF point to ro image and keep header as a part of ec.RO.flat.
10. Fixed RO_FRID and RW_FRID issues which caused by CONFIG_CODERAM_ARCH.
Patch Set 5:
11. Modified system.c in common folder for supporting *_STORAGE_OFF.
12. Use *_STORAGE_OFF in firmware_image.lds.S to indicate flat file layout in flash.
Patch Set 6:
13. rebase to newest version
14. system.c: Modified for the newest include/system.h
Patch Set 7:
15. Merge from version 0625
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: Ifd7c10b81b5781ccd75bb2558dc236486976e8ed
Signed-off-by: Ian Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/272034
Reviewed-by: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Shawn N <shawnn@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>
This was causing the amount of data sent to be larger than the
total size of the descriptors.
Before this CL, connecting the Cr50 through USB gave this kernel
message:
usb 2-1.4.7: config 1 descriptor has 1 excess byte, ignoring
When the host requests the descriptor, the code in chip/*/usb.c
that handles it looks like this:
case USB_DT_CONFIGURATION: /* Setup : Get configuration desc */
desc = __usb_desc;
len = USB_DESC_SIZE;
break;
But include/usb.h has this:
#define USB_DESC_SIZE (__usb_desc_end - __usb_desc)
And both __usb_desc and __usb_desc_end come from the linker
script.
BUG=none
BRANCH=none
TEST=manual
Before this change, I built the Cr50 firmware from m/master,
tried it, and got the dmesg complaint on the host.
After this change, the dmesg complaint doesn't show up anymore.
Change-Id: I83ae2333a9e76af7acb18bd2f0e4cef5c095862a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265765
Reviewed-by: 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>
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>
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>
Most GPIO/peripheral interrupts are enabled in HOOK_INIT or some other
*_init() functions that are called before task_start(). Quite a lot of
these IRQ handler wake some task to process the interrupt, and this
causes a race condition. If the interrupt is triggered before
task_start() is called, the system may crash/hang/whatever.
Fix this by only allowing rescheduling tasks if task_start() is called.
This is basically the cortex-m version of commit e541eeb2.
BRANCH=Ryu
BUG=None
TEST=Without this fix, my Ryu P3 always crashes when cold resetting from
bootloader mode. After applying this fix, it doesn't anymore.
Change-Id: I0f81e90482ff97469c4f0423d6aa060f2ac76f74
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/243626
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
When the MPU region to modify is empty (size == 0) returns EC_SUCCESS
rather than EC_ERROR_INVAL, so we are not failing MPU activation on
systems without anything in the .iram.text section.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=all
BUG=chrome-os-partner:35774
TEST=on Samus, with WP, try "sysjump disable" on the EC command line
and see "RAM locked. Exclusion 20006ee0-20006ee0" message.
Change-Id: I0103e0f7aa81ee64a70dd47ffb1c50067ce5a6ee
Reviewed-on: https://chromium-review.googlesource.com/242690
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@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
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>
Ryu sensor hub has asymectric RO/RW images. The first one is very limited
(not i2c master, no sensor drivers, gesture recognition).
Image size is alter to offer more space for the RW firmware image,
compiled with ryu_sh board.
To write RO image and basic RW image:
flashrom -V -p ec:type=sh,block=0x800 --fast-verify -w /tmp/ryu_sh_loader/ec.bin
To write the expected RW image:
flashrom -V -p ec:type=sh,block=0x800 --fast-verify -w -i EC_RW:/tmp/ryu_sh/ec.bin
BRANCH=ToT
BUG=chrome-os-partner:33908
CQ-DEPEND=CL:231970,CL:233233
TEST=load on Ryu, confirmed limited operation.
Change-Id: Ib976e2b048935adfb9b2b072c071db5be2bc1c09
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231984
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>
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>
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>
Added storing of FPU regs on context switches when CONFIG_FPU is defined.
On context switches, EXC_RETURN[4] is checked in order to tell which tasks
have used floating point and which have not. The FPU regs are only stored on
task stacks for tasks that use the floating point. Tasks that use floating
point will therefore require roughly an additional 128 bytes of stack space,
and context switches will take about 32 clock cycles longer for each task
involved in the switch that uses FP.
For tasks that don't use floating point, the stack usage actually decreases
by 64 bytes because previously we were reserving stack space for FPU regs
S0-S15 on every context switch for every task, even though we weren't doing
anything with them.
If a task only uses the FPU for a brief window, it can call
task_clear_fp_used() in order to clear the FP used bit so that context
switches using that task will not backup FP regs anymore.
BUG=chrome-os-partner:27971
BRANCH=none
TEST=Tested on glimmer and peppy. Added the following code, which uses the
FPU in both the hooks task and the console task. Note, I tested this for
a handful of registers, notably registers in the group s0-s15 which are
backed up by lazy stacking, and registers in the group s16-s31 which are
backed up manually.
float dummy = 2.0f;
static void hook_fpu(void)
{
union {
float f;
int i;
} tmp;
/* do a dummy FP calculation to set CONTROL.FPCA high. */
dummy = 2.3f*7.8f;
/* read and print FP reg. */
asm volatile("vmov %0, s29" : "=r"(tmp.f));
ccprintf("Hook float 0x%08x\n", tmp.i);
/* write FP reg. */
tmp.i = 0x1234;
asm volatile("vmov s29, %0" : : "r"(tmp.f));
}
DECLARE_HOOK(HOOK_SECOND, hook_fpu, HOOK_PRIO_DEFAULT);
static int command_fpu_test(int argc, char **argv)
{
union {
float f;
int i;
} tmp;
/* do a dummy FP calculation to set CONTROL.FPCA high. */
dummy = 2.7f*7.8f;
/* read and print FP reg. */
asm volatile("vmov %0, s29" : "=r"(tmp.f));
ccprintf("Console float 0x%08x\n", tmp.i);
if (argc == 2) {
char *e;
tmp.i = strtoi(argv[1], &e, 0);
if (*e)
return EC_ERROR_PARAM1;
/* write FP reg. */
asm volatile("vmov s29, %0" : : "r"(tmp.f));
} else {
task_clear_fp_used();
}
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(fputest, command_fpu_test, "", "", NULL);
When you call fputest 5 from EC console before this CL, then on the next
HOOK_SECOND, the value of register s29 is 5, instead of 0x1234 because
register s29 is not saved on context switches:
Hook float 0x00001234
> fputest 5
Console float 0x00001234
Hook float 0x00000005
When this CL is in use, the register holds the correct value for each task:
Hook float 0x00001234
> fputest 5
Console float 0x00001234
Hook float 0x00001234
> fputest
Console float 0x00000005
Hook float 0x00001234
Change-Id: Ifb1b5cbf1c6fc9193f165f8d69c96443b35bf981
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194949
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This can be helpful when debugging "Imprecise" data bus errors.
BUG=None
BRANCH=None
TEST=Write to a memory-mapped register such as LM4_ADC_ADCISC
for a hardware block that is powered down.
Check the exception trace for a "Precise" error.
Change-Id: Ia246c3661b482e212bb0ce37b9c2d383021de639
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191392
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In order to achieve really tiny firmwares, make our runtime (tasks,
hooks, muxed timers, GPIO abstraction ...) optional.
Add 2 new build options for it : CONFIG_COMMON_RUNTIME and
CONFIG_COMMON_GPIO which are enabled by default, and ensure all the
source files are built according to the right configuration variable.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
build a minimal board with no runtime.
Change-Id: Icb621cbe0a75b3a320cb53c3267d6e578cd3c32f
Reviewed-on: https://chromium-review.googlesource.com/189403
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Put each functions in a separate section by using -ffunction-sections,
then discard the non-referenced ones in the linker with -gc-sections.
Force keeping a few special symbols by using the KEEP() linker
directive.
This modification is not saving a lot of spaces per se, but will enable
larger code pruning with future optional features.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall, manually check discarded symbols in the .map file
and run on Spring and Link.
The size delta is the following:
Link: total 85.7k -> 84.9k (.text 60.3k -> 59.5k)
Spring: total 59.2k -> 57.2k (.text 44.4k -> 42.5k)
Change-Id: Ib6eb0d3f2cc4fc172c9fc26acac2e486921690a3
Reviewed-on: https://chromium-review.googlesource.com/189224
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
When we are calling the re-scheduling routine at the end of an irq
handling routine, we need to ensure that the high registers are not
currently saved on the system stack.
On Cortex-M3/M4, the compiler is normally doing tail-call optimization
there and behaving properly, but this fixes the fact that insanely large
interrupt handling routines where sometimes not compile and not running
properly (aka issue 24515).
This also prepares for one more core-specific DECLARE_IRQ routine on
Cortex-M0.
Note: now on, the IRQ handling routines should no longer be "static".
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:24515
TEST=make -j buildall
revert the workaround for 24515, see the issue happening only without
this CL.
Change-Id: Ic419369231925568df05815fd079ed191a5446db
Reviewed-on: https://chromium-review.googlesource.com/189153
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This make minor syntactic changes and renames some camel-cased symbols
to keep checkpatch from complaining. The goal is to reduce the
temptation to use 'repo upload --no-verify'.
This is a big furball of find/replace, but no functional changes.
BUG=chromium:322144
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I0269b7dd95836ef9a6e33f88c003ab0f24f842a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180495
Move the non-core dependent code out of core/$(CORE) directory to
common/ directory.
Put all panic printing code in common/panic_output.c
Put timer management code in common/timer.c
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:23574
TEST=./util/make_all.sh
use "crash divzero" and "panicinfo" on Link.
Change-Id: Ia4e1ebc74cd53da55fe24f69e96f39f512b9336d
Reviewed-on: https://chromium-review.googlesource.com/178871
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
BSS section is usually put at the beginning of the RAM, so large
alignemnt causes the least memory usage penalty here, compared to
alignment using __attribute__((aligned(x))).
Also remove .bss.tasks and .bss.task_scratchpad, which are both not
present anymore.
BUG=chrome-os-partner:24107
TEST=Build all boards. Boot mec1322_evb.
BRANCH=None
Change-Id: Ie19b9feb76773a94f0443c2a0d39505ddef7a1df
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178274
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
A cprintf could increase 96+ bytes of stack usage and may overflow
the stack of idle task, which is 256 bytes on stm32.
BUG=chrome-os-partner:23982
BRANCH=nyan
TEST=verified on nyan
Change-Id: If96a1c51010116a2b4f3d67481ec0acc7bf78dd9
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176619
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Changes somewhere in the recent past have caused I2C operations to
consume more stack space. The current failure mode is that after some
debug command or infrequent battery operation, the system fails.
Clean up and enable stack overflow detection by default, and add a
debug command (disabled by default) to verify overflow detection
works.
This adds several instructions to each context switch, but it's still
fairly inexpensive, and represents only a few percent increase in the
size of svc_handler(). That's better than silent failures.
BUG=chrome-os-partner:23938
BRANCH=none
TEST=Enable CONFIG_CMD_STACKOVERFLOW, then run the 'stackoverflow' command.
This should cause a stack overflow to be detected in the CONSOLE task.
Change-Id: I9303aee5bd9318f1d92838b399d15fb8f6a2bbf9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176113
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
