Re: Device Tree Blob for Beaglebone Black?

On Mon, Feb 24, 2020 at 8:16 PM Alan Cudmore wrote: > Hi Vijay, > My uEnv.txt was very similar, but I did not have the "fdt addr > 0x8800" command. But that did not seem to help. I still get a > fatal exception when trying to run the usb01 and ping01 programs. > > Do you think the u-boot

Project query : [Improve Coverage Analysis Toolset]

Hello, My name is Anmol, I am a Google Summer of Code, Student developer aspirant for 2020. I have completed the Hello-world task. I am interested in Ticket #2920 i.e "Improve Coverage Analysis Toolset". I know that Dr. Joel is the owner and Dr. Gedare has reported it. Is there any mentor

RE: Tool Roadmap for the RTEMS Pre-Qualification

Hello Gedare, In the sequence of your last e-mail, I spent some time to putting to work again the CLANG Static Analyzer. About one year ago, I run the CLANG Static Analyzer version 7.0.0 in my Debian 9 machine. I followed the next steps to install it: tar xvf llvm-7.0.0.src.tar.xz mv

Re: Device Tree Blob for Beaglebone Black?

It looks like the mkimage command difference fixed the crash. The original BSP README: https://git.rtems.org/rtems/tree/bsps/arm/beagle/README $ mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n RTEMS -d $exe.bin.gz rtems-app.img The docs.rtems.org beagle BSP readme:

Re: Device Tree Blob for Beaglebone Black?

On 24/02/2020 19:43, Alan Cudmore wrote: > It looks like the mkimage command difference fixed the crash. > > The original BSP README: > https://git.rtems.org/rtems/tree/bsps/arm/beagle/README > $ mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n > RTEMS -d $exe.bin.gz rtems-app.img

tar/psx/bsdtar on CentOS 8

Hi CentOS 8 does not have a package for pax. It does have a package for bsdtar. Is bsdtar sufficient for the tests? I don't call the precise issue we favored pax over GNU tar. If so, could testsuites/libtests/configure.ac accept both? Pax appears to be used only for the dl* and tar* tests. I

[PATCH] Fix typo in error message

From: Cláudio Maia --- tester/rtems-test | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tester/rtems-test b/tester/rtems-test index 3eb5701..520366a 100755 --- a/tester/rtems-test +++ b/tester/rtems-test @@ -39,4 +39,4 @@ elif test -f ${base}/share/rtems/${PYTHON_WRAPPER};

pkg-config RTEMS BSP files in master branch cause me problems

The files that get installed (for example as "lib/pkgconfig/arm-rtems5-xilinx_zynq_a9_qemu.pc") are making my life difficult in that they add compile and link flags that are difficult to over-ride and I need to in some situations. It states clearly in the file "Warning: This stuff is

Re: Status of implementation of fenv.h test suites

For implementation of fegetround() and fesetround() basic details : https://pubs.opengroup.org/onlinepubs/9699919799/functions/fegetround.html As I used fesetround() to change the rounding direction it returns a successful result but when I test fegetround() for the same rounding direction then

Re: Status of implementation of fenv.h test suites

On Mon, Feb 24, 2020 at 1:33 PM Eshan Dhawan wrote: > For implementation of fegetround() and fesetround() > > basic details : > https://pubs.opengroup.org/onlinepubs/9699919799/functions/fegetround.html > > As I used fesetround() to change the rounding direction it returns a > successful result

Re: Device Tree Blob for Beaglebone Black?

> On 24 Feb 2020, at 7:39 pm, Christian Mauderer > wrote: > > On 24/02/2020 07:01, Chris Johns wrote: >> >> On 24 Feb 2020, at 5:32 am, Christian Mauderer wrote: >>> >>> On 23/02/2020 17:07, Alan Cudmore wrote: I have been trying to bring up RTEMS with rtems-libbsd on the

Re: Waf Build System Status in RTEMS?

On 21/2/20 11:11 pm, Sebastian Huber wrote: > On 21/02/2020 12:26, Hesham Almatary wrote: >> On Fri, 21 Feb 2020 at 11:07, Sebastian Huber >>   wrote: >>> Hello Hesham, >>> >>> On 20/02/2020 16:40, Hesham Almatary wrote: Hello, Are there any progress updates to the Waf build system

Re: Waf Build System Status in RTEMS?

On Mon, Feb 24, 2020, 4:50 PM Chris Johns wrote: > On 21/2/20 11:11 pm, Sebastian Huber wrote: > > On 21/02/2020 12:26, Hesham Almatary wrote: > >> On Fri, 21 Feb 2020 at 11:07, Sebastian Huber > >> wrote: > >>> Hello Hesham, > >>> > >>> On 20/02/2020 16:40, Hesham Almatary wrote: >

