GSoC project: Memory protection (Ticket no: 2904)

Hello RTEMS community, I am interested in the ticket: Memory protection. I saw that this topic has been pursued a few times in GSoC. It would be great if someone can let me know the current status of this project and guide me about what are the contributions that can be done this year. Thanks and

Re: [PATCH rtems-docs v2 3/6] rtems-docs: Edit command to install toolsuite

Hi Vijay, Will send a v3 soon On Sat, 20 Mar 2021, 7:07 am Gedare Bloom, wrote: > Hi Ida, > > On Wed, Mar 17, 2021 at 11:36 PM Gedare Bloom wrote: > > > > On Wed, Mar 17, 2021 at 9:04 PM Vijay Kumar Banerjee > wrote: > > > > > > Hello Ida, > > > > > > > > > On Wed, Mar 17, 2021 at 8:42 PM Ida

Re: [PATCH v3 3/3] stackchk: Fixed 32bit pointers

This one is also looks fine by inspection, although I don't immediately see why it is needed. On Fri, Mar 19, 2021 at 9:35 AM Stephen Clark wrote: > > Using 32bit types like uint32_t for pointers creates issues on 64 bit > architectures like AArch64. Replaced occurrences of these with uintptr_t,

Re: [PATCH v3 2/3] rtems-fdt: Fixed 32bit pointers

this one looks fine to me by inspection. On Fri, Mar 19, 2021 at 9:35 AM Stephen Clark wrote: > > Using 32bit types like uint32_t for pointers creates issues on 64 bit > architectures like AArch64. Replaced occurrences of these with uintptr_t, > which will work for both 32 and 64 bit architecture

Re: [PATCH v3 1/3] rtems-debugger: Fixed 32bit pointers

Hi Stephen, Joel: On Fri, Mar 19, 2021 at 9:35 AM Stephen Clark wrote: > > Using 32bit types like uint32_t for pointers creates issues on 64 bit > architectures like AArch64. Replaced occurrences of these with uintptr_t, > which will work for both 32 and 64 bit architectures. > --- > cpukit/libd

Re: [PATCH] gsoc_task: Proof that I can contribute to RTEMS in GSoC

Hi Gedare, Thanks for the feedback. I'll avoid adding links here and just mention the ticket numbers. Regarding the systems related tickets, I looked into #2904 (memory protection) and #2899 (Improving the RPi BSP). It would be great if you can provide some information regarding the status of thes

Re: [PATCH] bsps/riscv: Add per cpu clock interrupt

seems fine to me, if it works, then push it On Fri, Mar 19, 2021 at 5:30 AM Jan Sommer wrote: > > - Fixes failure of test smpclock01 > --- > bsps/riscv/riscv/clock/clockdrv.c | 61 +-- > 1 file changed, 50 insertions(+), 11 deletions(-) > > diff --git a/bsps/riscv/ris

Re: [PATCH] rsb: Add aarch64 target to qemu-couverture

ok On Fri, Mar 19, 2021 at 3:31 PM Alex White wrote: > > --- > bare/config/devel/qemu-couverture-git-1.cfg | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/bare/config/devel/qemu-couverture-git-1.cfg > b/bare/config/devel/qemu-couverture-git-1.cfg > index 0f5629e..bb9b7a

Re: [PATCH] rtems-fdt/rtems-fdt.c: Fix bug in loop termination

This looks good to me. Is the bug also on 5? If so, a ticket should be opened and a patch filed for 5.2. If someone cares to push this please go ahead. I wouldn't get to it until next week sometime. Niteesh, ping it on Tuesday if no one has pushed. On Wed, Mar 17, 2021 at 8:51 PM G S Niteesh Babu

Re: [PATCH rtems-docs v2 3/6] rtems-docs: Edit command to install toolsuite

Hi Ida, On Wed, Mar 17, 2021 at 11:36 PM Gedare Bloom wrote: > > On Wed, Mar 17, 2021 at 9:04 PM Vijay Kumar Banerjee wrote: > > > > Hello Ida, > > > > > > On Wed, Mar 17, 2021 at 8:42 PM Ida Delphine wrote: > > > > > > I just installed texlive and trying to do a top level build using ./waf >

