Re: Comments in spec files in rtems.git
On 21/9/20 12:35 am, Sebastian Huber wrote: > On 19/09/2020 02:43, Chris Johns wrote: >> Hi, >> >> Can comments be added to the .yml files under specs in rtems.git? > the problem with comments in YAML files is that they are not preserved if you > parse the files and write them back. Could we have a comment block that is a YAML field? Hmm I see a description field, I wonder if that could serve this purpose. Is that field available in all files? >> I was looking over a few files and wonder if some comments would help. > Could you give an example? Maybe we could add an attribute for this. I picked this file at random ... https://git.rtems.org/rtems/tree/spec/build/bsps/optabi.yml What does it do? It is needed in all BSP build files? While this file ... https://git.rtems.org/rtems/tree/spec/build/bsps/tst.yml ... has something which indicates what it is for and I assume I could edit this and add more detail, for example it is automatically picked up or it needs to be included in XXX. Then in a BSP ... https://git.rtems.org/rtems/tree/spec/build/bsps/powerpc/mvme5500/bspmvme5500.yml ... says nothing about the board, has no links. There is no way to see the dependencies between all the files unless you build a mental image ... https://git.rtems.org/rtems/tree/spec/build/bsps/powerpc/mvme5500/bspmvme5500.yml and ../../opto2 What does this file do ... https://git.rtems.org/rtems/tree/spec/build/bsps/powerpc/motorola_powerpc/qemufakerom.yml ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Build FreeBSD: FAILED 6/rtems-arm on x86_64-freebsd12.1 (rtems-tools-9fcc20789367ef476eb9ffbc6e2f9fabf686e10f-1)
On 21/9/20 10:42 am, Joel Sherrill wrote: > Add doesn't address starting from Cron I run the RSB from cron on FreeBSD and MacOS without any issues. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: gcc/RSB std::runtime patches and tickets
On 22/9/20 7:09 am, Joel Sherrill wrote: > Hi > > I'm trying to get this one tidied up and committed. I'm questioning how many > tickets this needs based on RTEMS and tools versions. > > + #2830 - I reassigned this to 5.2 > + #4084 - Created to track against 6. > - need RSB patch against gcc 10.2.1 for RTEMS 6 > > Do we need another ticket for rtems7 tools or is $4084 enough? Looks pretty cheap to me! The single ticket for "master" is fine. > When I get the patch into gcc master, rtems7 will fix itself. > > If I get the patch onto the gcc 10 branch, then we have to revisit the RSB > patch > addition when we update to a new gcc 10.x release. > > I'd like to think a ticket for 5 and a ticket for 6 are sufficient. I agree. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
gcc/RSB std::runtime patches and tickets
Hi I'm trying to get this one tidied up and committed. I'm questioning how many tickets this needs based on RTEMS and tools versions. + #2830 - I reassigned this to 5.2 + #4084 - Created to track against 6. - need RSB patch against gcc 10.2.1 for RTEMS 6 Do we need another ticket for rtems7 tools or is $4084 enough? When I get the patch into gcc master, rtems7 will fix itself. If I get the patch onto the gcc 10 branch, then we have to revisit the RSB patch addition when we update to a new gcc 10.x release. I'd like to think a ticket for 5 and a ticket for 6 are sufficient. Thoughts? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: pc386 BSP documentation tweaks.
On Mon, Sep 21, 2020 at 12:40 PM Karel Gardas wrote: > On 9/21/20 7:34 PM, Gedare Bloom wrote: > > On Sat, Sep 19, 2020 at 2:31 PM Karel Gardas > wrote: > >> > >> > >> Hello, > >> > >> attached are three patches: > >> > >> pc386 BSP: add runtime options for debugging and move few lines > >> around for better context. > >> pc386 BSP: add a note about default baud rate for console over > UART/COM. > >> pc386 BSP: remove USE_COM1_AS_CONSOLE reference, the option is long > >> time gone. > > > > We still have this option, but I don't think it does anything. Maybe > > it should be noted as "Obsolete"? > > By "long gone" I mean this option is handled by configure/make and now > also waf, but is not preserved in the C code at all. So basically the > option does nothing as implementation C code was probably removed. > > Or am I looking wrong? > No. It is dead as in "He's dead, Jim". :) It is still in the README: pc386/README:+ BSP_ENABLE_COM1_COM4 - value of 1 to enable, 0 to disable pc386/README:+ BSP_USE_COM1_AS_CONSOLE - value of 1 forces console to COM1 pc386/README: USE_COM1_AS_CONSOLE=1 --enable-rtemsbsp=pc386 \ And I think providing guidance in the user's manual that if you used to use this option when building, that there is a new way to achieve the same result would be desirable. --joel > > Thanks, > Karel > ___ > 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: pc386 BSP documentation tweaks.
On 9/21/20 7:52 PM, Gedare Bloom wrote: >> By "long gone" I mean this option is handled by configure/make and now >> also waf, but is not preserved in the C code at all. So basically the >> option does nothing as implementation C code was probably removed. >> >> Or am I looking wrong? >> > > I think you're correct. I'm just wondering if it is better to note > that this option exists but doesn't do anything, as opposed to just > removing its documentation. I've not managed this over my weekend RTEMS hobby but my idea was to submit doc change first and then also submit source code change which would remove configuration bits of the option completely -- result would be RTEMS clean of the option completely. Sorry about missing source code removal yet. Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: pc386 BSP documentation tweaks.
On Mon, Sep 21, 2020 at 11:40 AM Karel Gardas wrote: > > On 9/21/20 7:34 PM, Gedare Bloom wrote: > > On Sat, Sep 19, 2020 at 2:31 PM Karel Gardas > > wrote: > >> > >> > >> Hello, > >> > >> attached are three patches: > >> > >> pc386 BSP: add runtime options for debugging and move few lines > >> around for better context. > >> pc386 BSP: add a note about default baud rate for console over > >> UART/COM. > >> pc386 BSP: remove USE_COM1_AS_CONSOLE reference, the option is long > >> time gone. > > > > We still have this option, but I don't think it does anything. Maybe > > it should be noted as "Obsolete"? > > By "long gone" I mean this option is handled by configure/make and now > also waf, but is not preserved in the C code at all. So basically the > option does nothing as implementation C code was probably removed. > > Or am I looking wrong? > I think you're correct. I'm just wondering if it is better to note that this option exists but doesn't do anything, as opposed to just removing its documentation. > Thanks, > Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: pc386 BSP documentation tweaks.
On 9/21/20 7:34 PM, Gedare Bloom wrote: > On Sat, Sep 19, 2020 at 2:31 PM Karel Gardas wrote: >> >> >> Hello, >> >> attached are three patches: >> >> pc386 BSP: add runtime options for debugging and move few lines >> around for better context. >> pc386 BSP: add a note about default baud rate for console over UART/COM. >> pc386 BSP: remove USE_COM1_AS_CONSOLE reference, the option is long >> time gone. > > We still have this option, but I don't think it does anything. Maybe > it should be noted as "Obsolete"? By "long gone" I mean this option is handled by configure/make and now also waf, but is not preserved in the C code at all. So basically the option does nothing as implementation C code was probably removed. Or am I looking wrong? Thanks, Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: pc386 BSP documentation tweaks.
On Sat, Sep 19, 2020 at 2:31 PM Karel Gardas wrote: > > > Hello, > > attached are three patches: > > pc386 BSP: add runtime options for debugging and move few lines > around for better context. > pc386 BSP: add a note about default baud rate for console over UART/COM. > pc386 BSP: remove USE_COM1_AS_CONSOLE reference, the option is long > time gone. We still have this option, but I don't think it does anything. Maybe it should be noted as "Obsolete"? > > please review/commit or request change(s). > > The patches are based on my playing with BSP and seeing documentation > limitations or missing info bits... > > Thanks, > Karel > ___ > 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: Fatal exceptions on context-switching for more than two isolated threads
On Sat, Sep 19, 2020 at 5:41 AM Utkarsh Rai wrote: > > Hello, > When I isolate more than two threads in RTEMS (the implementation can be > found here), I get fatal exceptions while context-switching. On stepping into > the code, the problem seems to be with the _User_extensions_Thread_*() call > just after a context-switch, in particular when the iterators are initialized > inside this call. The issue is the fact that we mark the stack space of the > switched out thread as 'NO_ACESS' and then try to access iterators(which > belong to the stack space of the switched-out thread) from a different > thread, which leads to fatal exceptions. > I am not sure how to handle this issue because I am not very clear on the > purpose of the "user extension" functionality or its implementation. Any help > would be appreciated, as this may possibly be the last hurdle for a mergeable > thread stack isolation feature. Are you testing in an SMP configuration? The user extensions in uniprocessor run before the context switch. It would help if you provide a trace of your debug. You might consider using the event recorder to also help with your debugging. https://docs.rtems.org/branches/master/user/tracing/index.html > ___ > 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: How to use lvgl on pc386 BSP.
Hello Karel and all others, the GPU PC grade graphics card are really complex systems which require firmware etc. Due to legacy nature of 1982 PC design and keeping compatibility forever there is no simple PCI hardware class which would allow to list supported modes and set one of them and map continuous framebuffer memory portabe way. Only register model which allows direct access to videoram is old VGA hardware registers set and mapping which is completely insufficient to send image to today displays. It allows only map 64kB (may be 128kB) starting from 0xA which is enough for text mode but unusable without page switching for anything more. The real solution is t use full featured driver but today GPUs are mainly 3D accelerators and plain flat RGB framebuffer is setup and image processed by part of 3D engine. When complete setup is required it pulls in complete 3D DRM driver. Some graphics cards have no documentation how to setup mode from driver (Nvidia,...) but reverseengineered open source drivers exists. Some GPUs (Intel, AMD) are documented. But port subset of the drivers to cover most of the graphics cards found on PCs is a problem. You have to take whole graphics stack from some system with really wider developers community (Linux, BSD) which is really huge. Or try to separate setup subset but when new card model appears, you are in a trouble, amount of work is huge. When we wanted to use RTEMS i386 BSP to test Microwindows/Nano-X RTEMS application in QEMU, we have tried to provide at least something that works (Our main target has been infusion system running on RTEMS on ARM https://devel.rtems.org/wiki/TBR/UserApp/AMV_Technic_I ). On Saturday 19 of September 2020 23:41:58 Karel Gardas wrote: > On 9/19/20 10:32 AM, Christian Mauderer wrote: > Yes, in fact there are three FB drivers in pc386 BSP family: > > - for VGA card > - for Cirrus Logic GD5446 card > - for VESA BIOS Extension capable graphics card One feasible option was to implement real hardware driver for simple target hardware available in QEMU. GD544 is old graphics card but with know registers set and that is why it is used by QEMU. The driver has been implemented during GSoC 2012 by Alexandru-Sever Horin. I have not tested it for years. If I remember well it is not capable to read EDID from the display so fixed parameters has to be specified. The other solution which has higher chance to work on broader hardware range is to use some firmware with know common API which is provided by board manufacturer and knows its internal structure and registers. Because even old PC BIOS, DOS code and operating systems loaders need to manage cards, VESA BIOS has been introduced as ROM module which is called by main BIOS, setups basic mode to shouw at least something on the monitor and allows to switch boot menus to graphic mode as well. In a theore, VBE extension entry point should allows to call this code from the protected mode environment but as we have experienced with Jan Dolezal in 2014, the most of the cards have not implemented this entry or its functionality has been broken. So only option was to use old "DOS" real mode entry from x86 CPU 16-bit real-mode. The graphics card setup is called before RTEMS takes full control over CPU and before switch to protected mode is proceed. Call to the VESA BIOS setups the graphics mode and maps complete framebuffer into memory address range available for IO/PCI boarads. Then the framebuffer start address is passed into RTEMS, it switches to the protexted linear address mode and framebuffer start address is returned to the application when it requests information from the driver. The is probably source of your problem. On the Linux and BSD, the framebuffer is mapped into virtual address range and page table has to be setup for graphics process to translate user-space address into physical address. So you need mmap of physical address range into virtual one or the framebuffer driver has to provide mmap operation which allows to map part of the "/dev/fb" "file" into process space. But RTEMS is single linear address space system, so the start of the framebuffer address returned by IOCTL is already address where the RGB color bytes are present. See the Nano-X RTEMS driver https://github.com/ghaerr/microwindows/blob/c1c3595674a1e64d5e26ff4ef25a557c7452d546/src/drivers/scr_rtems.c#L78 The IOCTL returns framebuffer parameters and returned start address is used directly as the address o the start of the plane to draw images onto https://github.com/ghaerr/microwindows/blob/c1c3595674a1e64d5e26ff4ef25a557c7452d546/src/drivers/scr_rtems.c#L140 So it is highly probable that if you skip mmap or other equivalent fragment of the code in LVGL and copy start address without modification, you have your graphics image on the screen. I have interrest for LVGL, we have tried it on NuttX. Which sources are you using and what is your configuration? > The latest one is enabled by default and that's what
[PATCH v4] Test for clock_nanosleep() with CLOCK_MONOTONIC option
From: Utkarsh
Closes #3890
Signed-off-by: Utkarsh Rai
---
spec/build/testsuites/psxtests/grp.yml| 2 +
.../psxtests/psxclocknanosleep01.yml | 20 +++
.../psxtests/psxclocknanosleep01/init.c | 94 ++
.../psxclocknanosleep01.doc | 13 ++
.../psxclocknanosleep01.scn | 41 ++
.../test-clock-nanosleep.c| 120 ++
6 files changed, 290 insertions(+)
create mode 100644 spec/build/testsuites/psxtests/psxclocknanosleep01.yml
create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
create mode 100644
testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
create mode 100644
testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
create mode 100644
testsuites/psxtests/psxclocknanosleep01/test-clock-nanosleep.c
diff --git a/spec/build/testsuites/psxtests/grp.yml
b/spec/build/testsuites/psxtests/grp.yml
index 47dedac275..3342fc6c18 100644
--- a/spec/build/testsuites/psxtests/grp.yml
+++ b/spec/build/testsuites/psxtests/grp.yml
@@ -79,6 +79,8 @@ links:
uid: psxclock
- role: build-dependency
uid: psxclock01
+- role: build-dependency
+ uid: psxclocknanosleep01
- role: build-dependency
uid: psxclockrealtime01
- role: build-dependency
diff --git a/spec/build/testsuites/psxtests/psxclocknanosleep01.yml
b/spec/build/testsuites/psxtests/psxclocknanosleep01.yml
new file mode 100644
index 00..39ec1657d2
--- /dev/null
+++ b/spec/build/testsuites/psxtests/psxclocknanosleep01.yml
@@ -0,0 +1,20 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2020 Utkarsh Rai (utkarsh.ra...@mail.com)
+cppflags: []
+cxxflags: []
+enabled-by: true
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/psxtests/psxclocknanosleep01/init.c
+- testsuites/psxtests/psxclocknanosleep01/test-clock-nanosleep.c
+stlib: []
+target: testsuites/psxtests/psxclocknanosleep01.exe
+type: build
+use-after: []
+use-before: []
diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c
b/testsuites/psxtests/psxclocknanosleep01/init.c
new file mode 100644
index 00..a5cb4d6054
--- /dev/null
+++ b/testsuites/psxtests/psxclocknanosleep01/init.c
@@ -0,0 +1,94 @@
+/* SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2020 Utkarsh Rai
+ *
+ * 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
+
+const char rtems_test_name[] = "PSXCLOCKNANOSLEEP01";
+
+static char buffer[512];
+
+static const T_action actions[] = {
+ T_report_hash_sha256,
+ T_check_task_context,
+ T_check_file_descriptors,
+ T_check_rtems_barriers,
+ T_check_rtems_extensions,
+ T_check_rtems_message_queues,
+ T_check_rtems_partitions,
+ T_check_rtems_periods,
+ T_check_rtems_regions,
+ T_check_rtems_semaphores,
+ T_check_rtems_tasks,
+ T_check_rtems_timers,
+ T_check_posix_keys
+};
+
+static const T_config config = {
+ .name = "POSIXCLOCKNANOSLEEPTEST01",
+ .buf = buffer,
+ .buf_size = sizeof( buffer ),
+ .putchar = rtems_put_char,
+ .verbosity = T_VERBOSE,
+ .now = T_now_clock,
+ .action_count = T_ARRAY_SIZE( actions ),
+ .actions = actions
+};
+
+static void
+Init( rtems_task_argument arg )
+{
+ int exit_code;
+
+ (void) arg;
+ TEST_BEGIN();
+
+ T_register();
+ exit_code = T_main( );
+ if (exit_code == 0) {
+ TEST_END();
+ }
+
+ rtems_test_exit( exit_code );
+}
+
