This commit updates the build spec to include the new UART drivers for
PL011 and Mini UART.
---
spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml | 1 -
spec/build/bsps/obj.yml | 7 ---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/spec/bu
This commit updates the existing BSPs to use the new PL011 driver.
---
bsps/aarch64/a53/console/console.c| 14 +-
bsps/aarch64/a72/console/console.c| 14 +-
bsps/aarch64/raspberrypi/console/console.c| 14 +-
bsps/arm/raspberrypi/console/console-c
This commit adds a new driver for the Mini UART peripheral present on
Raspberry Pi devices. It implements the termios API with support for
setting attributes. It supports interrupts through the
BSP_CONSOLE_USE_INTERRUPTS macro.
---
bsps/include/dev/serial/mini-uart.h | 54 +
bsps/shared/dev/s
This commit adds a new driver for the PL011. It uses the termios API
with support for setting attributes and interrupts. Interrupts can be
enabled using the BSP_CONSOLE_USE_INTERRUPTS macro.
---
bsps/include/dev/serial/arm-pl011-regs.h | 143 --
.../dev/serial/{arm-pl011.h => pl011.h}
This patch series adds two drivers, PL011 and Mini UART. Both support
interrupts and implement the termios API.
Why add a new driver for the PL011 when we already have one?
The existing driver is a very basic one and uses memory-mapped structs
to access the registers. This proved to be problemati
Looks ok to push
On Mon, Aug 28, 2023, 9:14 PM wrote:
> From: Chris Johns
>
> Updates #4951
> ---
> rtems/config/tools/rtems-tools-6.cfg | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/rtems/config/tools/rtems-tools-6.cfg
> b/rtems/config/tools/rtems-tools-6.cfg
>
From: Chris Johns
Updates #4951
---
rtems/config/tools/rtems-tools-6.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/rtems/config/tools/rtems-tools-6.cfg
b/rtems/config/tools/rtems-tools-6.cfg
index 6eed755..b360f7e 100644
--- a/rtems/config/tools/rtems-tools-6.cfg
+
(cross posted from discord) I did some digging and it looks like the right
macros/defines to gate on are CPU_SOFTWARE_FP and CPU_HARDWARE_FP. The FP
code in the loadable module should only be present if at least one of those
is available and the definition in the host binary should only be present
On Mon, Aug 28, 2023 at 10:31 AM Sam Price wrote:
>
> Nevermind that would be done at the linker and not at compile time.
I searched for some way to check if soft float routines are being used, but I
couldn't find anything.
Maybe we just remove the conditional altogether? I don't think it's a pr
Nevermind that would be done at the linker and not at compile time.
On Mon, Aug 28, 2023 at 11:04 AM Sam Price wrote:
>
> Just curious instead of doing #ifdef __microblaze__
> could you do
> #ifndef __extendsfdf2
>
> Or something similar to determine if the floating point symbols are known?
>
> T
Just curious instead of doing #ifdef __microblaze__
could you do
#ifndef __extendsfdf2
Or something similar to determine if the floating point symbols are known?
This would make it more portable.
On Mon, Aug 28, 2023 at 10:11 AM Alex White wrote:
>
> On Sun, Aug 27, 2023 at 11:48 PM Chris Johns
On Sun, Aug 27, 2023 at 11:48 PM Chris Johns wrote:
>
> On 28/8/2023 2:12 pm, Alex White wrote:
> > On Sun, Aug 27, 2023 at 8:38 PM Chris Johns wrote:
> >> The floats need to stay to make sure there are no issues with this type. I
> >> see
> >> the tests with floats as valid.
> >>
> >> Is the on
12 matches
Mail list logo
