summaryrefslogtreecommitdiff
path: root/core
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* make the common runtime optionalVincent Palatin2014-03-226-4/+16
| | | | | | | | | | | | | | | | | | | | | 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>
* it8380dev: fix firmware can't startup (re-generate)Dino Li2014-03-182-4/+5
| | | | | | | | | | | | | | | | | | | | | | Some section(entry point, interrupt vector, e-flash signature and so on) of linker script file are not linked. The start address of e-flash signature should always at 00000080h. Default firmware treats VCC logic high to prevent pin 11 logic low but use following functions. (EC2I, KBC, SWUC, PMC, CIR, SSPI, UART, BRAM, and PECI) Signed-off-by: Dino Li <dino.li@ite.com.tw> BRANCH=none BUG=none TEST=Firmware can startup on IT8380 emulation board. Change-Id: I9860ac5b99dcc6e9e00dbc9d1e79a141237b7789 Reviewed-on: https://chromium-review.googlesource.com/190008 Reviewed-by: Alec Berg <alecaberg@chromium.org> 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>
* discard unused functions at link timeVincent Palatin2014-03-113-63/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add Cortex-M0 core supportVincent Palatin2014-03-1114-0/+1734
| | | | | | | | | | | | | | | | | | The Cortex-M0 core is based on ARMv6-M instruction set rather than ARMv7-M as Cortex-M3 and M4. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=run console on STM32F072, and pass all available unit-tests on target. Change-Id: I9bdf6637132ba4a3e739d388580a72b4c84e930e Reviewed-on: https://chromium-review.googlesource.com/188982 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* force the compiler to use a valid register allocation for irq handlersVincent Palatin2014-03-113-0/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Move CLZ emulation to common codeVincent Palatin2014-03-062-39/+5
| | | | | | | | | | | | | | | | | | | Move the CLZ instruction emulation C code to the common directory, so it can be reused for all CPU cores missing a CLZ instruction (e.g. CortexM0). Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=run EC console on STM32F072B Discovery board with Cortex-M0 core, and pass all available unit-tests on target. Change-Id: Ief56cac7430fcb0fbced8a8925250c89cbd0bcfc Reviewed-on: https://chromium-review.googlesource.com/188981 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* emulator: Move trace dump to a separate moduleVic (Chun-Ju) Yang2014-01-226-85/+142
| | | | | | | | | | | | | | | The implementation of trace dump has little to do with task scheduling, so we should move it to a separate module for cleaner code. This requires exposing some emulator-specific task info, as defined in host_task.h. BUG=chrome-os-partner:19235 TEST=Pass all tests BRANCH=None Change-Id: Iba9bc0794a4e1dd4ddb92b98345162b398fa6a8d Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/183238
* emulator: Use udelay() for usleep() if task hasn't startedVic (Chun-Ju) Yang2014-01-211-0/+6
| | | | | | | | | | | | | | If the task scheduler hasn't started yet, use udelay() for any call to usleep(). This is what we do for real core now. BUG=chrome-os-partner:19235 TEST=Call usleep() in init hook BRANCH=None Change-Id: Ia5d14ee165ab25bfa231497af1aa8c87fbc324f0 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/183271 Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
* Use pthread_equal() to compare thread IDVic (Chun-Ju) Yang2014-01-111-1/+1
| | | | | | | | | | | | | | Pthread document explicitly stated that == operator should not be used to compare thread IDs. Let's use pthread_equal() to be safe. BUG=chrome-os-partner:19235 TEST=Check trace dump can be generated from non-main thread BRANCH=None Change-Id: I5011e0e380db0ce43c4fcf8fca0d94d5b3108f55 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/182039 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* emulator: Guard interrupt status with mutex lockVic (Chun-Ju) Yang2014-01-081-2/+8
| | | | | | | | | | | | | | This prevents an interrupt from being triggered when we happen to be enabling/disabling global interrupt. BUG=chrome-os-partner:19235 TEST=Repeatedly run interrupt test BRANCH=None Change-Id: I0163aff801ddbcee4aedba7a78966d97336c79ca Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/181920 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Dump stack trace on emulator test failureVic (Chun-Ju) Yang2014-01-083-5/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Emulator test failures are sometimes hard to debug, especially when the test is stuck somewhere and times out. Let's have the emulator dump stack trace when an assertion fails or a test times out. The produced stack trace is in this format: #0 build/host/kb_8042/kb_8042.exe() [0x412421] /home/victoryang/trunk/src/platform/ec/test/kb_8042.c:104 #1 build/host/kb_8042/kb_8042.exe() [0x4124a9] /home/victoryang/trunk/src/platform/ec/test/kb_8042.c:129 #2 build/host/kb_8042/kb_8042.exe(run_test+0x3a) [0x412e2c] /home/victoryang/trunk/src/platform/ec/test/kb_8042.c:262 #3 build/host/kb_8042/kb_8042.exe(_run_test+0x11) [0x4061de] /home/victoryang/trunk/src/platform/ec/core/host/task.c:90 #4 build/host/kb_8042/kb_8042.exe(_task_start_impl+0x79) [0x406b72] /home/victoryang/trunk/src/platform/ec/core/host/task.c:408 #5 /lib64/libpthread.so.0(+0x70b1) [0x7f6dc2fa10b1] ??:0 #6 /lib64/libc.so.6(clone+0x6d) [0x7f6dc2cd8efd] ??:0 The file name and line number in the trace is generated by addr2line. BUG=chrome-os-partner:19235 chromium:331548 TEST=Put in a infinite loop in a test, and see stack trace when it times out. TEST=Add a failing assertion, and see stack trace when it fails. BRANCH=None Change-Id: I4494ffd1ebc98081ce40e860a146202084aa2a1e Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/181730
* Process emulator UART events in interrupt contextVic (Chun-Ju) Yang2014-01-061-0/+9
| | | | | | | | | | | | | | | | | Currently emulator UART input/output are processed in various context, including UART thread, individual tasks, and tests. By moving the processing to interrupt context, the way it works resemble real chips more. Also, this provides a cleaner cut between emulated UART device and UART processing code. BUG=chrome-os-partner:23804 TEST=make buildall BRANCH=None Change-Id: I58127e66f4058a68d37be9029e9ddbbd798381c6 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/181590 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Add interrupt support for emulatorVic Yang2014-01-062-22/+171
| | | | | | | | | | | | | | | | | | This provides us a way to inject interrupts during a test. If a test has interrupt_generator() defined, it will run in a separate thread. The generator can then trigger interrupts when it decides to. The current running task is suspended while emulator is executing ISR. Also fixes a bug that tasks run without scheduler notifying them during emulator start-up. BUG=chrome-os-partner:19235 TEST=Repeatedly run all tests. BRANCH=None Change-Id: I0f921c47c0f848a9626da6272d9040e2b7c5ac86 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/55671
* cleanup: Remove checkpatch warningsRandall Spangler2013-12-193-21/+19
| | | | | | | | | | | | | | | | 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
* Protect inactive EC image from code executionDaisuke Nojiri2013-12-172-54/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change configures MPU to prevent instruction fetch from the flash image that is not running at the time system_disable_jump is called. Violating the protection causes instruction access violation, then the EC reboots. RO image protection is tested as follows: ... [6.255696 MPU type: 00000800] [6.255874 RAM locked. Exclusion 20005680-200056a0] [6.256168 RO image locked] ... > sysjump 0 Jumping to 0x00000000 === PROCESS EXCEPTION: 03 ====== xPSR: 60000000 === r0 :00000000 r1 :2000541c r2 :00001388 r3 :20007fe8 r4 :200032f0 r5 :00000000 r6 :20002b70 r7 :20002df4 r8 :0002d308 r9 :20002df4 r10:00000000 r11:00000000 r12:00000002 sp :20002358 lr :0002a1a7 pc :00000000 Instruction access violation, Forced hard fault mmfs = 1, shcsr = 70000, hfsr = 40000000, dfsr = 0 =========== Process Stack Contents =========== 200023c0: 00000098 00000000 00000000 0002a785 200023d0: 00000002 20002dfd 00000007 20002b70 200023e0: 00000002 00025777 00000000 20002dfd 200023f0: 20002df4 20002dfc 00000000 00000000 Rebooting... Memory management fault status register has bit0 set, indicating there was an instruction fetch volation. FYI, RAM protection is still working: > sysjump 0x20000000 Jumping to 0x20000000 === PROCESS EXCEPTION: 03 ====== xPSR: 60000000 === r0 :00000000 r1 :2000541c r2 :00001388 r3 :20007fe8 r4 :200032f0 r5 :20000000 r6 :20002b70 r7 :20002df4 r8 :0002d308 r9 :20002df4 r10:00000000 r11:00000000 r12:00000002 sp :20002358 lr :0002a1a7 pc :20000000 Instruction access violation, Forced hard fault mmfs = 1, shcsr = 70000, hfsr = 40000000, dfsr = 0 =========== Process Stack Contents =========== 200023c0: 00000098 00000000 20000000 0002a785 200023d0: 00000002 20002e06 00000007 20002b70 200023e0: 00000002 00025777 00000000 20002e06 200023f0: 20002df4 20002dfc 00000000 00000000 Rebooting... TEST=Booted Peppy. Tested lid close & open. Ran Flashrom from userspace to update main firmware then software-synched an EC image. BUG=chrome-os-partner:16904 BRANCH=none Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Change-Id: Id4f84d24325566a9f648194166bde0d94d1124dc Reviewed-on: https://chromium-review.googlesource.com/169050 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Daisuke Nojiri <dnojiri@google.com> Tested-by: Daisuke Nojiri <dnojiri@google.com>
* nds32: WORKAROUND for toolchain bug on rodataVincent Palatin2013-12-101-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes the toolchain tries to put a relocation which is not suitable to access variables in a read-only section. The nds32 gcc uses GP-relative signed 17-bit relocation to access variables stored in .rodata (eg lwi.gp $r0, [ +gp ]) That's wrong since $gp is pointing in the middle of .data and .bss in the SRAM, while .rodata is sitting in flash. Since on IT8380, the flash is at 0x00000 and the SRAM is at 0x80000 (512kB further), the linker will fail trying to create the signed 17-bit relocation (it detect that it needs to truncate it) Force the compiler to put another relocation as a workaround for now. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:24378 TEST=./util/make_all.sh ; make BOARD=it8380dev check "version" and "gpioget" on spring, link and it8380dev. Change-Id: Ife50adf3a26be28f113292f73a1a70e8d74b5d8c Reviewed-on: https://chromium-review.googlesource.com/176913 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* ite: Port OS layer to Andestar v3m architectureVincent Palatin2013-12-1011-0/+1310
| | | | | | | | | | | | | | | | | This will be used to support ITE IT8380 chip which contains an Andes N801 core. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:23574 TEST=make BOARD=it8380dev Change-Id: I91f9380c51c7712aa6a6418223a11551ab0091ce Reviewed-on: https://chromium-review.googlesource.com/175480 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* extract common core codeVincent Palatin2013-12-053-466/+34
| | | | | | | | | | | | | | | | | | | | | | 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>
View Lorry Controller Status