sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

ARMv7-A: Need 8-byte stack alignment when callign C code from interrupt handlers. This change needs to be ported to other ARM architectures as well

Browse Source
This commit is contained in:
Gregory Nutt 2013-07-23 14:47:16 -06:00
parent 14df812735
commit 812bf02972
3 changed files with 75 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
ChangeLog
View File

@ -5165,4 +5165,7 @@
definitions for the SAMA5D3 (2013-7-23).
* arch/arm/src/sama5/chip/: New header files for SAMA5 AXI Matrix
SFR, and BSC blocks (2013-7-23).
* arch/arm/src/armv7-a/arm_vectors.S: Force 8-byte stack alignment
in interrupt handlers before calling C code. Other ARM
architectures need to do this as well (2013-7-23).

83
TODO
View File

@ -1,7 +1,7 @@
NuttX TODO List (Last updated June 23, 2013)
NuttX TODO List (Last updated July 23, 2013)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This file summarizes known NuttX bugs, limitations, inconsistencies with
This file summarizes known NuttX bugs, limitations, inconsistencies with
standards, things that could be improved, and ideas for enhancements. See
also individual README.txt files in the configs/ sub-directories for each
board port.
@ -24,7 +24,7 @@ nuttx/
(1) Documentation (Documentation/)
(6) Build system / Toolchains
(5) Linux/Cywgin simulation (arch/sim)
(4) ARM (arch/arm/)
(5) ARM (arch/arm/)
(1) ARM/C5471 (arch/arm/src/c5471/)
(3) ARM/DM320 (arch/arm/src/dm320/)
(2) ARM/i.MX (arch/arm/src/imx/)
@ -149,7 +149,7 @@ o Task/Scheduler (sched/)
Title: ISSUES WITH atexit() AND on_exit()
Description: These functions execute with the following bad properties:
1. They run with interrupts disabled,
2. They run in supervisor mode (if applicable), and
3. They do not obey any setup of PIC or address
@ -426,7 +426,7 @@ o Kernel Build
the count becomes negative the caller must be blocked.
Update:
"I am thinking that there should be a "magic" global, user-accessible
"I am thinking that there should be a "magic" global, user-accessible
variable that holds the PID of the currently executing thread;
basically the PID of the task at the head of the ready-to-run list.
This variable would have to be reset each time the head of the ready-
@ -474,10 +474,10 @@ o Kernel Build
OS services within the kernel and with other OS facilities, such
as the file system, message queues, etc., residing in user-space
and to interfacing with those core OS facilities through traps.
Status: Open
Status: Open
Priority: Low. This is a good idea and certainly an architectural
improvement. However, there is no strong motivivation now do
do that partitioning work.
do that partitioning work.
o C++ Support
^^^^^^^^^^^
@ -641,7 +641,7 @@ o Binary loaders (binfmt/)
Priority: Medium-High
Title: READ-ONLY DATA IN RAM
Description: At present, all .rodata must be put into RAM. There is a
Description: At present, all .rodata must be put into RAM. There is a
tentative design change that might allow .rodata to be placed
in FLASH (see Documentation/NuttXNxFlat.html).
Status: Open
@ -676,9 +676,9 @@ o Binary loaders (binfmt/)
else
NXFLATLDSCRIPT=$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.ld
endif
Then use
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T"$(NXFLATLDSCRIPT)" -no-check-sections
Status: Open
@ -712,15 +712,15 @@ o Binary loaders (binfmt/)
.word .LC4-(.LPIC5+4)
This is good and bad. This is good because it means that .rodata.str1.1 can now
reside in FLASH with .text and can be accessed using PC-relative addressing.
reside in FLASH with .text and can be accessed using PC-relative addressing.
That can be accomplished by simply moving the .rodata from the .data section to
the .text section in the linker script. (The NXFLAT linker script is located at
nuttx/binfmt/libnxflat/gnu-nxflat.ld).
This is bad because a lot of stuff may get broken an a lot of test will need to
be done. One question that I have is does this apply to all kinds of .rodata?
be done. One question that I have is does this apply to all kinds of .rodata?
Or just to .rodata.str1.1?
Status: Open. Many of the required changes are in place but, unfortunately, not enough
go be fully functional. I think all of the I-Space-to-I-Space fixes are in place.
However, the generated code also includes PC-relative references to .bss which
@ -797,7 +797,7 @@ o Network (net/, drivers/net)
Description: At present, there cannot be two concurrent active TCP send
operations in progress using the same socket. This is because
the uIP ACK logic will support only one transfer at a time. The
solution is simple: A mutex will be needed to make sure that each
solution is simple: A mutex will be needed to make sure that each
send that is started is able to be the exclusive sender until all of
the data to be sent has been ACKed.
Status: Open. There is some temporary logic to apps/nshlib that does
@ -1001,13 +1001,13 @@ o Libraries (libc/)
Title: RESETTING GETOPT()
Description: There is an issue with the way that getopt() handles errors that
return '?'.
1. Does getopt() reset its global variables after returning '?' so
that it can be re-used? That would be required to support where
the caller terminates parsing before reaching the last parameter.
2. Or is the client expected to continue parsing after getopt()
returns '?' and parse until the final parameter?
The current getopt() implementation only supports #2.
Status: Open
Priority: Low
@ -1030,11 +1030,11 @@ o Libraries (libc/)
ferror().
Title: CONCURRENT STREAM READ/WRITE
Description: NuttX only supports a single file pointer so reads and writes
Description: NuttX only supports a single file pointer so reads and writes
must be from the same position. This prohibits implementation
of behavior like that required for fopen() with the "a+" mode.
According to the fopen man page:
"a+ Open for reading and appending (writing at end of file).
The file is created if it does not exist. The initial file
position for reading is at the beginning of the file, but
@ -1059,11 +1059,11 @@ o Libraries (libc/)
by zero, since it will result in a compile-time diagnostic, if the
implementation does not support infinity."
Status: Open
Priority:
Priority:
Title: OLD dtoa NEEDS TO BE UPDATED
Description: This implementation of dtoa in libc/stdio is old and will not
work with some newer compilers. See
work with some newer compilers. See
http://patrakov.blogspot.com/2009/03/dont-use-old-dtoac.html
Status: Open
Priority: ??
@ -1208,7 +1208,7 @@ o Graphics subystem (graphics/)
Priority: Medium. Not important for day-to-day testing but would be
a critical improvement if NxConsole were to be used in a
product.
o Pascal Add-On (pcode/)
^^^^^^^^^^^^^^^^^^^^^^
@ -1350,7 +1350,7 @@ o Linux/Cywgin simulation (arch/sim)
least, partially functional (it has never been rigorously tested).
Status: Open
Priority: Low (unless you want to test networking features on the simulation).
Title: ROUND-ROBIN SCHEDULING IN THE SIMULATOR
Description: Since the simulation is not pre-emptible, you can't use round-robin
scheduling (no time slicing). Currently, the timer interrupts are
@ -1361,7 +1361,7 @@ o Linux/Cywgin simulation (arch/sim)
irqrestore() to block and (conditionally) unblock the signal.
Status: Open
Priority: Low
Title: NSH ISSUES ON THE SIMULATOR
Descripion: The NSH example has some odd behaviors. Mult-tasking -- for example,
execution of commands in background -- does not work normally. This
@ -1455,6 +1455,31 @@ o ARM (arch/arm/)
If your design needs continous interrupts like this, please try
the above change and, please, submit a patch with the working fix.
Title: STACK ALIGNMENT IN INTERRUPT HANDLERS
Description: The EABI standard requires that the stack always have a 32-byte
alignment. There is no guaratee at present that the stack will be
so aligned in an interrupt handler. Therefore, I would expect some
issues if, for example, floating point or perhaps long long operations
were performed in an interrupt handler.
This issue exists for ARM7, ARM9, Cortex-M0, Cortex-M3, and
Cortex-M4 but has been addressed for the Cortex-A5. The fix
is really simple can cannot be incorporated without some
substantial testing. For ARM, the fix is the following logic
arround each call into C code from assembly:
mov r4, sp /* Save the SP in a preserved register */
bic sp, sp, #7 /* Force 8-byte alignement */
bl cfunction /* Call the C function */
mov sp, r4 /* Restore the possibly unaligned stack pointer */
This same issue applies to the interrupt stack which is, I think
improperly aligned in almost all cases (except Cortex-A5).
Status: Open
Priority: Low for me because I never do floating point operations in
interrupt handlers.
o ARM/C5471 (arch/arm/src/c5471/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -1590,7 +1615,7 @@ o ARM/LPC214x (arch/arm/src/lpc214x/)
Title: USB BROKEN?
Description: I tried to bring up the new configuration at configs/mcu123-214x/composite,
and Linux failed to enumerate the device. I don't know if this is
and Linux failed to enumerate the device. I don't know if this is
a problem with the lpc214x USB driver (bit rot), or due to recent
changed (e.g., -r4359 is suspicious), or an incompatibility between the
Composite driver and the LPC214x USB driver. It will take more work
@ -1698,7 +1723,7 @@ o ARM/STM32 (arch/arm/src/stm32/)
is sent, the driver works fine.
Status: Open
Priority: Medium-High
Title: DMA EXTENSIONS F1/3
Description: DMA logic needs to be extended. DMA2, Channel 5, will not work
because the DMA2 channels 4 & 5 share the same interrupt.
@ -1941,7 +1966,7 @@ o Renesas M16C/26 (arch/sh/src/m16c)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Title: M16C DOES NOT BUILD
Description: The M16C target cannot be built. The GNU m16c-elf-ld link fails with
Description: The M16C target cannot be built. The GNU m16c-elf-ld link fails with
the following message:
m32c-elf-ld: BFD (GNU Binutils) 2.19 assertion fail /home/Owner/projects/nuttx/buildroot/toolchain_build_m32c/binutils-2.19/bfd/elf32-m32c.c:482
@ -2167,7 +2192,7 @@ o z16 (arch/z16)
Title: ZDS-II COMPILER PROBLEMS
Description: The file drivers/mmcsd/mmcsd_sdio.c generates an internal compiler
error like:
mmcsd\mmcsd_sdio.c
Internal Error(0503) On line 2504 of "MMCSD\MMCSD_SDIO.C"
File <c3>, Args(562,46)
@ -2182,7 +2207,7 @@ o z16 (arch/z16)
reliable Windows native build. As of this writing, the Cygwin
based build has not been re-verified.
Status: Open
Priority: Low -- I don't think anyone uses the Z16 port.
Priority: Low -- I don't think anyone uses the Z16 port.
o mc68hc1x (arch/hc)
^^^^^^^^^^^^^^^^^^
@ -2219,7 +2244,7 @@ o Network Utilities (apps/netutils/)
Title: THE ARP ISSUES AGAIN
Description: The first GET received by THTTPD is not responded to. Refreshing the page
from the browser solves the problem and THTTPD works fine after thatg. I
from the browser solves the problem and THTTPD works fine after thatg. I
believe that this is the duplicate of another bug: "Outgoing [uIP] packets are dropped
and overwritten by ARP packets if the destination IP has not been mapped to a MAC."
Status: Open

19
arch/arm/src/armv7-a/arm_vectors.S
View File

@ -134,10 +134,15 @@ arm_vectorirq:
#if CONFIG_ARCH_INTERRUPTSTACK > 3
ldr sp, .Lirqstackbase /* SP = interrupt stack base */
str r0, [sp] /* Save the user stack pointer */
mov r4, sp /* Save the SP in a preserved register */
bic sp, sp, #7 /* Force 8-byte alignement */
bl up_decodeirq /* Call the handler */
ldr sp, [sp] /* Restore the user stack pointer */
ldr sp, [r4] /* Restore the user stack pointer */
#else
mov r4, sp /* Save the SP in a preserved register */
bic sp, sp, #7 /* Force 8-byte alignement */
bl up_decodeirq /* Call the handler */
mov sp, r4 /* Restore the possibly unaligned stack pointer */
#endif
/* Restore the CPSR, SVC modr registers and return */
@ -192,7 +197,10 @@ arm_vectorswi:
mov fp, #0 /* Init frame pointer */
mov r0, sp /* Get r0=xcp */
mov r4, sp /* Save the SP in a preserved register */
bic sp, sp, #7 /* Force 8-byte alignement */
bl up_syscall /* Call the handler */
mov sp, r4 /* Restore the possibly unaligned stack pointer */
/* Restore the CPSR, SVC modr registers and return */
@ -262,7 +270,10 @@ arm_vectordata:
mov r0, sp /* Get r0=xcp */
mrc CP15_DFAR(r1) /* Get R1=DFAR */
mrc CP15_DFSR(r2) /* Get r2=DFSR */
mov r4, sp /* Save the SP in a preserved register */
bic sp, sp, #7 /* Force 8-byte alignement */
bl arm_dataabort /* Call the handler */
mov sp, r4 /* Restore the possibly unaligned stack pointer */
/* Restore the CPSR, SVC modr registers and return */
@ -335,7 +346,10 @@ arm_vectorprefetch:
mov r0, sp /* Get r0=xcp */
mrc CP15_IFAR(r1) /* Get R1=IFAR */
mrc CP15_IFSR(r2) /* Get r2=IFSR */
mov r4, sp /* Save the SP in a preserved register */
bic sp, sp, #7 /* Force 8-byte alignement */
bl arm_prefetchabort /* Call the handler */
mov sp, r4 /* Restore the possibly unaligned stack pointer */
/* Restore the CPSR, SVC modr registers and return */
@ -403,7 +417,10 @@ arm_vectorundefinsn:
mov fp, #0 /* Init frame pointer */
mov r0, sp /* Get r0=xcp */
mov r4, sp /* Save the SP in a preserved register */
bic sp, sp, #7 /* Force 8-byte alignement */
bl arm_undefinedinsn /* Call the handler */
mov sp, r4 /* Restore the possibly unaligned stack pointer */
/* Restore the CPSR, SVC modr registers and return */