| Commit message (Collapse) | Author | Files | Lines |
|
Merge the timecounter and CPU counter support for the leon3 BSP family.
Remove now unused functions from the CPU counter support of the erc32
and leon3 BSPs.
Update #4954.
|
|
Enable a BSP-specific CPU counter implementation.
Update #4954.
|
|
|
|
It is too big with GCC 13.
|
|
Updates #4949
|
|
Updates #4948
|
|
This fixes unaligned data access exceptions found while debugging test
dl05.
|
|
Update #3767
|
|
This implementation disables the MMU during the modification of the
translation table. This behaviour is required by boot loaders for these
boards.
|
|
Replace --rtems-version with a PROGRAM_PREFIX option. This allows also
the use of vendor tools.
|
|
|
|
|
|
This reverts commit 26d50bdfb601b9ef71ec2b30d2d9467c2437f443.
|
|
This allows to use a I2C RTC together with this BSP.
|
|
The MCP7940M is a I2C RTC chip. The new driver uses the dev/i2c API to
support the RTC. It is written with the intention, that the driver can
be adapted to other RTCs with a similar register layout by just
replacing the initialization function.
|
|
|
|
This allows application and library build systems to derive option
values from the BSP base and family names.
|
|
|
|
This change allows for the pins assigned to UART7 to be reconfigured via
config.ini.
|
|
The BSP is for a custom i.MXRT1166 based board. At the moment, only the
cortex M7 is supported.
|
|
The flash configuration is something very board specific. So move the
file to a board specific location. Beneath that, not all controllers and
configurations need the flash config right at the address 0 of the
flash. For example on the i.MXRT11xx, the config has an offset for some
flash types.
|
|
Useful for creating an application specific device tree that is based on
the evaluation board.
|
|
This adds support for the STM32H750B-DK discovery kit. This kit includes
a built-in STLINKv3 debugger which provides a USB serial bridge for
USART3. USART1 is routed to the Arduino header and USART2 is routed to
the STMOD connector. This BSP reuses what would otherwise be duplicated
files from the stm32h747i-disco BSP. Note that system_stm32h7xx.c has
been imported from the STM repository with two minor changes wrapped
with #if __rtems__. This hardware has been tested with hello and ticker.
|
|
|
|
Remove the BSP_POWER_DOWN_AT_FATAL_HALT BSP option. Applications should
do the customization of the system termination with an initial fatal
extension.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Separate the probing of the interrupt controller from the
initialization.
|
|
QEMU is known to fail certain tests intermittently due to clock tick
delivery issues. This defines those tests as intermittent for BSPs
intended to run on QEMU alone.
Updates #4922
Updates #4072
|
|
There is no point in wasting precious memory space on enforced section
alignment for the purpose of MPU which is not implemented on M4 core
anyway.
|
|
|
|
Update #3269.
|
|
|
|
The embedded brains GmbH & Co. KG is the legal successor of embedded
brains GmbH.
|
|
Depending on the chip variant, the OCRAM can have different addresses.
Make it configurable.
|
|
Move the files that are board specific and not specific to the chip
family into a separate folder.
|
|
Remove the old NXP MCUXpresso SDK and adapt the BSP so that it uses the
new mcux-sdk.
|
|
This imports new files from the mcux-sdk support library. NXP now offers
the library as a git repository instead of a zip package. The git
repository supports multiple CPUs from the i.MXRT family:
https://github.com/nxp-mcuxpresso/mcux-sdk.git
The imported files are from revision
2b9354539e6e4f722749e87b0bdc22966dc080d9
This revision is the same as MCUXpresso 2.13.0 with small bug fixes.
For importing the files, a script has been used, that parses the
mcux-sdk cmake files and creates the yaml files for RTEMS:
https://raw.githubusercontent.com/c-mauderer/nxp-mcux-sdk/d21c3e61eb8602b2cf8f45fed0afa50c6aee932f/export_to_RTEMS.py
|
|
The embedded brains GmbH & Co. KG is the legal successor of embedded
brains GmbH.
|
|
The number of GPIO devices along with each of their particular
configurations is application-specific. Encoding this information as
build options also introduced a lot of clutter.
|
|
The new amd64efi BSP supports:
- multiboot2 boot format. Runs well with GRUB.
- console based on either EFI simple text output or GOP-based framebuffer
- clock based on EFI event/timer API
- early console using either hard-wired PC-AT serial or just memory buffer
- with EFI support disabled the BSP is more or less equivalent to amd64 BSP
with multiboot2 support
|
|
|