summaryrefslogtreecommitdiff
path: root/core
Commit message (Collapse)AuthorAgeFilesLines
* nuc: Add SHI driver for arm-based platform in chip folder.Ian Chao2015-06-261-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cleanup: fix all the header guardsBill Richardson2015-06-1813-39/+39
| | | | | | | | | | | | | | | 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>
* it8380dev: add pmc control moduleDino Li2015-06-172-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add pmc(LPC ACPI) control module for emulation board. Signed-off-by: Dino Li <dino.li@ite.com.tw> BRANCH=none BUG=none TEST=1. 62h/66h port. 1-a. out 66h 80h, out 62h 00h, in 62h 02h 1-b. out 66h 81h, out 62h 01h, out 62h 55h 1-c. out 66h 80h, out 62h 01h, in 62h 55h 1-d. out 66h 80h, out 62h 02h, in 62h aah 2. H2RAM LPC I/O cycle 900h ~ 9FFh = DLM 0x8D900 ~ 0x8D9FF and host read only. 3. 80h port, console command port80. 4. host command. 4-a. host request (LPC I/O 800h ~ 807h) 03 FD 00 00, 00 00 00 00 out 204h DAh, in 200h 00h host response (LPC I/O 800h ~ 80Bh) 03 F7 00 00, 04 00 00 00, 02 00 00 00 4-b. host request 03 EE 01 00, 00 00 04 00, 01 02 03 04 out 204h DAh, in 200h 00h host response 03 E5 00 00, 04 00 00 00, 05 05 05 05 Change-Id: I5c3bac66306dfba380548a74a64536ea606ddd3e Reviewed-on: https://chromium-review.googlesource.com/269271 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Tested-by: Dino Li <dino.li@ite.com.tw> Commit-Queue: Dino Li <dino.li@ite.com.tw>
* common: Add i2c 32bit read/writeGwendal Grignou2015-06-171-0/+8
| | | | | | | | | | | | | Add functions and associated test to read/write a 32 bit register BRANCH=smaug TEST=Test on smaug with bm160 driver BUG=chromium:39900 Change-Id: Ieff24b65f1eb8610874fe13c4a8fadf583a218cb Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/277535 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* coderam: Don't assume that RO/RW images reside at start of code memoryShawn Nematbakhsh2015-06-131-6/+17
| | | | | | | | | | | | | | | | | | RO/RW images may reside at an offset to the start of code memory, defined at the chip-level by CONFIG_R*_MEM_OFF. BUG=chrome-os-partner:38103 TEST=Manual on Cyan. Verify sysjump works correctly in both directions. BRANCH=None Change-Id: I54c5f20335a5646d49afcc8d3fa2eb90ca9349d0 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/274434 Reviewed-by: Divya Jyothi <divya.jyothi@intel.com> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Divya Jyothi <divya.jyothi@intel.com> Reviewed-by: Mulin Chao <mlchao@nuvoton.com> Tested-by: Mulin Chao <mlchao@nuvoton.com>
* core: Assert if task_get_current() cannot return a valid task IDShawn Nematbakhsh2015-06-123-0/+12
| | | | | | | | | | | | | | | | | | | 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>
* core: add task_wait_event_mask() function to other coresAlec Berg2015-06-113-2/+57
| | | | | | | | | | | | | | | 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>
* Cr50: USB hardware uses 8-bit buffers, not 16-bitBill Richardson2015-05-292-4/+4
| | | | | | | | | | | | | | | 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 option to enable GCC LTOVincent Palatin2015-05-199-10/+21
| | | | | | | | | | | | | | | | | | | | | | 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>
* cleanup: Rename image geometry CONFIGsShawn Nematbakhsh2015-05-123-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* flash: Add option to move pstate inside RO imageRandall Spangler2015-04-172-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* usb: Remove unnecessary alignment for descriptorsBill Richardson2015-04-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* it8380dev: add KBC/KMSC moduleDino Li2015-03-221-0/+6
| | | | | | | | | | | | | | | | | 1. DLM 16KB. 2. Add KBC/KMSC module for emulation board. Signed-off-by: Dino Li <dino.li@ite.com.tw> BRANCH=none BUG=none TEST=EVB + x86 MB can boot into DOS and keyboard works. Change-Id: Ia5cc2d4f1733ce07879d410b0447b2d48e50cd95 Reviewed-on: https://chromium-review.googlesource.com/259923 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Tested-by: Dino Li <dino.li@ite.com.tw> Commit-Queue: Dino Li <dino.li@ite.com.tw>
* lm4: stm32: Store panic data in backup registers on hard resetShawn Nematbakhsh2015-03-144-10/+52
| | | | | | | | | | | | | | | | | | 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>
* cortex-m0: Fix branch from 64-bit signed to unsigned divideRandall Spangler2015-02-251-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cortex-m0: Fix panic reason on div0Shawn Nematbakhsh2015-02-181-1/+1
| | | | | | | | | | | | | | The wrong constant was used in the previous commit. BUG=chrome-os-partner:36744 TEST=None BRANCH=Samus Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I74e365b00adb6909a4940229647f9aecebe5e0b1 Reviewed-on: https://chromium-review.googlesource.com/250700 Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* cortex-m*: Save panicinfo on non-exception panicsShawn Nematbakhsh2015-02-189-69/+60
| | | | | | | | | | | | | | | | | | 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>
* cortex-m0: Add deferred schedulerAlexandru M Stan2015-02-124-76/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cortex-m0: Fix handling uint64 divide-by-0stabilize-6783.BRandall Spangler2015-02-111-0/+3
| | | | | | | | | | | | | | | | | | | | 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>
* Add 64-bit divide library routines for Cortex-M, Cortex-M0Randall Spangler2015-02-056-2/+525
| | | | | | | | | | | | | | | | | | | 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>
* hooks: add hook for battery state of charge changeAlec Berg2015-02-034-0/+16
| | | | | | | | | | | | | | 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>
* cortex-m: disallow rescheduling if task_start() has not yet runVic Yang2015-01-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | 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>
* cortex-m: allow to lock/unlock empty MPU regionVincent Palatin2015-01-231-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
* fix off-by-one in flash size checkVincent Palatin2015-01-142-2/+2
| | | | | | | | | | | | | | | | | | | __hey_flash_used is actually a size rather than an offset, it might be equal to flash if we use every single byte. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=none TEST=make buildall with the following CLs, samus_pd uses every single byte of flash. Change-Id: I98ddac73fab80c44ca2743ab2847321d71746752 Reviewed-on: https://chromium-review.googlesource.com/240539 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>
* cortex-m0: optimize out unused assembly helpersVincent Palatin2015-01-143-32/+8
| | | | | | | | | | | | | | | | | | | | | 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>
* nuc: Add all IC specific drivers of NPCX5M5GIan Chao2015-01-141-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: NVIC: Fix macro for the priority registersstabilize-6592.BAlexandru M Stan2014-12-181-1/+1
| | | | | | | | | | | | | | | | | 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>
* NVIC: Adjust priority settingAlexandru M Stan2014-12-172-1/+5
| | | | | | | | | | | | | | | | | | | 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_sh_loader: Add board directory for load imageGwendal Grignou2014-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Stop mutex_lock() from eating pending eventsBill Richardson2014-11-224-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* rsa: add support for 4096 and 8192 bit keysVincent Palatin2014-11-152-6/+38
| | | | | | | | | | | | | | | | | | | | | 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>
* USB: Fix issue with USB RAM sizesAnton Staaf2014-11-112-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* MKBP event signalling implementationVic Yang2014-10-242-0/+10
| | | | | | | | | | | | | | | | | | | 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>
* cortex-m0: add more constraints on atomic implementationVincent Palatin2014-10-211-2/+2
| | | | | | | | | | | | | | | | | | | In ARMv6-m instruction set, the load/store address register can only be a "low" register : r0..r7. Update the inline assembly constraints to match the hardware. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=make buildall Change-Id: I9872aeb437b2bb6401bed8076348e26d434320dd Reviewed-on: https://chromium-review.googlesource.com/224582 Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* stm32f: Add DMA interrupt handlers for channel 1 to 3Vic Yang2014-10-212-2/+4
| | | | | | | | | | | | | | | | | | 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>
* cortex-m0: disallow rescheduling if task_start() has not yet runAlec Berg2014-10-071-1/+2
| | | | | | | | | | | | | | | | | | | | | 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>
* Slow down time when running unit testsVic Yang2014-10-042-4/+14
| | | | | | | | | | | | | | | | | | | | | | When a timing sensitive test run on a heavily loaded system, sometimes a task runs for longer than it usually does and causes the test to fail. All the timing requirements in the unit tests are trying to verify the various delays in our codebase, and mostly we don't care about the time taken by active running code (as they are very quick.) To improve the stability of tests, let's slow down the time. To a test, it's as if the code runs faster. If a test uses udelay() and exceeds the 10-second time limit, we can make that single test faster by setting the time scale. BUG=None TEST=Repeatedly run 'make runtests' BRANCH=None Change-Id: I9bc5c77e0d34d04c8630d495387a751ef29c7bd5 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220717 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* zinger: check RW firmware signatureVincent Palatin2014-10-022-0/+14
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Add options to disable rarely used console commandsVic Yang2014-09-242-0/+4
| | | | | | | | | | | | | | | | | | | '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>
* cortex-m0: stm32f0: use RW vector table when running RW codeAlec Berg2014-07-292-12/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cortex-m0: add 64-bit multiplicationVincent Palatin2014-07-102-1/+75
| | | | | | | | | | | | | | | | | | | | 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>
* better unhandled exception panic without runtimeVincent Palatin2014-07-033-8/+3
| | | | | | | | | | | | | | | | | | | | | | 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>
* stm32: add USB driverVincent Palatin2014-06-182-0/+40
| | | | | | | | | | | | | | | | | | 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>
* Add cprints() and ccprints()Vic Yang2014-05-214-6/+6
| | | | | | | | | | | | | | | | | | | | | 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>
* cortex-m0: fix hard-faults during software interrupt calls part 2Alec Berg2014-05-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cortex-m0: fix hard-faults during software interrupt callsVincent Palatin2014-04-251-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From time to time (usually under heavy interrupt load), the runtime on Cortex-M0 was panic'ing at the "svc" instruction with a HardFault exception (inside the wait_event() function). The issue was probably the following : the wait_event() code is doing an atomic_read_clear() whose critical section disables interrupts and re-enables them using "cpsie i", then do __schedule() call which is essentially a "svc" instruction. According to ARMv6-m reference manual : "If execution of a CPS instruction: increases the execution priority, the CPS execution serializes that change to the instruction stream. decreases the execution priority, the architecture guarantees only that the new priority is visible to instructions executed after either executing an ISB instruction, or performing an exception entry or exception return." So, when we are executing the "svc", PRIMASK.PM can still be seen as 1 (while it was set to 0 by "cpsie i") and in that case the software interrupt is replaced by a HardFault. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:28296 TEST=run Firefly board under load for extended periods of time. Change-Id: Ie355c36f06e6fe2fee5cca8998a469fa096badad Reviewed-on: https://chromium-review.googlesource.com/196659 Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* cortex-m: store FPU regs on context switchAlec Berg2014-04-182-14/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cortex-m0: add more thumb1 helpersVincent Palatin2014-04-111-11/+53
| | | | | | | | | | | | | | | | Add other helpers for compact switch on ARMv6-M. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=none Change-Id: I711ee8361ff1545acd978974d9f9fc306ca43b78 Reviewed-on: https://chromium-review.googlesource.com/190711 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* cortex-m: Add task_wait_event_mask() helper functionChromeOS Developer2014-03-261-0/+29
| | | | | | | | | | | | | BUG=chrome-os-partner:27180 BRANCH=rambi TEST=Tested indirectly via subsequent patches to use this call in the adc and i2c handlers for the lm4. Change-Id: I53501fdf47d606ea6c7705facb66e945e25d9745 Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/191300 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cortex-m: Add debug config option for disabling buffered writesChromeOS Developer2014-03-261-0/+10
| | | | | | | | | | | | | | | 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>
View Lorry Controller Status