mirror of
https://github.com/Telecominfraproject/OpenCellular.git
synced 2025-12-28 02:35:28 +00:00
e68cfa73ca
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>
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.