Re: What opens stdout? printf() fails after rtems-tester printf() succeeds.
Hello Peter, did you configure the console driver? https://docs.rtems.org/branches/master/c-user/configuring_a_system.html#configure-application-needs-console-driver -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-libbsd commit] Add pselect()
On 24/09/2019 15:34, Joel Sherrill wrote: Before I update the compliance tracking to add pselect(), have any other POSIX methods been added recently which I have missed? This is only a partial implementation. The signal mask stuff is not supported. I needed it for the new ping/ping6 commands. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Where are results of rtems-tester test results archived?
On 25/9/19 1:08 am, Gedare Bloom wrote: > On Sat, Sep 21, 2019 at 9:41 AM Joel Sherrill wrote: >> On Sat, Sep 21, 2019, 10:18 AM wrote: On Sep 21, 2019, at 11:03 , Joel Sherrill wrote: On Sat, Sep 21, 2019, 9:55 AM Peter Dufault wrote: I’ve searched but can’t find anywhere. I’d like to see the results of the tests on all architectures to compare to what I see on PowerPC-beatnik. There is a build@ mailing list and the archives are at https://lists.rtems.org/pipermail/build/ There should be results from at least me for psim. You are encouraged to subscribe to the list and post results. Many boards have no results. >>> That doesn’t look like what I want. I’m looking for something like the >>> following (a small snippet of my test run in progress) to see what failures >>> are shared by what board support packages. >>> >>> [141/597] p:128 f:7 u:2 e:0 I:0 B:3 t:0 i:0 W:0 | >>> powerpc/beatnik: telnetd01.exe >>> [142/597] p:129 f:7 u:2 e:0 I:0 B:3 t:0 i:0 W:0 | >>> powerpc/beatnik: termios.exe >>> [143/597] p:129 f:7 u:3 e:0 I:0 B:3 t:0 i:0 W:0 | >>> powerpc/beatnik: termios01.exe >>> [144/597] p:129 f:8 u:3 e:0 I:0 B:3 t:0 i:0 W:0 | >>> powerpc/beatnik: termios02.exe >>> [145/597] p:129 f:9 u:3 e:0 I:0 B:3 t:0 i:0 W:0 | >>> powerpc/beatnik: termios03.exe >>> [146/597] p:130 f:9 u:3 e:0 I:0 B:3 t:0 i:0 W:0 | >>> powerpc/beatnik: termios04.exe >>> [147/597] p:131 f:9 u:3 e:0 I:0 B:3 t:0 i:0 W:0 | >>> powerpc/beatnik: termios05.exe >> >> Most are for tools builds. I have a script I run periodically which includes >> tools and bsps. This is a psim results post: >> https://lists.rtems.org/pipermail/build/2019-August/002973.html >> >> It shows the failures but still doesn't show the in process view. Does that >> help at all? >> > Just to jump in, as I recall the "in process" view is not always > useful, since it does not exactly tell you what has failed (when you > run several tests in parallel, that is). Collecting the end results > of could be nice. Sorry, I am not following what is being said here. The tester collects the results for a single run as shown in ... https://lists.rtems.org/pipermail/build/2019-August/002970.html which is ... Summary === Passed:578 Failed: 2 User Input: 6 Expected Fail: 0 Indeterminate: 0 Benchmark: 3 Timeout: 0 Invalid: 0 Wrong Version: 0 Wrong Build: 0 Wrong Tools: 0 -- Total: 589 Failures: dl06.exe dl09.exe User Input: dl10.exe monitor.exe termios.exe top.exe capture.exe fileio.exe Benchmark: dhrystone.exe linpack.exe whetstone.exe Are you asking for something across separate runs of the tester? > Automating this and creating a colored status matrix > would be a nice little project for someone. Where would this be run and the data held? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: BSD licensed Picolibc 1.0 released
On 25/9/19 1:03 am, Gedare Bloom wrote: > Hi mko, > > RTEMS has a fairly strong relationship (dependency) with newlib, and > that has been working well for a long time. Although the prospect of > having a way to 'drop-in' alternative libc could be nice for small > targets, it would be of more interest to us to see ways to optimize > newlib to shrink it if needed. The use of stripped-down libc for > low-resource targets usually means a feature-rich RTOS like RTEMS will > not be needed either. These kinds of libc are more interesting for > baremetal or low-complexity RTOSs, and some hypervisor-like systems > that want an extremely small, trusted code base. I agree and it builds with meson which is also interesting. I am finding the license a little confusing. The repo on github [1] contains GPL2, GPL3, LGPL, Newlib and more licenses while the README.md says there is no GPL bits from newlib in the repo and it is basically a mix of 2 and 3 clause BSD. Why have a copy of the GPL licenses in the repo? Chris [1] https://github.com/keith-packard/picolibc > > But, thanks for the heads up about the picolibc. > > Gedare > > On Tue, Sep 24, 2019 at 5:09 AM mko wrote: >> >> Hi List, >> I just got this news from my RSS feed, after a brief read, I think this is a >> better and simpler alternative of newlib library, Does anyone know how to >> use it in rtems project? >> >> mko >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: What opens stdout? printf() fails after rtems-tester printf() succeeds.
> On Sep 24, 2019, at 17:41 , Joel Sherrill wrote:
>
> On Tue, Sep 24, 2019 at 4:29 PM Peter Dufault wrote:
>>
>> I've started testing the PowerPC MVME5500 "beatnik" BSP on the mainline.
>> I've run through the majority of the RTEMS tests, with some failures, but
>> when I went to run any basic programs they do not produce any output. They
>> are obviously running, I can put in a "sleep(3)" and observe it, but no
>> output.
>>
>> I looked at what rtems-tester does and see it wraps "printf()" and friends.
>> I found that if:
>> - I add CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION to my
>> configuration;
>> - I used "rtems_test_printf()" that output via "rtems_test_printf()" works.
>>
>> After that I tried this in my _POSIX_Init(), to see if file descriptor 1 was
>> open:
>>
>> const char *hello="Hello to FD 1\r\n";
>> size_t n = strlen(hello);
>> size_t output;
>>
>> rtems_test_printf("rtems_test_printf %s: Hello...\n", __func__);
>> if ( (output = write(1, hello, n)) != n) {
>>printk("%s: write() returned %d not %d: %s\n", __func__,
>>(int)output, (int)n, strerror(errno));
>> }
>>
>> The output is:
>>
>> rtems_test_printf _POSIX_Init: Hello...
>> _POSIX_Init: write() returned -1 not 15: Bad file number
>>
>> So file descriptor 1 isn't opened. What establishes the standard open file
>> descriptors that isn't being called in my update?
>>
>> I *think* I have the GDB stub working, I had to modify it to bring it
>> up-to-date, but I'd rather see a console message like "GDB stub starting
>> up..." before I go further.
>
> As a simple check, try "nm -g -n" on the executable and look at what's
> in the Sysinit linker section. On psim hello,.exe, I see this:
>
> 001d660 D _Linker_set__Sysinit_begin
> 0001d660 D _Linker_set__Sysinit_bsp_work_area_initialize
> 0001d660 D __start_set_sysctl_set
> 0001d660 D __stop_set_sysctl_set
> 0001d664 D _Linker_set__Sysinit_bsp_start
> 0001d668 D _Linker_set__Sysinit__User_extensions_Handler_initialization
> 0001d66c D _Linker_set__Sysinit_rtems_initialize_data_structures
> 0001d670 D _Linker_set__Sysinit__RTEMS_tasks_Manager_initialization
> 0001d674 D _Linker_set__Sysinit__POSIX_Keys_Manager_initialization
> 0001d678 D _Linker_set__Sysinit__Thread_Create_idle
> 0001d67c D _Linker_set__Sysinit_rtems_libio_init
> 0001d680 D _Linker_set__Sysinit_rtems_filesystem_initialize
> 0001d684 D _Linker_set__Sysinit__Console_simple_Initialize
> 0001d688 D _Linker_set__Sysinit__IO_Initialize_all_drivers
> 0001d68c D _Linker_set__Sysinit__RTEMS_tasks_Initialize_user_tasks_body
> 0001d690 D _Linker_set__Sysinit_rtems_libio_post_driver
> 0001d694 D _Linker_set__Sysinit_end
>
> It's the libio_post_driver one.
>
> Another possibility based on my recollection of the mvme2100 is that
> there are variants where some ports are missing or wired out strange
> places. Given the file descriptor isn't there, I suspect that
> /dev/console wasn't registered. That could mean the console driver
> isn't in the build or it didn't see the device it wanted to register.
>
> Check the linker set via nm first. That's easy.
>
> --joel
>
>
It's getting late for me so I won't be analyzing this, but the section is "R"
(relocatable?) and not "D". It's also interesting that there's an "endPeter"
section, I'm not sure what I did to create that.
00081a90 R _Linker_set__Sysinit_Stack_check_Prepare_interrupt_stacks
00081a90 R _Linker_set__Sysinit_begin
00081a94 R _Linker_set__Sysinit_bsp_work_area_initialize
00081a98 R _Linker_set__Sysinit_bsp_start
00081a9c R _Linker_set__Sysinit_bsp_work_area_initialize_later
00081aa0 R _Linker_set__Sysinit__User_extensions_Handler_initialization
00081aa4 R _Linker_set__Sysinit_rtems_initialize_data_structures
00081aa8 R _Linker_set__Sysinit__RTEMS_tasks_Manager_initialization
00081aac R _Linker_set__Sysinit__Message_queue_Manager_initialization
00081ab0 R _Linker_set__Sysinit__Semaphore_Manager_initialization
00081ab4 R _Linker_set__Sysinit__POSIX_signals_Manager_Initialization
00081ab8 R _Linker_set__Sysinit__POSIX_Threads_Manager_initialization
00081abc R _Linker_set__Sysinit__POSIX_Keys_Manager_initialization
00081ac0 R _Linker_set__Sysinit__Thread_Create_idle
00081ac4 R _Linker_set__Sysinit_rtems_libio_init
00081ac8 R _Linker_set__Sysinit_rtems_filesystem_initialize
00081acc R _Linker_set__Sysinit_BSP_vme_config
00081ad0 R _Linker_set__Sysinit__IO_Initialize_all_drivers
00081ad4 R _Linker_set__Sysinit__POSIX_Threads_Initialize_user_threads_body
00081ad8 R _Linker_set__Sysinit_rtems_libio_post_driver
00081adc R _Linker_set__Sysinit_endPeter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to
interception and tampering.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: What opens stdout? printf() fails after rtems-tester printf() succeeds.
On Tue, Sep 24, 2019 at 4:29 PM Peter Dufault wrote:
>
> I've started testing the PowerPC MVME5500 "beatnik" BSP on the mainline.
> I've run through the majority of the RTEMS tests, with some failures, but
> when I went to run any basic programs they do not produce any output. They
> are obviously running, I can put in a "sleep(3)" and observe it, but no
> output.
>
> I looked at what rtems-tester does and see it wraps "printf()" and friends.
> I found that if:
> - I add CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION to my
> configuration;
> - I used "rtems_test_printf()" that output via "rtems_test_printf()" works.
>
> After that I tried this in my _POSIX_Init(), to see if file descriptor 1 was
> open:
>
> const char *hello="Hello to FD 1\r\n";
> size_t n = strlen(hello);
> size_t output;
>
> rtems_test_printf("rtems_test_printf %s: Hello...\n", __func__);
> if ( (output = write(1, hello, n)) != n) {
> printk("%s: write() returned %d not %d: %s\n", __func__,
> (int)output, (int)n, strerror(errno));
> }
>
> The output is:
>
> rtems_test_printf _POSIX_Init: Hello...
> _POSIX_Init: write() returned -1 not 15: Bad file number
>
> So file descriptor 1 isn't opened. What establishes the standard open file
> descriptors that isn't being called in my update?
>
> I *think* I have the GDB stub working, I had to modify it to bring it
> up-to-date, but I'd rather see a console message like "GDB stub starting
> up..." before I go further.
As a simple check, try "nm -g -n" on the executable and look at what's
in the Sysinit linker section. On psim hello,.exe, I see this:
001d660 D _Linker_set__Sysinit_begin
0001d660 D _Linker_set__Sysinit_bsp_work_area_initialize
0001d660 D __start_set_sysctl_set
0001d660 D __stop_set_sysctl_set
0001d664 D _Linker_set__Sysinit_bsp_start
0001d668 D _Linker_set__Sysinit__User_extensions_Handler_initialization
0001d66c D _Linker_set__Sysinit_rtems_initialize_data_structures
0001d670 D _Linker_set__Sysinit__RTEMS_tasks_Manager_initialization
0001d674 D _Linker_set__Sysinit__POSIX_Keys_Manager_initialization
0001d678 D _Linker_set__Sysinit__Thread_Create_idle
0001d67c D _Linker_set__Sysinit_rtems_libio_init
0001d680 D _Linker_set__Sysinit_rtems_filesystem_initialize
0001d684 D _Linker_set__Sysinit__Console_simple_Initialize
0001d688 D _Linker_set__Sysinit__IO_Initialize_all_drivers
0001d68c D _Linker_set__Sysinit__RTEMS_tasks_Initialize_user_tasks_body
0001d690 D _Linker_set__Sysinit_rtems_libio_post_driver
0001d694 D _Linker_set__Sysinit_end
It's the libio_post_driver one.
Another possibility based on my recollection of the mvme2100 is that
there are variants where some ports are missing or wired out strange
places. Given the file descriptor isn't there, I suspect that
/dev/console wasn't registered. That could mean the console driver
isn't in the build or it didn't see the device it wanted to register.
Check the linker set via nm first. That's easy.
--joel
> Peter
> -
> Peter Dufault
> HD Associates, Inc. Software and System Engineering
>
> This email is delivered through the public internet using protocols subject
> to interception and tampering.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
What opens stdout? printf() fails after rtems-tester printf() succeeds.
I've started testing the PowerPC MVME5500 "beatnik" BSP on the mainline. I've
run through the majority of the RTEMS tests, with some failures, but when I
went to run any basic programs they do not produce any output. They are
obviously running, I can put in a "sleep(3)" and observe it, but no output.
I looked at what rtems-tester does and see it wraps "printf()" and friends. I
found that if:
- I add CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION to my
configuration;
- I used "rtems_test_printf()" that output via "rtems_test_printf()" works.
After that I tried this in my _POSIX_Init(), to see if file descriptor 1 was
open:
const char *hello="Hello to FD 1\r\n";
size_t n = strlen(hello);
size_t output;
rtems_test_printf("rtems_test_printf %s: Hello...\n", __func__);
if ( (output = write(1, hello, n)) != n) {
printk("%s: write() returned %d not %d: %s\n", __func__,
(int)output, (int)n, strerror(errno));
}
The output is:
rtems_test_printf _POSIX_Init: Hello...
_POSIX_Init: write() returned -1 not 15: Bad file number
So file descriptor 1 isn't opened. What establishes the standard open file
descriptors that isn't being called in my update?
I *think* I have the GDB stub working, I had to modify it to bring it
up-to-date, but I'd rather see a console message like "GDB stub starting up..."
before I go further.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to
interception and tampering.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] bsps/beagle: update i2c section
--- user/bsps/arm/beagle.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst index 87c6ecf..fe2dc6f 100644 --- a/user/bsps/arm/beagle.rst +++ b/user/bsps/arm/beagle.rst @@ -61,9 +61,9 @@ Add the following to a file named uEnv.txt: I2C Driver -- -For registering the `/dev/i2c-0` device, a wrapper function is provided, -``bbb_register_i2c_0()`` similarly ``bbb_register_i2c_1()`` and -``bbb_register_i2c_2()`` are respectively used to register `i2c-1` and `i2c-2`. +The Beagle has the `i2c-0` device registered at initialization. For registering +`i2c-1` and `i2c-2` ``bbb_register_i2c_1()`` and +``bbb_register_i2c_2()`` wrapper functions are respectively used. For registering an I2C device with a custom path (say `/dev/i2c-3`) the function ``am335x_i2c_bus_register()`` has to be used. -- 2.20.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Problem running sparc-rtems5-gdb
On Tue, Sep 24, 2019 at 11:00 PM Vijay Kumar Banerjee < vijaykumar9...@gmail.com> wrote: > > > > On Tue, Sep 24, 2019 at 8:42 PM Gedare Bloom wrote: > >> On Sun, Sep 22, 2019 at 2:14 AM Vijay Kumar Banerjee >> wrote: >> > >> > >> > >> > On Sun, Sep 22, 2019, 1:22 PM Niteesh wrote: >> >> >> >> Sorry, for so many questions. >> >> But I was actually following the latest quick start guide, but it is >> lacking information on building and running applications, the last page on >> quick start section was about testing the BSP. That's why I had to refer to >> the old wiki section. >> > >> > >> > The doc has been updated recently and I don't know if someone is >> working on it or not. I see a todo section there, which probably is for >> building and running apps. >> > >> >> how could I patch this? >> > >> > Everyone: Where to add the guide to build and run hello world in docs? >> > >> The User Manual Ch. 2 Quick Start is the right place. >> > Thanks Gedare! > > Niteesh: Would you like to add the instructions to the docs? you will > basically have > to add the steps you followed to get your hello world running. :) > > to write the documentation: > 1. git clone git://git.rtems.org/rtems-docs.git > 2. follow the README.txt to build the docs > 3. add a hello-world.rst under rtems-docs/user/start and write the content. > > Please don't hesitate to ask any question that you might have. > > Best regards, > Vijay. > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Problem running sparc-rtems5-gdb
On Tue, Sep 24, 2019 at 8:42 PM Gedare Bloom wrote: > On Sun, Sep 22, 2019 at 2:14 AM Vijay Kumar Banerjee > wrote: > > > > > > > > On Sun, Sep 22, 2019, 1:22 PM Niteesh wrote: > >> > >> Sorry, for so many questions. > >> But I was actually following the latest quick start guide, but it is > lacking information on building and running applications, the last page on > quick start section was about testing the BSP. That's why I had to refer to > the old wiki section. > > > > > > The doc has been updated recently and I don't know if someone is working > on it or not. I see a todo section there, which probably is for building > and running apps. > > > >> how could I patch this? > > > > Everyone: Where to add the guide to build and run hello world in docs? > > > The User Manual Ch. 2 Quick Start is the right place. > Thanks Gedare! Niteesh: Would you like to add the instructions to the docs? you will basically have to add the steps you followed to get your hello world running. :) to write the documentation: 1. git clone git://git.rtems.org/rtems-docs.git 2. follow the README.txt to build the docs 3. add a hello-world.rst under rtems-docs/user/start and write the content. Please don't hesitate to ask any question that you might have. Best regards, Vijay. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] implementation of smp test smpmrsp02
---
testsuites/smptests/Makefile.am | 16 ++
testsuites/smptests/configure.ac| 2 +
testsuites/smptests/smpmrsp02/init.c| 231
testsuites/smptests/smpmrsp02/smpmrsp02.doc | 15 ++
4 files changed, 264 insertions(+)
create mode 100755 testsuites/smptests/smpmrsp02/init.c
create mode 100644 testsuites/smptests/smpmrsp02/smpmrsp02.doc
diff --git a/testsuites/smptests/Makefile.am b/testsuites/smptests/Makefile.am
index 38cc87e3c5..edb6478b8f 100644
--- a/testsuites/smptests/Makefile.am
+++ b/testsuites/smptests/Makefile.am
@@ -314,6 +314,18 @@ smpmrsp01_CPPFLAGS = $(AM_CPPFLAGS)
$(TEST_FLAGS_smpmrsp01) \
endif
endif
+if HAS_SMP
+if TEST_smpmrsp02
+smp_tests += smpmrsp02
+smp_screens += smpmrsp02/smpmrsp02.scn
+smp_docs += smpmrsp02/smpmrsp02.doc
+smpmrsp02_SOURCES = smpmrsp02/init.c
+smpmrsp02_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_smpmrsp02) \
+ $(support_includes)
+endif
+endif
+
+
if HAS_SMP
if TEST_smpmulticast01
smp_tests += smpmulticast01
@@ -670,4 +682,8 @@ smpwakeafter01_CPPFLAGS = $(AM_CPPFLAGS)
$(TEST_FLAGS_smpwakeafter01) \
endif
endif
+
+
+
noinst_PROGRAMS = $(smp_tests)
+
diff --git a/testsuites/smptests/configure.ac b/testsuites/smptests/configure.ac
index 83b5b9fe41..6336b4e481 100644
--- a/testsuites/smptests/configure.ac
+++ b/testsuites/smptests/configure.ac
@@ -60,6 +60,7 @@ RTEMS_TEST_CHECK([smplock01])
RTEMS_TEST_CHECK([smpmigration01])
RTEMS_TEST_CHECK([smpmigration02])
RTEMS_TEST_CHECK([smpmrsp01])
+RTEMS_TEST_CHECK([smpmrsp02])
RTEMS_TEST_CHECK([smpmulticast01])
RTEMS_TEST_CHECK([smpmutex01])
RTEMS_TEST_CHECK([smpmutex02])
@@ -93,5 +94,6 @@ RTEMS_TEST_CHECK([smpthreadpin01])
RTEMS_TEST_CHECK([smpunsupported01])
RTEMS_TEST_CHECK([smpwakeafter01])
+
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
diff --git a/testsuites/smptests/smpmrsp02/init.c
b/testsuites/smptests/smpmrsp02/init.c
new file mode 100755
index 00..c097fde50b
--- /dev/null
+++ b/testsuites/smptests/smpmrsp02/init.c
@@ -0,0 +1,231 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2019 Ricardo Gomes
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "tmacros.h"
+
+const char rtems_test_name[] = "SMPMRSP 2";
+
+#define CPU_COUNT 2
+
+typedef struct
+{
+ rtems_id init_id;
+ rtems_id scheduler_ids[CPU_COUNT];
+ rtems_id mrsp_id;
+ rtems_id task_id;
+} test_context;
+
+static test_context test_instance;
+
+static void assert_priority(rtems_id task_id, rtems_task_priority priority)
+{
+ rtems_status_code sc;
+ rtems_task_priority prio;
+
+ sc = rtems_task_set_priority(task_id, RTEMS_CURRENT_PRIORITY, );
+ rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+ rtems_test_assert(priority == prio);
+}
+
+/*
+ * Verifying if it is possible to define a priority ceiling
+ * on each scheduler instance
+ */
+static void create_semaphore(test_context *ctx, rtems_id *id,
rtems_task_priority prio)
+{
+ uint32_t index;
+ rtems_status_code sc;
+
+ sc = rtems_semaphore_create(
+ rtems_build_name('M', 'R', 'S', 'P'),
+ 1,
+ RTEMS_MULTIPROCESSOR_RESOURCE_SHARING | RTEMS_BINARY_SEMAPHORE,
+ prio,
+ id);
+ rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+ rtems_task_priority old_prio;
+
+ old_prio = 1;
+ sc = rtems_semaphore_set_priority(
+ *id,
+ ctx->scheduler_ids[1],
+ prio + 1,
+ _prio);
+ rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+ prio = 2;
+ for (index = 0; index < CPU_COUNT; index++)
+ {
+rtems_task_priority pr = RTEMS_CURRENT_PRIORITY;
+sc = rtems_semaphore_set_priority(*id,
Re: BSD licensed Picolibc 1.0 released
On Tue, Sep 24, 2019 at 10:03 AM Gedare Bloom wrote: > > Hi mko, > > RTEMS has a fairly strong relationship (dependency) with newlib, and > that has been working well for a long time. Although the prospect of > having a way to 'drop-in' alternative libc could be nice for small > targets, it would be of more interest to us to see ways to optimize > newlib to shrink it if needed. The use of stripped-down libc for > low-resource targets usually means a feature-rich RTOS like RTEMS will > not be needed either. These kinds of libc are more interesting for > baremetal or low-complexity RTOSs, and some hypervisor-like systems > that want an extremely small, trusted code base. I don't know what was done beyond the nano configure option to newlib. And, honestly, I don't know if that switch breaks any POSIX behavior. Is there a list of what's been done since the nano switch work on newlib? Replacing the build system isn't of interest to us. --joel > > But, thanks for the heads up about the picolibc. > > Gedare > > On Tue, Sep 24, 2019 at 5:09 AM mko wrote: > > > > Hi List, > > I just got this news from my RSS feed, after a brief read, I think this is > > a better and simpler alternative of newlib library, Does anyone know how to > > use it in rtems project? > > > > mko > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Problem running sparc-rtems5-gdb
On Sun, Sep 22, 2019 at 2:14 AM Vijay Kumar Banerjee wrote: > > > > On Sun, Sep 22, 2019, 1:22 PM Niteesh wrote: >> >> Sorry, for so many questions. >> But I was actually following the latest quick start guide, but it is lacking >> information on building and running applications, the last page on quick >> start section was about testing the BSP. That's why I had to refer to the >> old wiki section. > > > The doc has been updated recently and I don't know if someone is working on > it or not. I see a todo section there, which probably is for building and > running apps. > >> how could I patch this? > > Everyone: Where to add the guide to build and run hello world in docs? > The User Manual Ch. 2 Quick Start is the right place. >> >>> >> On Sun, Sep 22, 2019 at 1:01 PM Vijay Kumar Banerjee >> a wrote: >>> >>> >>> >>> On Sun, Sep 22, 2019 at 12:59 PM Niteesh wrote: https://devel.rtems.org/wiki/TBR/UserManual/Quick_Start#Running I actually changed the rtems version from 4.11 to 5 in the command, there was no documentation about the change in version 5. >>> This wiki page is a bit outdated and marked as "To be removed". You should >>> follow the latest docs quickstart guide: >>> https://docs.rtems.org/branches/master/user/start/index.html On Sun, Sep 22, 2019 at 12:30 PM Vijay Kumar Banerjee wrote: > > Hello, > > I just checked that the built-in sis in gdb has been disabled in this > commit: > https://git.rtems.org/rtems-source-builder/commit/?id=abc540105d10ddc9cad7de3c7ac0a9aa209ac828 > > Niteesh: This means that the command you should use is `sparc-rtems5-sis`. > Can you please post the link to the exact page where the > `sparc-rtems5-gdb` > steps are mentioned with `tar sim`? I think this would need to be updated > and > you can propose a patch for this. > > Best regards, > Vijay > > > On Sun, Sep 22, 2019 at 11:04 AM Vijay Kumar Banerjee > wrote: >> >> >> >> ( Please use the reply to all option to keep the conversation on the >> list ) >> On Sun, Sep 22, 2019 at 10:50 AM Niteesh wrote: >>> >>> bsp: erc32 >>> >>> arch: sparc >> >> Odd. It is expected to work in erc32 if your build is right. I don't >> have a >> recent sparc build so I can't verify right now. >> Let's wait for other people to join and help with the issue. :) >>> >>> >>> On Sun, Sep 22, 2019 at 10:49 AM Vijay Kumar Banerjee >>> wrote: On Sun, Sep 22, 2019 at 10:35 AM Niteesh wrote: > > The problem actually occurred when I was trying to run the hello.exe > with gdb. > 1: sparc-rtems5-gdb hello.exe > and inside gdb to set the target as simulator. > 2: tar sim > This is the expected sequence, what BSP are you using? > > (gdb) tar sim > Undefined target command: "sim". Try "help target". > > While going through some stackoverflow posts I found that to target > simulators --enable-sim has to given while building gdb, Is this the > problem or am I missing something? > > On Sun, Sep 22, 2019 at 10:29 AM Vijay Kumar Banerjee > wrote: >> >> >> >> On Sun, Sep 22, 2019 at 10:01 AM Niteesh wrote: >>> >>> I was following the quick-start guide from >>> https://docs.rtems.org/branches/master/user/start/index.html >>> I followed the exact steps but still couldn't get the hello world >>> running. I face issues when running the GDB, when trying to set the >>> target to simulator I get "undefined target cmd: sim", >>> Is it an issue on my side or is something missing in the docs? >> >> Hi Niteesh, >> >> Usually, it is enough to post to any one of devel or users list. >> >> Can you please post the exact command sequence that gave you the >> error? You can copy the command output here if it's not long, or >> paste >> it somewhere like a github gist and send the link here. >> >> Best regards, >> Vijay >>> >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Where are results of rtems-tester test results archived?
On Sat, Sep 21, 2019 at 9:41 AM Joel Sherrill wrote: > > > > On Sat, Sep 21, 2019, 10:18 AM wrote: >> >> >> > On Sep 21, 2019, at 11:03 , Joel Sherrill wrote: >> > >> > >> > >> > On Sat, Sep 21, 2019, 9:55 AM Peter Dufault wrote: >> > I’ve searched but can’t find anywhere. I’d like to see the results of the >> > tests on all architectures to compare to what I see on PowerPC-beatnik. >> > >> > There is a build@ mailing list and the archives are at >> > https://lists.rtems.org/pipermail/build/ >> > >> > There should be results from at least me for psim. >> > >> > You are encouraged to subscribe to the list and post results. Many boards >> > have no results. >> > >> > >> >> That doesn’t look like what I want. I’m looking for something like the >> following (a small snippet of my test run in progress) to see what failures >> are shared by what board support packages. >> >> [141/597] p:128 f:7 u:2 e:0 I:0 B:3 t:0 i:0 W:0 | >> powerpc/beatnik: telnetd01.exe >> [142/597] p:129 f:7 u:2 e:0 I:0 B:3 t:0 i:0 W:0 | >> powerpc/beatnik: termios.exe >> [143/597] p:129 f:7 u:3 e:0 I:0 B:3 t:0 i:0 W:0 | >> powerpc/beatnik: termios01.exe >> [144/597] p:129 f:8 u:3 e:0 I:0 B:3 t:0 i:0 W:0 | >> powerpc/beatnik: termios02.exe >> [145/597] p:129 f:9 u:3 e:0 I:0 B:3 t:0 i:0 W:0 | >> powerpc/beatnik: termios03.exe >> [146/597] p:130 f:9 u:3 e:0 I:0 B:3 t:0 i:0 W:0 | >> powerpc/beatnik: termios04.exe >> [147/597] p:131 f:9 u:3 e:0 I:0 B:3 t:0 i:0 W:0 | >> powerpc/beatnik: termios05.exe > > > Most are for tools builds. I have a script I run periodically which includes > tools and bsps. This is a psim results post: > https://lists.rtems.org/pipermail/build/2019-August/002973.html > > It shows the failures but still doesn't show the in process view. Does that > help at all? > Just to jump in, as I recall the "in process" view is not always useful, since it does not exactly tell you what has failed (when you run several tests in parallel, that is). Collecting the end results of could be nice. Automating this and creating a colored status matrix would be a nice little project for someone. > FWIW I haven't investigated the 15 failures on psim. > > --joel >> >> >> >> >> >> >> Peter >> - >> Peter Dufault >> HD Associates, Inc. Software and System Engineering >> >> This email is delivered through the public internet using protocols subject >> to interception and tampering. >> > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: BSD licensed Picolibc 1.0 released
Hi mko, RTEMS has a fairly strong relationship (dependency) with newlib, and that has been working well for a long time. Although the prospect of having a way to 'drop-in' alternative libc could be nice for small targets, it would be of more interest to us to see ways to optimize newlib to shrink it if needed. The use of stripped-down libc for low-resource targets usually means a feature-rich RTOS like RTEMS will not be needed either. These kinds of libc are more interesting for baremetal or low-complexity RTOSs, and some hypervisor-like systems that want an extremely small, trusted code base. But, thanks for the heads up about the picolibc. Gedare On Tue, Sep 24, 2019 at 5:09 AM mko wrote: > > Hi List, > I just got this news from my RSS feed, after a brief read, I think this is a > better and simpler alternative of newlib library, Does anyone know how to use > it in rtems project? > > mko > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-libbsd commit] Add pselect()
Hi
Before I update the compliance tracking to add pselect(), have any other
POSIX methods been added recently which I have missed?
Thanks.
--joel
On Mon, Sep 23, 2019 at 7:38 AM Sebastian Huber wrote:
>
> Module:rtems-libbsd
> Branch:master
> Commit:cff1625f2787e08f33e67f949c0722c0aa05f618
> Changeset:
> http://git.rtems.org/rtems-libbsd/commit/?id=cff1625f2787e08f33e67f949c0722c0aa05f618
>
> Author:Sebastian Huber
> Date: Mon Sep 23 14:27:32 2019 +0200
>
> Add pselect()
>
> ---
>
> freebsd/sys/kern/sys_generic.c | 37
> testsuite/selectpollkqueue01/test_main.c | 62 +-
> testsuite/syscalls01/test_main.c | 76
>
> 3 files changed, 174 insertions(+), 1 deletion(-)
>
> diff --git a/freebsd/sys/kern/sys_generic.c b/freebsd/sys/kern/sys_generic.c
> index 24da393..cc208d6 100644
> --- a/freebsd/sys/kern/sys_generic.c
> +++ b/freebsd/sys/kern/sys_generic.c
> @@ -1179,6 +1179,43 @@ select(int nfds, fd_set *readfds, fd_set *writefds,
> fd_set *errorfds,
> rtems_set_errno_and_return_minus_one(error);
> }
> }
> +
> +int
> +pselect(int nfds, fd_set *readfds, fd_set *writefds, fd_set *errorfds,
> +const struct timespec *timeout, const sigset_t *set)
> +{
> + struct thread *td;
> + int error;
> +
> + if (set != NULL) {
> + rtems_set_errno_and_return_minus_one(ENOSYS);
> + }
> +
> + td = rtems_bsd_get_curthread_or_null();
> +
> + if (td != NULL) {
> + struct timeval tv;
> + struct timeval *tvp;
> +
> + if (timeout != NULL) {
> + TIMESPEC_TO_TIMEVAL(, timeout);
> + tvp =
> + } else {
> + tvp = NULL;
> + }
> +
> + error = kern_select(td, nfds, readfds, writefds, errorfds,
> + tvp, NFDBITS);
> + } else {
> + error = ENOMEM;
> + }
> +
> + if (error == 0) {
> + return td->td_retval[0];
> + } else {
> + rtems_set_errno_and_return_minus_one(error);
> + }
> +}
> #endif /* __rtems__ */
>
> /*
> diff --git a/testsuite/selectpollkqueue01/test_main.c
> b/testsuite/selectpollkqueue01/test_main.c
> index fc05643..244f5b5 100755
> --- a/testsuite/selectpollkqueue01/test_main.c
> +++ b/testsuite/selectpollkqueue01/test_main.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2013 embedded brains GmbH. All rights reserved.
> + * Copyright (c) 2013, 2019 embedded brains GmbH. All rights reserved.
> *
> * embedded brains GmbH
> * Dornierstr. 4
> @@ -522,6 +522,63 @@ test_select_close(test_context *ctx)
> }
>
> static void
> +test_pselect_sigmask(void)
> +{
> + int rv;
> + sigset_t set;
> +
> + puts("test pselect sigmask");
> +
> + sigemptyset();
> + errno = 0;
> + rv = pselect(0, NULL, NULL, NULL, NULL, );
> + assert(rv == -1);
> + assert(errno == ENOSYS);
> +}
> +
> +static void
> +test_pselect_timeout(test_context *ctx)
> +{
> + struct timespec timeout = {
> + .tv_sec = 0,
> + .tv_nsec = 1
> + };
> + int fd = ctx->lfd;
> + int nfds = fd + 1;
> + struct fd_set set;
> + int rv;
> + int i;
> +
> + puts("test pselect timeout");
> +
> + set_non_blocking(ctx->lfd, 0);
> +
> + FD_ZERO();
> + FD_SET(fd, );
> +
> + rv = pselect(nfds, , NULL, NULL, , NULL);
> + assert(rv == 0);
> +
> + for (i = 0; i < nfds; ++i) {
> + assert(!FD_ISSET(i, ));
> + }
> +
> + rv = pselect(nfds, NULL, , NULL, , NULL);
> + assert(rv == 0);
> +
> + for (i = 0; i < nfds; ++i) {
> + assert(!FD_ISSET(i, ));
> + }
> +
> + rv = pselect(nfds, NULL, NULL, , , NULL);
> + assert(rv == 0);
> +
> + for (i = 0; i < nfds; ++i) {
> + assert(!FD_ISSET(i, ));
> + }
> +}
> +
> +static void
> test_poll_timeout(test_context *ctx)
> {
> static const short events[] = {
> @@ -1199,6 +1256,9 @@ test_main(void)
> test_select_write(ctx);
> test_select_close(ctx);
>
> + test_pselect_sigmask();
> + test_pselect_timeout(ctx);
> +
> test_poll_timeout(ctx);
> test_poll_connect(ctx);
> test_poll_read(ctx);
> diff --git a/testsuite/syscalls01/test_main.c
> b/testsuite/syscalls01/test_main.c
> index b95a6c2..3254ba5 100644
> --- a/testsuite/syscalls01/test_main.c
> +++ b/testsuite/syscalls01/test_main.c
> @@ -1329,6 +1329,81 @@ test_socket_select(void)
> }
>
> static void
> +no_mem_socket_pselect(int fd)
> +{
> + struct fd_set set;
> + int nfds;
> + int rv;
> +
> + FD_ZERO();
> + FD_SET(fd, );
> + nfds = fd + 1;
> +
> + errno = 0;
> + rv = pselect(nfds, , NULL, NULL, NULL, NULL);
> +
BSD licensed Picolibc 1.0 released
Hi List, I just got this news from my RSS feed, after a brief read, I think this is a better and simpler alternative of newlib library, Does anyone know how to use it in rtems project? mko ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LLVM on openSUSE 15.1
On 24/9/19 4:06 pm, Sebastian Huber wrote:
> Hello,
>
> with the libedit development package mentioned by Gedare,
Thank you for testing this.
> I got a bit further in the build:
>
> onfig: tools/rtems-llvm-8.0.1.cfg
> package: rtems-llvm-8.0.1-x86_64-linux-gnu-1
> building: rtems-llvm-8.0.1-x86_64-linux-gnu-1
> error: building rtems-llvm-8.0.1-x86_64-linux-gnu-1
> Build FAILED
> error: failure to create error report
> Build Set: Time 0:34:28.127871
> Traceback (most recent call last):
> File "../source-builder/sb/cmd-set-builder.py", line 26, in
> setbuilder.run()
> File "/scratch/git-rtems-source-builder/source-builder/sb/setbuilder.py",
> line
> 732, in run
> b.build(deps, mail = mail)
> File "/scratch/git-rtems-source-builder/source-builder/sb/setbuilder.py",
> line
> 473, in build
> self.build_package(configs[s], b)
> File "/scratch/git-rtems-source-builder/source-builder/sb/setbuilder.py",
> line
> 258, in build_package
> _build.make()
> File "/scratch/git-rtems-source-builder/source-builder/sb/build.py", line
> 579,
> in make
> self._generate_report_('Build: %s' % (gerr))
> File "/scratch/git-rtems-source-builder/source-builder/sb/build.py", line
> 126,
> in _generate_report_
> self.opts, header, footer)
> File "/scratch/git-rtems-source-builder/source-builder/sb/ereport.py", line
> 56, in generate
> l.write(os.linesep.join(r))
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 156:
> ordinal not in range(128)
This looks like a bug in the RSB. Hmmm I will need to think of a way to create
this problem so I can fix it.
> The build error was:
>
> /scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Core/IOHandler.cpp:14:10:
> fatal error: panel.h: No such file or directory
> #include
> ^
> compilation terminated.
>
> This looks like an openSUSE problem:
>
> https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/llvm/lldb-cmake.patch?expand=0
I am starting to wonder if lldb is a step to far for us at this point in time.
Enabling it has exposed these issues. If I disable it so the tools build we can
concentrate on building and running RTEMS and once we have that sorted we can
come back to lldb. Maybe things will have improved by them.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: LLVM on openSUSE 15.1
Hello,
with the libedit development package mentioned by Gedare, I got a bit
further in the build:
onfig: tools/rtems-llvm-8.0.1.cfg
package: rtems-llvm-8.0.1-x86_64-linux-gnu-1
building: rtems-llvm-8.0.1-x86_64-linux-gnu-1
error: building rtems-llvm-8.0.1-x86_64-linux-gnu-1
Build FAILED
error: failure to create error report
Build Set: Time 0:34:28.127871
Traceback (most recent call last):
File "../source-builder/sb/cmd-set-builder.py", line 26, in
setbuilder.run()
File
"/scratch/git-rtems-source-builder/source-builder/sb/setbuilder.py",
line 732, in run
b.build(deps, mail = mail)
File
"/scratch/git-rtems-source-builder/source-builder/sb/setbuilder.py",
line 473, in build
self.build_package(configs[s], b)
File
"/scratch/git-rtems-source-builder/source-builder/sb/setbuilder.py",
line 258, in build_package
_build.make()
File "/scratch/git-rtems-source-builder/source-builder/sb/build.py",
line 579, in make
self._generate_report_('Build: %s' % (gerr))
File "/scratch/git-rtems-source-builder/source-builder/sb/build.py",
line 126, in _generate_report_
self.opts, header, footer)
File
"/scratch/git-rtems-source-builder/source-builder/sb/ereport.py", line
56, in generate
l.write(os.linesep.join(r))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position
156: ordinal not in range(128)
The build error was:
/scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Core/IOHandler.cpp:14:10:
fatal error: panel.h: No such file or directory
#include
^
compilation terminated.
This looks like an openSUSE problem:
https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/llvm/lldb-cmake.patch?expand=0
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
