We need a simple way to build an EC image that is binary-wise much
different from the original one, so that we can test EC update as much
thoroughly as possible. By padding useless space, we can have an image
with exactly same functionality but binary-wise different.
BUG=chrome-os-partner:10264
TEST=Build and run without error.
Change-Id: I070bec7cec71db1662238ca6af10e864c82ba428
Reviewed-on: https://gerrit.chromium.org/gerrit/26083
Reviewed-by: Yung-Chieh Lo <yjlou%chromium.org@gtempaccount.com>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
panic_putc was doing an infinite loop on platforms with a UART FIFO.
(e.g. LM4F)
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:10825
TEST=on Link EVT and Lucas DVT, type "rw 1" in the EC serial console and
see the panic trace.
Change-Id: I47f43183e6e938b88874c80244430ddf88c5a567
Reviewed-on: https://gerrit.chromium.org/gerrit/26052
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
When copying .data section from flash to internal RAM at startup, we
assume the content of the section is aligned on a word size in flash.
Force the alignment in the linker file.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:10823
TEST=on Link EVT, type "sysjump RO" in EC console and see you are
jumping to RO partition and not getting a watchdog reset.
Change-Id: I1a1387ef8bff01d287d85ee2a660811c9e4620c6
Reviewed-on: https://gerrit.chromium.org/gerrit/26032
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
In addition to ASSERT(), it might be useful to panic() sometimes, so add
a tidy way of doing it which will print a message and reset.
BUG=chrome-os-partner:10149
TEST=manual
Build a special version for snow where the 'rw' command calls panic()
See that a message is produced:
> rw 0
read 0x0 = 0x20001048
** PANIC: Address is 0
Change-Id: I4512c0193f4c1d52d0c256b2deefacf551056fd9
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/25413
Rather than just reset the board, report assertion failures to aid
debugging. To enable this, use CONFIG_ASSERT_HELP.
BUG=chrome-os-partner:10149
TEST=manual
Enable the option for snow, add a failing ASSERT() to the rw command
and see the a nice message is printed now.
ASSERTION FAILURE 'address' in command_read_word() at common/memory_commands.c:00000037
Change-Id: Ice59434c5daf610832dd0e1fcfa5630dc847bb67
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/25411
The fault status registers sometimes have useful information, so provide
an option to display these.
This adds about 1KB to the code size.
BUG=chrome-os-partner:10146
TEST=manual:
build for all boards
On snow, cause a panic and see that it is reported correctly.
=== EXCEPTION: 03 ====== xPSR: 01000000 ===========
r0 :0000000b r1 :00000047 r2 :60000000 r3 :200013dd
r4 :00000000 r5 :080053f4 r6 :200013d0 r7 :00000002
r8 :00000000 r9 :200013de r10:00000000 r11:00000000
r12:00000000 sp :200009a0 lr :08002b85 pc :08003a8a
Precise data bus error, Forced hard fault, Vector catch, bfar = 60000000
mmfs = 00008200, shcsr = 00000000, hfsr = 40000000, dfsr = 00000008
Change-Id: I1a18c85ee63760502c92b300f5a87e57468469a5
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24505
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For particularly nasty errors the stack or stack pointer may be corrupt,
or in a place that we do not want overwritten. Provide and option to
place the stack in a fresh place, assuming you can reach exception_panic().
Note that exception_panic() does not write anything to stack itself.
BUG=chrome-os-partner:10146
TEST=manual:
build for all boards
On snow, cause a panic and see that it is reported correctly.
Change-Id: I21d8b9bb12455758309d54ef20de66640d8a2df6
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24504
We want this function to be available for all chips, so move it into a
generic place.
The task_disable_irq() from the LM4 version can be left in
watchdog_check(), to keep the watchdog_trace() function generic.
BUG=chrome-os-partner:10145
TEST=build for all boards
Change-Id: I98c60ce5958f1498b84a233ef04290a68a7838c5
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24397
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The SCB registers are defined in the ARMv7-M architecture, so they are
common to all chips.
We will need System Control Register (SCR aka SYSCTRL) to implement
power management on stm32.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=make BOARD=link && make BOARD=snow
Change-Id: I35c283731306541b3d21398c96fdca89954fe20a
Reviewed-on: https://gerrit.chromium.org/gerrit/25392
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Move the implementation of panic into C code. Only a very small part
needs to be in assembler, and the reset is easier to maintain as C.
As part of this, define panic_putc() and panic_puts() which directly
wite to the UART.
To make things more convenience for the future, add a simple printf()
implementation in the panic path. This is not reliant on the uart
buffering system being in a happy state. However, we do call the
emergency flush so that our panic message will appear after previous
output rather that surpressing it (which would be extremely confusing).
Code/data size for panic.o grows by about 200 bytes, but this is mostly
due to the increased flexibility.
text data bss dec hex filename
292 272 0 564 234 old panic.S
692 3 48 743 2e7 new panic.c
BUG=chrome-os-partner:10146
TEST=manual:
build and boot on snow:
> rw 0x06000000
=== EXCEPTION: 03 ====== xPSR: 01000000 ===========
r0 :0000000b r1 :00000047 r2 :06000000 r3 :200013dd
r4 :00000000 r5 :080052cc r6 :200013d0 r7 :00000002
r8 :00000000 r9 :200013de r10:00000000 r11:00000000
r12:00000000 sp :200009a0 lr :08002a5d pc :08003962
Rebooting...
Change-Id: If3e3f572e0f32af780b6ebda235b1b3cde4de5e4
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24503
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Some things about watchdogs are common across Cortex-M3, so create a
common watchdog file to hold these. Put the watchdog task in there as
the first customer.
BUG=chrome-os-partner:10145
TEST=build for all boards
Change-Id: Id55f71a807ee12bae3758afc213c30c731eadc07
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24395
Reviewed-by: Randall Spangler <rspangler@chromium.org>
...so I can use usleep() for eeprom delays in the CL coming next...
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:10200
TEST=if it boots, it worked
Change-Id: I564578f24452a4ac39abe79ff28cfff4b665ad2f
Additional help messages and usage are gated by
CONFIG_CONSOLE_CMDHELP, so we can turn it on if there's space (adds
about 3KB to image size) and turn it off when there isn't.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=manual
1) help
2) help list
3) help gpioset
4) gpioset -> wrong number of params
5) gpioset fred 0 -> param1 bad
6) gpioset cpu_prochot fred -> param2 bad
Change-Id: Ibe99f37212020f763ebe65a068e6aa83a809a370
Instead of storing task contexts in .data and wasting several kB of
flash with mostly 0s, move them to .bss and fill the initial context at EC
startup. The runtime overhead is small enough.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:9839
TEST=run on Link and check verified boot and chromeOS startup are OK.
Change-Id: Iaef23d46a4e3e80e49886dfbf7ab1f537c587362
This makes timestamps much easier to read.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9866
TEST=timerinfo, taskinfo, battery commands have fixed-point numbers,
and timestamps printed in the log look right.
Change-Id: If91c83f725984c8e04bfb7cdcff316d9c3bfe24c
This simplifies the re-flashing for stm32 based platforms.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865
TEST=On Daisy, flashrom -p internal:bus=lpc -w ec.bin
Change-Id: I66860383c34110b1edf852929c244a2b682bc105
On platform where the flash base address is non null (e.g. stm32), we need to
take it into account.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=On Daisy, type "sysjump A" and "version" into the EC console
and observe that the commands succeed.
Change-Id: I95596d45f6970259d19d7063f6794fae0c400ab7
(Touchscreen was already disabled in S5)
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9736
TEST=from console, 'gpioget touchscreen_resetn' in these cases:
1) system is off -> 0
2) system is on with lid open -> 1
3) system is on with lid closed -> 1
4) system is suspended with lid open -> 1
5) system is suspended with lid closed -> 1
6) system is shut back down -> 0
7) suspend system with lid open, THEN close lid -> 0
Change-Id: I5fc80b72ea9dcfbf11f5280d79ae805c2ef1b6df
The VMA of the .data segment is in RAM, but we actually put it into FLASH.
The linker doesn't notice if it runs out of flash, so it creates an invalid
image.
This adds an explicit check to be sure it all fits. It also refactors the
region declarations to be more explicit. For vboot-enabled configurations,
CONFIG_SECTION_* - describes the extent of flash for one entire image
CONFIG_FW_* - the region within the SECTION for the firmware only
CONFIG_VBLOCK_* - the region within the RW SECTIONs for the vblocks
CONFIG_VBOOT_ROOTKEY - the region within the RO SECTION for the root key
Look at chip/lm4/config.h for the best example.
BUG=chrome-os-partner:9839
TEST=manual
Build it, run it.
Change-Id: I3c652e82d58a5328115cc750c80ecba6a3fd99a3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
And start wiring to x86_power so it can detect AC state changes
(needed to enable/disable turbo).
*YES*, this compiles for BDS/Daisy now...
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9069
TEST=plug/unplug AC power and look for "x86 AC on" / "x86 AC off" in debug log
Change-Id: I8399fab9637d6635a1c615f07448fd45b86bc25f
Charging state machine doesn't need to be able to preempt everybody.
Keyboard scanning and power button should preempt, because they need
to debounce/scan at a stable rate.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=system still boots
Change-Id: Id57c680b9fa4652bc10d19270620d63788a7b269
When the flash memory base address is not 0 (e.g. stm32), the .google
section for FMAP was badly positioned inside the EC binary.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865
TEST=make BOARD=daisy && make BOARD=link
manually verify the .map file for Daisy and boot patched Daisy EC with CONFIG_VBOOT
activated.
Change-Id: Ibc994d4d52e49dc7bc642a1a138ac533ededbcd3
Use the linker to sort console commands by name,
this saves execution time and memory.
BUG=none
TEST=generate several images with 5N, 5N+1, 5N-1 commands and check the
output of the "help" command.
Change-Id: Ib5d8f3bca726621c68ab152f4fa662cee355abb1
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
To avoid calling get_time() when the caller already knows the value, add
a parameter to timestamp_expired().
BUG=chrome-os-partner:9424
TEST=build and boot on Daisy
Change-Id: Ibb97c86f429ec4b814e17b41cbf79b612a75097a
Signed-off-by: Simon Glass <sjg@chromium.org>
This helps us keep track of how long vboot is taking on the EC.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9651
TEST=reboot system and look at debug log. time shouldn't start over after it jumps to image A.
Change-Id: Iad86e90d42dabf1c67b2c2be80dda1151cf9a288
BUG=chrome-os-partner:7459
TEST=manual
In the chroot:
cd src/platform/ec
make BOARD=link
The firmware image (build/link/ec.bin) is signed with dev-keys. Reflash the
EC and try it, and it should verify and reboot into RW A.
Additional tests (setting USE_RO_NORMAL, poking random values into VBLOCK_A
or FW_MAIN_A to force RW B to run, etc.) are left as an exercise for the
reader. I've done them and they work, though.
Change-Id: I29a23ea69aef02a11aebd4af3b043f6864723523
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
This is cleaner than having x86_power explicitly know about everything
else in the system that cares about power transitions.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=boot and shutdown system; still works. Mouse powered to system is off in S5.
Change-Id: Ib673ca2d9edd5473334e7604e98b99b02b768419
Implements the on-chip flash erasing and writing functions.
The actual writing is done from a routine in internal RAM (using the
special .iram.text section) with interrupt disabled as we cannot read
flash during the writing process.
The write-protect feature is only lightly tested.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865
TEST=run on Daisy, from the EC console, use flasherase and flashwrite
commands and observe the results using rw command.
Change-Id: I4c64cf28b23df52b18500b42a32a7d3668d45ba6
This just reserves room. It doesn't actually perform any verification yet.
BUG=chrome-os-partner:7459
TEST=manual
make BOARD=link
dump_fmap build/link/ec.bin
Change-Id: I424db1d601a614be3dfe5abb200e24e8bc62e47e
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Rather than open code this each time, create a function for this. The
wrap-around condition may not be needed, if the timer starts at zero,
since we have 64 bits to play with.
BUG=chrome-os-partner:9424
TEST=build and boot on daisy
Change-Id: I84ae651212769b5927c452bc03f31f60a25a829e
Signed-off-by: Simon Glass <sjg@chromium.org>
this fixes the build breakage on stm32-based platforms.
In the linker script, remove the ASSERT since this macro is not designed
to work in that context and this size condition is already verified by
the linker by setting the "length" of the "FLASH" memory region.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=make BOARD=link && make BOARD=daisy
boot on Link and Daisy
Change-Id: I08964749d44f47caa0a359bc93c303a9611e5d73
This is very basic, so you can only rely on RO_SECTION, RW_SECTION_A, and
RW_SECTION_B for now. We'll fill in more regions as we add vboot stuff.
Still, you should be able to do things like this:
flashrom -p internal:bus=lpc -r ec.bin
flashrom -p internal:bus=lpc -w ec.bin -i RW_SECTION:ec.B.flat
BUG=chrome-os-partner:8198
TEST=manual
Build the image, look for the FMAP in it.
cd src/platform/ec
make BOARD=link
dump_fmap ./build/link/ec.bin
Change-Id: I0adbbfb8e975faae805bda271873fcef46590cf4
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
ensure we cannot miss any timer, no matter how slow is the CPU and how
many simultaneous timer we set.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:9319
TEST=boot Link EC and do long key press, see the EC watchdog panic no
longer happening.
Change-Id: I1ecc88fc06698175444fd86cce4c0abb5e846996
1) When frequency changes, reload the watchdog timer right away, or it
may expire before the next reload. (Only matters when re-enabling the
PLL.)
2) Split out the timer/task debug output used by the watchdog into
their own routines, instead of assuming it's safe to call the command
handlers. Also make the flushes in those print routines safe to call
from interrupt level.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=waitms 1500; should print task dump again
Change-Id: I07e0ed24a526ae499566dab0bbeb0f5755cd5be6
(Or, if profiling is enabled.)
Also, track the number of task switches if profiling is enabled.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9274
TEST=taskinfo
Also test by commenting out CONFIG_TASK_PROFILING in board.h; code
should still compile and run.
Change-Id: Ib3dbce74b6ccfba2bbe18c7309136412c30f364e
This completes console output cleanup. The remaining calls to
uart_puts() and uart_printf() actually need to be that way.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7464
TEST=manual
Change-Id: Ib1d6d370d30429017b3d11994894fece75fab6ea
This adds a 'ch' command which prints/sets which channels are active
This handles all the async output; the remaining debug commands will
be refactored to use ccprintf() / ccputs() in a followup CL.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7464
TEST=manual
ch --> all channels active
ch 0x100 -> just port80 active
powerbtn -> system boots; only port 80 codes shown on console
Change-Id: I9efc43acec919b62b78c2c82c61946d32380adfe
Also tracks the distribution of IRQs, so we can see what's triggering
interrupts.
Task profiling is optional, enabled via CONFIG_TASK_PROFILING.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7464
TEST=taskinfo
Change-Id: I266f2b49bff9648cda446210d5a302b460fec244
This also changes shared_mem to use all the remaining RAM, instead of
reserving a fixed-size buffer.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9161
TEST=manual
hostevent --> all masks should be 0
hostevent smi 0x12300000
hostevent --> should confirm SMI mask was set
sysjump b
hostevent --> should confirm SMI mask is still set
reboot
hostevent --> should confirm SMI mask is back to 0
Change-Id: Iccb6da6ccc93ee5036a3f478d24b717a462d9150
This covers modules which need to initialize before task_start(), but
don't particularly care in what order they're initialized.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=if it boots, it works
Change-Id: I69829aac8d1c3c14ee04916a794b84bbf03a09eb
This will be used for sleep/wake/sysjump/etc. For now it's just wired
up to clock frequency changing.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=manual: use nopll command, should still work
Change-Id: Iedcea5830bc18eacfd955c29b8f793aba8905dd8
When we are in interrupt context and doing a task_set_event,
if we are interrupted by a timer interrupt firing, we might end
resetting the runnable bit added by the expiration of a timer (when
finishing the interrupted read-modify-write to tasks_ready).
So we need to have an atomic access there.
We don't need to atomic primitives (and the associated overhead) on other
tasks_ready accesses because there are always done at the highest
priority.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8721
TEST=from Linux, run "ectool lightbar test" several times and see that
the keyboard task no longer ends up stuck with a timer event set and no
runnable bit.
Change-Id: Ied45ee33cb6aba4549626d35d694f1c259f2400c
