* ports: add Linux build scripts for Cortex-A5 SMP
* ports: fix Cortex-A5 SMP sample linking on Linux
* ports: add Linux build scripts for Cortex-A7 and A9 SMP
* ports: fix Cortex-A7 SMP assembly source path
* wip: add ATFE selection to Armv7 SMP scripts
* ports: complete Armv7 SMP Linux toolchain support
* ports: add local startup for Armv7 SMP samples
* ports: add license headers to Armv7 SMP scripts
* Dropped the preprocessing flag the file extension now carries
Two lines named assembly sources that #672 renamed. That change moved
twenty-nine files under gnu trees from .s to .S, because GAS runs the C
preprocessor on .S and not on .s: in a .s file every # line is a comment, so a
#define is never substituted and an #if/#else pair emits both arms. Four files
were silently doing the wrong thing as a result, including
ports_smp/cortex_a7_smp/gnu/src/tx_thread_smp_unprotect.s, which ignored all
four of its own feature macros.
These scripts had worked around the same defect with -x assembler-with-cpp
rather than hitting it, which was correct when they were written. With the
rename the flag is redundant and the lowercase names no longer resolve, so
cortex_a5_smp/build_threadx.sh failed with "cc1: fatal error:
tx_initialize_low_level.s: No such file or directory". The other seven
references to those two files across these three scripts already named them
with a capital S.
Verified with the pinned Arm GNU 14.3.rel1 rather than the 13.2 that a distro
package supplies: build_threadx.sh and build_threadx_sample.sh both succeed for
a5, a7 and a9, all three link a sample_threadx.out, and scripts/check_gcc.sh
passes end to end with its example stage reading 45 of 45, up from 42.
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Frédéric Desbiens <frederic.desbiens@eclipse-foundation.org>
* modules: free kernel stack on thread deletion
Signed-off-by: Prashit Vora <prashitvora2006@gmail.com>
* Preserved the thread object release when the kernel stack cannot be freed
Releasing the kernel stack ahead of the thread object made a failure of the kernel
stack deallocation abort the thread object release. The thread had already been
deleted at that point, so the thread object would have stayed allocated for the
lifetime of the module.
The thread object is now always released once the delete succeeds, and the kernel
stack failure is reported only when it does not mask a thread object failure.
---------
Signed-off-by: Prashit Vora <prashitvora2006@gmail.com>
Co-authored-by: Frédéric Desbiens <frederic.desbiens@eclipse-foundation.org>
Assisted-by: Copilot (Opus 5) <noreply@github.com>
tardigradeandFrédéric Desbiens