Re: What to do with rtems_cache_disable_data()?
> On Jun 14, 2024, at 5:47 AM, Sebastian Huber
> wrote:
>
> Hello,
>
> an user noticed that for example on the Xilinx Zynq 7000 BSP, the
> rtems_cache_disable_data() doesn't work.
>
> I had a look at this and managed to disable the L1 and L2 caches, however,
> afterwards I got not that far. On the Cortex-A cores it seems at least the L1
> data cache is required to provide support for atomic operations:
>
> https://stackoverflow.com/questions/76207164/disabled-dcache-will-prevent-atomic-flag-from-being-set
>
> I guess we have this situation on most modern chips with caches since the
> reservation granule is usually a cache line. How do we want to deal with
> rtems_cache_disable_data() in this case? From my point of view, this function
> as no real use case and adding it in the first place was a mistake.
>
> We have a couple of options:
>
> * Make the rtems_cache_disable_data() directive a no-operation. Afterwards
> the cache is still enabled, and an user may get confused.
>
> * Issue a fatal error if someone calls rtems_cache_disable_data().
>
> * Really disable the cache and let the user figure out that the atomic
> operations no longer work. Disabling the data cache can be a quite complex
> thing to do.
>
> * Add a return status code to rtems_cache_disable_data() and let it return
> RTEMS_UNSATISFIED for example.
Assuming "this function has no real use case and adding it in the first place
was a mistake" how about:
- In the active release continue to disable the data cache but add a warning
attribute 'warning ("Disabling data cache breaks atomic functionality")';
- In the next release change it to an error attribute and change the function
behavior to do nothing except return RTEMS_UNSATISFIED (in case someone somehow
still calls it), or better change it to call an RTEMS fatal function.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 6 branching
> On Apr 24, 2024, at 9:27 AM, Kinsey Moore wrote: > > That use case definitely wasn't considered for rtems-lwip and I don't know > that it's ever been discussed. If that were intended, I'd expect a "./waf > uninstall" target to exist that would remove the installed network stack so > that you could install a different one since the different stacks install > vastly different sets of headers. IIRC, Chris advocates for installing the > network libraries into a different location than the installed BSP to allow > you to choose which you want at a later time. > > Kinsey I've been moving a driver from legacy to bsd so I definitely need to easily switch back and forth for the same BSP for testing. I agree with Chris, but it's apparently a desirement, not a requirement, so it shouldn't hold up the branching. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 6 branching
> On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee wrote: > > > > On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill wrote: > > > On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber > wrote: > - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org: > > > Hi, > > > > There has been some discussion about when we will branch and it is timely we > > discuss this. This is my input. :) > > > > While I create the releases I am not solely responsible for milestone dates > > or > > thresholds for a release. > > > > Please test the RC snaphots on our ftp server. Saying you have is as > > important > > as reporting issues. > > > > 1. Are all the things need for the release resolved? Tickets reviewed? > > It would be nice to have the interrupt get/set priority API in RTEMS 6. The > Cortex-M floating point issue is not yet fixed in the RTEMS master. > > There should be time to get it in. The Gitlab transition needs to be complete > before the branch is cut. > > > > > 2. The tickets are now in GitLab and locked down in Trac so how does that > > work > > if we make a release now? I do not think it does. > > > > 3. GitLab is going to happen soon so do we take this moment in time and > > make 6 > > with GitLab and learn what we need to do easing dot releases that always > > follow? > > If we do not we may end up with 6.1 and then 6.2 that has differences. > > We should definitely wait with the release after the Gitlab migration is done > and some basic CI is running. > > I don't think holding a release for CI is needed. We have the same basic > quality and testing we have now. > > Requiring more work and improvements just moves the release bar. > > That said, we do need to get some CI processes in place. Hopefully between > 6.1 and 6.2, we will have at least one or two BSPs required to build. > > > > > 4. GitLab breaks the release scripts for the release notes (ChangeLog). > > Amar and > > I have discussed a few options but we are yet to test and settle on > > anything. As > > is the case with these things easy is often is a series of small things that > > take time to get right. > > > > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they > > updated > > for a separated legacy network stack, net services and waf building? > > Ryan and Ray worked on the autoconf to waf documentation changes a couple of > years ago. > > I have no idea what impact the separated Network stacks have on the > documentation. > > The legacy networking docs are separated now with instructions on how to > build them using waf: > https://docs.rtems.org/branches/master/legacy-networking/index.html > > We might need to mention in the user manual that there is no default > networking stack anymore and the user needs to build the network stack > separately. I do (or did, haven't checked lately) have an issue that if I "./waf install" one of the network stacks, probably "libbsd", that I can't then switch back and forth. I think a header file got installed that broke things. Don't know if that was fixed, I've just been careful to not install either stack so I can switch. Is that a bug? Should I figure out what the problem was and report it? > > > 6. I have a few small patches to push and then an update to the RSB to pick > > those changes up before I can create RC4. > > I recently checked in a fix for powerpc and the AArch64 multilib changes for > Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be updated. > Maybe we should even wait for the GCC 13.3 release. > > I asked about a gcc 13.3 release and we should not wait. They intend to do a > 14 release before returning to 13.3. We should plan to do 6.1 with a GCC 13 > branch hash and probably plan to swap that out with a 13.3 tarball when it's > released. > > We are good at imposing more requirements. :) > > Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RFC] rtems: Add options to kernel output char handler
tion_type, so I used "output" here and not "transmit". > > The function outputs data, the device transmits. If the requirement is to > output > the data it does not cover the transmission and the transmission is the > important part. > >> Also, the character may not get immediately transmitted if FIFOs are involved >> (thus the need for the flush). Maybe my understanding of transmitted is >> wrong, >> but for me transmitting has something to do with signals on a medium. > > I have never heard of a device that has data loaded into a FIFO to transmit > has > a mode that transmits sooner or faster? I would have assumed outputting the > data > to the FIFO would sent it. There is a distinct difference between output and > transmit and I would like to see the transmit aspect be specified and met. > >>> 3. Flush needs to be worded in terms of successfully transmitted by the >>> device >>> to avoid the case of data being written to the device is held in FIFOs >>> awaiting >>> transmission and reset is asserted. Maybe FLUSH is the wrong term because >>> it is >>> so overloaded in what it means? An alternative could be >>> RTEMS_BSP_IO_TRANSMISSION_COMPLETE? And following on you could have >>> RTEMS_BSP_IO_NO_TRANSMISSION? The key point is "transmission" relates to the >>> external data pin of the interface. >> >> The no-output option is used to just flush the device without transmitting a >> new >> character. > > Like what flush does? > >> For the flush, we could add something like this: >> >> Flushing the device should ensure that all characters handed over to the >> device >> for output are visible to external consumers. For example, the device output >> FIFO and transmit shift registers should be empty. > > Lets just say transmitted. The devices we manage are embedded and so we > receive > and transmit data. Lets not introduce new or custom terms. > > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-kernel-init.c tries to re-make existing "/etc"
> On Apr 18, 2024, at 10:55 AM, Joel Sherrill wrote: > > > > On Thu, Apr 18, 2024 at 9:50 AM Peter Dufault wrote: > > > > On Apr 18, 2024, at 10:34 AM, Kinsey Moore wrote: > > > > A patch for EEXIST here should be fine. It would be nice if the caller were > > more resilient. > > > > I also changed "default-network-init.h" to assert rtems_bsd_initialize() > worked. > > sc = rtems_bsd_initialize(); > assert(sc == RTEMS_SUCCESSFUL); > > At least you get a panic message. I'll submit a patch. > > Why does /etc already exist? Is it really an error if it already exists? > > If the startup code untar'ed some initial file system contents before calling > this, then /etc would almost certainly exist. > > Unless I am missing something EEXIST should be acceptable. Other errors are > most likely really fatal. > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdir.html > > --joel > > Peter > - > Peter Dufault > HD Associates, Inc. Software and System Engineering > Oh, and maybe you misunderstood: The "assert()" is in *addition* to allowing EEXIST for the "mkdir()" call. It avoids a weird crash in case "rtems_bsd_initialize()" fails for some other reason. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-kernel-init.c tries to re-make existing "/etc"
> On Apr 18, 2024, at 10:55 AM, Joel Sherrill wrote: > > > > On Thu, Apr 18, 2024 at 9:50 AM Peter Dufault wrote: > > > > On Apr 18, 2024, at 10:34 AM, Kinsey Moore wrote: > > > > A patch for EEXIST here should be fine. It would be nice if the caller were > > more resilient. > > > > I also changed "default-network-init.h" to assert rtems_bsd_initialize() > worked. > > sc = rtems_bsd_initialize(); > assert(sc == RTEMS_SUCCESSFUL); > > At least you get a panic message. I'll submit a patch. > > Why does /etc already exist? Is it really an error if it already exists? > > If the startup code untar'ed some initial file system contents before calling > this, then /etc would almost certainly exist. > > Unless I am missing something EEXIST should be acceptable. Other errors are > most likely really fatal. > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdir.html > > --joel > The function "_libcsupport_pwdgrp_init()" over in RTEMS also creates "/etc" through a "pthread_once()". A call to "getpwnam()", "getpwuid()", "getgrnam()" and family will create it. Apparently that is called first. Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-kernel-init.c tries to re-make existing "/etc"
> On Apr 18, 2024, at 10:34 AM, Kinsey Moore wrote: > > A patch for EEXIST here should be fine. It would be nice if the caller were > more resilient. > I also changed "default-network-init.h" to assert rtems_bsd_initialize() worked. sc = rtems_bsd_initialize(); assert(sc == RTEMS_SUCCESSFUL); At least you get a panic message. I'll submit a patch. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-kernel-init.c tries to re-make existing "/etc"
I just rebased to "6-freebsd-12". This change:
###
commit 62e0ca8283603573d42a0f15da044cd406a2f00a
Author: Kinsey Moore
Date: Tue Jan 23 13:25:45 2024 -0600
rtemsbsd/rtems: Check function return values
###
[dufault@gen6 rtems-libbsd]$ git diff 6514d561587fd1527fe6a26cb43e6b5742c8c779
rtemsbsd/rtems/rtems-kernel-init.c
diff --git a/rtemsbsd/rtems/rtems-kernel-init.c
b/rtemsbsd/rtems/rtems-kernel-init.c
index 90a9c80..8ac2f59 100644
--- a/rtemsbsd/rtems/rtems-kernel-init.c
+++ b/rtemsbsd/rtems/rtems-kernel-init.c
@@ -223,7 +223,9 @@ rtems_bsd_initialize(void)
return RTEMS_UNSATISFIED;
}
- mkdir("/etc", S_IRWXU | S_IRWXG | S_IRWXO);
+ if (mkdir("/etc", S_IRWXU | S_IRWXG | S_IRWXO) != 0) {
+ return RTEMS_UNSATISFIED;
+ }
sc = rtems_timer_initiate_server(rtems_bsd_get_task_priority(name),
rtems_bsd_get_task_stack_size(name), RTEMS_DEFAULT_ATTRIBUTES);
###
causes a crash at startup in "uma_zalloc()" (in at least the "telnetd01" test).
I printed out the error, the directory already exists:
mkdir("/etc",...): File exists
For now I'm just checking for EEXIST and ignoring the error.
Does anyone care to object now and say I should investigate further to fix the
caller before I submit a patch?
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: PowerPC e7400 executable is type powerpc:e500 making debug difficult
> On Mar 30, 2024, at 2:15 PM, Joel Sherrill wrote: > > It also leads to dead/unused code in any deployment whose BSP uses this file > I don't know the full definition of code coverage. I suppose code that can never be exercised on a given platform is "dead code"? Even if the code as a ".o" is tested on other targets? We can now start discussing which code is basically better written or more well-tested. In most cases the general code written by someone familiar with multiple architectures will be better written. IMHO. > > Feel free to submit a patch > Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PowerPC e7400 executable is type powerpc:e500 making debug difficult
It's the source code lines that I quoted that cause the problem. To avoid getting the object defined as an e500 then that file needs to be conditionally compiled (I think that's the way it is, there should be another way, having a binary that adapts to its target isn't *that* evil.). Including those e500 instructions "taints" the object. That's the only object I could find that wasn't e7400. I guess there is a rule for the ABI to promote objects up to whatever architecture includes all the instructions that are present. And that survives through the linker stage. So that particular object file winds up needing the "Signal Processing Extensions", as do any executables that it is linked into. It makes sense, it also makes sense to have a way to avoid it. > On Mar 29, 2024, at 2:05 PM, Joel Sherrill wrote: > > Hi > > Chris and I discussed this for a few minutes last night and wondered if > code like this which includes arbitrary CPU model specific code could > be the culprit? > > https://git.rtems.org/rtems/tree/bsps/powerpc/shared/exceptions/ppc_exc_initialize.c#n65 > > There may be other sections that do this. > > If this were wrapped in a conditional for the proper CPU core variants, it > might resolve the issue. One would hope that if there were no e500 code, > binutils and gdb wouldn't get confused. > > --joel > > On Wed, Mar 27, 2024 at 12:19 PM Peter Dufault wrote: > The PowerPC e7400 executables I built for the PowerPC-Beatnik BSP have an > architecture of "powerpc:e500". I assume it is like this for any powerpc > target that includes "ppc_exc_initialize.c". This causes "GDB" to use the > wrong size register set in remote debugging, and I couldn't figure out how to > convince "gdb" to do something different. I tried multiple settings but the > "bfd_arch_info" wouldn't change from "powerpc:e500" (seen with "maint print > architecture") and "gdb" continued to use the wrong register set size. > > (gdb) set powerpc vector-abi altivec > (gdb) set arch powerpc:7400 > The target architecture is set to "powerpc:7400". > (gdb) set gnutarget powerpc:7400 > (gdb) target remote 192.168.240.3:2159 > Remote debugging using 192.168.240.3:2159 > Remote 'g' packet reply is too long (expected 292 bytes, got 412 bytes): > 003a5914007a0ae0007a7b60006577e00052af140052af1c007a0ac80a010014003764ec2062885000645760007a0ae00037265c0202b03240376508003764ecfff8 > (gdb) maint print architecture > gdbarch_dump: GDB_NM_FILE = > gdbarch_dump: bfd_arch_info = powerpc:e500 > gdbarch_dump: byte_order = 0 > gdbarch_dump: byte_order_for_code = 0 > (...) > > This is because "ppc_exc_initialize.o" has a ".PPC.EMB.apuinfo" section that > says it needs the "E500 SPE APU". Here's what is in that section. > > 0 | 0008 | 8 bytes in "APUinfo\0" > 4 | 0008 | 8 bytes (2 words) of APU information. > 8 | 0002 | Section type is rev 2. > 12 | "APUinfo\0" > 16 | 0101 | APU 0x100 "e500 SPE APU" revision 1 > 20 | 00410001 | APU 0x041 "Motorola Book E Performance Monitor APU" revision > 1. > > The resultant linked output is the superset of all requirements, so the > linked output is also "powerpc:e500". > > This is because "ppc_exc_initialize.c" includes instructions for different > targets that it avoids at run time. > > These code lines cause the ".o" to be "powerpc:e500": > > ppc_mtivor(32, ppc_exc_vector_address(ASM_E500_SPE_UNAVAILABLE_VECTOR, > vector_base)); > ppc_mtivor(33, ppc_exc_vector_address(ASM_E500_EMB_FP_DATA_VECTOR, > vector_base)); > ppc_mtivor(34, ppc_exc_vector_address(ASM_E500_EMB_FP_ROUND_VECTOR, > vector_base)); > > This line causes the ".o" to be "powerpc:titan" (if the above E500 lines are > removed): > > ppc_mtivor(35, ppc_exc_vector_address(ASM_E500_PERFMON_VECTOR, vector
PowerPC e7400 executable is type powerpc:e500 making debug difficult
The PowerPC e7400 executables I built for the PowerPC-Beatnik BSP have an architecture of "powerpc:e500". I assume it is like this for any powerpc target that includes "ppc_exc_initialize.c". This causes "GDB" to use the wrong size register set in remote debugging, and I couldn't figure out how to convince "gdb" to do something different. I tried multiple settings but the "bfd_arch_info" wouldn't change from "powerpc:e500" (seen with "maint print architecture") and "gdb" continued to use the wrong register set size. (gdb) set powerpc vector-abi altivec (gdb) set arch powerpc:7400 The target architecture is set to "powerpc:7400". (gdb) set gnutarget powerpc:7400 (gdb) target remote 192.168.240.3:2159 Remote debugging using 192.168.240.3:2159 Remote 'g' packet reply is too long (expected 292 bytes, got 412 bytes): 003a5914007a0ae0007a7b60006577e00052af140052af1c007a0ac80a010014003764ec2062885000645760007a0ae00037265c0202b03240376508003764ecfff8 (gdb) maint print architecture gdbarch_dump: GDB_NM_FILE = gdbarch_dump: bfd_arch_info = powerpc:e500 gdbarch_dump: byte_order = 0 gdbarch_dump: byte_order_for_code = 0 (...) This is because "ppc_exc_initialize.o" has a ".PPC.EMB.apuinfo" section that says it needs the "E500 SPE APU". Here's what is in that section. 0 | 0008 | 8 bytes in "APUinfo\0" 4 | 0008 | 8 bytes (2 words) of APU information. 8 | 0002 | Section type is rev 2. 12 | "APUinfo\0" 16 | 0101 | APU 0x100 "e500 SPE APU" revision 1 20 | 00410001 | APU 0x041 "Motorola Book E Performance Monitor APU" revision 1. The resultant linked output is the superset of all requirements, so the linked output is also "powerpc:e500". This is because "ppc_exc_initialize.c" includes instructions for different targets that it avoids at run time. These code lines cause the ".o" to be "powerpc:e500": ppc_mtivor(32, ppc_exc_vector_address(ASM_E500_SPE_UNAVAILABLE_VECTOR, vector_base)); ppc_mtivor(33, ppc_exc_vector_address(ASM_E500_EMB_FP_DATA_VECTOR, vector_base)); ppc_mtivor(34, ppc_exc_vector_address(ASM_E500_EMB_FP_ROUND_VECTOR, vector_base)); This line causes the ".o" to be "powerpc:titan" (if the above E500 lines are removed): ppc_mtivor(35, ppc_exc_vector_address(ASM_E500_PERFMON_VECTOR, vector_base)); I "#ifdef'd" them out to get it to "work" but unless someone can figure out how to get rid of that section in the output "ppc_exc_initialize.c" needs to be changed to be conditionally compiled. If no one has any good ideas I'll open a bug with this. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH libbsd] freebsd/sys/dev/e1000: Fix long timeout
This is for 6-freebsd-12. How is that specified? I don't see [PATCH
libbsd-6-freebsd-12] etc.
> On Feb 1, 2024, at 6:00 AM, dufa...@hda.com wrote:
>
> From: Peter Dufault
>
> - safe_pause_us() and safe_pause_ms() depend on the clock tick. Use DELAY().
> ---
> freebsd/sys/dev/e1000/e1000_osdep.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/freebsd/sys/dev/e1000/e1000_osdep.h
> b/freebsd/sys/dev/e1000/e1000_osdep.h
> index 70db294..15dfc6f 100644
> --- a/freebsd/sys/dev/e1000/e1000_osdep.h
> +++ b/freebsd/sys/dev/e1000/e1000_osdep.h
> @@ -80,6 +80,7 @@ ms_scale(int x) {
> }
> }
>
> +#if !defined(__rtems__)
> static inline void
> safe_pause_us(int x) {
> if (cold) {
> @@ -97,6 +98,17 @@ safe_pause_ms(int x) {
> pause("e1000_delay", ms_scale(x));
> }
> }
> +#else
> +static inline void
> +safe_pause_us(int x) {
> + DELAY(x);
> +}
> +
> +static inline void
> +safe_pause_ms(int x) {
> + DELAY(x*1000);
> +}
> +#endif
>
> #define usec_delay(x) safe_pause_us(x)
> #define usec_delay_irq(x) usec_delay(x)
> --
> 1.8.3.1
>
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH libbsd] freebsd/sys/dev/e1000: Fix long timeout
From: Peter Dufault
- safe_pause_us() and safe_pause_ms() depend on the clock tick. Use DELAY().
---
freebsd/sys/dev/e1000/e1000_osdep.h | 12
1 file changed, 12 insertions(+)
diff --git a/freebsd/sys/dev/e1000/e1000_osdep.h
b/freebsd/sys/dev/e1000/e1000_osdep.h
index 70db294..15dfc6f 100644
--- a/freebsd/sys/dev/e1000/e1000_osdep.h
+++ b/freebsd/sys/dev/e1000/e1000_osdep.h
@@ -80,6 +80,7 @@ ms_scale(int x) {
}
}
+#if !defined(__rtems__)
static inline void
safe_pause_us(int x) {
if (cold) {
@@ -97,6 +98,17 @@ safe_pause_ms(int x) {
pause("e1000_delay", ms_scale(x));
}
}
+#else
+static inline void
+safe_pause_us(int x) {
+ DELAY(x);
+}
+
+static inline void
+safe_pause_ms(int x) {
+ DELAY(x*1000);
+}
+#endif
#define usec_delay(x) safe_pause_us(x)
#define usec_delay_irq(x) usec_delay(x)
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems6 v2] libmisc/shell: Fix timeout getting terminal size
From: Peter Dufault
- Fix detection of timeout in rtems_shell_term_wait_for().
- Use the "termios" VTIME inter-character timeout.
The previous version depends on the BSP clock tick and can be long.
- Add debugging regarding terminal size sequences.
Updates #4763
---
cpukit/libmisc/shell/shell.c | 103 +--
1 file changed, 59 insertions(+), 44 deletions(-)
diff --git a/cpukit/libmisc/shell/shell.c b/cpukit/libmisc/shell/shell.c
index 9cefc80..6a9e11e 100644
--- a/cpukit/libmisc/shell/shell.c
+++ b/cpukit/libmisc/shell/shell.c
@@ -40,14 +40,19 @@
#include
#define SHELL_STD_DEBUG 0
+#define SHELL_WINSIZE_DEBUG 0
-#if SHELL_STD_DEBUG
#include
+#define shell_std_debug_(EN, ...)
\
+ do {
\
+if (EN) { printk("shell[%08x]: ", rtems_task_self()); printk(__VA_ARGS__);
} \
+ } while (0)
+
#define shell_std_debug(...) \
- do { printk("shell[%08x]: ", rtems_task_self()); printk(__VA_ARGS__); }
while (0)
-#else
-#define shell_std_debug(...)
-#endif
+ shell_std_debug_(SHELL_STD_DEBUG, __VA_ARGS__)
+
+#define shell_winsize_debug(...) \
+ shell_std_debug_(SHELL_WINSIZE_DEBUG, __VA_ARGS__)
#define SHELL_MAGIC rtems_build_name('S', 'E', 'N', 'V')
@@ -805,28 +810,35 @@ void rtems_shell_print_env(
}
#endif
+/* Window size detection knob.
+ * VTIME timeout in .1 seconds. No way to set without editing.
+ */
+static const int rtems_shell_winsize_vtime = 1;
+
/*
* Wait for the string to return or timeout.
*/
-static bool rtems_shell_term_wait_for(const int fd, const char* str, const int
timeout)
+static bool rtems_shell_term_wait_for(const int fd, const char* str)
{
- int msec = timeout;
int i = 0;
- while (msec-- > 0 && str[i] != '\0') {
+ while (str[i] != '\0') {
char ch[2];
-if (read(fd, &ch[0], 1) == 1) {
- fflush(stdout);
+ssize_t n;
+if ((n = read(fd, &ch[0], 1)) == 1) {
if (ch[0] != str[i++]) {
+shell_winsize_debug("Wrong char at char %d.\n", i);
return false;
}
- msec = timeout;
} else {
- usleep(1000);
+ shell_winsize_debug(
+"%s reading char %d.\n",
+(n == 0) ? "Timeout" : "Error", i
+ );
+ return false;
}
}
- if (msec == 0) {
-return false;
- }
+
+ shell_winsize_debug("Matched string.\n");
return true;
}
@@ -836,41 +848,43 @@ static bool rtems_shell_term_wait_for(const int fd, const
char* str, const int t
static int rtems_shell_term_buffer_until(const int fd,
char* buf,
const int size,
- const char* end,
- const int timeout)
+ const char* end)
{
- int msec = timeout;
int i = 0;
int e = 0;
memset(&buf[0], 0, size);
- while (msec-- > 0 && i < size && end[e] != '\0') {
+ while (i < size && end[e] != '\0') {
char ch[2];
-if (read(fd, &ch[0], 1) == 1) {
- fflush(stdout);
+ssize_t n;
+if ( (n = read(fd, &ch[0], 1)) == 1) {
buf[i++] = ch[0];
if (ch[0] == end[e]) {
e++;
} else {
+shell_winsize_debug("Reset search for end string.\n");
e = 0;
}
- msec = timeout;
} else {
- usleep(1000);
+ /* There is an error or timeout. */
+ shell_winsize_debug(
+ "%s looking for end string \"%s\". Read \"%s\".\n",
+ (n == 0) ? "Timeout" : "Error",
+ end, buf
+ );
+ return -1;
}
}
- if (msec == 0 || end[e] != '\0') {
-return -1;
- }
- i -= e;
+ i -= e; /* Toss away the matched end. */
if (i < size) {
buf[i] = '\0';
}
+ shell_winsize_debug("Found end string \"%s\".\n", end);
return i;
}
/*
- * Determine if the terminal has the row and column values
- * swapped
+ * Determine if this is a version of the "tmux" terminal emulator with
+ * the row and column values swapped
*
* https://github.com/tmux/tmux/issues/3457
*
@@ -878,19 +892,19 @@ static int rtems_shell_term_buffer_until(const int fd,
* in the time it takes to get the fix into code so see if tmux is
* running and which version and work around the bug.
*
- * The terminal device needs to have VMIN=0, and VTIME=0
+ * The terminal device needs to have VMIN=0, and VTIME set to the
+ * desired timeout in .1 seconds.
*/
-static bool rtems_shell_term_row_column_swapped(const int fd, const int
timeout) {
+static bool rtems_shell_term_row_c
Re: [PATCH rtems6 1/1] libmisc/shell: Fix timeout in getting terminal size
> On Jan 23, 2024, at 7:09 PM, Chris Johns wrote:
>
> On 23/1/2024 9:00 pm, Peter Dufault wrote:
>>> On Jan 22, 2024, at 1:51 PM, Peter Dufault wrote:
>>>> On Jan 22, 2024, at 12:16 PM, Gedare Bloom wrote:
>>>>
>>>> I have a couple minor notes below. More important, does this change
>>>> require updating documentation?
>>>
>>> I'd have to look to see if this window size detection is documented, I
>>> wanted to fix the problem it caused me.
>>>
>>>>
>>>> I know we have a somewhat aging shell-specific guide:
>>>> https://docs.rtems.org/branches/master/shell/index.html
>>>>
>
> The original change is by me so I can take a look at this. Thanks for
> mentioning
> this. :)
>
>>>>
>>>> On Fri, Jan 19, 2024 at 5:19 AM wrote:
>>>>>
>>>>> From: Peter Dufault
>>>>>
>>>>> - Fix detection of timeout in rtems_shell_term_wait_for().
>>>>>
>>>>> - Switch to using "termios" VTIME inter-character timeout.
>>>>> The previous implementation is dependent on the BSP clock tick value.
>>>>>
>>>>> Updates #4763
>>>>> ---
>>>>> cpukit/libmisc/shell/shell.c | 101
>>>>> ++-
>>>>> 1 file changed, 62 insertions(+), 39 deletions(-)
>>>>>
>>>>> diff --git a/cpukit/libmisc/shell/shell.c b/cpukit/libmisc/shell/shell.c
>>>>> index 9cefc80..60cdb4f 100644
>>>>> --- a/cpukit/libmisc/shell/shell.c
>>>>> +++ b/cpukit/libmisc/shell/shell.c
>>>>> @@ -805,28 +805,52 @@ void rtems_shell_print_env(
>>>>> }
>>>>> #endif
>>>>>
>>>>> +/* Debugging output for the terminal I/O associated with window size
>>>>> detection
>>>>> + * can be sent with rtems_shell_winsize_db().
>>>>> + */
>>>>> +
>>>>> +/* Window size detection knobs.
>>>>> + */
>>>>> +static bool rtems_shell_winsize_dbf;/* Debug. "true" to debug.
>>>>> */
>>>> Is this necessary? How does the application set/test this?
>>>
>>> I don't know. Same with the "vtime" setting, no way to change that either.
>>> Rationale:
>>>
>>> - It puts what you may want to change in one place.
>>> - I'm not a fan of "#define".
>>> - I didn't want to add a public interface to tweak things (then I *would*
>>> need to document).
>>> - It was useful. I left it in to make it clear how to compile-time turn it
>>> on if you need it.
>>>
>>> I can make the "dbf" behavior pre-processor enabled at compile-time. Or
>>> take it out.
>>
>> I'm embarrassed to say I didn't see that SHELL_WINSIZE_DEBUG is already in
>> the code. I will switch to use that.
>> I don't like losing the format checking when a flag is undefined. I can
>> avoid that by unconditionally adding . There is already
>> SHELL_DEBUG conditional code using "printk()" without including
>> .
>
> Thanks for look into this and cleaning up the cruft. It couuld be BPS specific
> and why it the include is an issue for some and not others.
>
>>
>> #define SHELL_STD_DEBUG 1 /* Or 0. */
>> #define SHELL_WINSIZE_DEBUG 1 /* Or 0. */
>>
>> #if SHELL_STD_DEBUG | SHELL_WINSIZE_DEBUG
>> #include
>> #define shell_std_debug_(...) \
>> do { printk("shell[%08x]: ", rtems_task_self()); printk(__VA_ARGS__); }
>> while (0)
>> #endif
>>
>> #if SHELL_STD_DEBUG
>> #define shell_std_debug(...) do { shell_std_debug_(__VA_ARGS__); } while (0)
>> #else
>> #define shell_std_debug(...)
>> #endif
>>
>> #if SHELL_WINSIZE_DEBUG
>> #define shell_winsize_debug(...) do { shell_std_debug_(__VA_ARGS__); } while
>> (0)
>> #else
>> #define shell_winsize_debug(...)
>> #endif
>
> Compiling out the debug code is a good approach if not enabled.
>
>>
>> - OR: Polluted (with rtems/bspIo.h) implementation:
>>
>> #define SHELL_STD_DEBUG 1 /* Or 0. */
>> #define SHELL_WINSIZE_DEBUG 1 /* Or 0. */
>>
>> #include
>> #define shell_std_debug_(ENABLE, ...) \
>> do { if (ENABLE) printk("shell[%08x]: ", rtems_task_self());
>> printk(__VA_ARGS__);
Re: [PATCH rtems6 1/1] libmisc/shell: Fix timeout in getting terminal size
> On Jan 22, 2024, at 1:51 PM, Peter Dufault wrote:
>
>
>
>> On Jan 22, 2024, at 12:16 PM, Gedare Bloom wrote:
>>
>> I have a couple minor notes below. More important, does this change
>> require updating documentation?
>
> I'd have to look to see if this window size detection is documented, I wanted
> to fix the problem it caused me.
>
>>
>> I know we have a somewhat aging shell-specific guide:
>> https://docs.rtems.org/branches/master/shell/index.html
>>
>>
>> On Fri, Jan 19, 2024 at 5:19 AM wrote:
>>>
>>> From: Peter Dufault
>>>
>>> - Fix detection of timeout in rtems_shell_term_wait_for().
>>>
>>> - Switch to using "termios" VTIME inter-character timeout.
>>> The previous implementation is dependent on the BSP clock tick value.
>>>
>>> Updates #4763
>>> ---
>>> cpukit/libmisc/shell/shell.c | 101
>>> ++-
>>> 1 file changed, 62 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/cpukit/libmisc/shell/shell.c b/cpukit/libmisc/shell/shell.c
>>> index 9cefc80..60cdb4f 100644
>>> --- a/cpukit/libmisc/shell/shell.c
>>> +++ b/cpukit/libmisc/shell/shell.c
>>> @@ -805,28 +805,52 @@ void rtems_shell_print_env(
>>> }
>>> #endif
>>>
>>> +/* Debugging output for the terminal I/O associated with window size
>>> detection
>>> + * can be sent with rtems_shell_winsize_db().
>>> + */
>>> +
>>> +/* Window size detection knobs.
>>> + */
>>> +static bool rtems_shell_winsize_dbf;/* Debug. "true" to debug. */
>> Is this necessary? How does the application set/test this?
>
> I don't know. Same with the "vtime" setting, no way to change that either.
> Rationale:
>
> - It puts what you may want to change in one place.
> - I'm not a fan of "#define".
> - I didn't want to add a public interface to tweak things (then I *would*
> need to document).
> - It was useful. I left it in to make it clear how to compile-time turn it on
> if you need it.
>
> I can make the "dbf" behavior pre-processor enabled at compile-time. Or take
> it out.
I'm embarrassed to say I didn't see that SHELL_WINSIZE_DEBUG is already in the
code. I will switch to use that.
I don't like losing the format checking when a flag is undefined. I can avoid
that by unconditionally adding . There is already SHELL_DEBUG
conditional code using "printk()" without including .
#define SHELL_STD_DEBUG 1 /* Or 0. */
#define SHELL_WINSIZE_DEBUG 1 /* Or 0. */
#if SHELL_STD_DEBUG | SHELL_WINSIZE_DEBUG
#include
#define shell_std_debug_(...) \
do { printk("shell[%08x]: ", rtems_task_self()); printk(__VA_ARGS__); } while
(0)
#endif
#if SHELL_STD_DEBUG
#define shell_std_debug(...) do { shell_std_debug_(__VA_ARGS__); } while (0)
#else
#define shell_std_debug(...)
#endif
#if SHELL_WINSIZE_DEBUG
#define shell_winsize_debug(...) do { shell_std_debug_(__VA_ARGS__); } while (0)
#else
#define shell_winsize_debug(...)
#endif
- OR: Polluted (with rtems/bspIo.h) implementation:
#define SHELL_STD_DEBUG 1 /* Or 0. */
#define SHELL_WINSIZE_DEBUG 1 /* Or 0. */
#include
#define shell_std_debug_(ENABLE, ...) \
do { if (ENABLE) printk("shell[%08x]: ", rtems_task_self());
printk(__VA_ARGS__); } while (0)
#define shell_std_debug(...) shell_std_debug_(SHELL_STD_DEBUG, __VA_ARGS__)
#define shell_winsize_debug(...) shell_std_debug_(SHELL_WINSIZE_DEBUG,
__VA_ARGS__)
>
> I would leave the "vtime" static, there was no way to change the previous
> timeout either.
>
>>
>>> +static int rtems_shell_winsize_vtime = 1; /* VTIME timeout in .1 seconds
>>> */
>>> +
>>> +static void rtems_shell_winsize_vdb(const char *format, va_list ap) {
>>> + if (rtems_shell_winsize_dbf == false)
>>> +return;
>>> + printf("shell_winsize: ");
>>> + vprintf(format, ap);
>>> + fflush(stdout);
>>> +}
>>> +
>>> +static void rtems_shell_winsize_db(const char *format, ...) {
>>> + va_list ap;
>>> + va_start(ap, format);
>>> + rtems_shell_winsize_vdb(format, ap);
>>> + va_end(ap);
>>> +}
>>> +
>>> /*
>>> * Wait for the string to return or timeout.
>>> */
>>> -static bool rtems_shell_term_wait_for(const int fd, const char* str, const
>>> int timeout)
>>> +static bool rtems_shell_term_wait_for(const int fd, const char* str)
>>> {
>>
Re: [PATCH rtems6 1/1] libmisc/shell: Fix timeout in getting terminal size
> On Jan 22, 2024, at 12:16 PM, Gedare Bloom wrote:
>
> I have a couple minor notes below. More important, does this change
> require updating documentation?
I'd have to look to see if this window size detection is documented, I wanted
to fix the problem it caused me.
>
> I know we have a somewhat aging shell-specific guide:
> https://docs.rtems.org/branches/master/shell/index.html
>
>
> On Fri, Jan 19, 2024 at 5:19 AM wrote:
>>
>> From: Peter Dufault
>>
>> - Fix detection of timeout in rtems_shell_term_wait_for().
>>
>> - Switch to using "termios" VTIME inter-character timeout.
>> The previous implementation is dependent on the BSP clock tick value.
>>
>> Updates #4763
>> ---
>> cpukit/libmisc/shell/shell.c | 101
>> ++-
>> 1 file changed, 62 insertions(+), 39 deletions(-)
>>
>> diff --git a/cpukit/libmisc/shell/shell.c b/cpukit/libmisc/shell/shell.c
>> index 9cefc80..60cdb4f 100644
>> --- a/cpukit/libmisc/shell/shell.c
>> +++ b/cpukit/libmisc/shell/shell.c
>> @@ -805,28 +805,52 @@ void rtems_shell_print_env(
>> }
>> #endif
>>
>> +/* Debugging output for the terminal I/O associated with window size
>> detection
>> + * can be sent with rtems_shell_winsize_db().
>> + */
>> +
>> +/* Window size detection knobs.
>> + */
>> +static bool rtems_shell_winsize_dbf;/* Debug. "true" to debug. */
> Is this necessary? How does the application set/test this?
I don't know. Same with the "vtime" setting, no way to change that either.
Rationale:
- It puts what you may want to change in one place.
- I'm not a fan of "#define".
- I didn't want to add a public interface to tweak things (then I *would* need
to document).
- It was useful. I left it in to make it clear how to compile-time turn it on
if you need it.
I can make the "dbf" behavior pre-processor enabled at compile-time. Or take
it out.
I would leave the "vtime" static, there was no way to change the previous
timeout either.
>
>> +static int rtems_shell_winsize_vtime = 1; /* VTIME timeout in .1 seconds */
>> +
>> +static void rtems_shell_winsize_vdb(const char *format, va_list ap) {
>> + if (rtems_shell_winsize_dbf == false)
>> +return;
>> + printf("shell_winsize: ");
>> + vprintf(format, ap);
>> + fflush(stdout);
>> +}
>> +
>> +static void rtems_shell_winsize_db(const char *format, ...) {
>> + va_list ap;
>> + va_start(ap, format);
>> + rtems_shell_winsize_vdb(format, ap);
>> + va_end(ap);
>> +}
>> +
>> /*
>> * Wait for the string to return or timeout.
>> */
>> -static bool rtems_shell_term_wait_for(const int fd, const char* str, const
>> int timeout)
>> +static bool rtems_shell_term_wait_for(const int fd, const char* str)
>> {
>> - int msec = timeout;
>> int i = 0;
>> - while (msec-- > 0 && str[i] != '\0') {
>> + while (str[i] != '\0') {
>> char ch[2];
>> -if (read(fd, &ch[0], 1) == 1) {
>> - fflush(stdout);
>> +ssize_t n;
>> +if ((n = read(fd, &ch[0], 1)) == 1) {
>> if (ch[0] != str[i++]) {
>> +rtems_shell_winsize_db("Wrong char at char %d.\n", i);
>> return false;
>> }
>> - msec = timeout;
>> } else {
>> - usleep(1000);
>> + rtems_shell_winsize_db("%s reading char %d.\n",
>> + (n == 0) ? "Timeout" : "Error", i);
> I'd suggest putting the 'i' on it's own line here. I don't know that
> there's a specific style guide for this file, but having trailing
> statements after the ternary is a bit harder to read. imo
Sure.
>
>> + return false;
>> }
>> }
>> - if (msec == 0) {
>> -return false;
>> - }
>> +
>> + rtems_shell_winsize_db("Matched string.\n");
>> return true;
>> }
>>
>> @@ -836,41 +860,42 @@ static bool rtems_shell_term_wait_for(const int fd,
>> const char* str, const int t
>> static int rtems_shell_term_buffer_until(const int fd,
>> char* buf,
>> const int size,
>> - const char* end,
>> - const int timeout)
>> + const char* end)
>> {
>> -
[PATCH rtems6 1/1] libmisc/shell: Fix timeout in getting terminal size
From: Peter Dufault
- Fix detection of timeout in rtems_shell_term_wait_for().
- Switch to using "termios" VTIME inter-character timeout.
The previous implementation is dependent on the BSP clock tick value.
Updates #4763
---
cpukit/libmisc/shell/shell.c | 101 ++-
1 file changed, 62 insertions(+), 39 deletions(-)
diff --git a/cpukit/libmisc/shell/shell.c b/cpukit/libmisc/shell/shell.c
index 9cefc80..60cdb4f 100644
--- a/cpukit/libmisc/shell/shell.c
+++ b/cpukit/libmisc/shell/shell.c
@@ -805,28 +805,52 @@ void rtems_shell_print_env(
}
#endif
+/* Debugging output for the terminal I/O associated with window size detection
+ * can be sent with rtems_shell_winsize_db().
+ */
+
+/* Window size detection knobs.
+ */
+static bool rtems_shell_winsize_dbf;/* Debug. "true" to debug. */
+static int rtems_shell_winsize_vtime = 1; /* VTIME timeout in .1 seconds */
+
+static void rtems_shell_winsize_vdb(const char *format, va_list ap) {
+ if (rtems_shell_winsize_dbf == false)
+return;
+ printf("shell_winsize: ");
+ vprintf(format, ap);
+ fflush(stdout);
+}
+
+static void rtems_shell_winsize_db(const char *format, ...) {
+ va_list ap;
+ va_start(ap, format);
+ rtems_shell_winsize_vdb(format, ap);
+ va_end(ap);
+}
+
/*
* Wait for the string to return or timeout.
*/
-static bool rtems_shell_term_wait_for(const int fd, const char* str, const int
timeout)
+static bool rtems_shell_term_wait_for(const int fd, const char* str)
{
- int msec = timeout;
int i = 0;
- while (msec-- > 0 && str[i] != '\0') {
+ while (str[i] != '\0') {
char ch[2];
-if (read(fd, &ch[0], 1) == 1) {
- fflush(stdout);
+ssize_t n;
+if ((n = read(fd, &ch[0], 1)) == 1) {
if (ch[0] != str[i++]) {
+rtems_shell_winsize_db("Wrong char at char %d.\n", i);
return false;
}
- msec = timeout;
} else {
- usleep(1000);
+ rtems_shell_winsize_db("%s reading char %d.\n",
+ (n == 0) ? "Timeout" : "Error", i);
+ return false;
}
}
- if (msec == 0) {
-return false;
- }
+
+ rtems_shell_winsize_db("Matched string.\n");
return true;
}
@@ -836,41 +860,42 @@ static bool rtems_shell_term_wait_for(const int fd, const
char* str, const int t
static int rtems_shell_term_buffer_until(const int fd,
char* buf,
const int size,
- const char* end,
- const int timeout)
+ const char* end)
{
- int msec = timeout;
int i = 0;
int e = 0;
memset(&buf[0], 0, size);
- while (msec-- > 0 && i < size && end[e] != '\0') {
+ while (i < size && end[e] != '\0') {
char ch[2];
-if (read(fd, &ch[0], 1) == 1) {
- fflush(stdout);
+ssize_t n;
+if ( (n = read(fd, &ch[0], 1)) == 1) {
buf[i++] = ch[0];
if (ch[0] == end[e]) {
e++;
} else {
+rtems_shell_winsize_db("Reset search for end string.\n");
e = 0;
}
- msec = timeout;
} else {
- usleep(1000);
+ /* Error or timeout. */
+ rtems_shell_winsize_db(
+ "%s looking for end string \"%s\". Read \"%s\".\n",
+ (n == 0) ? "Timeout" : "Error", end, buf
+);
+ return -1;
}
}
- if (msec == 0 || end[e] != '\0') {
-return -1;
- }
- i -= e;
+ i -= e; /* Toss away the matched end. */
if (i < size) {
buf[i] = '\0';
}
+ rtems_shell_winsize_db("Found end string \"%s\".\n", end);
return i;
}
/*
- * Determine if the terminal has the row and column values
- * swapped
+ * Determine if this is a version of the "tmux" terminal emulator with
+ * the row and column values swapped
*
* https://github.com/tmux/tmux/issues/3457
*
@@ -878,19 +903,19 @@ static int rtems_shell_term_buffer_until(const int fd,
* in the time it takes to get the fix into code so see if tmux is
* running and which version and work around the bug.
*
- * The terminal device needs to have VMIN=0, and VTIME=0
+ * The terminal device needs to have VMIN=0, and VTIME set to the
+ * desired timeout in .1 seconds.
*/
-static bool rtems_shell_term_row_column_swapped(const int fd, const int
timeout) {
+static bool rtems_shell_term_row_column_swapped(const int fd, const int fout) {
char buf[64];
memset(&buf[0], 0, sizeof(buf));
/*
* CSI > Ps q
*Ps = 0 => DCS > | text ST
*/
- fputs("\033[>0q", stdout);
- fflush(stdout);
- if (rtems_shell_term_wait_for(fd, "\033P>|", timeout)) {
-
[PATCH rtems6 0/1] libmisc/shell: Fix timeout in getting terminal
From: Peter Dufault This is my first submission of a patch using format-patch and send-email from my Linux system. Let me know if anything is wrong. Peter Dufault (1): libmisc/shell: Fix timeout in getting terminal size cpukit/libmisc/shell/shell.c | 101 ++- 1 file changed, 62 insertions(+), 39 deletions(-) -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Pause on console in libmisc/shell detecting terminal size (mvme5500, beatnik)
> On Jan 10, 2024, at 7:05 PM, Chris Johns wrote: > >> I changed the code to use VTIME of 1 (1/10 second, or 100 msec) instead of >> 0. That lets TERMIOS do the character arrival timeout instead of using a >> delay in a loop that resets - essentially duplicating VTIME != 0 VMIN == 0. >> Once I did that it times out as I expect in .1 seconds. > > Thanks for investigating this and finding a solution. Are you able to post a > patch? > >> I don't know WHY no characters arrive but I know why it has a long delay. > > The 150msec timeout is needed when accessing remote devices on the other side > of > the world but it should be 1/10 of a second and then the shall moves on. The > process is only done when the command prompt is painted so it should not > normally be noticeable. I can post a patch. Do I need to open a bug first? Only downside is VTIME needs to be multiples of .1 seconds, so it will be .1 or .2. The VTIME and VMIN is a good interface *except* that the VTIME>0 VMIN>0 case initial timeout is infinity. I don't like that, though I suppose an alarm and EINTR would let me do what I wish they had defined. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Pause on console in libmisc/shell detecting terminal size (mvme5500, beatnik)
> On Jan 5, 2024, at 1:36 PM, Peter Dufault wrote:
>
> I "#if 0"d out the call to "rtems_shell_term_row_column_swapped()" that
> checks for a broken "tmux" terminal. That is what sends "\033[>0q" to the
> console. I no longer see "0q" on the console but there is still a long pause
> before the command is executed.
>
> Does it make sense to check the shell's terminal for its size before
> executing every command? It could be checked once, or the check could be
> moved into its own command. Now the shell checks for the terminal size and
> if it is a "tmux" terminal before it calls every command.
>
> The escape sequence does work on gnome-terminal, so I'm not sure what causes
> the delay. I can investigate that, but question if this
> should be done in the shell.
There's a bug detecting the timeout in rtems_shell_term_wait_for(). It does
this:
int msec = 150;
while (msec-- > 0 && str[i] != '\0') {
/* Do stuff. */
if (nothing_arrived()) {
usleep(1000);
}
}
if (msec == 0) {
/* BUG when we broke from the loop due to time out msec is -1, not 0. */
}
so if nothing comes in it treats it like it found a match, and for some reason
nothing is coming in.
The "telnetd01" test I'm running doesn't set CONFIGURE_MICROSECONDS_PER_TICK so
I think the default is 1 us. That means we call usleep(1000) 150 times
when no data arrives. If usleep() delays for one clock tick then that is 150 *
.01 or 1.5 seconds. Since the code times out twice that's three seconds.
Actually it used to timeout in 4.5 seconds before I disabled the call to
rtems_shell_term_row_column_swapped() - that function is called even when the
calls to get the lines and columns fails.
I changed the code to use VTIME of 1 (1/10 second, or 100 msec) instead of 0.
That lets TERMIOS do the character arrival timeout instead of using a delay in
a loop that resets - essentially duplicating VTIME != 0 VMIN == 0. Once I did
that it times out as I expect in .1 seconds.
I don't know WHY no characters arrive but I know why it has a long delay.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Pause on console in libmisc/shell detecting terminal size (mvme5500, beatnik)
> On Jan 4, 2024, at 8:01 PM, Joel Sherrill wrote: > > > Commit 7260887fa989c0141e7265cd851e00b4101410d8 "Work around tmux bug in > row and column" introduced 150ms timeout(usleep(1000) 150 times). I > tested On my board, the exact delay is about 300ms. Timeout (in process > shell command) will be called 3times, so the whole delay is about 1s. > > So maybe 150ms seems a bit long. > > But I found usleep() always sleep 1 more millisecond. usleep(1000) > actual delay is about 2000us, usleep(100) actual delay is about > 1001000us. rtems_task_wake_after() is exact. > > Sounds like some math is arbitrarily adding a tick in the conversion to > ticks. It should just be a matter of following the code in a desk check and > checking the math. Could need a modulo to only add an extra tick when there > is a remainder. > I "#if 0"d out the call to "rtems_shell_term_row_column_swapped()" that checks for a broken "tmux" terminal. That is what sends "\033[>0q" to the console. I no longer see "0q" on the console but there is still a long pause before the command is executed. Does it make sense to check the shell's terminal for its size before executing every command? It could be checked once, or the check could be moved into its own command. Now the shell checks for the terminal size and if it is a "tmux" terminal before it calls every command. The escape sequence does work on gnome-terminal, so I'm not sure what causes the delay. I can investigate that, but question if this should be done in the shell. [dufault@gen6 rtems]$ echo -e "\e[18t" ^[[8;42;111t [dufault@gen6 rtems]$ Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Pause on console in libmisc/shell detecting terminal size (mvme5500, beatnik)
I guess maybe the list went down for a while. I sent this on 12-30, and just
got a bounce message today and no "devel" mail until today.
On master when I type a shell command at the console there is a pause, rough
timing:
- Three second pause after hitting return;
- "0q" shows up on the console;
- Three second pause again, then the command is executed.
This doesn't happen on a telnet session. It is this commit:
commit 8425e679c149096a5d0a97990f6ebdbdd55ca522
Author: Chris Johns
Date: Tue Nov 22 21:05:48 2022 +1100
libmisc/shell: Support terminal size as env variables
Closes #4763
Which has this:
fputs("\033[>0q", stdout);
I backed it out for now. Anyone else seeing this?
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Outdated list of BSPs in rtems-tools/config
> On Sep 14, 2023, at 15:22 , o...@c-mauderer.de wrote: > > At the moment a lot of chips start to provide two different ARM cores. One > bigger (often Cortex-A; sometimes multicore) and one smaller one (most of the > time Cortex-M). I haven't used both CPUs of these dual CPU systems yet. But > in theory they should allow some quite nice division of tasks: The small CPU > can handle the timing intensive application (maybe with some bare metal > code). The second CPU can handle higher level control and communication. It > would be interesting to implement something like that. I have thought about this. It's more hand-coding for the control loops, but it's traditional coding. Not everyone thinks the eTPU/PowerPC architecture is as well-designed as I do - "Way too complicated!" is the feedback I get. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Outdated list of BSPs in rtems-tools/config
It will be difficult to replace how well the PowerPC motor controllers work for motor control when the canned, pre-written eTPU code do what you need. It's a great architecture, the DMA chain is well thought out. There is a Bosch "GTM" Generic Timer IP module that is intended to replace the eTPU. I'll look at that to see how close it comes to providing the clean support for motor control coupled to a general purpose processor that the eTPU / PowerPC has. When I see "IP" in a "chip" description I get nervous - I assume Bosch is selling "IP" and the integration is up to the licensor. That said, ARM works well. > On Sep 14, 2023, at 15:22 , o...@c-mauderer.de wrote: > > Hello Peter, > > Am 13.09.23 um 19:22 schrieb Peter Dufault: >>> On Jul 25, 2023, at 10:14 , Joel Sherrill wrote: >>> >>> Most of those are recent and from a lot of different people. GSoC, Kinsey, >>> you, Vijay or Chris, Karel, etc. But I wonder about that phycore_mpc5554. I >>> think it has been around a LONG time. >>> >> I'm cleaning my in-box, and I missed a reference to te Phycore-MPC5554 BSP >> in July. >> I am the one who added the Phycore-mpc5554 as a minor refinement to the >> Freescale MPC55xx embedded board BSPs developed by "eb". >> It *is* time to retire the Phytec board as that board is no longer available. >> But, I hope we can keep it around for a while as I now need to work on a >> follow-up to that BSP. > > That thread was not about retiring or deprecating BSPs. It was about some > missing BSPs in the rtems-tools/config files. So if it is still necessary, I > don't think the BSP should be removed. > >> One of my clients uses the Phycore-MPC5554. They missed the end-of life >> announcement for that board. They need to quickly update to something very >> compatible, and a BSP based on the PHYTEC MPC5674F will work, the MPC5674F >> has all the functionality they require without software changes. >> I'd like to keep the Phycore-MPC5554 BSP alive and kicking while I develop >> equivalent MPC5674F support. > > OK for me. > >> A related question. I think "eb" has a "gwlcfm" target that uses this NXP >> architecture in one of their products. "eb", are you planning another >> "gwlcfm", or are you done with that, and what platform would you move to? >> I'd like to learn about an architecture that works as well as the old >> Motorola architecture does without custom FPGA programming. > > I think it's possible that a new batch of the gwlcfm hardware will be > manufactured in the next few years. But it's quite unlikely that the software > will get an upgrade. > > The question about a good architecture is quite difficult because it's always > quite application specific. > > For RTEMS work that I do, usually a customer already selected a chip (most of > the time some ARM). Therefore, I can't pick a platform that often. For > eb-projects, we usually use NXP or ST chips. On the NXP it would be i.MX or > now also i.MXRT and for ST it's one of the many STM32 chips. > > Personally I would like to play a bit with Risc-V chips. But I haven't found > any time yet. Additionally, it seems that there are still not that many > manufacturers that produce Risc-V chips. > > >> If I leave the old Motorola PowerPC's architecture targeted at engine >> control, I will miss how the ADC DMA chain works together with the eTPU and >> also schedules the output so cleanly do background motor control, and other >> timing intensive applications, so that the main CPU is free to e.g. run >> RTEMS (and in my case position servo control). > > Difficult. Best bet is some NXP chip because they have quite some peripherals > that are still based on the Motorola chips. But I think you know these chips > already and it seems that they are not a good enough replacement. Otherwise, > you wouldn't ask. > > At the moment a lot of chips start to provide two different ARM cores. One > bigger (often Cortex-A; sometimes multicore) and one smaller one (most of the > time Cortex-M). I haven't used both CPUs of these dual CPU systems yet. But > in theory they should allow some quite nice division of tasks: The small CPU > can handle the timing intensive application (maybe with some bare metal > code). The second CPU can handle higher level control and communication. It > would be interesting to implement something like that. > > Best regards > > Christian > >> Peter >> - >> Peter Dufault >> HD Associates, Inc. Software and System Engineering >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel Peter - Peter Dufault HD Associates, Inc. Software and System Engineering signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Outdated list of BSPs in rtems-tools/config
> On Jul 25, 2023, at 10:14 , Joel Sherrill wrote: > > Most of those are recent and from a lot of different people. GSoC, Kinsey, > you, Vijay or Chris, Karel, etc. But I wonder about that phycore_mpc5554. I > think it has been around a LONG time. > I'm cleaning my in-box, and I missed a reference to te Phycore-MPC5554 BSP in July. I am the one who added the Phycore-mpc5554 as a minor refinement to the Freescale MPC55xx embedded board BSPs developed by "eb". It *is* time to retire the Phytec board as that board is no longer available. But, I hope we can keep it around for a while as I now need to work on a follow-up to that BSP. One of my clients uses the Phycore-MPC5554. They missed the end-of life announcement for that board. They need to quickly update to something very compatible, and a BSP based on the PHYTEC MPC5674F will work, the MPC5674F has all the functionality they require without software changes. I'd like to keep the Phycore-MPC5554 BSP alive and kicking while I develop equivalent MPC5674F support. A related question. I think "eb" has a "gwlcfm" target that uses this NXP architecture in one of their products. "eb", are you planning another "gwlcfm", or are you done with that, and what platform would you move to? I'd like to learn about an architecture that works as well as the old Motorola architecture does without custom FPGA programming. If I leave the old Motorola PowerPC's architecture targeted at engine control, I will miss how the ADC DMA chain works together with the eTPU and also schedules the output so cleanly do background motor control, and other timing intensive applications, so that the main CPU is free to e.g. run RTEMS (and in my case position servo control). Peter - Peter Dufault HD Associates, Inc. Software and System Engineering signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
e: I'm OK with most orders as long as most of the maintainers can >> agree on one. >> -- > > Thanks for taking this on. Instead of a strict priority for the goals, > we might consider a limited set of different priorities that require > judgment to make good trade-offs. In this case, I would suggest the > following as somewhat equivalent goals, and the sets in priority > order: > > 1. Real-time Impacts + Maintainability Loss > 2. Transparency Loss + Modularity Loss + Code/RAM Size Increase > 3. Performance Loss > > I wrote each goal now as a "minimize" objective. I think it is not > possible to establish strict priorities on these objectives. > > Good engineering requires understanding and making good tradeoffs. I > believe that #1 addresses the highest requirements we place on RTEMS > and the libbsd philosophy. > > #2 leaves us with the burden of discussing and debating when tradeoffs > are made. It may be better in some cases to increase code size by > increasing modularity, but in other cases it may be better to reduce > transparency to reduce code size. > > Gedare > I'm presenting my concerns without doing appropriate research. This ties in to other needed RTEMS specifications, in particular, the specification of whsy light-weight IP can support, and if it is possible to have a project to tie "libbsd" drivers into the LWIP infrastructure (*I* don't know if that's possible). Yes, I want my cake, and eat it too. "It would be great" if it is clear what small memory platforms lose when going with "LWIP" vs "libbsd", and how easy to switch between the stacks given a supported driver. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Dies libbsd DHCP provide a private network address?
I've been looking into this but I don't see anywhere where a link-level private address might be assigned. At one of my clients the RTEMS client (client overload!, my client, DHCP client) gets a link-level private address e.g. 169.254.208.184. They insist that "libbsd" must be providing this as a fall-back address. It happens infrequently. Does the libbsd DHCP client have fall back to provide a private address, e.g. "169.254.208.184"? I did some searching in "libbsd" but didn't find it. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Using libbsd dhcpcd options
This stored as "/etc/dhcpcd.conf" might not be completely correct but it works. In the call-back hook you'll get a "new_root_path=" entry with what is set on the DHCP host. Thanks! static const char* dhcpcd_conf_text = \ "debug\n" "clientid\n" "nodhcp6\n" "ipv4only\n" "timeout 0\n" "interface ffec0\n" "option bootfile_name\n" "option root_path\n" "\n"; Peter - Peter Dufault HD Associates, Inc. Software and System Engineering signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Using libbsd dhcpcd options
> On Aug 19, 2021, at 20:02 , Chris Johns wrote:
>
> On 20/8/21 1:45 am, junkes wrote:
>> Hallo Peter,
>> I do not know if this is best practice but I run the following code:
>>
>> static void
>> default_network_dhcpcd(void)
>> {
>> static const char default_cfg[] = "clientid test client\n";
>> rtems_status_code sc;
>> int fd;
>> int rv;
>> ssize_t n;
>> struct stat statbuf;
>>
>> if (ENOENT == stat("/etc/dhcpcd.conf", &statbuf)) {
>> fd = open("/etc/dhcpcd.conf", O_CREAT | O_WRONLY,
>> S_IRWXU | S_IRWXG | S_IRWXO);
>> assert(fd >= 0);
>>
>> n = write(fd, default_cfg, sizeof(default_cfg) - 1);
>> assert(n == (ssize_t) sizeof(default_cfg) - 1);
>>
>> static const char fhi_cfg[] =
>> "nodhcp6\n"
>> "ipv4only\n"
>> "option ntp_servers\n"
>> "option rtems_cmdline\n"
>> "option tftp_server_name\n"
>> "option bootfile_name\n"
>> "define 129 string rtems_cmdline\n"
>> "timeout 0";
>>
>> n = write(fd, fhi_cfg, sizeof(fhi_cfg) - 1);
>> assert(n == (ssize_t) sizeof(fhi_cfg) - 1);
>>
>> rv = close(fd);
>> assert(rv == 0);
>> }
>>
>> sc = rtems_dhcpcd_start(NULL);
>> assert(sc == RTEMS_SUCCESSFUL);
>> }
> Hienz, this is a good solution and using a file best solution.
>
> Chris
I see online that DHCP option 129 has three definitions: "PXE - undefined
(vendor specific)", "Kernel options Variable length string", and "Call Server
IP address".
Above does "option rtems_cmdline" and "define 129 string rtems_cmdline" set
option 129 to correspond to "Kernel options"? There's no "DHO_" define for 129
in dhcp.h so I assume that's why you need the "define 129".
Option 17 is defined in dhcp.h ("#define DHO_ROOT_PATH 17") so I assume I just
add "option root_path". I'll try it later today.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Using libbsd dhcpcd options
I'd like to use the DHCP option 17 (Root Path) to get a mount point for NFS
from the DHCP server.
I'm starting dhcp with "rtems_dhcpcd_start(NULL)" so it's starting with only
the argv array of {"dhcpcd", NULL }.
I *think* I need to start it with a customized rtems_dhcpcd_config that would
maybe include a "--option" argument, and retrieve it in a run hook (I'm using
the run hook already to wait for an IP address to be assigned). The FreeBSD
"--option" documentation is:
-o, --option "option"
Request the DHCP "option" variable for use in
"/usr/local/libexec/dhcpcd-run-hooks".
which would be an argv of {"dhcpcd", "--option", "17", NULL }.
Or is best practice to do something with "rtems-bsd-rc-conf-net.c"?
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
> On Aug 4, 2021, at 18:42 , Chris Johns wrote: > > On 5/8/21 2:22 am, Christian Mauderer wrote: >> On 04/08/2021 18:09, Gedare Bloom wrote: >>> On Wed, Aug 4, 2021 at 9:05 AM Christian MAUDERER >>> wrote: >>>> Am 04.08.21 um 16:55 schrieb Gedare Bloom: >>>>> On Wed, Aug 4, 2021 at 4:18 AM Christian MAUDERER >>>>> wrote: >>>>> My preference would be to leave the legacy doc where it is, >>>> >>>> Just a comment for that point: I know that the doc has been moved around >>>> a bit. But I think we should try to get all similar options onto the >>>> same "level". Otherwise if a user searches for "How to do networking >>>> with RTEMS" and he finds https://docs.rtems.org/ the only manual with >>>> "Networking" is the legacy stack. If it is on the same page (level, >>>> hirarchie, ...) like the headline "libbsd Networking and other cool >>>> stuff" or "lwIP", a user instantly can see that there is more than one >>>> option. >>>> >>> >>> That's a good point, but I want to keep the legacy stack separate from >>> the rest of the documentation to make it simpler to deprecate/obsolete >>> it. I don't see value in moving it, just to kill it in the next >>> release. AFAIK, we will strongly discourage anyone from using it in >>> rtems-6, and I'd like to kill it off moving forward once we feel >>> confident that lwIP is feasible for us to maintain. Your point about >>> marketing is well-taken though. >> >> OK. I didn't expect that we are that far that we already plan to (maybe) >> remove >> it in the next release. In that case I agree: It's not worth the effort to >> move it. >> > > Should something be added to the legacy manual indicating it's status? > Is this realistic? I looked at the list of board support packages output by "./rtems-bsps" in RTEMS-6 and there are many old ones (M68K, old VME boards) that I assume use the legacy stack and aren't likely to be updated to use LWIP or "libbsd" and where the old stack works and has a small memory foot print. I understand not adding new drivers to legacy but deprecating the stack requires deprecation and freezing at a given release of those BSPs. That's OK with me, the use of these must be primarily maintenance. I think all these points need to be explained. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Is rtems/bsd/test/network-config.h supposed to be installed?
> On Jul 6, 2021, at 06:42 , Chris Johns wrote: > >> On 3 Jul 2021, at 5:14 am, Peter Dufault wrote: >> >> I updated my libbsd today and an application is failing to build because it >> can't find the include file "rtems/bsd/test/network-config.h". It was added >> yesterday to "rtemsbsd/include/bsp/nexus-devices.h". "nexus-devices.h" the >> only file outside of the testsuite directory that includes >> "network-config.h", and that network-config.h file is in .gitignore. Or am >> I missing a build step? > > I think including it in a user facing header is a mistake. It is a tool to > handle the tests that are internal to libbsd. > > Chris > That was my impression as well. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
WAF build system: configure to prepend .o to all links?
I want to build the i.MX RT BSP with a custom DTS file. It's easy to build an application using ones own "dts.o" file, but I want to build all the BSP tests with my dts.o. For now I just change the one in the tree but I don't want to do that. I don't want a BSP variant, either, since it's a custom board that shouldn't have changes in the tree. I want to get my "dts.o" in the link commands before the "-lrtemsbsp". I looked through what is in "config.ini" and don't see what I need. I can't over-ride LDFLAGS since that is appended in the command line after the libraries were already added. So I want to add a .o to the sources or a flag that goes in after the "-o" for the program output. Is there a way to do that? I even tried setting LINK_CC but though "waf configure" warned be it was set it didn't use it. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Is rtems/bsd/test/network-config.h supposed to be installed?
I updated my libbsd today and an application is failing to build because it can't find the include file "rtems/bsd/test/network-config.h". It was added yesterday to "rtemsbsd/include/bsp/nexus-devices.h". "nexus-devices.h" the only file outside of the testsuite directory that includes "network-config.h", and that network-config.h file is in .gitignore. Or am I missing a build step? Build failure: -- Waf: Entering directory `XXX/build/arm-rtems6-imxrt1052' [6/9] Compiling demo/init.c In file included from /opt/flatland/opt/rtems-6/arm-rtems6/imxrt1052/lib/include/machine/rtems-bsd-config.h:230, from ../../demo/init.c:695: /opt/flatland/opt/rtems-6/arm-rtems6/imxrt1052/lib/include/bsp/nexus-devices.h:41:10: fatal error: rtems/bsd/test/network-config.h: No such file or directory 41 | #include | ^ compilation terminated. "rtems/bsd/test/network-config.h" was added to "rtemsbsd/include/bsp/nexus-devices.h" Committed yesterday by Joel at 11:30: -- Module:rtems-libbsd Branch:6-freebsd-12 Commit:b0c8153d54f7b14ed305f0da23a3dc2e207a0968 Changeset: http://git.rtems.org/rtems-libbsd/commit/?id=b0c8153d54f7b14ed305f0da23a3dc2e207a0968 Author:Kinsey Moore Date: Wed Jun 30 15:00:58 2021 -0500 rtemsbsd: Use config.inc to control ZynqMP ethernet This alters the selection of the 4 Cadence GEM interfaces on the Zynq Ultrascale+ MPSoC BSP to be provided by config.inc instead of being provided by options in the RTEMS BSP itself since those options appear to be dead code when not used in conjunction with LibBSD. --- rtemsbsd/include/bsp/nexus-devices.h | 9 + testsuite/include/rtems/bsd/test/network-config.h.in | 8 waf_libbsd.py| 4 +++- 3 files changed, 16 insertions(+), 5 deletions(-) diff --git a/rtemsbsd/include/bsp/nexus-devices.h b/rtemsbsd/include/bsp/nexus-devices.h index 5c1bab4..cbb3f48 100644 --- a/rtemsbsd/include/bsp/nexus-devices.h +++ b/rtemsbsd/include/bsp/nexus-devices.h @@ -38,6 +38,7 @@ #include #include +#include #include ... signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Minimum RAM for "libbsd"? Can't run in 8MB on "imxrt".
> On Jun 23, 2021, at 01:17 , Sebastian Huber > wrote: > > > On 21/06/2021 15:31, dufa...@hda.com wrote: >>> On Jun 21, 2021, at 08:52 , Sebastian >>> Huber wrote: >>> >>> What happens when you reduce the memory space for the mbufs to 4MiB? What >>> is the "RTEMS work space"? >> By "RTEMS work space" I mean the space between bsp_section_work_begin and >> bsp_section_work_end, which I assume is handed over to the unified work >> space. I also assume allocated "libbsd" data structures come from there. > > Yes, the space between bsp_section_work_begin and bsp_section_work_end is > used for the heap which is used by libbsd. > >> After reducing the space for the mbufs I still run out of RAM. I've been >> patching rtems_bsd_allocator_domain_page_mbuf_size in the debugger for test. >> I'll put it in at compile time but looking at the code that won't make a >> difference. > > Which memory allocation fails? Is it in the libbsd initialization or > afterwards? I want to close this thread before someone finds it in a search (and to be nice to Sebastian, thanks for your help). The failure was in libbsd initialization but that's irrelevant. To get HyperRAM on "imxrt" functional (at least initially) I need to disable read pre-fetch on the FlexSPI. The HyperRAM worked surprisingly well with pre-fetch on without libbsd, but when I tried to initialize libbsd it would consistently crash at the same place complaining that it was out of work area, so I thought it was out of work area. The memory locations being allocated were valid ones from near the end of the HyperRAM address space, it appears that consistent memory corruption caused consistent excess allocation, I don't what was happening. After turning off FlexSPI prefetch it worked. Without making a heroic effort to reduce the libbsd memory footprint (I don't want to chase those problems now) I have about 4MB of the 8MB RAM left. That puts the RTEMS "libbsd" RAM foot print at about 3.5MB (on the imxrt) with my preliminary configuration. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Minimum RAM for "libbsd"? Can't run in 8MB on "imxrt".
> On Jun 21, 2021, at 08:52 , Sebastian Huber > wrote: > > What happens when you reduce the memory space for the mbufs to 4MiB? What is > the "RTEMS work space"? By "RTEMS work space" I mean the space between bsp_section_work_begin and bsp_section_work_end, which I assume is handed over to the unified work space. I also assume allocated "libbsd" data structures come from there. After reducing the space for the mbufs I still run out of RAM. I've been patching rtems_bsd_allocator_domain_page_mbuf_size in the debugger for test. I'll put it in at compile time but looking at the code that won't make a difference. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Minimum RAM for "libbsd"? Can't run in 8MB on "imxrt".
What's the minimum RAM for "libbsd"? I'm getting concerned since I assumed 8MB would be enough, but there are data structures that default to that size, e.g. rtems_bsd_allocator_domain_page_mbuf_size defaults to RTEMS_BSD_CFGDECL_DOMAIN_PAGE_MBUF_DEFAULT which is 8MB. I committed to run in 8MB RAM and 16MB FLASH on the "imxrt" BSP. I've got 7.8MB of RTEMS work space out of my 8MB of RAM and can't get a network application to start up after trying to reduce the configuration. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible
I'm getting back to this as I have the HyperRAM working so I'm trying to set up
appropriate linker settings.
> On Jun 10, 2021, at 01:43 , Sebastian Huber
> wrote:
>
> The initial stack needs to be in an accessible memory area. Currently it is
> placed in this linker output section:
>
> .rtemsstack (NOLOAD) : ALIGN_WITH_INPUT {
> bsp_section_rtemsstack_begin = .;
> *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.rtemsstack*)))
> bsp_section_rtemsstack_end = .;
> } > REGION_WORK AT > REGION_WORK
> bsp_section_rtemsstack_size = bsp_section_rtemsstack_end -
> bsp_section_rtemsstack_begin;
>
> Maybe we should place the .rtemsstack.interrupt input section into the
> REGION_VECTOR memory region.
On the "imxrt" REGION_VECTOR is in FLASH, at least ".vector' in the app I'm
testing is at 0x6004653c which is in HyperFLASH.
In HyperRAM I see these regions allocated:
REGION_DATA: .rwbarrier
REGION_DATA_LOAD: .data, .rtemsrwset
REGION_BSS: .bss
REGION_WORK: .rtemsstack, .work
REGION_STACK: .stack
So I put REGION_WORK in the OCRAM to get .rtemsstack out of HyperRAM to get
started. My application is now running out of HyperFLASH and HyperRAM though
I'm sure I'll find issues.
- What's in "REGION_WORK"? Does that have anything to do with the RTEMS work
space?
- What's the proper solution? I don't particularly want to redo my HyperRAM
initialization to avoid using stack since I'm calling some NXP functions. I'd
like a small amount of stack available in the context of bsp_start_hook_0() to
set up the external RAM.
- What's going on in the shared ARM _start with bsp_start_hook_0_done and the
branch to bsp_start_hook_0()?
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.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Can't build minimal buildset for libbsd on IMXRT
> On Jun 11, 2021, at 09:36 , wrote: > > I *do* have a previously installed libbsd in my prefix. I don't understand > the workflow properly. > > I figured that if I did "./waf distclean" in rtems-libbsd between switching > build sets the build woiuld bootstrap properly but evidently not. > > Do you need to use multiple prefixes to support multiple build sets? I > wanted to try the minimal one first before installing. > I removed the installed "imxrt1052" BSP and then it worked. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Can't build minimal buildset for libbsd on IMXRT
> On Jun 11, 2021, at 09:22 , Christian Mauderer wrote: > > Yes, right. But if I didn't miss one, they should be all called only if INET6 > is defined (in rtemsbsd/include/rtems/bsd/local/opt_inet6.h). In the minimal > buildset that shouldn't be the case. > > Do you have a previously installed libbsd in your prefix that might mess with > the build? I *do* have a previously installed libbsd in my prefix. I don't understand the workflow properly. I figured that if I did "./waf distclean" in rtems-libbsd between switching build sets the build woiuld bootstrap properly but evidently not. Do you need to use multiple prefixes to support multiple build sets? I wanted to try the minimal one first before installing. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Can't build minimal buildset for libbsd on IMXRT
> On Jun 11, 2021, at 09:20 , Joel Sherrill wrote: > > Any chance you forget to switch to the 6-freebsd-12 branch? No, I checked that. It is the branch with Jennifer's MVME5500 work in it, but that is off 6-freebsd-12. I suppose for completeness I can switch to the standard one. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Can't build minimal buildset for libbsd on IMXRT
> On Jun 11, 2021, at 08:07 , Christian Mauderer wrote: > > Hello Peter, > > On 11/06/2021 13:23, Peter Dufault wrote: >> I tried to build the "minimal" buildset for the IMXRT BSP and I get >> undefined INET6 references - _bsd_inet6_pfil_hook, _bsd_ip6stat, etc. Only >> two executables are created - swi01.exe and timeout01.exe. For "default" >> (almost) everything builds except for a few that won't fit in RAM but I >> don't currently have enough RAM to run anything so I figured my first step >> should be to build "minimal". > > I just tried it with beagle bone black: The minimal buildset builds fine. Can > you tell from the output who is referencing the inet6_pfil_hook and ip6stat? Let's look at inet6_pfil_hook. It's only called in "if_bridge.c" by bridge_pfil, bridge_fragment, bridge_dummynet, bridge_broadcast, bridge_ioctl, bridge_ioctl_add, bridge_forward, and bridge_input. These are all statics. Is there something going on with inlining and "garbage collecting"? Do I have C flags messed up? I'm not sure how this is works as I see that "_bsd_inet6_pfil_hook" is defined in ip6_input.c and the object is in the built libbsd.a. I see there's some -Bstatic and -Bdynamic stuff going on in the link. Start of the link of netshell01. I can send more info if you'd like, I don't want to swamp the list. [1147/1178] Linking build/arm-rtems6-imxrt1052-minimal/netshell01.exe 06:29:59 runner ['/opt/flatland/opt/rtems-6/bin/arm-rtems6-gcc', '-mthumb', '-mcpu=cortex-m7', '-mfpu=fpv5-d16', '-mfloat-abi=hard', '-I/opt/flatland/opt/rtems-6/arm-rtems6/imxrt1052/lib/include', '-MMD', '-B/opt/flatland/opt/rtems-6/arm-rtems6/imxrt1052/lib', '-qrtems', '-Wl,--gc-sections', 'testsuite/netshell01/test_main.c.65.o', 'testsuite/netshell01/shellconfig.c.65.o', '-o/home/dufault/development/rtems/rtems-libbsd/build/arm-rtems6-imxrt1052-minimal/netshell01.exe', '-Wl,-Bstatic', '-L.', '-lbsd', '-Wl,-Bdynamic', '-lbsd', '-lm', '-lz', '-lrtemstest'] /opt/flatland/opt/rtems-6/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/bin/ld: ./libbsd.a(if_bridge.c.17.o): in function `bridge_pfil': /home/dufault/development/rtems/rtems-libbsd/build/arm-rtems6-imxrt1052-minimal/../../freebsd/sys/net/if_bridge.c:3346: undefined reference to `_bsd_inet6_pfil_hook' > >> The configure command is: >> ./waf configure --rtems-tools=bla/rtems-6 --rtems=bla/rtems-6 >> --rtems-bsps=arm/imxrt1052 --buildset=buildset/minimal.ini > > Looks OK. > >> The libbsd is a recent 6-freebsd=12 >> is "minimal" built regularly? Any hints? > > No it is not build regularly. I think the buildset are often forgotten if > someone works on libbsd. For example "everything" doesn't build at the moment. > > Best regards > > Christian > >> 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 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Can't build minimal buildset for libbsd on IMXRT
I tried to build the "minimal" buildset for the IMXRT BSP and I get undefined INET6 references - _bsd_inet6_pfil_hook, _bsd_ip6stat, etc. Only two executables are created - swi01.exe and timeout01.exe. For "default" (almost) everything builds except for a few that won't fit in RAM but I don't currently have enough RAM to run anything so I figured my first step should be to build "minimal". The configure command is: ./waf configure --rtems-tools=bla/rtems-6 --rtems=bla/rtems-6 --rtems-bsps=arm/imxrt1052 --buildset=buildset/minimal.ini The libbsd is a recent 6-freebsd=12 is "minimal" built regularly? Any hints? 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible
Let's get back to the patch itself and the initialization of "FlexSPI"
peripheral.
The FlexSPI is one of the "imxrt" on-chip devices that can have flash attached
to it, and that the on-chip boot ROM knows how to probe, configure, and then
boot from. The "imxrt" chips don't have on-chip flash, only a boot ROM that
knows how to look for boot devices or possible download devices (serial, USB,
CAN etc).
In particular, I'm adding support for HyperRAM as the main memory for my
application. This means that the RAM isn't visible until it is set up.
Back to FlexSPI: you can have up to four banks of FLASH attached to FlexSPI -
Port A, chip selects 1 and 2 and Port B, chip selects 1 and 2. I'll call them
A1, A2, B1, B2. I will have HyperFLASH connected to A1 and HyperRAM connected
to A2.
Memory mapping: the FlexSPI will address chips consecutively and the possible
total flash size, IMXRT_MEMORY_FLASH_SIZE, could be
IMXRT_MEMORY_FLEXSPI_FLASH_A1_SIZE + IMXRT_MEMORY_FLEXSPI_FLASH_A2_SIZE +
IMXRT_MEMORY_FLEXSPI_FLASH_B1_SIZE + IMXRT_MEMORY_FLEXSPI_FLASH_B2_SIZE if
there are four flashes connected to the FlexSPI.
I think only the first "A1" FLASH/RAM will be configured by the on-chip boot
loader, and anything else needs to be setup very early in boot, maybe in
"bsp_start_hook_0()". There are special cases such as when all four flash
devices are the same device, but that's special.
The on-chip boot loader supports ".sflash{A2,B1,B2}Size" members in the
"flexspi_nor_config_t" structure that it interprets, but I don't know if it
uses configuration blocks in other flashes, it seems easier to set things up in
"bsp_start_hook_0()", and the RAM won't have a configuration structure in it.
So:
- IMXRT_MEMORY_FLASH_SIZE should be set as the sum of the up to four flash
regions to support linking into the full set of flashes. Only one will be
mapped at "bsp_start_hook_0()". This isn't too important to me unless we can't
guarantee that the setup is in the boot flash. That gets to the next point.
- Do we need an IMXRT_MEMORY_FLASH_BOOT_SIZE? For FlexSPI this is
IMXRT_MEMORY_FLEXSPI_FLASH_A1_SIZE. This is to ensure:
-- The boot data, flash configuration, and startup code that finishes
initializing the FlexSPI need to go into the region mapped by the boot flash.
-- How early can linker sets be used? Can you have a "bsp_start_hook_0()"
linker set where you can e.g. finish setting up the FlexSPI?
- The "imxrt_boot_data.size" member should be set to
IMXRT_MEMORY_FLASH_BOOT_SIZE, which would be IMXRT_MEMORY_FLEXSPI_FLASH_A1_SIZE
for FlexSPI, maybe.
- "flash-config.c" is specific to the FlexSPI peripheral. You could have a
design that boots using flash on the QSPI. "flash-config.c" should be
"flexspi-flash-config.c".
- The "imxrt_flexspi_config.sflashA1Size" should be initialized to
IMXRT_MEMORY_FLEXSPI_FLASH_A1_SIZE.
Similar comments apply to RAM. I'll be adding HyperRAM attached to FlexSPI
port A chip select 2 and it won't be setup until we get past
"bsp_start_hook_0()". So initial stack needs to be in on-chip RAM and we can't
access anything outside of on-chip RAM until after we finish setting HyperRAM
up in "bsp_start_hook_0()".
The code for the "imxrt" "_start" assigns something to the stack pointer that
isn't mapped yet if we haven't set up HyperRAM. It's not clear to me as
someone not that clear with ARM if that is ever going to be accessed.
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.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems 1/2] cpu/armv7m: Avoid regions with negative size
Looks good to me.
> On Jun 4, 2021, at 03:47 , Christian Mauderer
> wrote:
>
> Don't initialze regions that have a negative size (for example due to a
> wrong calculation).
>
> Update #4450
> ---
> cpukit/score/cpu/arm/include/rtems/score/armv7m.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
> b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
> index 8f926e826a..a5eaaef418 100644
> --- a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
> +++ b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
> @@ -656,7 +656,7 @@ static inline void _ARMV7M_MPU_Set_region(
> RTEMS_OBFUSCATE_VARIABLE(end);
> size = (uintptr_t) end - (uintptr_t) begin;
>
> - if ( size > 0 ) {
> + if ( (uintptr_t) end > (uintptr_t) begin ) {
> rbar = (uintptr_t) begin | region | ARMV7M_MPU_RBAR_VALID;
> rasr |= _ARMV7M_MPU_Get_region_size(size);
> } else {
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
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.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS source builder: can't find RTEMS include files but then can?
> On May 26, 2021, at 21:50 , Joel Sherrill wrote:
>
>
>
> On Wed, May 26, 2021, 7:54 PM Chris Johns wrote:
> On 30/4/21 1:15 am, dufa...@hda.com wrote:
> >
> >
> >> On Apr 30, 2021, at 05:03 , dufa...@hda.com wrote:
> >>
> >> Can I override what to use as "cmake" in RSB to specify "cmake3"?
> >>
> >>> On Apr 30, 2021, at 04:41 , Peter Dufault wrote:
> >>>
> >>> I verified my environment is squeaky-clean with a simple path and no
> >>> environment variables set that affect RTEMS or "make".
> >>
> >
> > I need help figuring out how to setup rtems-source-builder, SOEM, and
> > cmake. I got it to "work" but it's mis-configured. At first it is not
> > finding header files (is it looking at the Linux headers?), then it
> > installs SOEM in the wrong place, etc. I can get the build and install to
> > "work" by re-running commands in a shell script - the second time a command
> > is run it behaves differently.
> >
> > - *Notes*
> > -- This started when I updated SOEM and needed to change to "cmake3".
> > -- After the following convoluted process the testing I've done on the
> > results are OK.
> >
> > - To simplify my path I make it simple except I add a directory with only a
> > "cmake" bash script: "cmake3 $*" in order to pick up cmake3.
>
> Maybe the --macros argument can help. Create a file `xyz.txt` containing ...
>
> __cmake: exe, optional, 'cmake3'
>
> then try running with `--macros=xyz.txt` If the recipe for the build using
> cmake
> uses `%{__cmake}` then this may work. I have not tested any of this. :)
>
> This may be a stupid question but can you build it by hand?
>
> --joel
I haven't built it by hand because the RTEMS SOEM came with source builder
support. Since my build is "working" it's gone to the back burner. However,
someone at my clients was just trying to build it (unsuccessfully) and I'd
forgotten about all the jumping through hoops that I'd done so I should get
back to it soon.
>
>
> Chris
>
> >
> > - The first time I run "sb-set-builder" the SOEM build fails because it
> > can't find . This is just after it compiled a C file that
> > includes . I'm not sure where it is looking for the headers, I'd
> > expect it would fail earlier if it was trying to use Linux headers, it's
> > all the way to the last file.
> >
> > - I then run the do-build script sb-set-builder created and it builds SOEM
> > *but it installs it in the wrong place*.
> > -- The do-build script is in
> > "${GITDIR}/rtems/rtems-source-builder/rtems/build/soem-powerpc-rtems6-1/do-build"
> > -- "do-build" installs SOEM in in
> > "${GITDIR}/rtems-source-builder/rtems/build/tmp/soem-powerpc-rtems6-1-root-dufault/opt/flatland/opt/rtems-6"
> > instead of "/opt/flatland/opt/rtems-6".
> >
> > - I then go to the generated directory
> > "${GITDIR}/rtems/rtems-source-builder/rtems/build/soem-powerpc-rtems6-1/build-xc"
> > and type "make install" The make succeeds, and *it installs SOEM in the
> > correct place* and SOEM is "successfully" built and installed.
> >
> > - The last nit is that when I try to build the SOEM examples I need to
> > export LDFLAGS="-lrtemsdefaultconfig -lm" to get the SOEM examples to
> > configure. *Note* this was an issue before I switched to cmake3, this one
> > is not new.
> >
> >
> > I hope this gives someone enough clues to suggest what must be done to set
> > source builder up correctly. For reference here's the script.
> >
> > #!/bin/sh
> > set -e
> > # Script to get SOEM to build and install "properly". I just need to be
> > insistent.
> >
> > HERE=$(pwd)
> > # Clean up environment rsb-overrides only has a cmake shell script that is
> > "cmake $*".
> > export PATH=${HOME}/bin/rsb-overrides:/usr/bin:/usr/sbin:/bin:/sbin
> > unset LD_IBRARY_PATH
> >
> > export RTEMS_GIT=/home/dufault/development/rtems
> > export RTEMS_VER=6
> > export RTEMS_SB=${RTEMS_GIT}/rtems-source-builder
> > export RTEMS_SB_BUILD=${RTEMS_SB}/rtems/build
> > export RTEMS_TOOLS=/opt/flatland/opt/rtems-${RTEMS_VER}
> > export RTEMS_ARCH=powerpc
> > export RTEMS_BSP=beatnik
> > # "soem-rtems" fetches waf-2.0.4.
> > SOEM_WAF=waf-2.0.4
> >
> >
Re: [PATCH 2/2] score: Simplify thread queue timeout handling
dwait.c
> @@ -60,7 +60,8 @@ int sem_timedwait(
> );
> _Thread_queue_Context_set_enqueue_timeout_realtime_timespec(
> &queue_context,
> - abstime
> + abstime,
> + true
> );
> _Thread_queue_Context_set_ISR_level( &queue_context, level );
> _Thread_queue_Enqueue(
> diff --git a/cpukit/posix/src/sigtimedwait.c b/cpukit/posix/src/sigtimedwait.c
> index 4e2b6c2658..0bdb65fd45 100644
> --- a/cpukit/posix/src/sigtimedwait.c
> +++ b/cpukit/posix/src/sigtimedwait.c
> @@ -76,7 +76,6 @@ int sigtimedwait(
> siginfo_t signal_information;
> siginfo_t*the_info;
> int signo;
> - struct timespec uptime;
> Thread_queue_Context queue_context;
> int error;
>
> @@ -93,13 +92,10 @@ int sigtimedwait(
>*/
>
> if ( timeout != NULL ) {
> -const struct timespec *end;
> -
> -_Timecounter_Nanouptime( &uptime );
> -end = _Watchdog_Future_timespec( &uptime, timeout );
> _Thread_queue_Context_set_enqueue_timeout_monotonic_timespec(
> &queue_context,
> - end
> + timeout,
> + false
> );
> } else {
> _Thread_queue_Context_set_enqueue_do_nothing_extra( &queue_context );
> diff --git a/cpukit/score/src/mutex.c b/cpukit/score/src/mutex.c
> index 88a390f323..f7e35093b2 100644
> --- a/cpukit/score/src/mutex.c
> +++ b/cpukit/score/src/mutex.c
> @@ -206,7 +206,8 @@ int _Mutex_Acquire_timed(
> } else {
> _Thread_queue_Context_set_enqueue_timeout_realtime_timespec(
> &queue_context,
> - abstime
> + abstime,
> + true
> );
> _Mutex_Acquire_slow( mutex, owner, executing, level, &queue_context );
>
> @@ -327,7 +328,8 @@ int _Mutex_recursive_Acquire_timed(
> } else {
> _Thread_queue_Context_set_enqueue_timeout_realtime_timespec(
> &queue_context,
> - abstime
> + abstime,
> + true
> );
> _Mutex_Acquire_slow( &mutex->Mutex, owner, executing, level,
> &queue_context );
>
> diff --git a/cpukit/score/src/threadqtimeout.c
> b/cpukit/score/src/threadqtimeout.c
> index ec8f67c93b..a3aeea43be 100644
> --- a/cpukit/score/src/threadqtimeout.c
> +++ b/cpukit/score/src/threadqtimeout.c
> @@ -10,7 +10,7 @@
> */
>
> /*
> - * Copyright (c) 2016, 2017 embedded brains GmbH
> + * Copyright (c) 2016, 2021 embedded brains GmbH
> *
> * The license and distribution terms for this file may be
> * found in the file LICENSE in this distribution or at
> @@ -55,8 +55,14 @@ static void _Thread_queue_Add_timeout_timespec(
> )
> {
> const struct timespec *abstime;
> + struct timespecbase;
>
> - abstime = queue_context->Timeout.arg;
> + if ( queue_context->timeout_absolute ) {
> +abstime = queue_context->Timeout.arg;
> + } else {
> +base = *now;
> +abstime = _Watchdog_Future_timespec( &base, queue_context->Timeout.arg );
> + }
>
> if ( _Watchdog_Is_valid_timespec( abstime ) ) {
> uint64_t expire;
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
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.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS source builder: can't find RTEMS include files but then can?
> On Apr 30, 2021, at 05:03 , dufa...@hda.com wrote:
>
> Can I override what to use as "cmake" in RSB to specify "cmake3"?
>
>> On Apr 30, 2021, at 04:41 , Peter Dufault wrote:
>>
>> I verified my environment is squeaky-clean with a simple path and no
>> environment variables set that affect RTEMS or "make".
>
I need help figuring out how to setup rtems-source-builder, SOEM, and cmake. I
got it to "work" but it's mis-configured. At first it is not finding header
files (is it looking at the Linux headers?), then it installs SOEM in the wrong
place, etc. I can get the build and install to "work" by re-running commands
in a shell script - the second time a command is run it behaves differently.
- *Notes*
-- This started when I updated SOEM and needed to change to "cmake3".
-- After the following convoluted process the testing I've done on the results
are OK.
- To simplify my path I make it simple except I add a directory with only a
"cmake" bash script: "cmake3 $*" in order to pick up cmake3.
- The first time I run "sb-set-builder" the SOEM build fails because it can't
find . This is just after it compiled a C file that includes
. I'm not sure where it is looking for the headers, I'd expect it
would fail earlier if it was trying to use Linux headers, it's all the way to
the last file.
- I then run the do-build script sb-set-builder created and it builds SOEM *but
it installs it in the wrong place*.
-- The do-build script is in
"${GITDIR}/rtems/rtems-source-builder/rtems/build/soem-powerpc-rtems6-1/do-build"
-- "do-build" installs SOEM in in
"${GITDIR}/rtems-source-builder/rtems/build/tmp/soem-powerpc-rtems6-1-root-dufault/opt/flatland/opt/rtems-6"
instead of "/opt/flatland/opt/rtems-6".
- I then go to the generated directory
"${GITDIR}/rtems/rtems-source-builder/rtems/build/soem-powerpc-rtems6-1/build-xc"
and type "make install" The make succeeds, and *it installs SOEM in the
correct place* and SOEM is "successfully" built and installed.
- The last nit is that when I try to build the SOEM examples I need to export
LDFLAGS="-lrtemsdefaultconfig -lm" to get the SOEM examples to configure.
*Note* this was an issue before I switched to cmake3, this one is not new.
I hope this gives someone enough clues to suggest what must be done to set
source builder up correctly. For reference here's the script.
#!/bin/sh
set -e
# Script to get SOEM to build and install "properly". I just need to be
insistent.
HERE=$(pwd)
# Clean up environment rsb-overrides only has a cmake shell script that is
"cmake $*".
export PATH=${HOME}/bin/rsb-overrides:/usr/bin:/usr/sbin:/bin:/sbin
unset LD_IBRARY_PATH
export RTEMS_GIT=/home/dufault/development/rtems
export RTEMS_VER=6
export RTEMS_SB=${RTEMS_GIT}/rtems-source-builder
export RTEMS_SB_BUILD=${RTEMS_SB}/rtems/build
export RTEMS_TOOLS=/opt/flatland/opt/rtems-${RTEMS_VER}
export RTEMS_ARCH=powerpc
export RTEMS_BSP=beatnik
# "soem-rtems" fetches waf-2.0.4.
SOEM_WAF=waf-2.0.4
SOEM_TIDY_UP="\
${RTEMS_TOOLS}/share/rtems/rsb/soem-${RTEMS_ARCH}-rtems${RTEMS_VER}-1.txt \
${RTEMS_TOOLS}/share/rtems/rsb/soem-${RTEMS_ARCH}-rtems${RTEMS_VER}-1.xml \
${RTEMS_TOOLS}/${RTEMS_ARCH}-rtems${RTEMS_VER}/${RTEMS_BSP}/lib/share/soem \
${RTEMS_TOOLS}/${RTEMS_ARCH}-rtems${RTEMS_VER}/${RTEMS_BSP}/lib/include/soem"
# We have this setup: ${RTEMS_GIT}
#|-- soem-rtems
#|-- rtems
#|-- rtems-source-builder
# First tidy-up so we always start in the same state.
rm -rf ${RTEMS_SB_BUILD} ${SOEM_TIDY_UP}
cd ${RTEMS_GIT}/soem-rtems
if [ ! -e ${SOEM_WAF} ]; then
wget -P . https://waf.io/${SOEM_WAF}
chmod u+x ${SOEM_WAF}
git submodule init
git submodule update
else
./${SOEM_WAF} distclean
fi
cd ${RTEMS_SB}/rtems
RTEMS_SB_DEBUG="--no-clean --jobs=1"
# Now configure to build SOEM.
# This will fail with:
#
${RTEMS_SB_BUILD}soem-${RTEMS_ARCH}-rtems${RTEMS_VER}-1/soem/oshw/rtems/nicdrv.c:37:10:
# fatal error: net/bpf.h: No such file or directory
if ${RTEMS_SB}/source-builder/sb-set-builder \
--log=log_${RTEMS_ARCH}_soem \
--prefix=${RTEMS_TOOLS} \
--with-tools=${RTEMS_TOOLS} \
--host=${RTEMS_ARCH}-rtems${RTEMS_VER} \
--with-rtems-bsp=${RTEMS_BSP} \
${RTEMS_SB_DEBUG} \
net/soem ; \
then
echo 2>&1 "*"
echo 2>&1 "* Success with sb-set-builder for
net/soem? But I expect failure!"
echo 2>&1 "*"
exit 1
else
echo "*"
Re: RTEMS source builder: can't find RTEMS include files but then can?
I lied. I had /usr/local/bin in my path to pick up "cmake3" instead of the system "cmake". I thought I repeated the test with PATH set to just /usr/bin and /usr/sbin, but I hadn't. Can I override what to use as "cmake" in RSB to specify "cmake3"? > On Apr 30, 2021, at 04:41 , Peter Dufault wrote: > > I verified my environment is squeaky-clean with a simple path and no > environment variables set that affect RTEMS or "make". 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS source builder: can't find RTEMS include files but then can?
I updated to the latest "Simple Open EtherCAT Master" (SOEM) git and the build
failed because gcc couldn't find . This is weird because:
- is where it shoud be;
- "gcc" had already compiled a source file that included just before
it failed to find .
To debug I turned off the "-j" (just because, it's irrelevant), saw the build
fail, then cut-and-pasted the "do-build" script to start debugging, and it
built and installed fine!
I verified my environment is squeaky-clean with a simple path and no
environment variables set that affect RTEMS or "make".
Here's what happened. I'm including the patch because I just noticed the one
file that is patched is the one that doesn't compile the first time.
RTEMS Tools Project - Source Builder Error Report
Build: error: building soem-powerpc-rtems6-1
Command Line:
/home/dufault/development/rtems/rtems-source-builder/source-builder/sb-set-builder
--log=log_powerpc_soem --prefix=/opt/flatland/opt/rtems-6
--with-tools=/opt/flatland/opt/rtems-6 --host=powerpc-rtems6
--with-rtems-bsp=beatnik --no-clean --jobs=1 net/soem
Python: 2.7.5 (default, Nov 16 2020, 22:23:17) [GCC 4.8.5 20150623 (Red Hat
4.8.5-44)]
git://git.rtems.org/rtems-source-builder.git/origin/0d8c97323fd4ba024ad35896cee6670c4981543a
Linux gen6 3.10.0-1160.21.1.el7.x86_64 #1 SMP Tue Mar 16 18:28:22 UTC 2021
x86_64
Tail of the build log:
(...)
script: 92: cd ${build_top}
warning: soem.diff: no hash found
making dir:
/home/dufault/development/rtems/rtems-source-builder/source-builder/patches
script: 93: /bin/cat
/home/dufault/development/rtems/rtems-source-builder/source-builder/patches/soem.diff
| /usr/bin/patch -p1
(...)
rtems.cmake
-- Building for RTEMS
-- OS is rtems
-- LIB_DIR: /opt/flatland/opt/rtems-6/powerpc-rtems6/beatnik/lib
-- Configuring done
-- Generating done
-- Build files have been written to:
/home/dufault/development/rtems/rtems-source-builder/rtems/build/soem-powerpc-rtems6-1/build-xc
+ make all
Scanning dependencies of target soem
[ 7%] Building C object CMakeFiles/soem.dir/soem/ethercatbase.c.obj
[ 15%] Building C object CMakeFiles/soem.dir/soem/ethercatcoe.c.obj
[ 23%] Building C object CMakeFiles/soem.dir/soem/ethercatconfig.c.obj
[ 30%] Building C object CMakeFiles/soem.dir/soem/ethercatdc.c.obj
[ 38%] Building C object CMakeFiles/soem.dir/soem/ethercateoe.c.obj
[ 46%] Building C object CMakeFiles/soem.dir/soem/ethercatfoe.c.obj
[ 53%] Building C object CMakeFiles/soem.dir/soem/ethercatmain.c.obj
[ 61%] Building C object CMakeFiles/soem.dir/soem/ethercatprint.c.obj
[ 69%] Building C object CMakeFiles/soem.dir/soem/ethercatsoe.c.obj
[ 76%] Building C object CMakeFiles/soem.dir/osal/rtems/osal.c.obj
[ 84%] Building C object CMakeFiles/soem.dir/oshw/rtems/nicdrv.c.obj
/home/dufault/development/rtems/rtems-source-builder/rtems/build/soem-powerpc-rtems6-1/soem/oshw/rtems/nicdrv.c:37:10:
fatal error: net/bpf.h: No such file or directory
37 | #include
| ^~~
compilation terminated.
make[2]: *** [CMakeFiles/soem.dir/oshw/rtems/nicdrv.c.obj] Error 1
make[1]: *** [CMakeFiles/soem.dir/all] Error 2
make: *** [all] Error 2
shell cmd failed: /bin/sh -ex
/home/dufault/development/rtems/rtems-source-builder/rtems/build/soem-powerpc-rtems6-1/do-build
error: building soem-powerpc-rtems6-1
-
Note that it had already compiled "osal/rtems/osal.c" and that includes
.
I cut-and-pasted the "do-build" line and it worked.
*The one thing I just noticed* is the single file I patch is the file that
fails to compile, that's why I don't apply it a second time in "do-build". It
does apply fine the first time around. Is that a clue?
++
[dufault@gen6 lou_files]$
/home/dufault/development/rtems/rtems-source-builder/rtems/build/soem-powerpc-rtems6-1/do-build
=> soem-powerpc-rtems6-1: BUILD
==> %prep:
patching file soem/oshw/rtems/nicdrv.c
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file soem/oshw/rtems/nicdrv.c.rej
==> clean %{buildroot}:
/home/dufault/development/rtems/rtems-source-builder/rtems/build/tmp/soem-powerpc-rtems6-1-root-dufault
==> %build:
rtems.cmake
rtems.cmake
-- Building for RTEMS
-- OS is rtems
-- LIB_DIR: /opt/flatland/opt/rtems-6/powerpc-rtems6/beatnik/lib
-- Configuring done
-- Generating done
-- Build files have been written to:
/home/dufault/development/rtems/rtems-source-builder/rtems/build/soem-powerpc-rtems6-1/build-xc
[ 7%] Building C object CMakeFiles/soem.dir/soem/ethercatbase.c.obj
[ 15%] Building C object CMakeFiles/soem.dir/soem/ethercatcoe.c.obj
[ 23%] Building C object CMakeFiles/soem.dir/soem/ethercatconfig.c.obj
[ 30%] Building C object CMakeFiles/soem.dir/soem/ethercatdc.c.obj
[ 38%] Building C object CMakeFiles/soem.dir/soem/ethercateoe.c.obj
[ 46%] Buildin
[PATCH v3 0/2] powerpc/shared/console: Console baud rate fixes
From: Peter Dufault With these two changes the "powerpc/shared/console" code supports a configurable baud rate. Peter Dufault (2): powerpc/shared/console: Make console baud rate configurable. powerpc/shared/console: "termios" first open sets console baud to 9600 bsps/powerpc/shared/console/console.c | 4 ++-- bsps/powerpc/shared/console/uart.c | 6 +- c/src/lib/libbsp/powerpc/beatnik/configure.ac | 4 c/src/lib/libbsp/powerpc/haleakala/configure.ac| 4 c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac | 4 c/src/lib/libbsp/powerpc/mvme3100/configure.ac | 4 c/src/lib/libbsp/powerpc/mvme5500/configure.ac | 4 spec/build/bsps/optconsolebaud.yml | 5 + spec/build/bsps/powerpc/beatnik/bspbeatnik.yml | 2 ++ spec/build/bsps/powerpc/haleakala/bsphaleakala.yml | 2 ++ spec/build/bsps/powerpc/motorola_powerpc/obj.yml | 4 +++- spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml | 2 ++ spec/build/bsps/powerpc/mvme5500/bspmvme5500.yml | 2 ++ 13 files changed, 43 insertions(+), 4 deletions(-) -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v3 1/2] powerpc/shared/console: Make console baud rate configurable.
From: Peter Dufault
The "powerpc/shared/console" code has the start-up console value fixed
at 9600 baud. This changes the hard-wired constant "9600" in the code
to the configuration setting "BSP_CONSOLE_BAUD" and adds configuration
support in both the "waf" and the legacy configuration systems.
Note that the VME BSPs beatnik, mvme3100, and mve5100 can be improved
by adding a "mvme" BSP family. This configuration change, as well
as future configuration changes, could then be made in a "grp.yml" file.
---
bsps/powerpc/shared/console/console.c | 4 ++--
bsps/powerpc/shared/console/uart.c | 2 +-
c/src/lib/libbsp/powerpc/beatnik/configure.ac | 4
c/src/lib/libbsp/powerpc/haleakala/configure.ac| 4
c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac | 4
c/src/lib/libbsp/powerpc/mvme3100/configure.ac | 4
c/src/lib/libbsp/powerpc/mvme5500/configure.ac | 4
spec/build/bsps/optconsolebaud.yml | 5 +
spec/build/bsps/powerpc/beatnik/bspbeatnik.yml | 2 ++
spec/build/bsps/powerpc/haleakala/bsphaleakala.yml | 2 ++
spec/build/bsps/powerpc/motorola_powerpc/obj.yml | 4 +++-
spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml | 2 ++
spec/build/bsps/powerpc/mvme5500/bspmvme5500.yml | 2 ++
13 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/bsps/powerpc/shared/console/console.c
b/bsps/powerpc/shared/console/console.c
index f275683..f6c8021 100644
--- a/bsps/powerpc/shared/console/console.c
+++ b/bsps/powerpc/shared/console/console.c
@@ -153,8 +153,8 @@ static int console_first_open(int major, int minor, void
*arg)
/* must not open a minor device we have no ISR for */
assert( minor>=0 && minor < sizeof(ttyS)/sizeof(ttyS[0]) && ttyS[minor].isr
);
- /* 9600-8-N-1 */
- BSP_uart_init(minor, 9600, 0);
+ /* BSP_CONSOLE_BAUD-8-N-1 */
+ BSP_uart_init(minor, BSP_CONSOLE_BAUD, 0);
status = BSP_uart_install_isr(minor, ttyS[minor].isr);
if (!status) {
printk("Error installing serial console interrupt handler for '%s'!\n",
diff --git a/bsps/powerpc/shared/console/uart.c
b/bsps/powerpc/shared/console/uart.c
index 62212b9..41db52f 100644
--- a/bsps/powerpc/shared/console/uart.c
+++ b/bsps/powerpc/shared/console/uart.c
@@ -160,7 +160,7 @@ BSP_uart_init(int uart, int baud, int hwFlow)
if ( (int)BSPBaseBaud <= 0 ) {
/* Use current divisor assuming BSPBaseBaud gives us the current speed
*/
- BSPBaseBaud = BSPBaseBaud ? -BSPBaseBaud : 9600;
+ BSPBaseBaud = BSPBaseBaud ? -BSPBaseBaud : BSP_CONSOLE_BAUD;
BSPBaseBaud *= ((uread(uart, DLM) << 8) | uread(uart, DLL));
}
diff --git a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
index b332aaa..584072d 100644
--- a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
+++ b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
@@ -34,6 +34,10 @@ Note that the policy can still be defined by the application
CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is removed
and a little memory is saved.])
+RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
+RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
+[default console baud])
+
AC_DEFINE(__ppc_generic, 1, [PowerPC model option])
# Explicitly list all Makefiles here
diff --git a/c/src/lib/libbsp/powerpc/haleakala/configure.ac
b/c/src/lib/libbsp/powerpc/haleakala/configure.ac
index cf3a552..627625b 100644
--- a/c/src/lib/libbsp/powerpc/haleakala/configure.ac
+++ b/c/src/lib/libbsp/powerpc/haleakala/configure.ac
@@ -25,6 +25,10 @@ RTEMS_BSPOPTS_HELP([PPC_VECTOR_FILE_BASE],
[This defines the base address of the exception table.
NOTE: Vectors are actually at 0xFFF0 but file starts at offset.])
+RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
+RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
+[default console baud])
+
AC_DEFINE(ppc405, 1, [PowerPC model option])
RTEMS_BSP_CLEANUP_OPTIONS
diff --git a/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
b/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
index 8b79309..56d550c 100644
--- a/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
+++ b/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
@@ -33,6 +33,10 @@ Note that the policy can still be defined by the application
CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is removed
and a little memory is saved.])
+RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
+RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
+[default console baud])
+
RTEMS_BSPOPTS_SET([mvme2100],[mvme2100],[1])
RTEMS_BSPOPTS_SET([mvme2100],[*],[])
RTEMS_BSPOPTS_HELP([mvme2100],
diff --git a/c/src/lib/libbsp/powerpc/mvme3100/configure.ac
b/c/src/lib/libbsp/powerpc/mvme3100/configure.ac
index 8b9a04f..cf35fd1 100644
--- a/c/src/lib/libbsp/powerpc/mvme3100/configure.ac
+++ b/c/src/lib/libbs
[PATCH v3 2/2] powerpc/shared/console: "termios" first open sets console baud to 9600
From: Peter Dufault When the PowerPC shared console baud rate starts at anything other than 9600 the termios code will set it to 9600 at the first open. --- bsps/powerpc/shared/console/uart.c | 4 1 file changed, 4 insertions(+) diff --git a/bsps/powerpc/shared/console/uart.c b/bsps/powerpc/shared/console/uart.c index 41db52f..83c0e87 100644 --- a/bsps/powerpc/shared/console/uart.c +++ b/bsps/powerpc/shared/console/uart.c @@ -536,6 +536,10 @@ BSP_uart_termios_set(int uart, void *p) uart_data[uart].ioMode = ttyp->device.outputUsesInterrupts; + /* Convert from the baud number to the "speed_t" termios setting. */ + ttyp->termios.c_ispeed = ttyp->termios.c_ospeed = +rtems_termios_number_to_baud(uart_data[uart].baud); + return; } -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 0/2] powerpc/shared/console: Console buad rate fixes
I forgot to specify V2. I'll try again, sorry for the noise. > On Apr 27, 2021, at 13:40 , wrote: > > From: Peter Dufault > > With these two changes the "powerpc/shared/console" code supports a > configurable baud rate. > > - Remove hard-wired start-up baud of 9600. > - Fix "termios" first-open that resets baud rate to 9600. > > Peter Dufault (2): > powerpc/shared/console: Make console baud rate configurable. > powerpc/shared/console: "termios" first open sets console baud to 9600 > > bsps/powerpc/shared/console/console.c | 4 ++-- > bsps/powerpc/shared/console/uart.c | 6 +- > c/src/lib/libbsp/powerpc/beatnik/configure.ac | 4 > c/src/lib/libbsp/powerpc/haleakala/configure.ac| 4 > c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac | 4 > c/src/lib/libbsp/powerpc/mvme3100/configure.ac | 4 > c/src/lib/libbsp/powerpc/mvme5500/configure.ac | 4 > spec/build/bsps/optconsolebaud.yml | 5 + > spec/build/bsps/powerpc/beatnik/bspbeatnik.yml | 2 ++ > spec/build/bsps/powerpc/haleakala/bsphaleakala.yml | 2 ++ > spec/build/bsps/powerpc/motorola_powerpc/obj.yml | 4 +++- > spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml | 2 ++ > spec/build/bsps/powerpc/mvme5500/bspmvme5500.yml | 2 ++ > 13 files changed, 43 insertions(+), 4 deletions(-) > > -- > 1.8.3.1 > 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] powerpc/shared/console: "termios" first open sets console baud to 9600
From: Peter Dufault When the PowerPC shared console baud rate starts at anything other than 9600 the termios code will set it to 9600 at the first open. --- bsps/powerpc/shared/console/uart.c | 4 1 file changed, 4 insertions(+) diff --git a/bsps/powerpc/shared/console/uart.c b/bsps/powerpc/shared/console/uart.c index 41db52f..83c0e87 100644 --- a/bsps/powerpc/shared/console/uart.c +++ b/bsps/powerpc/shared/console/uart.c @@ -536,6 +536,10 @@ BSP_uart_termios_set(int uart, void *p) uart_data[uart].ioMode = ttyp->device.outputUsesInterrupts; + /* Convert from the baud number to the "speed_t" termios setting. */ + ttyp->termios.c_ispeed = ttyp->termios.c_ospeed = +rtems_termios_number_to_baud(uart_data[uart].baud); + return; } -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] powerpc/shared/console: Make console baud rate configurable.
From: Peter Dufault
The "powerpc/shared/console" code has the start-up console value fixed
at 9600 baud. This changes the hard-wired constant "9600" in the code
to the configuration setting "BSP_CONSOLE_BAUD" and adds configuration
support in both the "waf" and the legacy configuration systems.
Note that the VME BSPs beatnik, mvme3100, and mve5100 can be improved
by adding a "mvme" BSP family. This configuration change, as well
as future configuration changes, could then be made in a "grp.yml" file.
---
bsps/powerpc/shared/console/console.c | 4 ++--
bsps/powerpc/shared/console/uart.c | 2 +-
c/src/lib/libbsp/powerpc/beatnik/configure.ac | 4
c/src/lib/libbsp/powerpc/haleakala/configure.ac| 4
c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac | 4
c/src/lib/libbsp/powerpc/mvme3100/configure.ac | 4
c/src/lib/libbsp/powerpc/mvme5500/configure.ac | 4
spec/build/bsps/optconsolebaud.yml | 5 +
spec/build/bsps/powerpc/beatnik/bspbeatnik.yml | 2 ++
spec/build/bsps/powerpc/haleakala/bsphaleakala.yml | 2 ++
spec/build/bsps/powerpc/motorola_powerpc/obj.yml | 4 +++-
spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml | 2 ++
spec/build/bsps/powerpc/mvme5500/bspmvme5500.yml | 2 ++
13 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/bsps/powerpc/shared/console/console.c
b/bsps/powerpc/shared/console/console.c
index f275683..f6c8021 100644
--- a/bsps/powerpc/shared/console/console.c
+++ b/bsps/powerpc/shared/console/console.c
@@ -153,8 +153,8 @@ static int console_first_open(int major, int minor, void
*arg)
/* must not open a minor device we have no ISR for */
assert( minor>=0 && minor < sizeof(ttyS)/sizeof(ttyS[0]) && ttyS[minor].isr
);
- /* 9600-8-N-1 */
- BSP_uart_init(minor, 9600, 0);
+ /* BSP_CONSOLE_BAUD-8-N-1 */
+ BSP_uart_init(minor, BSP_CONSOLE_BAUD, 0);
status = BSP_uart_install_isr(minor, ttyS[minor].isr);
if (!status) {
printk("Error installing serial console interrupt handler for '%s'!\n",
diff --git a/bsps/powerpc/shared/console/uart.c
b/bsps/powerpc/shared/console/uart.c
index 62212b9..41db52f 100644
--- a/bsps/powerpc/shared/console/uart.c
+++ b/bsps/powerpc/shared/console/uart.c
@@ -160,7 +160,7 @@ BSP_uart_init(int uart, int baud, int hwFlow)
if ( (int)BSPBaseBaud <= 0 ) {
/* Use current divisor assuming BSPBaseBaud gives us the current speed
*/
- BSPBaseBaud = BSPBaseBaud ? -BSPBaseBaud : 9600;
+ BSPBaseBaud = BSPBaseBaud ? -BSPBaseBaud : BSP_CONSOLE_BAUD;
BSPBaseBaud *= ((uread(uart, DLM) << 8) | uread(uart, DLL));
}
diff --git a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
index b332aaa..584072d 100644
--- a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
+++ b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
@@ -34,6 +34,10 @@ Note that the policy can still be defined by the application
CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is removed
and a little memory is saved.])
+RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
+RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
+[default console baud])
+
AC_DEFINE(__ppc_generic, 1, [PowerPC model option])
# Explicitly list all Makefiles here
diff --git a/c/src/lib/libbsp/powerpc/haleakala/configure.ac
b/c/src/lib/libbsp/powerpc/haleakala/configure.ac
index cf3a552..627625b 100644
--- a/c/src/lib/libbsp/powerpc/haleakala/configure.ac
+++ b/c/src/lib/libbsp/powerpc/haleakala/configure.ac
@@ -25,6 +25,10 @@ RTEMS_BSPOPTS_HELP([PPC_VECTOR_FILE_BASE],
[This defines the base address of the exception table.
NOTE: Vectors are actually at 0xFFF0 but file starts at offset.])
+RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
+RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
+[default console baud])
+
AC_DEFINE(ppc405, 1, [PowerPC model option])
RTEMS_BSP_CLEANUP_OPTIONS
diff --git a/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
b/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
index 8b79309..56d550c 100644
--- a/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
+++ b/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
@@ -33,6 +33,10 @@ Note that the policy can still be defined by the application
CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is removed
and a little memory is saved.])
+RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
+RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
+[default console baud])
+
RTEMS_BSPOPTS_SET([mvme2100],[mvme2100],[1])
RTEMS_BSPOPTS_SET([mvme2100],[*],[])
RTEMS_BSPOPTS_HELP([mvme2100],
diff --git a/c/src/lib/libbsp/powerpc/mvme3100/configure.ac
b/c/src/lib/libbsp/powerpc/mvme3100/configure.ac
index 8b9a04f..cf35fd1 100644
--- a/c/src/lib/libbsp/powerpc/mvme3100/configure.ac
+++ b/c/src/lib/libbs
[PATCH 0/2] powerpc/shared/console: Console buad rate fixes
From: Peter Dufault With these two changes the "powerpc/shared/console" code supports a configurable baud rate. - Remove hard-wired start-up baud of 9600. - Fix "termios" first-open that resets baud rate to 9600. Peter Dufault (2): powerpc/shared/console: Make console baud rate configurable. powerpc/shared/console: "termios" first open sets console baud to 9600 bsps/powerpc/shared/console/console.c | 4 ++-- bsps/powerpc/shared/console/uart.c | 6 +- c/src/lib/libbsp/powerpc/beatnik/configure.ac | 4 c/src/lib/libbsp/powerpc/haleakala/configure.ac| 4 c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac | 4 c/src/lib/libbsp/powerpc/mvme3100/configure.ac | 4 c/src/lib/libbsp/powerpc/mvme5500/configure.ac | 4 spec/build/bsps/optconsolebaud.yml | 5 + spec/build/bsps/powerpc/beatnik/bspbeatnik.yml | 2 ++ spec/build/bsps/powerpc/haleakala/bsphaleakala.yml | 2 ++ spec/build/bsps/powerpc/motorola_powerpc/obj.yml | 4 +++- spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml | 2 ++ spec/build/bsps/powerpc/mvme5500/bspmvme5500.yml | 2 ++ 13 files changed, 43 insertions(+), 4 deletions(-) -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 0/2] powerpc/shared/console: Console baud rate fixes
> On Apr 15, 2021, at 08:55 , Joel Sherrill wrote: > > No one has posted publicly about these in 5 days and asking privately a > group of mvme users, I only got feedback from Heinz > > == > I can only note that we have some (many) users who would like to stay at the > fixed 9600 baud because that is what > they have been used to since "forever”. > I had received feedback on the MVME2500. There I had set the console of this > QorIQ based system to the typical > 125600 baud for arm (also with the option BSP_CONSOLE_BAUD). Some were not > happy that there are two different > baud rates for the different MVME boards. > I personally find Paul's approach ok and if the default value (bsp-defaults) > eventually stays at 9600 baud on all > these boards could everyone be happy? I kept all the defaults at what they are now (usually 9600) to avoid surprises. > > == > > This patch series makes all the mvme BSPs consistent so I plan to > merge these today. > Moving the legacy network code broke the patches that added baud rate configuration to the ".yml" files. I'll resubmit the patches after I've tested a recent version, but I'll need to pull down the new legacy network branch and build that as well. Hopefully all goes smoothly and I'll find time today. FYI, since other people are working in this area: I'll soon submit a PCI multi-port serial driver for an eight port PMC serial port card. Some of the files will need to be shuffled around. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] c-user: Add scheduler glossary terms
> On Apr 13, 2021, at 11:23 , Gedare Bloom wrote: > >> What about "ineligible" as Gedare originally suggested. >> > that would be my preference. It is a cleaner terminology fit. > > From reading the mailings this is in contrast to the "eligible scheduler". So "ineligible" is good. That's based on the mailings and not the code. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 0/2] powerpc/shared/console: Console baud rate fixes
> On Apr 10, 2021, at 08:41 , wrote: > > The "powerpc/shared/console" code has the start-up console value fixed > at 9600 baud. This changes the hard-wired constant "9600" in the code > to the configuration setting "BSP_CONSOLE_BAUD" and adds configuration > support in both the "waf" and the legacy configuration systems. > > In addition, once the shared console baud rate can be set to start at > anything other than 9600 the termios code will reset it to 9600 at the > first open. I did this over incorporating both patches and using "git send-email" from my "git" server. Joel told me it appeared I'd cut-and-pasted the previous patch. I hadn't, I imported it into Apple mail as "mbox" format and then sent it. I don't know if it was the import or the fact it was digitally signed that looked odd. At any rate, this patch should at least be received properly. 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 v2 0/2] powerpc/shared/console: Console baud rate fixes
From: Peter Dufault The "powerpc/shared/console" code has the start-up console value fixed at 9600 baud. This changes the hard-wired constant "9600" in the code to the configuration setting "BSP_CONSOLE_BAUD" and adds configuration support in both the "waf" and the legacy configuration systems. In addition, once the shared console baud rate can be set to start at anything other than 9600 the termios code will reset it to 9600 at the first open. Peter Dufault (2): powerpc/shared/console: Make console baud rate configurable. powerpc/shared/console: "termios" first open sets console baud to 9600 bsps/powerpc/shared/console/console.c | 4 ++-- bsps/powerpc/shared/console/uart.c | 5 - c/src/lib/libbsp/powerpc/beatnik/configure.ac | 4 c/src/lib/libbsp/powerpc/haleakala/configure.ac| 4 c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac | 4 c/src/lib/libbsp/powerpc/mvme3100/configure.ac | 4 c/src/lib/libbsp/powerpc/mvme5500/configure.ac | 4 spec/build/bsps/optconsolebaud.yml | 5 + spec/build/bsps/powerpc/beatnik/bspbeatnik.yml | 2 ++ spec/build/bsps/powerpc/haleakala/bsphaleakala.yml | 2 ++ spec/build/bsps/powerpc/motorola_powerpc/obj.yml | 4 +++- spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml | 2 ++ spec/build/bsps/powerpc/mvme5500/bspmvme5500.yml | 2 ++ 13 files changed, 42 insertions(+), 4 deletions(-) -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 1/2] powerpc/shared/console: Make console baud rate configurable.
From: Peter Dufault
The "powerpc/shared/console" code has the start-up console value fixed
at 9600 baud. This changes the hard-wired constant "9600" in the code
to the configuration setting "BSP_CONSOLE_BAUD" and adds configuration
support in both the "waf" and the legacy configuration systems.
Note that the VME BSPs beatnik, mvme3100, and mve5100 can be improved
by adding a "mvme" BSP family. This configuration change, as well
as future configuration changes, could then be made in a "grp.yml" file.
---
bsps/powerpc/shared/console/console.c | 4 ++--
bsps/powerpc/shared/console/uart.c | 2 +-
c/src/lib/libbsp/powerpc/beatnik/configure.ac | 4
c/src/lib/libbsp/powerpc/haleakala/configure.ac| 4
c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac | 4
c/src/lib/libbsp/powerpc/mvme3100/configure.ac | 4
c/src/lib/libbsp/powerpc/mvme5500/configure.ac | 4
spec/build/bsps/optconsolebaud.yml | 5 +
spec/build/bsps/powerpc/beatnik/bspbeatnik.yml | 2 ++
spec/build/bsps/powerpc/haleakala/bsphaleakala.yml | 2 ++
spec/build/bsps/powerpc/motorola_powerpc/obj.yml | 4 +++-
spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml | 2 ++
spec/build/bsps/powerpc/mvme5500/bspmvme5500.yml | 2 ++
13 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/bsps/powerpc/shared/console/console.c
b/bsps/powerpc/shared/console/console.c
index f275683..f6c8021 100644
--- a/bsps/powerpc/shared/console/console.c
+++ b/bsps/powerpc/shared/console/console.c
@@ -153,8 +153,8 @@ static int console_first_open(int major, int minor, void
*arg)
/* must not open a minor device we have no ISR for */
assert( minor>=0 && minor < sizeof(ttyS)/sizeof(ttyS[0]) && ttyS[minor].isr
);
- /* 9600-8-N-1 */
- BSP_uart_init(minor, 9600, 0);
+ /* BSP_CONSOLE_BAUD-8-N-1 */
+ BSP_uart_init(minor, BSP_CONSOLE_BAUD, 0);
status = BSP_uart_install_isr(minor, ttyS[minor].isr);
if (!status) {
printk("Error installing serial console interrupt handler for '%s'!\n",
diff --git a/bsps/powerpc/shared/console/uart.c
b/bsps/powerpc/shared/console/uart.c
index 62212b9..41db52f 100644
--- a/bsps/powerpc/shared/console/uart.c
+++ b/bsps/powerpc/shared/console/uart.c
@@ -160,7 +160,7 @@ BSP_uart_init(int uart, int baud, int hwFlow)
if ( (int)BSPBaseBaud <= 0 ) {
/* Use current divisor assuming BSPBaseBaud gives us the current speed
*/
- BSPBaseBaud = BSPBaseBaud ? -BSPBaseBaud : 9600;
+ BSPBaseBaud = BSPBaseBaud ? -BSPBaseBaud : BSP_CONSOLE_BAUD;
BSPBaseBaud *= ((uread(uart, DLM) << 8) | uread(uart, DLL));
}
diff --git a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
index b332aaa..584072d 100644
--- a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
+++ b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
@@ -34,6 +34,10 @@ Note that the policy can still be defined by the application
CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is removed
and a little memory is saved.])
+RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
+RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
+[default console baud])
+
AC_DEFINE(__ppc_generic, 1, [PowerPC model option])
# Explicitly list all Makefiles here
diff --git a/c/src/lib/libbsp/powerpc/haleakala/configure.ac
b/c/src/lib/libbsp/powerpc/haleakala/configure.ac
index cf3a552..627625b 100644
--- a/c/src/lib/libbsp/powerpc/haleakala/configure.ac
+++ b/c/src/lib/libbsp/powerpc/haleakala/configure.ac
@@ -25,6 +25,10 @@ RTEMS_BSPOPTS_HELP([PPC_VECTOR_FILE_BASE],
[This defines the base address of the exception table.
NOTE: Vectors are actually at 0xFFF0 but file starts at offset.])
+RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
+RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
+[default console baud])
+
AC_DEFINE(ppc405, 1, [PowerPC model option])
RTEMS_BSP_CLEANUP_OPTIONS
diff --git a/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
b/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
index 8b79309..56d550c 100644
--- a/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
+++ b/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
@@ -33,6 +33,10 @@ Note that the policy can still be defined by the application
CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is removed
and a little memory is saved.])
+RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
+RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
+[default console baud])
+
RTEMS_BSPOPTS_SET([mvme2100],[mvme2100],[1])
RTEMS_BSPOPTS_SET([mvme2100],[*],[])
RTEMS_BSPOPTS_HELP([mvme2100],
diff --git a/c/src/lib/libbsp/powerpc/mvme3100/configure.ac
b/c/src/lib/libbsp/powerpc/mvme3100/configure.ac
index 8b9a04f..cf35fd1 100644
--- a/c/src/lib/libbsp/powerpc/mvme3100/configure.ac
+++ b/c/src/lib/libbs
[PATCH v2 2/2] powerpc/shared/console: "termios" first open sets console baud to 9600
From: Peter Dufault When the PowerPC shared console baud rate starts at anything other than 9600 the termios code will set it to 9600 at the first open. --- bsps/powerpc/shared/console/uart.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/bsps/powerpc/shared/console/uart.c b/bsps/powerpc/shared/console/uart.c index 41db52f..f30b6a3 100644 --- a/bsps/powerpc/shared/console/uart.c +++ b/bsps/powerpc/shared/console/uart.c @@ -536,6 +536,9 @@ BSP_uart_termios_set(int uart, void *p) uart_data[uart].ioMode = ttyp->device.outputUsesInterrupts; + /* Convert from the baud number to the "speed_t" termios setting. */ + ttyp->termios.c_ispeed = ttyp->termios.c_ospeed = rtems_termios_number_to_baud(uart_data[uart].baud); + return; } -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] powerpc/shared/console: Make console baud rate configurable.
> On Apr 9, 2021, at 11:55 , wrote: > > My first "git format-patch" for RTEMS, sent using an Apple mailer yet. I > hope it's OK. Critiquing my own patch. I have a second simple patch I was going to submit separately. After the start-up baud rate is made configurable, there is a second issue where if you switch to "termios" it sets the baud rate back to 9600 at the termios first_open() call. The fix is to add: "ttyp->termios.c_ispeed = ttyp->termios.c_ospped = rtems_termios_number_to_baud(uart_data[uart].baud);" to the bottom of BSP_uart_termios_set(). Is this a different patch (since it is a separate issue) or a [2/2] patch to the "Make console baud rate configurable" patch (since the issue didn't show up as the start-up baud rate was fixed at 9600 anyway)? 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
Re: [PATCH] powerpc/shared/console: Make console baud rate configurable.
> On Apr 9, 2021, at 11:53 , Peter Dufault wrote: > > The "powerpc/shared/console" code has the start-up console value fixed > at 9600 baud. This changes the hard-wired constant "9600" in the code > to the configuration setting "BSP_CONSOLE_BAUD" and adds configuration > support in both the "waf" and the legacy configuration systems. > > Note that the VME BSPs beatnik, mvme3100, and mve5100 can be improved > by adding a "mvme" BSP family. This configuration change, as well > as future configuration changes, could then be made in a "grp.yml" file. My first "git format-patch" for RTEMS, sent using an Apple mailer yet. I hope it's OK. I've made a resolution to get my local changes back ASAP. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] powerpc/shared/console: Make console baud rate configurable.
The "powerpc/shared/console" code has the start-up console value fixed
at 9600 baud. This changes the hard-wired constant "9600" in the code
to the configuration setting "BSP_CONSOLE_BAUD" and adds configuration
support in both the "waf" and the legacy configuration systems.
Note that the VME BSPs beatnik, mvme3100, and mve5100 can be improved
by adding a "mvme" BSP family. This configuration change, as well
as future configuration changes, could then be made in a "grp.yml" file.
---
bsps/powerpc/shared/console/console.c | 4 ++--
bsps/powerpc/shared/console/uart.c | 2 +-
c/src/lib/libbsp/powerpc/beatnik/configure.ac | 4
c/src/lib/libbsp/powerpc/haleakala/configure.ac| 4
c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac | 4
c/src/lib/libbsp/powerpc/mvme3100/configure.ac | 4
c/src/lib/libbsp/powerpc/mvme5500/configure.ac | 4
spec/build/bsps/optconsolebaud.yml | 5 +
spec/build/bsps/powerpc/beatnik/bspbeatnik.yml | 2 ++
spec/build/bsps/powerpc/haleakala/bsphaleakala.yml | 2 ++
spec/build/bsps/powerpc/motorola_powerpc/obj.yml | 4 +++-
spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml | 2 ++
spec/build/bsps/powerpc/mvme5500/bspmvme5500.yml | 2 ++
13 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/bsps/powerpc/shared/console/console.c
b/bsps/powerpc/shared/console/console.c
index f275683..f6c8021 100644
--- a/bsps/powerpc/shared/console/console.c
+++ b/bsps/powerpc/shared/console/console.c
@@ -153,8 +153,8 @@ static int console_first_open(int major, int minor, void
*arg)
/* must not open a minor device we have no ISR for */
assert( minor>=0 && minor < sizeof(ttyS)/sizeof(ttyS[0]) && ttyS[minor].isr );
- /* 9600-8-N-1 */
- BSP_uart_init(minor, 9600, 0);
+ /* BSP_CONSOLE_BAUD-8-N-1 */
+ BSP_uart_init(minor, BSP_CONSOLE_BAUD, 0);
status = BSP_uart_install_isr(minor, ttyS[minor].isr);
if (!status) {
printk("Error installing serial console interrupt handler for '%s'!\n",
diff --git a/bsps/powerpc/shared/console/uart.c
b/bsps/powerpc/shared/console/uart.c
index 62212b9..41db52f 100644
--- a/bsps/powerpc/shared/console/uart.c
+++ b/bsps/powerpc/shared/console/uart.c
@@ -160,7 +160,7 @@ BSP_uart_init(int uart, int baud, int hwFlow)
if ( (int)BSPBaseBaud <= 0 ) {
/* Use current divisor assuming BSPBaseBaud gives us the current speed
*/
- BSPBaseBaud = BSPBaseBaud ? -BSPBaseBaud : 9600;
+ BSPBaseBaud = BSPBaseBaud ? -BSPBaseBaud : BSP_CONSOLE_BAUD;
BSPBaseBaud *= ((uread(uart, DLM) << 8) | uread(uart, DLL));
}
diff --git a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
index b332aaa..584072d 100644
--- a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
+++ b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
@@ -34,6 +34,10 @@ Note that the policy can still be defined by the application
CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is removed
and a little memory is saved.])
+RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
+RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
+[default console baud])
+
AC_DEFINE(__ppc_generic, 1, [PowerPC model option])
# Explicitly list all Makefiles here
diff --git a/c/src/lib/libbsp/powerpc/haleakala/configure.ac
b/c/src/lib/libbsp/powerpc/haleakala/configure.ac
index cf3a552..627625b 100644
--- a/c/src/lib/libbsp/powerpc/haleakala/configure.ac
+++ b/c/src/lib/libbsp/powerpc/haleakala/configure.ac
@@ -25,6 +25,10 @@ RTEMS_BSPOPTS_HELP([PPC_VECTOR_FILE_BASE],
[This defines the base address of the exception table.
NOTE: Vectors are actually at 0xFFF0 but file starts at offset.])
+RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
+RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
+[default console baud])
+
AC_DEFINE(ppc405, 1, [PowerPC model option])
RTEMS_BSP_CLEANUP_OPTIONS
diff --git a/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
b/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
index 8b79309..56d550c 100644
--- a/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
+++ b/c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
@@ -33,6 +33,10 @@ Note that the policy can still be defined by the application
CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is removed
and a little memory is saved.])
+RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
+RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
+[default console baud])
+
RTEMS_BSPOPTS_SET([mvme2100],[mvme2100],[1])
RTEMS_BSPOPTS_SET([mvme2100],[*],[])
RTEMS_BSPOPTS_HELP([mvme2100],
diff --git a/c/src/lib/libbsp/powerpc/mvme3100/configure.ac
b/c/src/lib/libbsp/powerpc/mvme3100/configure.ac
index 8b9a04f..cf35fd1 100644
--- a/c/src/lib/libbsp/powerpc/mvme3100/configure.ac
+++ b/c/src/lib/libbsp/powerpc/mvme3100/configure.ac
@@ -33,6 +33,10 @@ Note that the policy can still be defined by the application
CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is removed
and a little memor
Re: Questions about waf config system: "grp" and updating configure.ac
> On Apr 9, 2021, at 08:25 , Sebastian Huber
> wrote:
>
> On 09/04/2021 14:01, dufa...@hda.com wrote:
>
>> I checked all the "spec/build/bsps/ARCH/grp.yml" files and don't see
>> anything like "variant" to restrict specifications to a subset of the BSPs
>> in "ARCH".
>
> This is the wrong level for BSP-specific options. You have to look for:
>
> spec/build/bsps/ARCH/FAMILY/grp.yml
This won't work, "powerpc/shared/console" is shared across powerpc FAMILYs:
[dufault@gen6 powerpc]$ grep -r shared/console .
./beatnik/bspbeatnik.yml:- bsps/powerpc/shared/console/console.c
./beatnik/bspbeatnik.yml:- bsps/powerpc/shared/console/uart.c
./haleakala/bsphaleakala.yml:- bsps/powerpc/shared/console/console.c
./haleakala/bsphaleakala.yml:- bsps/powerpc/shared/console/uart.c
./motorola_powerpc/obj.yml:- bsps/powerpc/shared/console/console.c
./motorola_powerpc/obj.yml:- bsps/powerpc/shared/console/uart.c
./mvme3100/bspmvme3100.yml:- bsps/powerpc/shared/console/console.c
./mvme3100/bspmvme3100.yml:- bsps/powerpc/shared/console/uart.c
./mvme5500/bspmvme5500.yml:- bsps/powerpc/shared/console/console.c
./mvme5500/bspmvme5500.yml:- bsps/powerpc/shared/console/uart.c
[dufault@gen6 powerpc]$
There is a missing FAMILY ("mvme") for the PowerPC VME boards "beatnik"
(supports MVME5500 and MVME6100), "mvme3100", and "mvme5500" where we would put
a "grp.yml" file for the console baud and other shared items on the VME boards.
There are still other FAMILY members outside of that non-existent VME family
that wouldn't be addressed ("haleakala", "motorola_powerpc"). Adding FAMILY
"mvme" is a valuable cleanup, but not one I can do now when I'm trying to
cleanly-enough fix the default console baud and then move on to other pressing
items.
I'll leave "uid: ../../optconsolebaud" in
"spec/build/bsps/powerpc/{beatnik,haleakala,motorola_powerpc,mvme3100,mvme5500}/bsp*yml".
>
>>
>> So, instead of changing the
>> "powerpc/{beatnik/haleakala,motorola_powerpc,mvme3100,mvme5500}/bsp*.yml}"
>> files to add the build-dependency on "uid: ../../optconsolebaud" can I put
>> it in the "spec/build/bsps/powerpc/grp.yml" file?
> Actually, it would be nice if all BSPs use the same option for this setting.
> However, this requires that someone has the time to convert all console
> drivers to use this option. Also the removal of the old build system is
> required for cleanup work like this.
>
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.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Questions about waf config system: "grp" and updating configure.ac
> On Apr 9, 2021, at 01:02 , Sebastian Huber
> wrote:
>
>> 1. I changed all the "spec/build/bsps/powerpc/foo/bspfoo.yml" files (for bsp
>> "foo", the ones that use powerpc/shared/{console.c,uart.c}) to add:
>> - role: build-dependency
>> - uid: ../../optconsolebaud
>
> if a BSP has more than one bsp*.yml file (and thus a grp.yml file), it should
> be added to the grp.yml file, see also:
>
> https://docs.rtems.org/branches/master/eng/build-system.html#build-specification-items
I looked at that documentation. For me it takes a while to sink in, I need to
go through the steps (at least!).
I checked all the "spec/build/bsps/ARCH/grp.yml" files and don't see anything
like "variant" to restrict specifications to a subset of the BSPs in "ARCH".
So, instead of changing the
"powerpc/{beatnik/haleakala,motorola_powerpc,mvme3100,mvme5500}/bsp*.yml}"
files to add the build-dependency on "uid: ../../optconsolebaud" can I put it
in the "spec/build/bsps/powerpc/grp.yml" file?
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.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Questions about waf config system: "grp" and updating configure.ac
> On Apr 9, 2021, at 03:03 , Chris Johns wrote: > > On 9/4/21 4:45 pm, Sebastian Huber wrote: >> On 09/04/2021 08:28, Chris Johns wrote: >> >>> On 9/4/21 3:02 pm, Sebastian Huber wrote: >>>> I try to not break the old build system, however, I don't add new stuff to >>>> it. >>>> From my point of view the old build system should be removed. The major >>>> blocking >>>> point for the removal is that nobody had the time to convert the BSP >>>> builder to >>>> use the new build system. >>> It looks like recent changes have broken the autotool build system... >>> >>> https://lists.rtems.org/pipermail/build/2021-April/027232.html >>> >>> Is there any point in it staying if it does not work? I noticed that "mpc55xxevb/configure.ac" still uses "BSP_DEFAULT_BAUD_RATE" while the "waf" build system changed the code and configuration name to the standardized "BSP_CONSOLE_BAUD". I didn't fix it since it's not associated with the powerpc/shared changes, but it is bit-rot. If the old build system isn't supposed to be kept up-to-date I recommend removing it. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Questions about waf config system: "grp" and updating configure.ac
I wanted to fix default console baud rate handling in "powerpc/beatnik" (and
thus in anything using powerpc/shared/console). I believe:
- The bsps (at least the "motload" ones) start up with the baud rate set by
"motload" and some of the RTEMS tests actually work, that is, the baud rate
must never be set.
- The default console baud rate is hard-wired to 9600 in
powerpc/shared/{console.c,uart.c};
- If you change the hard-wiring to e.g. 115200 the baud rate gets set back to
9600 if you use "termios" (in the first-open function the o_speed is still
9600).
I fixed these items and figured how to configure the baud rate using "waf" with
the BSP_CONSOLE_BAUD option but have questions:
1. I changed all the "spec/build/bsps/powerpc/foo/bspfoo.yml" files (for bsp
"foo", the ones that use powerpc/shared/{console.c,uart.c}) to add:
- role: build-dependency
- uid: ../../optconsolebaud
2. I changed "spec/build/bsps/optconsolebaud.yml" to default those BSPs to 9600
(to retain current behavior):
- value: 9600
variants:
- m68k/m5484FireEngine
- powerpc/hsc_cm01
- powerpc/beatnik
- powerpc/haleakala
- powerpc/motorola_powerpc
- powerpc/mvme3100
- powerpc/mvme5500
3. I changed the associated "configure.ac" for those BSPS to add:
RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
[default console baud])
Questions:
1. Does this look about right?
2. I don't quite understand what "grp" does. Is there a way to create a group
for the above BSPS that use powerpc/shared/console to simplify the changes I
made? Or more likely going forward, to treat them more like a group since they
share a lot of code that should be cleaned up.
3. Is it correct to update the "configure.ac" files when new options are added
or are those now considered defunct?
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.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: How do we know what priority of the Init task is?
I re-read Joel's mail and I agree, the priority should be left ridiculously low (as it is now) or maybe set in the middle (but why bother?). I was thinking about matching classic RTEMS behavior. I don't think it matters in POSIX. > On Feb 23, 2021, at 17:12 , Peter Dufault wrote: > > Signed PGP part > A few notes. All are my understanding and IMHO. > > - The reason that VRTX and other ancient RTOS's use 1 as the highest priority > was the prevalence of "find first bit set" instructions. With e.g. 32 > priorities you could in one instruction find the highest priority object that > has something in it. Such single instruction optimizations have been suspect > for a long time, not to mention "find last bit set" instructions. > - That's why POSIX has a minimum of 32 priority levels. POSIX standards need > to support a "least common denominator", and when defining the standards some > either wanted to match existing practice or support suspect optimal > compilation. > - As for the decision to make higher priorities higher and not lower, I'd > need to read the "rationale" sections of the POSIX work about priorities and > POSIX. I'm guessing they were sick of saying "lower priorities are higher" > and that it was time to move forward. *I* think that was a mistake, the Unix > "nice" levels had the same "lower is higher" attribute as do the legacy > RTOS's. > - The default priority for the POSIX_Init thread should be obtained by > mapping through the same function that maps classic priorities to POSIX > priorities. POSIX_init is a "special" thread, and I don't see why it > shouldn't have a special priority that matches the priorithy that rtems > classic uses for it's init function. > > It's probably safe to make the change. All existing POSIX_init applications > must either elevate their priority or ensure that any spawned threads do so. > > >> On Feb 23, 2021, at 12:47 , Joel Sherrill wrote: >> >> >> >> On Tue, Feb 23, 2021, 11:14 AM Heinz Junkes wrote: >> Thank you for the detailed explanation. I may have asked my question >> incorrectly. >> >> If I choose POSIX_Init for RTEMS the Init process has a very low priority >> and if I use >> the normal (RTEMS) Init a very high priority. This does not fit in my >> opinion. >> >> Shouldn't the POSIX_Init - process have the prio 98 or so? >> >> No. To match, it would need to be 254 but it gets the default pthread >> attributes which are implementation defined. Being very low is probably a >> good punishment for not specifying what you wanted in an application but may >> not have been the best choice for POSIX init thread. >> >> The ability to set very few attributes on the posix initialization thread >> was a deliberate decision because you have to set them via API calls and >> that would have increased the minimum footprint of a posix application to >> include all pthread attribute set methods. >> >> I don't have a good solution in mind. :( >> >> >> Heinz >> >>> On 23. Feb 2021, at 15:17, Joel Sherrill wrote: >>> >>> >>> >>> On Tue, Feb 23, 2021 at 4:25 AM Heinz Junkes >>> wrote: >>> what I have just never understood >>> >>> POSIX Prio 2 ist LOW Priority >>> RTEMS Prio 1 is HIGH Priority >>> >>> In general, RTOS threading APIs tended to use 1 as a high priority. The >>> RTEMS >>> Classic API based on pSOS+, VxWorks, and VRTX32 which preceded all those >>> all follow 1 is high priority model. >>> >>> POSIX calls for the opposite range. Not sure why. Interestingly, I had a >>> discussion >>> with the main kernel person for another RTOS about this in a standards >>> meeting >>> and he noted that although every implementation of POSIX threads we both >>> knew >>> about does use low number as low priority, it is not as explicit in the >>> POSIX standard >>> as one would think. We have just all read the same text that way since >>> POSIX is >>> careful to say raises or lowers priority and the implication we all saw is >>> that the >>> numbers follow that languge. But at this point, the priorities run this way >>> for no >>> other reason than history and compatibility. For all I know, it may even be >>> baked >>> into the POSIX Compliance Test Suite. Any program with hard-coded numbers >>>
Re: How do we know what priority of the Init task is?
. This design dates back to at least VMS > > where you have 32 priority levels because you could scan 32 bits in a > > single instruction. This was carried forward into Windows NT. > > > > THe diversity of choices reminded me of this quote from Andrew Tanenbaum: > > > > "The nice thing about standards is that there are so many of them to choose > > from." > > > > In the end different people had an arbitrary decision and picked different > > answers. Ada task priority is another set of choices. :) > > > > --joel > > > > > > Heinz > > > > > > > On 23. Feb 2021, at 09:17, Sebastian Huber > > > wrote: > > > > > > On 23/02/2021 08:36, Heinz Junkes wrote: > > > > > >> I would have a similar question ;-) > > >> > > >> What is the priority of the POSIX_Init - Task (as Posix-Prio)? > > > There is no option to configure the priority of the POSIX initialization > > > thread, so the default priority of 2 is used, see > > > _POSIX_Threads_Default_attributes. > > > > > > -- > > > embedded brains GmbH > > > 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 > > > > > > Registergericht: Amtsgericht München > > > Registernummer: HRB 157899 > > > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > > > Unsere Datenschutzerklärung finden Sie hier: > > > https://embedded-brains.de/datenschutzerklaerung/ > > > > > > > ___ > > 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 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 13/13] rtems: Avoid potential recursion in ASR handling
> On Feb 18, 2021, at 12:49 , Gedare Bloom wrote: > > willing to buy: style formatter. I'll buy one too. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi
> On Feb 16, 2021, at 11:33 , Gedare Bloom wrote: > >> The umlaut is part of the official brand. >> That can be tricky, depending on the corporate policy. >> >>> I find it odd to avoid Unicode and not allow umlauts in 2021. >>> >> > > We do allow unicode with justification. For names, I have no problem > with unicode characters. We do need to confirm when it commits, that > it comes back out the other side properly and doesn't become mangled > by some ASCII conversion. Sebastian pointed out this file in an earlier Unicode discussion: testsuites/fstests/fsdosfsname01/create_files.cs It's full of Unicode. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi
You could use "fuer" to replace "für" as was done in the olden days. Or do you need permission for that as well? I find it odd to avoid Unicode and not allow umlauts in 2021. > On Feb 16, 2021, at 05:21 , jan.som...@dlr.de wrote: > > Ok, I asked if it is ok to use the English name for our organization as well. > > The answer might take some time, though. > > > > Best regards, > > > > Jan > > > > From: Joel Sherrill > Sent: Monday, February 15, 2021 9:41 PM > To: Peter Dufault > Cc: Sommer, Jan ; rtems-de...@rtems.org > Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi > > > > Christian submitted a series of patches to eliminate unicode. I'd prefer if > we avoided it > > > > On Mon, Feb 15, 2021, 8:20 AM Peter Dufault wrote: > > An international project should allow UTF in source code. You might need to > hunt what setting you need (for gnome-terminal "export LANG=en_US.UTF-8" > works for me in the US). I'm surprised if anyone is working on a system that > can't at least display UTF-8. > > > On Feb 15, 2021, at 03:21 , jan.som...@dlr.de wrote: > > > > Hi Chris, > > > >> -Original Message- > >> From: Chris Johns > >> Sent: Sunday, February 14, 2021 10:20 PM > >> To: Sommer, Jan ; devel@rtems.org > >> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for > >> cadence-spi > >> > >> Hi Jan, > >> > >> Thank you for the changes. I have one question inlined below ... > >> > >> On 14/2/21 10:30 pm, Jan Sommer wrote: > >>> --- > >>> bsps/include/dev/spi/cadence-spi-regs.h | 84 + > >>> bsps/include/dev/spi/cadence-spi.h | 48 +++ > >>> bsps/shared/dev/spi/cadence-spi.c | 437 > >> > >>> 3 files changed, 569 insertions(+) > >>> create mode 100644 bsps/include/dev/spi/cadence-spi-regs.h > >>> create mode 100644 bsps/include/dev/spi/cadence-spi.h > >>> create mode 100644 bsps/shared/dev/spi/cadence-spi.c > >>> > >>> diff --git a/bsps/include/dev/spi/cadence-spi-regs.h > >>> b/bsps/include/dev/spi/cadence-spi-regs.h > >>> new file mode 100644 > >>> index 00..2851c88df1 > >>> --- /dev/null > >>> +++ b/bsps/include/dev/spi/cadence-spi-regs.h > >>> @@ -0,0 +1,84 @@ > >>> +/* SPDX-License-Identifier: BSD-2-Clause */ > >>> + > >>> +/* > >>> + * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum für Luft- und > >> Raumfahrt e. V. > >> > >> Is there a unicode character in this line? I cannot see anything in our > >> coding > >> standard about unicode characters in source and I am not sure what the > >> actual policy is. I seem to remember some have been removed in the past. I > >> thought I would ask on the list now before we push these changes. > >> > > > > There is an u-Umlaut in it. That is probably it. As it is part of the name, > > it's hard to get rid of. > > I could probably use the English name (German Aerospace Center) which has > > no special characters. > > Would that be preferred? > > > > Best regards, > > > >Jan > > > >> Chris > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > 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 > 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi
An international project should allow UTF in source code. You might need to hunt what setting you need (for gnome-terminal "export LANG=en_US.UTF-8" works for me in the US). I'm surprised if anyone is working on a system that can't at least display UTF-8. > On Feb 15, 2021, at 03:21 , jan.som...@dlr.de wrote: > > Hi Chris, > >> -Original Message- >> From: Chris Johns >> Sent: Sunday, February 14, 2021 10:20 PM >> To: Sommer, Jan ; devel@rtems.org >> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi >> >> Hi Jan, >> >> Thank you for the changes. I have one question inlined below ... >> >> On 14/2/21 10:30 pm, Jan Sommer wrote: >>> --- >>> bsps/include/dev/spi/cadence-spi-regs.h | 84 + >>> bsps/include/dev/spi/cadence-spi.h | 48 +++ >>> bsps/shared/dev/spi/cadence-spi.c | 437 >> >>> 3 files changed, 569 insertions(+) >>> create mode 100644 bsps/include/dev/spi/cadence-spi-regs.h >>> create mode 100644 bsps/include/dev/spi/cadence-spi.h >>> create mode 100644 bsps/shared/dev/spi/cadence-spi.c >>> >>> diff --git a/bsps/include/dev/spi/cadence-spi-regs.h >>> b/bsps/include/dev/spi/cadence-spi-regs.h >>> new file mode 100644 >>> index 00..2851c88df1 >>> --- /dev/null >>> +++ b/bsps/include/dev/spi/cadence-spi-regs.h >>> @@ -0,0 +1,84 @@ >>> +/* SPDX-License-Identifier: BSD-2-Clause */ >>> + >>> +/* >>> + * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum für Luft- und >> Raumfahrt e. V. >> >> Is there a unicode character in this line? I cannot see anything in our >> coding >> standard about unicode characters in source and I am not sure what the >> actual policy is. I seem to remember some have been removed in the past. I >> thought I would ask on the list now before we push these changes. >> > > There is an u-Umlaut in it. That is probably it. As it is part of the name, > it's hard to get rid of. > I could probably use the English name (German Aerospace Center) which has no > special characters. > Would that be preferred? > > Best regards, > >Jan > >> Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: How to Classify Intermittent Test Failures
Can the test be marked as a possible emulator failure? For example (I haven't looked at the report) use "?" (Huh?) and not "!" (Failed!) or "." )(Passed), that is, the test failed as an emulated system and the RTEMS project suspects the emulation itself is causing this. You shouldn't be allowed to use this on physical devices. > On Feb 1, 2021, at 12:31 , Joel Sherrill wrote: > > > > On Mon, Feb 1, 2021 at 11:14 AM Gedare Bloom wrote: > > > On Mon, Feb 1, 2021 at 9:42 AM Joel Sherrill wrote: > Hi > > On the aarch64 qemu testing, we are seeing some tests which seem to pass most > of the time but fail intermittently. It appears to be based somewhat on host > load but there may be other factors. > > There does not appear to be a good test results state for these. Marking them > expected pass or fail means they will get flagged incorrectly sometimes. > > > Are they expected to pass every time? > > Normally yes. But there appears to be some external factors particularly load > impacting qemu which lead to failures on target side code. > > > Intermittent failures are suspicious, and there is limited value to running a > test that has an "intermittent failure" state, since it will always be > successful if you don't care if it passes or fails. > > Yeah. No matter what you mark them, it sucks. > > > I don't see not running them as a good option. Beyond adding a new state to > reflect this oddity, any suggestions? > > --joel > ___ > 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 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Use defines for Thread_Life_state
> On Jan 29, 2021, at 13:59 , Gedare Bloom wrote:
>
>
>
> On Fri, Jan 29, 2021 at 11:38 AM Joel Sherrill
> wrote:
>
>
> On Fri, Jan 29, 2021, 12:28 PM Sebastian Huber
> wrote:
> On 29/01/2021 18:33, Peter Dufault wrote:
>
> >>> Do not use an enum as a bit field. Document the state flags.
> >>>
> >>>
> >>> Is this a new style rule that needs to be documented?
> >> Into which category would you put this? Language and Compiler?
> >>
> >> https://docs.rtems.org/branches/master/eng/coding-conventions.html
> >>
> >>
> >> Yes.
> >>
> >>
> > I use enums as bit fields a lot. I use them in conjunction with objects
> > that are the same enum.
> >
> > I avoid using #define. In most situations you can't print them in a
> > debugger and they imply restricted usage.
> >
> > Is this an appropriate warning? Does it always mean that the enum should
> > be replaced with a #define?
> >
> > If it doesn't always apply then the style should make it clear when it
> > should apply.
>
> We don't have to agree with Coverity. This is why I asked before the change:
>
> https://lists.rtems.org/pipermail/devel/2021-January/064105.html
>
> From my point of view enums are useful for bit fields and I don't think
> this point of view is too exotic since debuggers such as GDB and
> Lauterbach support it. For example:
>
> enum a {
> A,
> B,
> C
> };
>
> enum a f(enum a x, enum a y)
> {
> return x | y;
> }
>
> enum a v;
>
> int main()
> {
> v = f(B, C);
> return 0;
> }
>
> Breakpoint 1, main () at test.c:16
> 16 v = f(B, C);
> (gdb) n
> 17 return 0;
> (gdb) p v
> $1 = (B | C)
>
> If we want enums as bitfields, we can add that as a coding guideline as an
> option and mention that some static analysis tools do not like it.
>
> Then mark these all as ignored with an explanation
>
> My only concern is whether the behavior is always well-defined (by the C
> standards). I'm not an expert and don't know where to find an answer to that
> question.
>
> What I seem to glean from a quick search is that the main requirement is that
> the type is guaranteed consistent with char, signed int, or unsigned int. So
> bit manipulations would seem to be well-defined. Does coverity offer any
> guidance why it complains?
>
Gedare's concerns about well-defined behavior match mine.
I don't know why Coverity calls this issue out. Maybe they are enforcing one
of my "I wish C worked that way" checks: a particular enum should only be used
in conjunction with other expressions of that enum. Yes, that might require
casting, but I'd like it. I don't know about Coverity but I bet it doesn't
support how I wish things worked.
As Gedare points out: maybe this exposes ill-defined behavior.
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.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Use defines for Thread_Life_state
> On Jan 29, 2021, at 11:37 , Gedare Bloom wrote: > > On Fri, Jan 29, 2021 at 9:03 AM Sebastian Huber > wrote: > On 29/01/2021 16:09, Joel Sherrill wrote: > > > On Fri, Jan 29, 2021 at 9:06 AM Gedare Bloom > <mailto:ged...@rtems.org>> wrote: > > > > > > > > On Fri, Jan 29, 2021 at 12:24 AM Sebastian Huber > > > <mailto:sebastian.hu...@embedded-brains.de>> wrote: > > > > Do not use an enum as a bit field. Document the state flags. > > > > > > Is this a new style rule that needs to be documented? > > Into which category would you put this? Language and Compiler? > > https://docs.rtems.org/branches/master/eng/coding-conventions.html > > > Yes. > > I use enums as bit fields a lot. I use them in conjunction with objects that are the same enum. I avoid using #define. In most situations you can't print them in a debugger and they imply restricted usage. Is this an appropriate warning? Does it always mean that the enum should be replaced with a #define? If it doesn't always apply then the style should make it clear when it should apply. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Add _Thread_Demand_objects_information()
> On Jan 29, 2021, at 10:57 , Sebastian Huber > wrote: > > On 29/01/2021 15:29, dufa...@hda.com wrote: > >>> On Jan 28, 2021, at 09:13 , Sebastian >>> Huber wrote: >>> >>>> What's the rationale for "Demand"? Is that in use other places? >>>> >>>> It sounds odd to me, as if you're insisting the function provide something >>>> that it might otherwise decide not to. >>> "Get" was already used. This is a "Get" when we know the identifier is >>> valid. Do you have a better verb? >>> >> Valid_ID_Get? Or is that getting too wordy? >> >> I like "_ValID_" (i.e. use "ValID" in interface names for validated IDs) but >> that must break the rules. > > What about: > > _Thread_Get_objects_information() -> > _Thread_Get_objects_information_by_id(Objects_Id) > > _Thread_Demand_objects_information() -> > _Thread_Get_objects_information(Thread_Control *) I like that. Since the interface change is internal to RTEMS the change in the signature isn't a big deal, and "Get_*_by_id" can be used going forward to imply the ID needs validation as opposed to getting it from a valid Thread_Control. I have to research the RTEMS naming convention. I know it must be well-defined and not Random_case. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Add _Thread_Demand_objects_information()
> On Jan 28, 2021, at 09:13 , Sebastian Huber > wrote: > >> What's the rationale for "Demand"? Is that in use other places? >> >> It sounds odd to me, as if you're insisting the function provide something >> that it might otherwise decide not to. > "Get" was already used. This is a "Get" when we know the identifier is valid. > Do you have a better verb? > Valid_ID_Get? Or is that getting too wordy? I like "_ValID_" (i.e. use "ValID" in interface names for validated IDs) but that must break the rules. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Add _Thread_Demand_objects_information()
What's the rationale for "Demand"? Is that in use other places? It sounds odd to me, as if you're insisting the function provide something that it might otherwise decide not to. > On Jan 28, 2021, at 24:18 , Sebastian Huber > wrote: > > On 27/01/2021 21:25, Joel Sherrill wrote: > >> Piling on Gedare's comment but also ... >> >> (1) If this is justifiable, then every use should have a comment >> block about why the id is known to be good. >> >> (2) What does this really save? That should be documented for the method. >> >> Seems like a micro-optimization which might be adding additional code in >> most use cases. > > Please have a look at the commit message in v2 of the patch: > > https://lists.rtems.org/pipermail/devel/2021-January/064076.html > > -- > embedded brains GmbH > 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 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ > > _______ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Status of clang-llvm builds? Related to powerpc-spe.
Actually, replying to myself: I bet the context-switching code is broken for platforms that use the SPE via a Freescale library. That's something I'll need to look at. > On Jan 22, 2021, at 14:26 , Peter Dufault wrote: > > Signed PGP part > The PowerPC Signal Processing Engine (powerpc-spe) is now gone from gcc and > therefore from RTEMS (on the master branch). It *appears* to be supported > with Clang/LLVM on FreeBSD, apparently primarily to support some Amiga > platforms (I think), I think it's supported beginning in FreeBSD 12. > > RTEMS has appropriately pulled out support for the SPE. Since in the > applications I use the SPE is used via libraries from Motorola/Freescale/... > that may be OK, but having support for the architecture would "look good" to > my clients. > > I'm not going to push for a project to switch to LLVM for the SPE targets, I > don't have either the time or the money and I'm not going to ask my clients > to fund it. But I do want to know: > > - What's the status of Clang/LLVM and RTEMS? Is it production-ready and > production-used on certain (RISCV?) platforms? > - Does anybody know anything the quality of the "powerpc-spe" support in > Clang/LLVM? > > This is must an exploratory question. I don't have a plan to work on this > soon. > > 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. > > > 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Status of clang-llvm builds? Related to powerpc-spe.
The PowerPC Signal Processing Engine (powerpc-spe) is now gone from gcc and therefore from RTEMS (on the master branch). It *appears* to be supported with Clang/LLVM on FreeBSD, apparently primarily to support some Amiga platforms (I think), I think it's supported beginning in FreeBSD 12. RTEMS has appropriately pulled out support for the SPE. Since in the applications I use the SPE is used via libraries from Motorola/Freescale/... that may be OK, but having support for the architecture would "look good" to my clients. I'm not going to push for a project to switch to LLVM for the SPE targets, I don't have either the time or the money and I'm not going to ask my clients to fund it. But I do want to know: - What's the status of Clang/LLVM and RTEMS? Is it production-ready and production-used on certain (RISCV?) platforms? - Does anybody know anything the quality of the "powerpc-spe" support in Clang/LLVM? This is must an exploratory question. I don't have a plan to work on this soon. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Add "CONSTRAINTS" section do directive documentation?
Totally agree. > On Jan 20, 2021, at 10:58 , Gedare Bloom wrote: > > I think this seems reasonable. > > On Wed, Jan 20, 2021 at 3:48 AM Sebastian Huber > wrote: > Hello, > > I would like to add a "CONSTRAINTS" section to the directive > documentation (after or before the NOTES). For example in the NOTES of > rtems_timer_create() > > https://docs.rtems.org/branches/master/c-user/timer/directives.html#rtems-timer-create > > we have "This directive may cause the calling task to be preempted due > to an obtain and release of the object allocator mutex.". > > I would like to move this to a CONSTRAINTS section and use a link in the > specification to indicate this. Other examples for constraints are: > > * the allowed environment to call the directive (task context, interrupt > context, device driver initialization, etc.) > > * dependency on a clock tick (directives with RTEMS_WAIT and a timeout) > > Due to the links in the specification we can generate list like this > automatically: > > https://docs.rtems.org/branches/master/c-user/interrupt/operations.html#directives-allowed-from-an-isr > > -- > embedded brains GmbH > 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 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ > > ___ > 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 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Oddity with address recorded for gcc instrumentation on ARM
> On Dec 18, 2020, at 17:52 , Joel Sherrill wrote: > > > Can someone explain this? > These are link register values. The least significant bit determines if > a bx instruction continues in ARM or Thumb mode. > > I guess I've never had to look that close. Thanks Sebastian. > It had me confused at first when I started working with ARM. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
"invalid %if operator" in RTEMS source builder .cfg file
I'm building "Simple Open EtherCAT Master" with rtems-6. I built it earlier
with rtems-5. I get the following error when I try to build it:
[dufault@build scripts]$
/home/dufault/development/rtems/rtems-source-builder/source-builder/sb-set-builder
\
--log=log_arm_soem \
--prefix=/opt/flatland/opt/rtems-6 \
--with-tools=/opt/flatland/opt/rtems-6 \
--host=arm-rtems6 \
--with-rtems-bsp=xilinx_zynq_zedboard \
net/soem
RTEMS Source Builder - Set Builder, 6 (f8d1f3c00db9)
Build Set: net/soem
config: net/soem-master.cfg
error: rtems-bsp.cfg:169: invalid %if operator:
-B/opt/flatland/opt/rtems-6/arm-rtems6/xilinx_zynq_a9_qemu/lib -qrtems ==
Build FAILED
Build Set: Time 0:00:00.055627
Build FAILED
[dufault@build scripts]$
It fails at the following "%if" directive:
#
# If there are no LDFLAGS create a path to RTEMS.
#
%if %{rtems_bsp_ldflags} == %{nil}
%define rtems_bsp_ldflags -L%{rtems_bsp_prefix}/lib
%endif
Not being sure how to proceed I commented the three lines out and then it
built. Any suggestions?
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.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-docs] shell: Document i2c and spi commands.
> On Nov 30, 2020, at 18:07 , Gedare Bloom wrote: > > Aren't nearly all shell commands at least a bit unsafe? And we don't > have a lot of commands that have to be explicitly turned on if > CONFIGURE_SHELL_COMMANDS_ALL is already set. I found only networking > commands. > > That seems accurate, you can go ahead with the approach you took then. It > seems to be mostly consistent with the state of practice. > > I was surprised at the need to enable each command instead of adding all I2C commands with a single enable. I don't think code overhead is an issue. If you're testing I2C from the shell I'm not sure when it's important to have only e.g. i2cget but not i2cset. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Proposal for hardware configuration dependent performance limits
I don't understand this proposal. Is this an approach used somewhere else where I can review how this works? If not I need a clearer explanation. > On Nov 13, 2020, at 14:01 , Gedare Bloom wrote: > > On Fri, Nov 13, 2020 at 3:48 AM Sebastian Huber > wrote: >> >> Hello, >> >> there is one aspect with respect to performance limits which is >> currently not considered in this proposal: >> >> https://lists.rtems.org/pipermail/devel/2020-November/063213.html >> >> You can run the some BSPs such as sparc/gr712rc on several boards. >> However, each board may have different settings which affect the system >> performance, for example the CPU frequency, memory controller settings, >> memory chips, etc. In the proposal, limits are specified like this: >> >> >> limits: >> sparc/gr712rc: >> DirtyCache: >> max-upper-bound: 0.05 >> mean-upper-bound: 0.05 >> FullCache: >> max-upper-bound: 0.05 >> mean-upper-bound: 0.05 >> HotCache: >> max-upper-bound: 0.05 >> mean-upper-bound: 0.05 >> Load/1: >> max-upper-bound: 0.1 >> mean-upper-bound: 0.1 >> Load/2: >> max-upper-bound: 0.1 >> mean-upper-bound: 0.1 >> Load/3: >> max-upper-bound: 0.1 >> mean-upper-bound: 0.1 >> Load/4: >> max-upper-bound: 0.1 >> mean-upper-bound: 0.1 >> >> This neglects that the limits are subject to a board configuration. One >> approach to cover this is the addition of a new BSP provided function: >> >> const char *rtems_get_hardware_performance_hash(); >> >> The BSP feeds all performance related data into a hash function and > "data" here means configuration? > >> returns a string encoding (for example a MD5 digest in base64 encoding). >> The example from above with the performance hash: >> >> limits: >> sparc/gr712rc/XrY7u+Ae7tCTyyK7j1rNww==: >> DirtyCache: >> max-upper-bound: 0.05 >> mean-upper-bound: 0.05 >> >> The test suite could report the performance has and a test output analyser >> coudl check that the reported values are in the specified bounds. >> > This will work for fixed sets of configurations. I wonder if it is > reasonable instead to define ranges over configuration values? Or to > use board variant mnemonic names instead? How many possible > configurations are we talking about? > > The hash output is fairly opaque, and really small configuration > changes would result in totally different hashes, so if I change a > board from 2 MiB RAM to 3 MiB RAM, I might like to know which > configuration this is closest to in case there is no matching hash. > > To invert the hash we will need to keep the table of all the > configurations mapped to hash values, which is fine I suppose. > > I can see that the advantage of a hash is that we don't need to create > a namespace for configuration options that may influence performance. > This can give some flexibility for boards that have different sets of > configuration options that matter. > > >> -- >> embedded brains GmbH >> 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 >> PGP: Public key available on request. >> >> embedded brains GmbH >> Registergericht: Amtsgericht München >> Registernummer: HRB 157899 >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler >> Unsere Datenschutzerklärung finden Sie hier: >> https://embedded-brains.de/datenschutzerklaerung/ >> >> ___ >> 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 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] shell: Remove not functioning fdisk mount/unmount command
_ERROR;
>> -goto cleanup;
>> - }
>> -}
>> - }
>> -
>> -cleanup:
>> -
>> - free( mount_point);
>> -
>> - return esc;
>> -}
>> diff --git a/cpukit/libmisc/shell/fdisk.c b/cpukit/libmisc/shell/fdisk.c
>> index d071e4fbba..c244922492 100644
>> --- a/cpukit/libmisc/shell/fdisk.c
>> +++ b/cpukit/libmisc/shell/fdisk.c
>> @@ -5,10 +5,10 @@
>> */
>>
>> /*
>> - * Copyright (c) 2009
>> + * Copyright (c) 2009, 2020
>> * embedded brains GmbH
>> - * Obere Lagerstr. 30
>> - * D-82178 Puchheim
>> + * Dornierstr. 4
>> + * 82178 Puchheim
>> * Germany
>> *
>> *
>> @@ -61,13 +61,8 @@ static const char rtems_bdpart_shell_usage [] =
>> "\tcreates a logical disk for each partition of the disk\n"
>> "\n"
>> "fdisk DISK_NAME unregister\n"
>> - "\tdeletes the logical disks associated with the partitions of the disk\n"
>> - "\n"
>> - "fdisk DISK_NAME mount\n"
>> - "\tmounts the file system of each partition of the disk\n"
>> - "\n"
>> - "fdisk DISK_NAME unmount\n"
>> - "\tunmounts the file system of each partition of the disk\n"
>> + "\tdeletes the logical disks associated with the partitions\n"
>> + "\tof the disk\n"
>> "\n"
>> "option values:\n"
>> "\tDISK_NAME: absolute path to disk device like '/dev/hda'\n"
>> @@ -84,14 +79,11 @@ static int rtems_bdpart_shell_main( int argc, char
>> **argv)
>> unsigned dist [RTEMS_BDPART_PARTITION_NUMBER_HINT];
>> size_t count = RTEMS_BDPART_PARTITION_NUMBER_HINT;
>> const char *disk_name = NULL;
>> - const char *mount_base = "/mnt";
>> bool do_create = false;
>> bool do_read = false;
>> bool do_write = false;
>> bool do_register = false;
>> bool do_unregister = false;
>> - bool do_mount = false;
>> - bool do_unmount = false;
>> bool do_dump = false;
>>
>> if (argc < 2) {
>> @@ -112,12 +104,6 @@ static int rtems_bdpart_shell_main( int argc, char
>> **argv)
>> } else if (strcmp( argv [2], "unregister") == 0) {
>> do_read = true;
>> do_unregister = true;
>> -} else if (strcmp( argv [2], "mount") == 0) {
>> - do_read = true;
>> - do_mount = true;
>> -} else if (strcmp( argv [2], "unmount") == 0) {
>> - do_read = true;
>> - do_unmount = true;
>> } else {
>> RTEMS_BDPART_SHELL_ERROR( "unexpected option: %s", argv [2]);
>> }
>> @@ -250,18 +236,6 @@ static int rtems_bdpart_shell_main( int argc, char
>> **argv)
>> RTEMS_BDPART_SHELL_ERROR_SC( sc, "cannot unregister partitions of '%s'",
>> disk_name);
>> }
>>
>> - if (do_mount) {
>> -/* Mount partitions */
>> -sc = rtems_bdpart_mount( disk_name, pt, count, mount_base);
>> -RTEMS_BDPART_SHELL_ERROR_SC( sc, "cannot mount partitions of '%s' to
>> '%s'", disk_name, mount_base);
>> - }
>> -
>> - if (do_unmount) {
>> -/* Unmount partitions */
>> -sc = rtems_bdpart_unmount( disk_name, pt, count, mount_base);
>> -RTEMS_BDPART_SHELL_ERROR_SC( sc, "cannot unmount partitions of '%s'",
>> disk_name);
>> - }
>> -
>> if (do_dump) {
>> /* Dump partitions */
>> rtems_bdpart_dump( pt, count);
>> diff --git a/spec/build/cpukit/librtemscpu.yml
>> b/spec/build/cpukit/librtemscpu.yml
>> index fe440de738..d039bd6267 100644
>> --- a/spec/build/cpukit/librtemscpu.yml
>> +++ b/spec/build/cpukit/librtemscpu.yml
>> @@ -539,7 +539,6 @@ source:
>> - cpukit/libblock/src/bdbuf.c
>> - cpukit/libblock/src/bdpart-create.c
>> - cpukit/libblock/src/bdpart-dump.c
>> -- cpukit/libblock/src/bdpart-mount.c
>> - cpukit/libblock/src/bdpart-read.c
>> - cpukit/libblock/src/bdpart-register.c
>> - cpukit/libblock/src/bdpart-sort.c
>> --
>> 2.26.2
>>
>> ___
>> 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
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.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] rtems: Generate
I have a minor issue with the ordering. *I haven't looked too much through earlier documents.* I don't think this has anything to do with Sebastians work, but I think it is odd that "close" comes before directives like "I/O control" (or whatever it's called) that need to be invoked when the interface is open. If the ordering is intended to correspond to normal usage, as I think Joel said, this is wrong and "close" should be at the end. If that's how the current documentation is structured we should stick with it and change it later. > On Oct 8, 2020, at 02:18 , Sebastian Huber > wrote: > > On 07/10/2020 21:12, Gedare Bloom wrote: > >> On Wed, Oct 7, 2020 at 11:40 AM Sebastian Huber >> wrote: >>> On 07/10/2020 17:26, Gedare Bloom wrote: >>> >>>> Thinking about the discussion about ordering directives in the docs, >>>> the generated header reorders directives also. Is it also doing >>>> generation by alphabetical order? >>>> >>>> Should we consider using the same order as defined for the API >>>> documentation? I guess this would make the Doxygen consistently >>>> ordered wrt the docs. >>> This would make things a lot more complicated. For the Doxygen we have >>> to take also the C language into account. For example before you use a >>> type, it must be declared. This is done through automatic dependency >>> tracking and a topological sorting. Adding a manual order into this >>> stuff would be difficult. >> Yeah, maybe. The value of ordering in the headers and doxygen is >> probably less than in a manual. We can revisit later if we like. It >> shouldn't be too hard in an API header (as opposed to an >> implementation header with inlines) to group first the typedefs and >> then the function declarations. But I have no real concern about the >> ordering here, it was just a thought. > > Good, I added a ticket for this: > > https://devel.rtems.org/ticket/4134#ticket > > It is not on my high priority list. > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Legacy networking stack removal
> On Oct 7, 2020, at 01:43 , Sebastian Huber > wrote: > > On 07/10/2020 02:07, Chris Johns wrote: > >> On 7/10/20 10:21 am, Joel Sherrill wrote: >>> On Tue, Oct 6, 2020, 6:16 PM Chris Johns >> <mailto:chr...@rtems.org>> wrote: >>> >>> What is the life span of the legacy stack in rtems.git? I see this >>> software as a >>> liability. >>> >>> I'd love it to be a sliver over autoconf. >> Sounds like a plan. I have created a task against the 6.1 milestone: >> >> https://devel.rtems.org/ticket/4126 >> >>> I think it is hard to actively encourage our users to use libbsd if we >>> have an >>> enable or waf equivalent at hand in rtems.git. >>> >>> I'd love it to go in its own separate repo. Is that at all possible? What's >>> required? >> I suggest we move it to a top level repo with the network demo code and then >> see >> what happens. In theory it should be easy to build with rtems_waf. >> >> The remaining fragments of code can be removed from the BSP files and maybe >> moved to a header file in the new repo once we have made the split. >> >> The change will break existing users but I think we need to make the change. >> Users who still depend on this stack need to either post here and make us >> aware, >> post fixes or directly contact you, me or others for support options. > Maintaining or removing the old network stack is both fine for me. Moving the > stuff out of the RTEMS repository is a bit of work. > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel The footprint is larger. I forget exactly which board I was evaluating but I couldn't always use the "libbsd" stack and made it conditional. I didn't spend much time trying to reduce the footprint. Maybe if I'd removed some of the shell commands it would have been smaller. An alternative is "lwIP". I don't have experience with that. Maybe "lwIP" and "libbsd" should be the recommended solutions. 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Purpose of rtems_device_driver?
I wasn't thinking about user code, I was thinking about the RTEMS source code
and that the construct should go away. The typedef should be gotten rid of in a
way that supports user code for a release or so.
> On Sep 29, 2020, at 15:34 , Joel Sherrill wrote:
>
> I'm not disagreeing with you at all Peter. This is definitely history and a
> "grep -r _routine | grep typedef" will show a few other cases where this
> pattern still exists. In at least one, it is internal and deprecated.
>
> You are right. This is from the earliest days of RTEMS. I looked in the
> scanned RTEID and ORKID documents and can't fine the IO manager. I swear it
> came from there but I did find a pSOS+ manual online and their interface was
> so bare, it did not use any typedef at all. It even mentioned CPU
> architecture specific differences.
>
> If we want to deprecate it, I'm ok with that. But we should put all of these
> kind of typedefs. on the way to the dustbin.
>
> It is definitely used enough where eliminating it will take scripting.
>
> grep -r "rtems_device_driver " . 2>/dev/null | wc -l
> 710
>
> That doesn't count timer_service_routine, the one for signals, etc.
>
> I'm not opposed and now is the time if there is consensus. I have reached the
> point where I acknowledge the long history and mostly am concerned about how
> changes impact user code more than the idea of change itself.
>
> --joel
>
> On Tue, Sep 29, 2020 at 1:01 PM Peter Dufault wrote:
>
>
> > On Sep 29, 2020, at 10:13 , Joel Sherrill wrote:
> >
> >
> >
> > On Tue, Sep 29, 2020 at 8:54 AM Sebastian Huber
> > wrote:
> > On 29/09/2020 15:47, Sebastian Huber wrote:
> >
> > > On 29/09/2020 15:42, Joel Sherrill wrote:
> > >
> > >>
> > >>
> > >> On Tue, Sep 29, 2020 at 8:37 AM Sebastian Huber
> > >> > >> <mailto:sebastian.hu...@embedded-brains.de>> wrote:
> > >>
> > >> Hello,
> > >>
> > >> I work currently on the documentation of the IO Manager. What is the
> > >> purpose of
> > >>
> > >> typedef rtems_status_code rtems_device_driver;
> > >>
> > >> ?
> > >>
> > >> For me this looks a bit like camouflage.
> > >>
> > >>
> > >> No. It is a use of typedef to make the purpose of the method clear.
> > >>
> > >> You have nibbled at these for years. There were at least types for
> > >> Classic Tasks, ASRs, and TSRs at one point.
> > > Yes, the typedefs to void.
> > >>
> > >> If this is the last one, I'm not going to fight it. This isn't the
> > >> hill I am
> > >> going to die on.
> > > I am not suggesting to remove them although I find these typedefs
> > > pretty odd. I just look for some documentation text.
> >
> > What about this:
> >
> > /**
> > * @ingroup RTEMSAPIClassicIO
> > *
> > * @brief This type shall be used in device driver entry declarations and
> > * definitions.
> > *
> > * Device driver entries return an #rtems_status_code status code. This
> > type
> > * definition helps to document device driver entries in the source code.
> > */
> > typedef rtems_status_code rtems_device_driver;
> >
> > That's more than sufficient.
> >
> > Thanks.
>
> This typedef is odd. Unless I'm missing a fine-point.
>
> If the typedef is, and always will remain, "rtems_status_code" I would not
> use a typedef.
>
> The RTEMS API documentation is moving to Doxygen (and more formally than that
> given Sebastian's ESA work). Using a typedef to indicate a function is part
> of a device driver as "documentation" is not a good idea.
>
> When I've thought I needed a special return code in the past I've made the
> return code a "struct" so that it can't be used interchangeably with other
> return codes, even with casting, and so that you need to be *sure* you really
> want such a special return type. This probably pre-dates enabling aggressive
> warnings.
>
> I haven't done this recently. Recently I've assumed that:
> - Status codes are an integral type;
> - Status codes of 0 always mean success.
>
> Trying to pretend you need to compare a return to a special "success" #define
> that is 0 is pointless and error prone now-a-days IMHO.
>
> If I really wanted a return code that was special I'd do something like:
>
> typedef struct {
> rtems_status_code status; /* Error return. */
> int unused; /* Unused */
> } rtems_device_driver;
>
> 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.
>
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.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Purpose of rtems_device_driver?
> On Sep 29, 2020, at 10:13 , Joel Sherrill wrote:
>
>
>
> On Tue, Sep 29, 2020 at 8:54 AM Sebastian Huber
> wrote:
> On 29/09/2020 15:47, Sebastian Huber wrote:
>
> > On 29/09/2020 15:42, Joel Sherrill wrote:
> >
> >>
> >>
> >> On Tue, Sep 29, 2020 at 8:37 AM Sebastian Huber
> >> >> <mailto:sebastian.hu...@embedded-brains.de>> wrote:
> >>
> >> Hello,
> >>
> >> I work currently on the documentation of the IO Manager. What is the
> >> purpose of
> >>
> >> typedef rtems_status_code rtems_device_driver;
> >>
> >> ?
> >>
> >> For me this looks a bit like camouflage.
> >>
> >>
> >> No. It is a use of typedef to make the purpose of the method clear.
> >>
> >> You have nibbled at these for years. There were at least types for
> >> Classic Tasks, ASRs, and TSRs at one point.
> > Yes, the typedefs to void.
> >>
> >> If this is the last one, I'm not going to fight it. This isn't the
> >> hill I am
> >> going to die on.
> > I am not suggesting to remove them although I find these typedefs
> > pretty odd. I just look for some documentation text.
>
> What about this:
>
> /**
> * @ingroup RTEMSAPIClassicIO
> *
> * @brief This type shall be used in device driver entry declarations and
> * definitions.
> *
> * Device driver entries return an #rtems_status_code status code. This
> type
> * definition helps to document device driver entries in the source code.
> */
> typedef rtems_status_code rtems_device_driver;
>
> That's more than sufficient.
>
> Thanks.
This typedef is odd. Unless I'm missing a fine-point.
If the typedef is, and always will remain, "rtems_status_code" I would not use
a typedef.
The RTEMS API documentation is moving to Doxygen (and more formally than that
given Sebastian's ESA work). Using a typedef to indicate a function is part of
a device driver as "documentation" is not a good idea.
When I've thought I needed a special return code in the past I've made the
return code a "struct" so that it can't be used interchangeably with other
return codes, even with casting, and so that you need to be *sure* you really
want such a special return type. This probably pre-dates enabling aggressive
warnings.
I haven't done this recently. Recently I've assumed that:
- Status codes are an integral type;
- Status codes of 0 always mean success.
Trying to pretend you need to compare a return to a special "success" #define
that is 0 is pointless and error prone now-a-days IMHO.
If I really wanted a return code that was special I'd do something like:
typedef struct {
rtems_status_code status; /* Error return. */
int unused; /* Unused */
} rtems_device_driver;
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.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
I think that stating that "Due to a shared address space" RTEMS can't generate a "core dump" is wrong. For example, when a thread de-references a NULL pointer the rest of the application will be intact enough to create a "core dump". In general, when you're developing an application I don't think you want a "core dump", you want to have a debugger attached. In the field, if your multi-threaded application is functional and has a place to store a "core dump", I think it would be great to do so if possible. > On Sep 15, 2020, at 12:03 , Joel Sherrill wrote: > > > > On Tue, Sep 15, 2020 at 10:26 AM Gedare Bloom wrote: > No, there is no facility to generate a core dump. Due to shared > address space, once there is a fatal error you can't really trust > anything running in the target. You wouldn't necessarily want to try > writing to a mounted filesystem. > > You could probably set up a debugger to do something like this by > triggering it in the fatal exception handler. You'd need to make use > of whatever the debugger can do already though. You really can't rely > on the executing target. > > On the more popular architectures, if you get an exception, the BSP > will print out a lot of information. Included in that is usually the address > of the fault and register set. You can use the symbol table (from nm) > or addr2line to map that back to source code. Look at the generated > assembly and you can often tell what went wrong. > > Better is to attach a debugger and set a breakpoint on the exception > handler address and then poke around to see more details. > > --joel > > Gedare > > On Tue, Sep 15, 2020 at 4:58 AM small...@aliyun.com > wrote: > > > > I am developing applications in rtems 5.1. As we know, my application and > > rtems kernel are both in the same address space. > > So if my application access an invalid address or encounter other fatal > > errors, I want the kernel not just being hunging, but create a core dump > > file. > > This file contains the whole contents of memory and I could use a debuger > > to analyse the file to handle the bug. > > The question arise because I do not want always debug rtems in the bsp. > > > > > > small...@aliyun.com > > ___ > > 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 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. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New coding style for new files?
> On Sep 11, 2020, at 13:43 , Joel Sherrill wrote:
>
> https://ftp.rtems.org/pub/rtems/people/amar/files/rtems.uncrustify
>
I've been using "uncrustify" for a long time. There are regular updates and
quick responses for clearly reported issues.
The formatting specification is complicated, but that goes along with being so
configurable. There are formatting specification GUIs and helpers that I
haven't used to assist with the generation of the formatting spec. See the
bottom of the main "github" page for "uncrustify".
Joel, when you were working with me the source code reformatting script we were
using used "uncrustify" as the main reformatting engine.
I can not help with this much. However, if I had time to do it, I think I'd do
it this way:
- Choose files that the RTEMS community RTEMS agrees are perfect examples of
RTEMS coding as reference sources. There should be a few and some should be
large.
- The "uncrustify" source includes sample configurations in its source code
"/etc" directory. Use a subset of the sample configurations to reformat the
RTEMS reference sources. For example, reformat to match FreeBSD, Linux kernel,
K&R, etc coding styles and store them as test input files.
- Run "uncrustify" with a proposed RTEMS configuration file on the hacked
reference files and then "diff" them with the original.
Ideally you would wind up with an RTEMS configuration with no diffs regardless
of how you reformatted the input.
I know this would use the same tool that is being tested to create the input
test files, but I think in this case it's OK due to how invasively "uncrustify"
can be configured to reformat the code. For example, it can probably strip "{"
"}" on single lines in a conditional.
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.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Applying an operation to a set of threads in RTEMS
This thought is intended to be evaluated, not adopted. What I meant was I think you have a "bitmask" of threads that need access to a stack that is similar to a "bitmask" of threads/processes that may be blocked in select. The select-mask is a major focus across operating systems. That's why I thought that if you consider it to be equivalent you should use that interface. > On Jul 3, 2020, at 08:42 , dufa...@hda.com wrote: > > My thought is that it matches what is needed and is expected to be optimized. > >> On Jul 3, 2020, at 24:37 , Utkarsh Rai wrote: >> >> >> >> On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault wrote: >> I finally have gotten to reviewing Utkarsh's work in GSOC. One item that I >> don't like is that there is a linked list management of the threads that >> have access to the stack. >> I think this access is similar to the file descriptors that are blocked in a >> select call. On a given architecture I don't know exactly how many file >> descriptors I can block, I don't know exactly what the FD_SET macro does, >> but I have access to multiple file descriptors through the FD_* macros. >> >> >> Hello, thank you for the feedback. If I understand your suggestion >> correctly, we can specify a file descriptor set 'fd_set' and then register >> the stack attributes to this set, and then check for the 'current stack' >> through select() and FD_ISSET()? >> >> Using FD_SET and friends for specifying thread access could be a good model >> to specify which threads need access to which thread. >> >> My question is, what benefit do we get by using FD_SET and friends? >> Ultimately we will have to iterate through the set to check for the 'current >> stack'. >> >> However, it won't scale infinitely. Linked lists won't scale infinitely in >> real-time either. >> >> An optimization that I had in mind was to use the LRU model. This way we can >> mark the stack attributes of the last thread as 'not current' without >> iterating through the list or the set. >> >> 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. >> > > 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 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
Re: Applying an operation to a set of threads in RTEMS
My thought is that it matches what is needed and is expected to be optimized. > On Jul 3, 2020, at 24:37 , Utkarsh Rai wrote: > > > > On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault wrote: > I finally have gotten to reviewing Utkarsh's work in GSOC. One item that I > don't like is that there is a linked list management of the threads that have > access to the stack. > I think this access is similar to the file descriptors that are blocked in a > select call. On a given architecture I don't know exactly how many file > descriptors I can block, I don't know exactly what the FD_SET macro does, but > I have access to multiple file descriptors through the FD_* macros. > > > Hello, thank you for the feedback. If I understand your suggestion correctly, > we can specify a file descriptor set 'fd_set' and then register the stack > attributes to this set, and then check for the 'current stack' through > select() and FD_ISSET()? > > Using FD_SET and friends for specifying thread access could be a good model > to specify which threads need access to which thread. > > My question is, what benefit do we get by using FD_SET and friends? > Ultimately we will have to iterate through the set to check for the 'current > stack'. > > However, it won't scale infinitely. Linked lists won't scale infinitely in > real-time either. > > An optimization that I had in mind was to use the LRU model. This way we can > mark the stack attributes of the last thread as 'not current' without > iterating through the list or the set. > > 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. > 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
Applying an operation to a set of threads in RTEMS
I finally have gotten to reviewing Utkarsh's work in GSOC. One item that I don't like is that there is a linked list management of the threads that have access to the stack. I think this access is similar to the file descriptors that are blocked in a select call. On a given architecture I don't know exactly how many file descriptors I can block, I don't know exactly what the FD_SET macro does, but I have access to multiple file descriptors through the FD_* macros. Using FD_SET and friends for specifying thread access could be a good model to specify which threads need access to which thread. However, it won't scale infinitely. Linked lists won't scale infinitely in real-time either. 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
