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
---
hello.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hello.c b/hello.c
index 622a9da..d78f5dd 100644
--- a/hello.c
+++ b/hello.c
@@ -9,6 +9,6 @@ rtems_task Init(
rtems_task_argument ignored
)
{
- printf( "\nHello From Cairo, its me Hamzy\n" );
+ printf( "\nHello
Hello Ken,
On 14.03.24 18:33, ken.un...@microchip.com wrote:
Hello RTEMS experts,
We’re in the process of implementing support for RTEMS on a new RISC-V
platform. Among other things, our processor core supports the RISC-V
Vector ISA (RVV), with its 32 vector registers which in our case are
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?
Greetings
Frank
On 2/23/24 17:29, Frank Kuehndel wrote:
On 12/3/2024 8:06 pm, Heinz Junkes wrote:
> Hello Chris,
>
> thanks for your mail. I have now installed the python as you described.
Great.
> The source-builder process runs quite well.
>
> Unfortunately, the gcc-13.2.0-newlib for powerpc cannot be built:
I updated to the latest RSB with the
Thanks. All pushed now.
On Thu, Mar 14, 2024 at 6:46 PM Chris Johns wrote:
> OK
>
> Thanks
> Chris
>
> On 12/3/2024 1:06 am, Joel Sherrill wrote:
> > _Thread_Close no longer exists. There are multiple exapmles which
> > show tracing in rtems-examples which fail to link due to this.
> > ---
> >
Hi RTEMS Community
I would like to announce that RTEMS will be moving to GitLib in the coming month
or so. We do not have any exact dates yet and we will let you know when we do.
The change is large and complex because we are integrating an active open source
project made up of various pieces
OK
Thanks
Chris
On 14/3/2024 7:00 am, Joel Sherrill wrote:
> In particular, the BSP set definitions for rtems-bsp-builder were
> out of sync with RTEMS and caused unnecessary failures reported to
> the build@ mailing list.
> ---
> rtems/config/tools/rtems-tools-6.cfg | 4 ++--
> 1 file changed,
OK
Thanks
Chris
On 12/3/2024 1:06 am, Joel Sherrill wrote:
> _Thread_Close no longer exists. There are multiple exapmles which
> show tracing in rtems-examples which fail to link due to this.
> ---
> linkers/rtems-score-thread.ini | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
---
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..cee3c67d0c 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -41,7 +41,7
Try at FreeBSD.org.
On Mar 14, 2024, at 10:18 AM, ashish wrote:
I am trying to run freebsd aarch64 12.x on qemu to know whether freebsd
supports usb or not.
and Error i am getting is this
```qemu-system-aarch64: device requires 67108864 bytes, block backend provides
2097152 bytes```
does
It should be in the repo now.
On Thu, Mar 14, 2024 at 12:50 PM zack leung
wrote:
> Did you check in the code?
>
> Il mar 12 mar 2024, 21:55 Kinsey Moore ha
> scritto:
>
>> Sorry, I missed this in the deluge of emails. Looks good to me.
>>
>> Kinsey
>>
>> On Tue, Mar 12, 2024 at 8:17 PM zack
Did you check in the code?
Il mar 12 mar 2024, 21:55 Kinsey Moore ha
scritto:
> Sorry, I missed this in the deluge of emails. Looks good to me.
>
> Kinsey
>
> On Tue, Mar 12, 2024 at 8:17 PM zack leung
> wrote:
>
>> ping
>>
>> On Fri, 8 Mar 2024 at 22:03, wrote:
>>
>>> From: Zack leung
>>>
Hello RTEMS experts,
We're in the process of implementing support for RTEMS on a new RISC-V
platform. Among other things, our processor core supports the RISC-V Vector
ISA (RVV), with its 32 vector registers which in our case are 512 bits (VLEN)
deep. RVV is used by applications to
I am trying to run freebsd aarch64 12.x on qemu to know whether freebsd
supports usb or not. following
https://gist.github.com/ctsrc/a1f57933a2cde9abc0f07be12889f97f and getting
error when running with qemu
command i am using to build is
qemu-system-aarch64 \
This was driven by the increase in fdset size from 64 to 256
files.
---
rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 4 ++--
rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 4 ++--
rtems/config/tools/rtems-gcc-12-newlib-head.cfg | 4 ++--
In particular, the BSP set definitions for rtems-bsp-builder were
out of sync with RTEMS and caused unnecessary failures reported to
the build@ mailing list.
---
rtems/config/tools/rtems-tools-6.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
This prototype should have been removed with commit
ac4db4cec5b6b1e0a25e910851e50831afb0749d.
---
rtemsbsd/include/rtems/bsd/bsd.h | 22 --
1 file changed, 22 deletions(-)
diff --git a/rtemsbsd/include/rtems/bsd/bsd.h b/rtemsbsd/include/rtems/bsd/bsd.h
index
Hello Ashish,
USB works on real hardware, however, I guess nobody tried it so far on Qemu.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Dear RTEMS developers,
we have made a progress with our CAN stack and virtual/CTU CAN FD
controller tests using standard x86-64 QEMU. We can now provide scripts
that build the stack and our applications on i386-pc686 target and run
RTEMS in QEMU. The actual CAN stack can still be found in our
Hello,
New to rtems and I am trying to Zynq on qemu with usb doesn't work for me
or which BSP will work with USB and hot plugged adapter on qemu any
suggestions?
thanks
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Thanks. Please add yourself to the table at
https://devel.rtems.org/wiki/GSoC/2024 and (continue to) discuss your
project ideas here/Discord.
On Tue, Mar 12, 2024 at 2:10 PM Matheus Pecoraro wrote:
>
> Hello, I am a fresh graduate from Brazil. I have developed a simple
> x86_64 kernel in Rust in
Sorry, I missed this in the deluge of emails. Looks good to me.
Kinsey
On Tue, Mar 12, 2024 at 8:17 PM zack leung wrote:
> ping
>
> On Fri, 8 Mar 2024 at 22:03, wrote:
>
>> From: Zack leung
>>
>> ---
>> cpukit/doxygen/appl-config.h | 3 +--
>> cpukit/include/rtems/confdefs/clock.h
ping
On Fri, 8 Mar 2024 at 22:03, wrote:
> From: Zack leung
>
> ---
> cpukit/doxygen/appl-config.h | 3 +--
> cpukit/include/rtems/confdefs/clock.h | 4
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/doxygen/appl-config.h
Hello, I am a fresh graduate from Brazil. I have developed a simple
x86_64 kernel in Rust in my free time and thus I am interested in the
x86_64 BSP project.
Although I did manage to compile the x86_64 BSP, the hello.exe test
was hanging, so I did the task with the i386 BSP. I definitely need to
301 - 400 of 41515 matches
Mail list logo
