diff options
author | Dino Li <Dino.Li@ite.com.tw> | 2020-05-05 11:50:47 +0800 |
---|---|---|
committer | Commit Bot <commit-bot@chromium.org> | 2020-05-13 15:46:23 +0000 |
commit | ffa5571e4d7de4dc96ba36f5069e3ff150bde071 (patch) | |
tree | 4c95daf590aefe2b193fe67dbb63c811accf1d6f /board/endeavour | |
parent | 0b034696389e0c6a9aa8b1397a49cf8548ccee05 (diff) | |
download | chrome-ec-ffa5571e4d7de4dc96ba36f5069e3ff150bde071.tar.gz |
risc-v: add comments about not needing 16-byte stack frame alignment
Since we are not actually executing on a stack frame that is not 16-byte
aligned, we are following the guidance (linked below). Add comments for
future developers to explain why.
Also, saving system stack pointer in the switch to function since the
isr function takes special care to not over write the stack pointer when
we are already using the system stack.
According to documentation, the stack frame should be 128-bit aligned
upon entering function boundaries.
"In the standard RISC-V calling convention, the stack pointer sp is
always 16-byte aligned" from
https://riscv.org/specifications/isa-spec-pdf/
"The stack grows downwards (towards lower addresses) and the stack
pointer shall be aligned to a 128-bit boundary upon procedure entry"
from
https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md
See also documentation issues discussing this
https://github.com/riscv/riscv-elf-psabi-doc/issues/21
BRANCH=none
BUG=none
TEST=ITE RISC-V FPU implementation still works
Signed-off-by: Jett Rink <jettrink@chromium.org>
Change-Id: I3460e6ee2b68c7793c72517e7d2d9bc645aaea65
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2173119
Tested-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Diffstat (limited to 'board/endeavour')
0 files changed, 0 insertions, 0 deletions