Re: pkg-config RTEMS BSP files in master branch cause me problems

On 25/2/20 7:50 am, Peter Dufault wrote: > The files that get installed (for example as > "lib/pkgconfig/arm-rtems5-xilinx_zynq_a9_qemu.pc") are making my life > difficult in that they add compile and link flags that are difficult to > over-ride and I need to in some situations. Yes this is

Re: Status of implementation of fenv.h test suites

Sent from my iPhone >> On 25-Feb-2020, at 4:20 AM, Joel Sherrill wrote: >  > > >> On Mon, Feb 24, 2020 at 1:33 PM Eshan Dhawan wrote: >> For implementation of fegetround() and fesetround() >> >> basic details : >> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fegetround.html

RTEMS 5 libdl bugs

Hello, there are six libdl bugs reported for RTEMS 5: https://devel.rtems.org/query?status=accepted=assigned=reopened=lib%2Fdl=5.1=status=id=summary=owner=type=priority=component=version=priority Are they release blockers or can they move to a new milestone? Chris, if you don't want to work

RTEMS test

Hello, I'm trying to run the rtems-test after closing my computer and switching operating systems(dual booted computer), but weirdly enough, I received the message rtems-test: command not found So I attempted running the command for rtems-tools, but then the message I received was ./rtems-test

Re: Device Tree Blob for Beaglebone Black?

On 24/02/2020 07:01, Chris Johns wrote: > > >> On 24 Feb 2020, at 5:32 am, Christian Mauderer wrote: >> >> On 23/02/2020 17:07, Alan Cudmore wrote: >>> I have been trying to bring up RTEMS with rtems-libbsd on the >>> beaglebone black (latest master). >>> >>> I can run the regular RTEMS

Re: Device Tree Blob for Beaglebone Black?

On 24/02/2020 06:57, Vijay Kumar Banerjee wrote: > > > On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore > wrote: > > Hi Christian, > Thanks for the quick response. I followed the instructions in the > docs.rtems.org manual and

Re: Device Tree Blob for Beaglebone Black?

On 24/02/2020 23:26, Chris Johns wrote: >> On 24 Feb 2020, at 7:39 pm, Christian Mauderer >> wrote: >> >> On 24/02/2020 07:01, Chris Johns wrote: >>> >>> > On 24 Feb 2020, at 5:32 am, Christian Mauderer wrote: On 23/02/2020 17:07, Alan Cudmore wrote: > I have been trying to

[PATCH 2/2] c-user: rtems_scheduler_map_from_posix_priority()

Close #3881. --- c-user/scheduling_concepts.rst | 40 1 file changed, 40 insertions(+) diff --git a/c-user/scheduling_concepts.rst b/c-user/scheduling_concepts.rst index 4106d41..12316b7 100644 --- a/c-user/scheduling_concepts.rst +++

[PATCH 1/2] c-user: rtems_scheduler_map_to_posix_priority()

Update #3881. --- c-user/scheduling_concepts.rst | 40 1 file changed, 40 insertions(+) diff --git a/c-user/scheduling_concepts.rst b/c-user/scheduling_concepts.rst index 22d39e1..4106d41 100644 --- a/c-user/scheduling_concepts.rst +++

Re: SPDX License Identifier Only and Full Copy?

On Mon, Feb 24, 2020, 6:03 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Andrew, > > On 24/02/2020 10:48, Andrew Butterfield wrote: > > Hi Sebastian, > > > > a quick question > > - does the Doxygen block requirement also apply to test programs > (xxtest/init.c), > >

Re: SPDX License Identifier Only and Full Copy?

Hi Joel, any test files we develop (at Lero/TCD) will be generated by python tools, so we could include file level Doxygen quite easily, if that is helpful. Regards, Andrew > On 24 Feb 2020, at 12:22, Joel Sherrill wrote: > > > > On Mon, Feb 24, 2020, 6:03 AM Sebastian Huber >

Re: SPDX License Identifier Only and Full Copy?

Hello Andrew, On 24/02/2020 10:48, Andrew Butterfield wrote: Hi Sebastian, a quick question - does the Doxygen block requirement also apply to test programs (xxtest/init.c), either hand-written or model-generated? we currently don't use Doxygen in the tests. There is some test

[PATCH 2/2] rtems: Add rtems_scheduler_map_from_posix_priority()

