On 27.03.24 18:34, Kinsey Moore wrote:
Constant reinitializations for BSP_output_char causes loss of output
data on QEMU. This change only initializes the UART once.
This is also fixed by my recent UART patch set. I would prefer to clean
up this copy and paste nightmare.
--
embedded brains
Constant reinitializations for BSP_output_char causes loss of output
data on QEMU. This change only initializes the UART once.
---
bsps/arm/xilinx-zynqmp-rpu/console/console-config.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
The PowerPC e7400 executables I built for the PowerPC-Beatnik BSP have an
architecture of "powerpc:e500". I assume it is like this for any powerpc
target that includes "ppc_exc_initialize.c". This causes "GDB" to use the wrong
size register set in remote debugging, and I couldn't figure out
On Mon, Mar 25, 2024 at 3:34 PM Bernd Moessner
wrote:
>
> On 25.03.2024 13:26, Sebastian Huber wrote:
> > Hello,
> >
> > the BSPs for the Xilinx Zynq/ZynqMP/Versal platforms use code from
> > Xilinx. They also install some header files from Xilinx in the
> > top-level include directory of the
On 25.03.24 21:44, berndmoessne...@gmail.com wrote:
From: Bernd Moessner
---
bsps/include/bsp/irq-generic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsps/include/bsp/irq-generic.h b/bsps/include/bsp/irq-generic.h
index 5ed9cac688..31f345486f 100644
---
On 25.03.24 21:36, Bernd Moessner wrote:
On 25.03.2024 13:26, Sebastian Huber wrote:
Hello,
the BSPs for the Xilinx Zynq/ZynqMP/Versal platforms use code from
Xilinx. They also install some header files from Xilinx in the
top-level include directory of the BSP, for example:
sleep.h
Add a multilib with workarounds for Cortex-A53 errata.
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
gcc/config.gcc | 1 +
This adds some information about loading the RPU TCMs from A53 u-boot
and additional information about debugging the RPU within QEMU since it
is non-standard.
---
user/bsps/arm/xilinx-zynqmp-rpu.rst | 35 ++---
1 file changed, 27 insertions(+), 8 deletions(-)
diff --git
From: Bernd Moessner
---
bsps/include/bsp/irq-generic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsps/include/bsp/irq-generic.h b/bsps/include/bsp/irq-generic.h
index 5ed9cac688..31f345486f 100644
--- a/bsps/include/bsp/irq-generic.h
+++
On 25.03.2024 13:26, Sebastian Huber wrote:
Hello,
the BSPs for the Xilinx Zynq/ZynqMP/Versal platforms use code from
Xilinx. They also install some header files from Xilinx in the
top-level include directory of the BSP, for example:
sleep.h xbasic_types.h xil_assert.h xil_cache.h
From: Bernd Moessner
---
rtemslwip/include/netstart.h | 8
1 file changed, 8 insertions(+)
diff --git a/rtemslwip/include/netstart.h b/rtemslwip/include/netstart.h
index 807183a..82cefce 100644
--- a/rtemslwip/include/netstart.h
+++ b/rtemslwip/include/netstart.h
@@ -30,6 +30,10 @@
On Mon, Mar 25, 2024 at 3:40 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello,
>
> I noticed that the aarch64/xilinx-zynqmp BSPs use -mno-outline-atomics.
> However, we don't have a corresponding multilib for this. So for
> example, the C++ standard library still uses
Hello,
the BSPs for the Xilinx Zynq/ZynqMP/Versal platforms use code from
Xilinx. They also install some header files from Xilinx in the top-level
include directory of the BSP, for example:
sleep.h xbasic_types.h xil_assert.h xil_cache.h xil_exception.h
xil_io.h xil_mem.h xil_printf.h
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
gcc/config.gcc | 1 +
gcc/config/aarch64/t-aarch64-rtems | 41 ++
2 files
Hello,
I noticed that the aarch64/xilinx-zynqmp BSPs use -mno-outline-atomics.
However, we don't have a corresponding multilib for this. So for
example, the C++ standard library still uses -moutline-atomics. I
suggest to add this option to a Cortex-A53 specific multilib. See also:
On 21.03.24 20:28, Gedare Bloom wrote:
Two basic questions:
Does the priority field type need to be Architecture- or BSP-defined
or is uint32_t always going to be fine.
In theory, the priority range depends on the interrupt controller
implementation. However, an uint32_t should be more than
On 22.03.24 16:10, Kinsey Moore wrote:
Putting these UART addresses in BSP options suggests that they're
user-configurable when they aren't. ZynqMP can use the ZYNQMP_UART0/1
from bsps/include/peripheral_maps/xilinx_zynqmp.h, but Zynq would need
its own peripheral map to reference.
This UART
On 22.03.24 20:57, Gedare Bloom wrote:
In some other architectures we have had "generic" BSP targets. It
would be good to have something following the lp64 part. I'm not
quite clear on what the purpose of this generic BSP target is here.
For this platform, there is no need for having specific
On 22.03.24 16:48, Kinsey Moore wrote:
This patch looks good. I would suggest dropping the a53 from the BSP
name since all AArch64 ZynqMP BSPs will run on the A53 cores.
We should keep this name. Maybe Xilinx provides a Zynq variant with
other cores in the future and for the Cortex-A53 we
Thanks! Just for clarification, should I create a new ticket for this
specific bug and then add "Closes #" to the commit message?
On Sat, Mar 23, 2024 at 12:08 PM Joel Sherrill wrote:
> This is a great explanation. Would you mind filing a ticket with this
> explanatino and referencing the
Fixes #1977: Previously, the 'mode' argument in
`mq_open` was accepted but not utilized.
---
cpukit/posix/src/mqueueopen.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/cpukit/posix/src/mqueueopen.c b/cpukit/posix/src/mqueueopen.c
index d01421a0c1..8f8c1c8634 100644
---
This is a great explanation. Would you mind filing a ticket with this
explanatino and referencing the ticket in the commit message of the patch?
When someone wonders about the change in the future, the ticket explanation
will be useful
On Fri, Mar 22, 2024 at 9:24 PM Matheus Pecoraro wrote:
>
I kept getting a general protection fault whenever attempting to
execute the amd64 BSP while preparing for my GSOC proposal.
The GPF was being caused by an instruction attempting to move an SSE
register to an address on the stack not aligned to 16 bytes. After
some debugging I noticed that the
Makes the code in bsp/x86_64/amd64/start/start.S and the stack frame
setup by _CPU_Context_Initialize align the stack properly according to
what is expected by the x86-64 SysV ABI
---
bsps/x86_64/amd64/clock/eficlock.c| 28 ++-
bsps/x86_64/amd64/start/start.S
In some other architectures we have had "generic" BSP targets. It
would be good to have something following the lp64 part. I'm not
quite clear on what the purpose of this generic BSP target is here.
On Fri, Mar 22, 2024 at 9:48 AM Kinsey Moore wrote:
>
> This patch looks good. I would suggest
ok
On Fri, Mar 22, 2024 at 3:32 AM Sebastian Huber
wrote:
>
> ---
> cpukit/include/rtems/score/basedefs.h | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/basedefs.h
> b/cpukit/include/rtems/score/basedefs.h
> index
LGTM, thanks!
On Fri, Mar 22, 2024 at 1:11 AM Sebastian Huber
wrote:
>
> Update #4862.
> ---
> bsp-howto/clock.rst | 34 ++
> 1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/bsp-howto/clock.rst b/bsp-howto/clock.rst
> index 043083f..ed83472
This patch looks good. I would suggest dropping the a53 from the BSP name
since all AArch64 ZynqMP BSPs will run on the A53 cores.
Kinsey
On Mon, Mar 18, 2024 at 11:30 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Add a BSP variant without a board-specific name.
> ---
>
This patch looks good.
Kinsey
On Mon, Mar 18, 2024 at 11:30 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Add a BSP variant without a board-specific name.
> ---
> .../arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml | 87 +--
>
This patch looks good.
Kinsey
On Mon, Mar 18, 2024 at 11:30 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> ---
> spec/build/bsps/objxilinxsupportr5.yml | 3 +--
> spec/build/bsps/optxilsupportpath.yml | 2 +-
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git
---
cpukit/include/rtems/score/basedefs.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/cpukit/include/rtems/score/basedefs.h
b/cpukit/include/rtems/score/basedefs.h
index 4f28e6a525..010728d795 100644
--- a/cpukit/include/rtems/score/basedefs.h
+++
Make the initialization and polled functions independent of the Termios
context. This helps to implement the kernel I/O support without a dependency
on the Termios framework.
---
bsps/aarch64/xilinx-zynqmp/console/console.c | 23 ---
bsps/arm/xilinx-zynq/console/debug-console.c |
Replace the BSP_CONSOLE_MINOR BSP option for the Xilinx Zynq BSPs with the new
BSP option ZYNQ_UART_KERNEL_IO_BASE_ADDR. Move the kernel I/O support to a
shared file.
---
bsps/aarch64/xilinx-zynqmp/console/console.c | 41 ++
bsps/arm/xilinx-zynq/console/console-config.c | 50
This helps to provide a shared implementation of the kernel I/O support.
---
bsps/aarch64/xilinx-zynqmp/console/console.c | 4 ++--
bsps/arm/xilinx-zynq/console/console-config.c | 5 +++--
.../console/console-config.c | 4 ++--
.../xilinx-zynqmp/console/console-config.c|
Sebastian Huber (3):
dev/serial: Simplify some Zynq UART functions
dev/serial: Add ZYNQ_UART_[01]_BASE_ADDR
dev/serial: Add Zynq UART kernel I/O support
bsps/aarch64/xilinx-zynqmp/console/console.c | 58 +++
bsps/arm/xilinx-zynq/console/console-config.c | 49
Update #4862.
---
bsp-howto/clock.rst | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/bsp-howto/clock.rst b/bsp-howto/clock.rst
index 043083f..ed83472 100644
--- a/bsp-howto/clock.rst
+++ b/bsp-howto/clock.rst
@@ -139,6 +139,9 @@ Simple
On 21/3/2024 5:39 pm, Sebastian Huber wrote:> On 21.03.24 00:28, Chris Johns
wrote:
>> On 21/3/2024 2:11 am, Sebastian Huber wrote:
>>> On 19.03.24 18:44, Chris Johns wrote:
On 20/3/2024 2:03 am, Sebastian Huber wrote:
> On 19.03.24 14:50, Kinsey Moore wrote:
>> The xilinx-zynqmp-rpu
Generally this looks ok to me, but please update
https://docs.rtems.org/branches/master/bsp-howto/clock.html#initialization
https://docs.rtems.org/branches/master/bsp-howto/clock.html#support-at-tick
to explain how this arg works.
On Wed, Mar 20, 2024 at 8:29 AM Sebastian Huber
wrote:
>
> Pass
Two basic questions:
Does the priority field type need to be Architecture- or BSP-defined
or is uint32_t always going to be fine.
Does changing (increasing) the priority of a vector from within
interrupt context possibly cause a pending interrupt to post that was
previously at a lower priority
On Thu, Mar 21, 2024 at 9:06 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 21.03.24 15:05, Joel Sherrill wrote:
> > Isn't this content generated from rtems-central?
>
> Yes, it is generated.
>
> >
> > Shouldn't there also be a change there?
>
> It should be there:
>
OK.
On 21.03.24 15:05, Joel Sherrill wrote:
Isn't this content generated from rtems-central?
Yes, it is generated.
Shouldn't there also be a change there?
It should be there:
Module:rtems-central
Branch:master
Commit:f5e42e5d9fae95e50f41a2ed71ee94e9908612c0
Changeset:
Isn't this content generated from rtems-central?
Shouldn't there also be a change there?
--joel
On Wed, Mar 20, 2024 at 9:24 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Close #4986.
> ---
> c-user/config/general.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On 21.03.24 00:28, Chris Johns wrote:
On 21/3/2024 2:11 am, Sebastian Huber wrote:
On 19.03.24 18:44, Chris Johns wrote:
On 20/3/2024 2:03 am, Sebastian Huber wrote:
On 19.03.24 14:50, Kinsey Moore wrote:
The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
file for
Screenshot: https://i.ibb.co/NTxGCj6/Screenshot-2024-03-20-22-41-54.png -
Modified the sample hello world to print the popular dialogue "Oh, Hi Mark"
from the movie "The Room" by Tommy Wiseau.
Abhinav Srivastava (1):
Modify hello world sample for GSoC task
testsuites/samples/hello/init.c |
---
testsuites/samples/hello/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index 83f6342ab3..f1c5983ad2 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -41,7 +41,7
Hi
Did gprof support some along as a side-effect of gcov support?
Any hints on getting it working appreciated.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On 21/3/2024 2:11 am, Sebastian Huber wrote:
> On 19.03.24 18:44, Chris Johns wrote:
>> On 20/3/2024 2:03 am, Sebastian Huber wrote:
>>> On 19.03.24 14:50, Kinsey Moore wrote:
The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
file for the new option. Its family
---
testsuites/samples/hello/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index 83f6342ab3..5ebcdc9ef2 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -41,7 +41,7
Move declarations of bsp_interrupt_get_affinity() and
bsp_interrupt_set_affinity() to . Canonicalize the
includes.
Implement bsp_interrupt_get_affinity() and bsp_interrupt_set_affinity() only if
needed (usually RTEMS_SMP).
Provide stub implementations for i386 to fix build errors.
---
The parameters are unused due to API constraints. The functions are
used through function pointers. Alternative implementations may use the
parameters.
Close #4862.
---
bsps/sparc/leon3/start/bspclean.c | 1 +
cpukit/score/src/threadchangepriority.c | 1 +
cpukit/score/src/threadq.c
On 19.03.24 18:44, Chris Johns wrote:
On 20/3/2024 2:03 am, Sebastian Huber wrote:
On 19.03.24 14:50, Kinsey Moore wrote:
The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
file for the new option. Its family differs from the arm/xilinx-zynqmp BSP
family with a -rpu
Pass the parameter of the clock interrupt handler to
Clock_driver_support_at_tick() and Clock_driver_timecounter_tick(). This makes
it possible to use the interrupt handler argument in clock drivers.
Use the interrupt handler provided by Clock_driver_support_install_isr() to
avoid local
Close #4986.
---
c-user/config/general.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/c-user/config/general.rst b/c-user/config/general.rst
index 5ff79e7..61bfa1e 100644
--- a/c-user/config/general.rst
+++ b/c-user/config/general.rst
@@ -1017,7 +1017,7 @@ configured, see
On 20.03.24 15:14, Joel Sherrill wrote:
This is generally ok but it contradicts the documented behavior
for CONFIGURE_TICKS_PER_TIMESLICE which states "The value of the
configuration option shall be greater than or equal to zero."
This is the problem of the referenced ticket:
This is generally ok but it contradicts the documented behavior
for CONFIGURE_TICKS_PER_TIMESLICE which states "The value of the
configuration option shall be greater than or equal to zero."
If zero is to be an error, then that needs to change.
Further, this series of changes has made me realize
Hello John,
On 3/19/24 16:53, John Howard wrote:
P.S.: UTF32 exists for Unicode in 2012 after consolidation from ISO 10646-2012.
The two standards merged.
Oops. I am apparently outdated ...
Frank
--
embedded brains GmbH & Co. KG
Herr Frank KÜHNDEL
Dornierstr. 4
82178 Puchheim
Germany
email:
Hello,
I added a ticket for a proposal for an API to get and set interrupt
priorities for interrupt vectors:
https://devel.rtems.org/ticket/5002
I would like to implement this API at least for the BSPs using the
ARM/AArch64 GIC.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Unconditionally make a CONFIGURE_TICKS_PER_TIMESLICE value less than or equal
to zero an error.
Update #4986.
---
cpukit/doxygen/appl-config.h | 2 +-
cpukit/include/rtems/confdefs/clock.h | 3 +--
testsuites/ada/tmtests/tm01/init.c| 1 -
On 19/3/2024 7:39 pm, Sebastian Huber wrote:
> Make the kernel I/O output character device flushing configurable. The
> bsp_reset() function should reset the unit and do nothing else.
This changes existing behaviour. RTEMS is poor at cleanly handling the console
output on reset. Working with the
On 20/3/2024 2:03 am, Sebastian Huber wrote:
> On 19.03.24 14:50, Kinsey Moore wrote:
>> The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
>> file for the new option. Its family differs from the arm/xilinx-zynqmp BSP
>> family with a -rpu suffix.
>
> Yes, but this BSP is
On 19.03.24 18:34, Chris Johns wrote:
I will build the BSPs for each commit today.
Thanks. The reason I raised this is GitLab can squash merges to `main` and the
reason is always being able to bisect `main` so it is an issue being considered.
This patch set made me wonder what we do now?
I
On 19/3/2024 5:59 pm, Sebastian Huber wrote:
> On 19.03.24 03:21, Chris Johns wrote:
>> Does this patch series build at the per commit level?
>
> I used
>
> ./waf bspdefaults > a.txt
> apply patch
> ./waf bspdefaults > b.txt
> diff a.txt b.txt
>
> to check that the defaults don't change.
On 19/3/2024 5:52 pm, Sebastian Huber wrote:
> On 19.03.24 03:20, Chris Johns wrote:
>> On 19/3/2024 3:30 am, Sebastian Huber wrote:
>>> ---
>>> spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml | 2 +-
>>> spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml | 2 +-
>>>
Sebastian,
Looks good with me. Stanislav also gave approval.
-Phil
From: Stanislav Pankevich
Sent: Tuesday, March 19, 2024 5:45 PM
To: Philip Kirkpatrick
Subject: WG: [PATCH 3/5] xilinx-zynqmp-rpu: Remove URLs from copyrights
A 32 bit character type is supported by FreeBSD.
Unicode 2012 says utf32 must be a 32 bit signed integer. Unicode only defines
the Codepoint character attribute.
RTEMS now uses libBSD and newlib. Need kernel to support the Codepoint range of
values. Applications can then use additional
Provide arm_gic_irq_processor_count() only in SMP configurations.
---
bsps/include/dev/irq/arm-gic-irq.h | 2 ++
bsps/shared/dev/irq/arm-gicv2.c| 2 ++
bsps/shared/dev/irq/arm-gicv3.c| 2 ++
3 files changed, 6 insertions(+)
diff --git a/bsps/include/dev/irq/arm-gic-irq.h
On 19.03.24 14:50, Kinsey Moore wrote:
The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the
spec file for the new option. Its family differs from the
arm/xilinx-zynqmp BSP family with a -rpu suffix.
Yes, but this BSP is quite new. I would prefer to let it not flush
anything
Hi Chris,
On 3/19/24 03:24, Chris Johns wrote:
On 16/3/2024 1:14 am, Frank Kühndel wrote:
Ping!
The last discussion of this patch was
https://lists.rtems.org/pipermail/devel/2024-February/077289.html
Does the fact that I recive no further comments to this patch mean it can be
pushed to
The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
file for the new option. Its family differs from the arm/xilinx-zynqmp BSP
family with a -rpu suffix. I'd be fine with this being enabled for the
AArch64 BSPs as well, but I imagine that's better as a separate patch.
Hello Sebastian,
I have also reviewed the other changes that we now have since the original BSP
patch, and it looks like our current queue for Zynq RPU is empty.
We are curious to see which changes/rework for RPU you are preparing.
Thanks,
Stanislav
Von:
Hello John,
just a side node:
Strictly speaking UTF32 does not exist [1]. The correct name is UCS-4
(i.e store each character in four bytes). "Current plans are that there
will never be characters assigned outside the 21-bit code space from
0x00 to 0x10" [2].
References:
[1]
Hello Stanislav,
that is a nice coincidence. I started to work with this BSP last week
and I also fixed this issue, but I had some other patches in the queue.
I reworked this driver a bit. I will check in your patch first.
On 19.03.24 10:54, Stanislav Pankevich wrote:
Dear RTEMS developers,
Dear RTEMS developers,
Here is a follow-up patch to our previous work on the Zynq US+ RPU BSP.
In fact, we had fixed this issue a few months ago but didn't find a good time
to upstream it since then.
P.S. It is great to see that the migration to GitLab is happening.
Thanks,
Stanislav
---
Make the kernel I/O output character device flushing configurable. The
bsp_reset() function should reset the unit and do nothing else.
The arm/xilinx-zynq and arm/xilinx-zynqmp BSPs were the only ones doing an UART
flush in bsp_reset(). The bsp_reset() function should reset the system and do
On 19.03.24 03:21, Chris Johns wrote:
Does this patch series build at the per commit level?
I used
./waf bspdefaults > a.txt
apply patch
./waf bspdefaults > b.txt
diff a.txt b.txt
to check that the defaults don't change. I will build the BSPs for each
commit today.
--
embedded brains GmbH
On 18.03.24 21:31, Kinsey Moore wrote:
Sorry, I didn't realize I had tests turned off in my local build when I
checked this. The test is now gated behind NEEDS_CLOCK_DRIVER as well.
This is fine for fixing the build, but I would rather fix the tests.
Applications may have there own clock
On 19.03.24 03:20, Chris Johns wrote:
On 19/3/2024 3:30 am, Sebastian Huber wrote:
---
spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml| 2 +-
spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml | 2 +-
spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml | 2 +-
On 19.03.24 03:16, Chris Johns wrote:
On 19/3/2024 3:49 am, Sebastian Huber wrote:
Make the kernel I/O output character device flushing configurable. The
bsp_reset() function should reset the unit and do nothing else.
---
bsps/aarch64/xilinx-zynqmp/console/console.c | 3 ++-
On 16/3/2024 1:14 am, Frank Kühndel wrote:
> Ping!
>
> The last discussion of this patch was
> https://lists.rtems.org/pipermail/devel/2024-February/077289.html
>
> Does the fact that I recive no further comments to this patch mean it can be
> pushed to the RTEMS User Manual as it is?
Sorry
On 19/3/2024 1:27 am, Joel Sherrill wrote:
> I am going through the logs on the test sweep VMs to see why some builds are
> failing. This is due to gdb's requirement for GMP and MPFR. What's the
> recommended way to address this? Load native packages?
No, we need to add support to build them. We
Does this patch series build at the per commit level?
Chris
On 19/3/2024 3:30 am, Sebastian Huber wrote:
> ---
> spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml| 6 +-
> spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml | 6 +-
> spec/build/cpukit/optsmp.yml | 6
On 19/3/2024 3:30 am, Sebastian Huber wrote:
> ---
> spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml| 2 +-
> spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml | 2 +-
> spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml | 2 +-
>
On 19/3/2024 3:49 am, Sebastian Huber wrote:
> Make the kernel I/O output character device flushing configurable. The
> bsp_reset() function should reset the unit and do nothing else.
> ---
> bsps/aarch64/xilinx-zynqmp/console/console.c | 3 ++-
> bsps/aarch64/xilinx-zynqmp/include/bsp.h
No. Just a lesson to remember -- Everyone along the path should have built
rtems with all tests enabled.
This is something that should never happen after the upcoming transition to
GitLab. It definitely shows we need to build at least one BSP with tests
enabled.
On Mon, Mar 18, 2024, 7:45 PM
Do I need to do anything?
On Mon, 18 Mar 2024 at 16:38, Kinsey Moore wrote:
> Sorry, I didn't realize I had tests turned off in my local build when I
> checked this. The test is now gated behind NEEDS_CLOCK_DRIVER as well.
>
> Kinsey
>
> On Mon, Mar 18, 2024 at 4:15 AM Sebastian Huber <
>
Sorry, I didn't realize I had tests turned off in my local build when I
checked this. The test is now gated behind NEEDS_CLOCK_DRIVER as well.
Kinsey
On Mon, Mar 18, 2024 at 4:15 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> This patch breaks the build:
>
> In file included
I think it would be wchar_t support in newlib.
On Mon, Mar 18, 2024 at 11:56 AM Joel Sherrill wrote:
>
> What does support for UTF-32 entail? Do you have an idea what software
> functions you are looking for?
>
> I see the International Components for Unicode (ICU) has a converter
>
What does support for UTF-32 entail? Do you have an idea what software
functions you are looking for?
I see the International Components for Unicode (ICU) has a converter (
https://icu.unicode.org/download) which looks it might be part of a
solution.
Multibyte character methods defined by POSIX
I want to add utf32 support.
Where do I start?
— John
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Make the kernel I/O output character device flushing configurable. The
bsp_reset() function should reset the unit and do nothing else.
---
bsps/aarch64/xilinx-zynqmp/console/console.c | 3 ++-
bsps/aarch64/xilinx-zynqmp/include/bsp.h | 2 --
.../console/console-config.c
The use of this function is optional. Newer BSPs do not use it.
---
.../score/cpu/arm/armv4-isr-install-vector.c | 75 +++
cpukit/score/cpu/arm/cpu.c| 28 +--
spec/build/cpukit/cpuarm.yml | 1 +
3 files changed, 77 insertions(+), 27
Add a BSP variant without a board-specific name.
---
.../arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml | 87 +--
.../bsps/arm/xilinx-zynqmp-rpu/bsprpu.yml | 17
spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml | 69 +++
spec/build/bsps/arm/xilinx-zynqmp-rpu/obj.yml |
---
spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml| 6 +-
spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml | 6 +-
spec/build/cpukit/optsmp.yml | 6 +-
3 files changed, 3 insertions(+), 15 deletions(-)
diff --git
---
spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml| 2 +-
spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml | 2 +-
spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml | 2 +-
spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml | 2 +-
4 files changed, 4 insertions(+),
Add a BSP variant without a board-specific name.
---
.../bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml | 21 +++
.../bsps/aarch64/xilinx-zynqmp/optloadoff.yml | 1 +
.../bsps/aarch64/xilinx-zynqmp/optramori.yml | 1 +
spec/build/bsps/objxilinxsupportlp64.yml | 1 +
---
spec/build/bsps/objxilinxsupportr5.yml | 3 +--
spec/build/bsps/optxilsupportpath.yml | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/spec/build/bsps/objxilinxsupportr5.yml
b/spec/build/bsps/objxilinxsupportr5.yml
index d800b83247..25221c5e0d 100644
---
Hi
I am going through the logs on the test sweep VMs to see why some builds
are failing. This is due to gdb's requirement for GMP and MPFR. What's the
recommended way to address this? Load native packages?
checking for the correct version of gmp.h... yes
checking for the correct version of
This patch breaks the build:
In file included from ../../../cpukit/include/rtems/confdefs.h:64,
from
../../../testsuites/rhealstone/rhdeadlockbrk/deadlockbrk.c:215:
../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
"CONFIGURE_TICKS_PER_TIMESLICE shall be
Hello everyone,
I have included the SD card support part in my proposal, please let me know how
I can continue to improve it.
The SD card support is complex, any suggestions would be very appreciated.
Thanks Gedare done.On Mar 15, 2024, at 8:04 PM, Gedare Bloom wrote:Thanks, please send the patch for your commit, and then add yourself to the proposal tracking table at https://devel.rtems.org/wiki/GSoC/2024#ContributorsProposalsOn Thu, Mar 14, 2024, 2:03 PM Muhammad Hamdy
301 - 400 of 41539 matches
Mail list logo
