mirror of
https://github.com/Telecominfraproject/OpenCellular.git
synced 2026-01-10 17:41:54 +00:00
96ef35acba
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>
In the most general case, the flash layout looks something like this: +---------------------+ | Reserved for EC use | +---------------------+ +---------------------+ | Vblock B | +---------------------+ | RW firmware B | +---------------------+ +---------------------+ | Vblock A | +---------------------+ | RW firmware A | +---------------------+ +---------------------+ | FMAP | +---------------------+ | Public root key | +---------------------+ | Read-only firmware | +---------------------+ BIOS firmware (and kernel) put the vblock info at the start of each image where it's easy to find. The Blizzard EC expects the firmware vector table to come first, so we have to put the vblock at the end. This means we have to know where to look for it, but that's built into the FMAP and the RO firmware anyway, so that's not an issue. The RO firmware doesn't need a vblock of course, but it does need some reserved space for vboot-related things. Using SHA256/RSA4096, the vblock is 2468 bytes (0x9a4), while the public root key is 1064 bytes (0x428) and the current FMAP is 644 bytes (0x284). If we reserve 4K at the top of each FW image, that should give us plenty of room for vboot-related stuff.