Re: [PATCH] gsoc_task: Proof that I can contribute to RTEMS in GSoC

Hi Rajiv, On Fri, Mar 19, 2021 at 11:35 PM Rajiv Vaidyanathan < rajiv.vaidyanath...@gmail.com> wrote: > Hi Gedare, > > Thank you for providing feedback on the patch. I'll make sure I follow the > character limit guidelines from now on. I have added my info template to > the Students' Proposals ta

Re: GSoC Project- BSP Executable Conversion

Hi Daman, On Fri, Mar 19, 2021 at 11:32 PM Daman Bir Singh wrote: > > Hello, > > Should I look for any other project other than this? > I think the project is of interest. Please note that generally the mailing list is less active on the weekends. Usually, if your email doesn't get any response

Re: [PATCH] gsoc_task: Proof that I can contribute to RTEMS in GSoC

Hi Gedare, Thank you for providing feedback on the patch. I'll make sure I follow the character limit guidelines from now on. I have added my info template to the Students' Proposals table. I looked into the open projects and found the following projects interesting: 1. https://devel.rtems.org/ti

Re: GSoC Project- BSP Executable Conversion

Hello, Should I look for any other project other than this? On Fri, Mar 19, 2021 at 7:52 AM Daman Bir Singh wrote: > Hello everyone, > > I am interested in pursuing ticket 4272 > as my GSoC project. I have started > going through the documentation to get t

[PATCH] rsb: Add aarch64 target to qemu-couverture

--- bare/config/devel/qemu-couverture-git-1.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bare/config/devel/qemu-couverture-git-1.cfg b/bare/config/devel/qemu-couverture-git-1.cfg index 0f5629e..bb9b7a6 100644 --- a/bare/config/devel/qemu-couverture-git-1.cfg +++ b/bare/

Re: #4328: New APIs added to POSIX Standard (2021)

On Fri, Mar 19, 2021 at 1:08 PM Gedare Bloom wrote: > On Fri, Mar 19, 2021 at 11:16 AM Matthew Joyce > wrote: > > > > Dr. Joel, > > > > Thanks very much...I'll keep working to get a sense of what goes > > where! In the meantime, where can I look to get the ground truth of > > which methods are "

[PATCH v4] covoar: Handle periods in symbols from objdump

Occasionally the compiler will generate symbols that look similar to symbols defined in RTEMS code except that they contain some suffix. These symbol suffixes are only found in the ELF symbol table; the symbols appear to be normal in the DWARF info. This appears to be happening on all architectures

Re: #4328: New APIs added to POSIX Standard (2021)

On Fri, Mar 19, 2021 at 11:16 AM Matthew Joyce wrote: > > Dr. Joel, > > Thanks very much...I'll keep working to get a sense of what goes > where! In the meantime, where can I look to get the ground truth of > which methods are "in RTEMS" as opposed to those in newlib? > There is only one ground tr

RE: [PATCH v3] psxtests: Fix math function build warnings

I must have misunderstood your email about using the file header block from https://docs.rtems.org/branches/master/eng/coding-file-hdr.html. Which header were you recommending that I add? -Original Message- From: Gedare Bloom Sent: Friday, March 19, 2021 12:02 PM To: Stephen Clark Cc:

Re: #4328: New APIs added to POSIX Standard (2021)

Dr. Joel, Thanks very much...I'll keep working to get a sense of what goes where! In the meantime, where can I look to get the ground truth of which methods are "in RTEMS" as opposed to those in newlib? Thanks again! Matt On Fri, Mar 19, 2021 at 1:58 PM Joel Sherrill wrote: > > Keep devel@ on

Re: [PATCH v3] psxtests: Fix math function build warnings

