The functions lpc24xx_uart_set_register() and
lpc24xx_uart_set_register() were unused if all of the
feature macros LPC24XX_CONFIG_CONSOLE and LPC24XX_CONFIG_UART_[123]
were undefined.
lpc32xx_mlc_write_blocks() had a different prototype in the header
from the implementation. Changed to match the prototype and Doxygen.
LPC32XX_SCRATCH_AREA_SIZE was tested with "ifdef" not "if" which
resulted in it being used as an array size when undefined or
set to 0.
This header file defines multiple empty structures which are
reported as errors by the test spstdc17 using GCC 15. Added an element
named "unused" to each structure. The macro LPC32XX_FILL() was
checked to ensure it handles the modified structure correctly.
Closes#5295.
Removed all uses and implementations of set_vector() function across ERC32,
LEON2, and LEON3 BSPs. Replaced with rtems_interrupt_handler_install() and
rtems_interrupt_entry_install().
- Added ERC32_Clear_and_unmask_interrupt() and LEON_Clear_and_unmask_interrupt()
for unmasking logic previously in set_vector().
- Deleted set_vector() definitions and implementations in each BSP.
- Updated related obj.yml files.
- Replaced set_vector() with rtems_interrupt_catch() in shared/gnatcommon.c.
The list formerly included the erc32 and pc386 varants which do not
support multi-core. Added the pc386 variants which include the
support necessary for multi-core.
This BSP supports a custom STM32U5 based board. It uses a similar
structure like the existing STM32H7 BSP and therefore should be well
adaptable to other boards.
Co-authored-by: Christian Mauderer <christian.mauderer@embedded-brains.de>
Some fixes where necessary to not handle ARMv8M identical to (for
example) ARMv8A. ARMv8M is more similar to ARMv7M.
Co-authored-by: Christian Mauderer <christian.mauderer@embedded-brains.de>
Include armv7m_cachel1.h in core_cm33.h file to allow access to
cache functions.
Co-authored-by: Christian Mauderer <christian.mauderer@embedded-brains.de>
Files are imported from https://github.com/ARM-software/CMSIS_5 revision
55b19837f5703e418ca37894d5745b1dc05e4c91
Like already checked in RTEMS commit
6b2318acef, the project still don't have a
NOTICE file.
If the Double Trap Extension is implemented, the
MDT bit of the mstatus (or mstatush in RV32)
register will be set when a trap is to be taken.
The MIE (Machine Interrupt Enable) bit can only
be set to 1 if the MDT bit is zero.
Thus, we need to clear MDT first if we want to
enable interrupts when dispatching a thread.
MDT is also cleared in register a1 before
restoring the interrupt frame as writing 1 to MDT
will cause MIE to be set to 0. In RV64 this
happens regardless of the value written to MIE in
the same write.
In RV32, MDT is in the mstatush so we do not need
to clear during restore as this register is not
restored.
With this change all 60 SMP tests pass (compared
to 20/60 before the fix). The tests have been run
on hardware using two RV64 CPUs that implement
the double trap extension.
Update #5274
- Modified the psximfs01 test to validate the functionality
- Modified the IMFS_fs_info_t keeping the jnode counter
- Added imfs_statvfs.c which sets the statvfs struct fields for imfs
Avoid reading from the pl011 data register unnecessarily. There is no
need to preserve the contents of this register as it is not normal
memory. This unnecessary read causes console spam when running under the
Xen hypervisor when the read FIFO is empty since the read is not
expected.
Before, the console driver needed
`BSP_CONSOLE_USE_INTERRUPTS` to be defined or it
would not build. The intent was to use polled
mode if the macro was equal to zero.
This change makes it so interrupt mode is used if
the macro is defined and polled mode is used if
the macro is not defined.
The old logic would lead to an error when
multiprocessing was enabled and
`LEON3_GPTIMER_BASE` was defined due to
`leon3_timer_core_index` being undefined.
The new logic fixes this and keeps the same
intent:
- If multiprocessing is not enabled, the timer
index is 0
- If multiprocessing is enabled and
`LEON3_GPTIMER_BASE` is defined, the timer
index is twice the CPU boot index
- If multiprocessing is enabled and
`LEON3_GPTIMER_BASE` is not defined, we
fallback to the old logic using the GPTIMER
core index.
Close#5258
- Provide an option for a file system to support close wtih
references held. This can happen in more complex file systems
and file descriptor handling with more complete reference
handling implementations where an fd can hold other fds and
close can be call on any fd and succeed.
- Fix open IOP leaks in the error paths.
- Provide better definition of the IOP flags to help clarify
the code.
Fixes#5201
The gen5200, gen83xx, and tqm8xx BSP families have multiple variants
which produced the same stray semi-colon warning from GCC 15 for
using LINKER_SYMBOLS() with a semi-colon at the end of the line.
Closes#5277.
This zlib source is a hacked down version just for the decompression
phase for the bootloader used by this family of BSPs. The proper
fix is to redo the hackery with a new version of zlib. But that
is risky so this is just addressing the warnings.
Updates #5276
GCC 14 generates an error for the wrong signature function being
passed in. The underlying type was a void * so adjusting the
signature of the ISR handler was not an option. Added cast.
Closes#5272
Provide missing GCC atomics helpers as part of BSPs where GCC
does not know how to provide it since the CPU's ISA has no
atomic instructions. The implementation provided in
bsps/shared/atomics/__atomic_test_and_set.c should work
on any single core CPU.
The BSPs that need thie function tend to have older cores. This
is the list of BSPs:
arm - csb336, csb337, csb637, edb7312, gumstix, kit637_v6, lpc24xx_ea,
lpc24xx_ncs_ram, lpc24xx_ncs_rom_ext, lpc24xx_ncs_rom_int,
lpc24xx_plx800_ram, lpc24xx_plx800_rom_int, lpc32xx_mzx,
lpc32xx_mzx_stage_1, lpc32xx_mzx_stage_2, lpc32xx_phycore,
rtl22xx, rtl22xx_t, smdk2410
m68k - av5282, mcf5329
mips - jmr3904
moxie - moxiesim
nios2 - nios2_iss
riscv - grv32i, grv32im, niosvc10lp, noel32im, rv32i, rv32im,
sparc - ut699
GCCC 14 introduced a linking warning about not knowing which
__sync_synchronize implementation to use. The BSPs impacted
are updated in this commit. The suggested correction is to
use -specs to pick up a GCC specific specs file which changes
__sync_synchronize to the desired implementation
__sync_synchronize_MECHANISM. Using this solution ties
the code to GCC 14+ since the spec files are not in GCC 13.
This solution maps __sync_synchronize to a RTEMS specific
__sync_synchronize implementation which avoids using of a
GCC extension and requiring GCC 14+,
Closes#5268
