When starting multitasking there is a chance an interrupt could be fired
while rsp is still pointing to the ISR stack area if we load rflags
before rsp on "_CPU_Context_restore"
This test was broken by b031cf2b19 since
it expects the macros to evaluate to an empty string for non-SMP builds.
This updates the check for the new content.
Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.
Sponsored by: Netflix
The interrupt context save is now done in the BSP. This avoids an issue
where a register is modified by the interrupt handler before it is
saved. Specifically, the MSR register was modified by the `addi`
instruction in the interrupt handler before the MSR was saved. This
caused the MSR to be saved with the wrong value.
Closes#4962
## spec/stm32h7: Default nucleo-h755zi BSP to build for CORE_M7
Some of the STM32H7 parts have a secondary Cortex M4 core included and require the user to select which core they are compiling for. The `arm/nucleo-h755zi` BSP was lacking a default core selection, causing the BSP to fail to build with the default options selected. This PR changes the default option to select the larger Cortex M7 core by default.
Use first 1GiB of the DDR RAM with the exception of a potential 64KiB NULL
pointer protection area by default. The upper part of the DDR RAM may be used
by the RPU or for dynamic memory.
The i.MXRT1166 has three iomux controllers. The driver in RTEMS
(originally for i.MX6) doesn't support that. Switching to absolute
addresses for the pins in the FDT works around that.
Compared to changing the IOMUX driver, it has the following advantages:
- If a devicetree is written, the pinctrl-groups don't have to be split
up between different iomux controllers which makes device trees simpler
to read.
- A driver or application doesn't has to handle multiple pinctrl-groups
which simplifies the drivers.
The C files that provide the device trees are generated with
rtems-bin2c. Due to that, the license information in these files is
lost. Therefore this patch adds the header manually. Also adapt the
commands that are used to generate the files to reflect that.
This makes the active level of the FDT available to the user. It doesn't
change the current behaviour. It only provides a function to get the
active or inactive level of a pin.
## Implement a new ST Nucleo STM32H755ZI BSP
Hi all, for a project I recently acquired a Nucleo STM32H755ZI. Thanks to the work of @sebhub, @c-mauderer, and Karel Gardas, it was pretty easy to create a new Nucleo BSP for this chip by copying the Nucleo H743 BSP. I was not able to get the 8 MHz HSE clock enabled, so this is currently clocked off of the PLL using the 64 MHz HSI clock and the RTC clock is disabled. Other features haven't been thoroughly tested, but since they rely on the high quality STM32H7 HAL from ST, I have pretty high confidence in them. I've been able to run most testsuites.
I have tested:
* The CM7 core
* The CM4 core
* Console output on UART3 (the default USB UART) and the shell
* GPIO
* Sample programs like `hello`, `fileio` (and shell), `paranoia`, `unlimited`, etc.
Known Broken:
* Debugging with OpenOCD is wonky. I can set breakpoints, halt the processor and inspect memory and registers and return from functions, but stepping does not work.
* The program begins to run after being flashed but soon (under 1 second) stops running. Pressing the reset button makes the program run continuously afterward. The board resets nearly instantly.
* Shell commands `ls`, `cd`, `cpuuse`, etc. hang for a while before executing. I'm not sure where the time is spent because the built-in `time` command reports that these commands execute nearly instantly.
I haven't tested:
* Pretty much everything else
<!-- Default settings, if it is a dropdown it will set after submission -->
This function may be used to ensure that a count of processors performed a set
of actions and then wait on the barrier performing only memory loads (no memory
stores).
