Commit Graph

5 Commits

Author SHA1 Message Date
Bill Richardson
15fcbc9596 Cleanup: Remove COMPILE_FOR_RAM option from linker scripts
This option was added way back in January 2012 for early EC
bringup, and never used since. We can probably remove it.

BUG=none
BRANCH=none
TEST=make buildall

Change-Id: Idc8c3099388f2e28d620848a0e78b555b02fba9c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/297334
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
2015-09-08 10:38:21 -07:00
Alec Berg
0e402965fa cortex-m0: stm32f0: use RW vector table when running RW code
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>
2014-07-29 04:36:44 +00:00
Vincent Palatin
6473343075 better unhandled exception panic without runtime
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>
2014-07-03 02:56:52 +00:00
Vincent Palatin
60e47a730f make the common runtime optional
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>
2014-03-22 06:24:16 +00:00
Vincent Palatin
0f73a129b4 Add Cortex-M0 core support
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>
2014-03-11 05:52:41 +00:00