Update #3881. --- cpukit/Makefile.am | 1 + cpukit/include/rtems/rtems/tasks.h | 18 cpukit/rtems/src/schedulermapfromposix.c | 70 testsuites/sptests/spscheduler01/init.c | 44 4 files changed, 133

[PATCH 1/2] rtems: Add rtems_scheduler_map_to_posix_priority()

Update #3881. --- cpukit/Makefile.am | 1 + cpukit/include/rtems/rtems/tasks.h | 18 cpukit/rtems/src/schedulermaptoposix.c | 81 + testsuites/sptests/spscheduler01/init.c | 52 ++--- 4 files changed, 145

Re: SPDX License Identifier Only and Full Copy?

Hi Sebastian, a quick question - does the Doxygen block requirement also apply to test programs (xxtest/init.c), either hand-written or model-generated? Regards, Andrew > On 24 Feb 2020, at 07:52, Sebastian Huber > wrote: > > Hello, > > I updated the File Template section: > >

Re: Device Tree Blob for Beaglebone Black?

Hi Vijay, My uEnv.txt was very similar, but I did not have the "fdt addr 0x8800" command. But that did not seem to help. I still get a fatal exception when trying to run the usb01 and ping01 programs. Do you think the u-boot version matters? I am using the following: - MLO and u-boot.img from

Re: SPDX License Identifier Only and Full Copy?

On Mon, Feb 24, 2020 at 6:46 AM Andrew Butterfield < andrew.butterfi...@scss.tcd.ie> wrote: > Hi Joel, > any test files we develop (at Lero/TCD) will be generated by python > tools, > so we could include file level Doxygen quite easily, if that is helpful. > If we have a desired pattern for

Re: Testing BSP package using beaglebone black

Hello John, On Sun, Feb 23, 2020 at 10:16 PM John kongtcheu wrote: > > Hello, > I was just testing the bsp package using beagleboard and I ran into an error > when trying to build the bsp. I received the error > checking for arm-rtems5-gcc... no > configure: error: no acceptable cc found in

[PATCH] added fesetexeptflag() test to the psxfenv test

--- testsuites/psxtests/psxfenv01/init.c | 36 1 file changed, 31 insertions(+), 5 deletions(-) diff --git a/testsuites/psxtests/psxfenv01/init.c b/testsuites/psxtests/psxfenv01/init.c index cdb0fa596e..8ffb9395b9 100644 --- a/testsuites/psxtests/psxfenv01/init.c

Re: rtems-boot-image tool: Raspberry Pi

Hi Niteesh, On Sun, Feb 23, 2020 at 11:34 PM G. S. Niteesh wrote: > > Hii, > > This is a follow-up message since this thread has been unnoticed for a while. > 2 days over a weekend is not a while. It is typical that you would not receive responses over a weekend, or that if your response relies

Re: [PATCH] added fesetexeptflag() test to the psxfenv test

I have added test for fegetflagexept and fesetflagexept in psxfenv test suite can someone check the test case for the correctness it runs fine in riscv also i have sent another patch to change assert() back to rtems_test_assert() On Mon, Feb 24, 2020 at 9:18 PM Eshan dhawan wrote: > --- >

Re: rtems-boot-image tool: Raspberry Pi

I am sorry. I'll make sure it doesn't happen again. On Mon, Feb 24, 2020 at 9:18 PM Gedare Bloom wrote: > Hi Niteesh, > > On Sun, Feb 23, 2020 at 11:34 PM G. S. Niteesh wrote: > > > > Hii, > > > > This is a follow-up message since this thread has been unnoticed for a > while. > > > 2 days over

Re: Testing BSP package using beaglebone black

On Mon, Feb 24, 2020 at 8:44 AM Gedare Bloom wrote: > > Hello John, > > On Sun, Feb 23, 2020 at 10:16 PM John kongtcheu > wrote: > > > > Hello, > > I was just testing the bsp package using beagleboard and I ran into an > > error when trying to build the bsp. I received the error > > checking

[PATCH v1] added test for fegetexeptflag and fesetexeptflag

--- testsuites/psxtests/psxfenv01/init.c | 27 +-- 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/testsuites/psxtests/psxfenv01/init.c b/testsuites/psxtests/psxfenv01/init.c index 8ffb9395b9..05f3cdc880 100644 --- a/testsuites/psxtests/psxfenv01/init.c +++

Re: SPDX License Identifier Only and Full Copy?

On Mon, Feb 24, 2020 at 12:53 AM Sebastian Huber wrote: > > Hello, > > I updated the File Template section: > > https://docs.rtems.org/branches/master/eng/coding-file-hdr.html > > Please have a look at it and check if it is all right for you. > Thanks. A few notes: * licence -> license * Do we