> diff --git a/testsuites/psxtests/psxhdrs/math/has_long_double.h > b/testsuites/psxtests/psxhdrs/math/has_long_double.h > new file mode 100644 > index 00..4372142288 > --- /dev/null > +++ b/testsuites/psxtests/psxhdrs/math/has_long_double.h > @@ -0,0 +1,53 @@ > +/* SPDX-License-Identifier

Re: QEMU Beagleboard Emulator

Resending with the screenshots stripped out, they made the message size too large. On Fri, Mar 19, 2021 at 8:58 AM Gedare Bloom wrote: > > > On Fri, Mar 19, 2021 at 8:47 AM Ahamed Husni > wrote: > >> This project is only suitable if you have access to the hardware. I >>> don't think there are e

Re: [PATCH 1/3] bsps: Renamed YAML files to match test names

On 19/03/2021 14:26, Kinsey Moore wrote: This was my suggestion since the introduction of the waf build system preserved the names of the executables generated as compared to the autotools build, but offered different internal names when setting expected test states. The waf build system was new

[PATCH v3] psxtests: Fix math function build warnings

Added conditionals to ensure that long double function tests were only built when newlib has long double math functions. --- testsuites/psxtests/psxhdrs/math/acoshl.c | 3 ++ testsuites/psxtests/psxhdrs/math/acosl.c | 3 ++ testsuites/psxtests/psxhdrs/math/asinhl.c | 3 ++ testsuit

[PATCH v3 3/3] stackchk: Fixed 32bit pointers

Using 32bit types like uint32_t for pointers creates issues on 64 bit architectures like AArch64. Replaced occurrences of these with uintptr_t, which will work for both 32 and 64 bit architectures. --- cpukit/libmisc/stackchk/check.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --

[PATCH v3 2/3] rtems-fdt: Fixed 32bit pointers

Using 32bit types like uint32_t for pointers creates issues on 64 bit architectures like AArch64. Replaced occurrences of these with uintptr_t, which will work for both 32 and 64 bit architectures. --- cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletion

[PATCH v3 1/3] rtems-debugger: Fixed 32bit pointers

Using 32bit types like uint32_t for pointers creates issues on 64 bit architectures like AArch64. Replaced occurrences of these with uintptr_t, which will work for both 32 and 64 bit architectures. --- cpukit/libdebugger/rtems-debugger-server.c | 4 ++-- cpukit/libdebugger/rtems-debugger-target.c

RE: [PATCH v1 2/2] psxtests: Fix math function build warnings

Gedare, Sorry, I didn't see that you had written comments below the first one yesterday. The conditional logic for building the long double functions comes from newlib. Given that it could change, it made sense to handle it in a single place in case it changed. As far as moving the logic into

Re: [PATCH] gsoc_task: Proof that I can contribute to RTEMS in GSoC

Hi Rajiv, On Fri, Mar 19, 2021 at 4:21 AM Rajiv Vaidyanathan wrote: > > Link to the task: https://docs.rtems.org/branches/master/user/start/gsoc.html > --- > testsuites/samples/hello/init.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/testsuites/samples/hello/init.c b

Re: Ada Tests Not Linking

On Fri, Mar 19, 2021, 9:37 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 18/03/2021 23:44, Joel Sherrill wrote: > > > I am trying to build Ada tests for the leon3 and all fail to link. > > When did these build last? > It works with GCC 10. There are a couple of Ada changes i

Re: Ada Tests Not Linking

On 18/03/2021 23:44, Joel Sherrill wrote: I am trying to build Ada tests for the leon3 and all fail to link. When did these build last? It works with GCC 10. There are a couple of Ada changes in GCC 11 which broke the RTEMS port. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 8217

Re: About is_non_preempt_mode_supported

On 19/03/2021 14:36, jan.som...@dlr.de wrote: How would I temporarily disable preemption for the current thread on its specific core only? You can raise its priority to zero. This is also more effective in uniprocessor systems due to this bug: http://devel.rtems.org/ticket/2365 For examp

[PATCH] rtems: Relax mode checks in rtems_signal_catch()

Check only for invalid modes if a valid handler is presented to rtems_signal_catch(). When NULL is used for the handler, ASR processing is disabled and the mode is not used. Update #4244. --- cpukit/rtems/src/signalcatch.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --

RE: About is_non_preempt_mode_supported

> -Original Message- > From: devel On Behalf Of Gedare Bloom > Sent: Thursday, March 18, 2021 8:11 PM > To: Richi Dubey > Cc: rtems-de...@rtems.org > Subject: Re: About is_non_preempt_mode_supported > > On Thu, Mar 18, 2021 at 11:25 AM Richi Dubey > wrote: > > > > Thanks for your he

RE: [PATCH 1/3] bsps: Renamed YAML files to match test names

This was my suggestion since the introduction of the waf build system preserved the names of the executables generated as compared to the autotools build, but offered different internal names when setting expected test states. The waf build system was new and different, so I thought it better to co

Re: #4328: New APIs added to POSIX Standard (2021)

Keep devel@ on the list. :) On Fri, Mar 19, 2021 at 7:51 AM Matthew Joyce wrote: > Sir, > > Thank you for the link! I see that you're right, those last four are > in newlib, plus memmem(). I updated those in the Google Sheet. > > Now I see the newlib part, but where are you referring to specific

Re: #4328: New APIs added to POSIX Standard (2021)

On Fri, Mar 19, 2021, 6:40 AM Joel Sherrill wrote: > > > On Fri, Mar 19, 2021, 5:48 AM Matthew Joyce wrote: > >> >> https://docs.google.com/spreadsheets/d/1reCNOIZC5JTwQENgl-hvG8THfQqNtlUDVy_07PYodic/edit?usp=sharing >> >> Hello, >> >> As suggested by Dr. Sherril, I've taken an initial look thro

Re: #4328: New APIs added to POSIX Standard (2021)

On Fri, Mar 19, 2021, 5:48 AM Matthew Joyce wrote: > > https://docs.google.com/spreadsheets/d/1reCNOIZC5JTwQENgl-hvG8THfQqNtlUDVy_07PYodic/edit?usp=sharing > > Hello, > > As suggested by Dr. Sherril, I've taken an initial look through this > document https://www.opengroup.org/austin/docs/austin_1

[PATCH] bsps/riscv: Add per cpu clock interrupt

- Fixes failure of test smpclock01 --- bsps/riscv/riscv/clock/clockdrv.c | 61 +-- 1 file changed, 50 insertions(+), 11 deletions(-) diff --git a/bsps/riscv/riscv/clock/clockdrv.c b/bsps/riscv/riscv/clock/clockdrv.c index d085b6bd95..04abe24545 100644 --- a/bsps/riscv

#4328: New APIs added to POSIX Standard (2021)

https://docs.google.com/spreadsheets/d/1reCNOIZC5JTwQENgl-hvG8THfQqNtlUDVy_07PYodic/edit?usp=sharing Hello, As suggested by Dr. Sherril, I've taken an initial look through this document https://www.opengroup.org/austin/docs/austin_1110.pdf and added the new methods to a Googe Sheet, linked above

Re: GSoC: Matt Joyce Introduction

Sir, Thanks very much, that sounds great! I'll start a new thread with the initial Google Sheet. Sincerely, Matt On Thu, Mar 18, 2021 at 5:31 PM Joel Sherrill wrote: > > > > On Wed, Mar 17, 2021 at 10:50 AM Gedare Bloom wrote: >> >> Hi Matt, >> >> On Wed, Mar 17, 2021 at 6:18 AM Matthew Joyce

gsoc_task: Screenshot

Respected RTEMS maintainers, Following up my previous email ([PATCH] gsoc_task: Proof that I can contribute to RTEMS in GSoC), please find attached the screenshot of the output. Thanks and regards, Rajiv Vaidyanathan ___ devel mailing list devel@rtems.o

[PATCH] gsoc_task: Proof that I can contribute to RTEMS in GSoC

Link to the task: https://docs.rtems.org/branches/master/user/start/gsoc.html --- 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 34ded37c55..a4e556de19 100644 --- a/testsuit