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
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_base)); > > I "#ifdef'd" them out to
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
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__); } while (0)
>>
>> #def
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)
>>> {
>>> - int msec = timeout;
>&g
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, [0], 1) == 1) {
>> - fflush(stdout);
>> +ssize_t n;
>> +if ((n = read(fd, [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)
>> {
>> - int msec = timeout;
>> int i = 0;
>> int e = 0;
>> memset([0], 0, size);
>>
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)
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", )) {
>> 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
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
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: [PATCH 2/2] score: Simplify thread queue timeout handling
+ true
> );
> _Thread_queue_Context_set_ISR_level( _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( );
> -end = _Watchdog_Future_timespec( , timeout );
> _Thread_queue_Context_set_enqueue_timeout_monotonic_timespec(
> _context,
> - end
> + timeout,
> + false
> );
> } else {
> _Thread_queue_Context_set_enqueue_do_nothing_extra( _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(
> _context,
> - abstime
> + abstime,
> + true
> );
> _Mutex_Acquire_slow( mutex, owner, executing, level, _context );
>
> @@ -327,7 +328,8 @@ int _Mutex_recursive_Acquire_timed(
> } else {
> _Thread_queue_Context_set_enqueue_timeout_realtime_timespec(
> _context,
> - abstime
> + abstime,
> + true
> );
> _Mutex_Acquire_slow( >Mutex, owner, executing, level,
> _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( , 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
RTEMS source builder: can't find RTEMS include files but then can?
/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 [ 92%] Building C object CMakeFiles/soem.dir/oshw/rtems/oshw.c.obj [100%] Linking C static library libsoem.a [100%] Built target soem ==> %install: (...) - 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
[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
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?
e 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
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 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()
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
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
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
/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?
> 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, 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
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
Re: Discussion regarding high-level interface for GSoC memory protection project.
> On Mar 27, 2020, at 14:16 , Utkarsh Rai wrote: > > > On Fri, Mar 27, 2020 at 9:31 PM Gedare Bloom wrote: > Hi Utkarsh, > > You can remove "Discussion regarding" from your subject lines. We know > your emails are discussions regarding the subject. > > On Fri, Mar 27, 2020 at 5:26 AM Utkarsh Rai wrote: > > > > Hi, > > My GSoC project proposal intended for providing thread-stack protection > > involves implementation on two levels, providing low-level hardware support > > for the target architecture and high-level architecture-independent APIs. > > As @Peter Dufault pointed to me in my draft the POSIX compliant way of > > doing it would be through mmap, I would request your feedback on the > > details of the high-level implementation of thread-stack protection. > > My idea is to obtain the stack attributes of the thread that is to be > > mapped by pthread_attr_getstack() and then get a file descriptor of the > > memory using posix_typed_mem_open() and finally mmap that to the stack of > > the required thread(With the specified permissions). > > Is this is a valid approach? If yes, I believe I would have to add the > > implementation of posix_typed_mem_open() to my work plan as RTEMS > > does not support it as of now. > > > > That's an interesting proposition. I guess you are suggesting to make > thread stacks be "typed memory objects"? I don't know the > ramifications of that, but it sounds like a really deep design and > implementation challenge. It's not clear to me that "typed_mem_open" > is proper to call on an existing typed object, but I'm not that > familiar with the TYM interface. It could be something worth fleshing > out though as a summer implementation project if there is plenty of > work to do. It could be something for extension activities. > > I think however you could instead use shared memory objects, which > already have some (limited) support, to accomplish the same ideas. You > could give each thread's stack a "named" object in some filesystem, > and other threads could shm_open() and mmap() the stack. I think that > is the right way to go at least based on where we are in RTEMS now. > > You should also know and understand that the mmap() interface in RTEMS > is quite shallow and restricted in its support. For file objects it > basically only works to provide a copy of the file, because it works > by copying the memory from the file to the destination. For shared > memory objects it can provide rw access between two threads, but can't > restrict access since we lack general protection mechanisms. If two > threads want to share writeable stack regions then the current support > could work, perhaps by using shared memory objects to set up the > thread stacks. But two threads can't share read-only stack regions > with the current implementation. That would be part of your work to > figure out, in addition to perhaps improving and fixing up the > existing mmap/shm support. > > I had looked into that and therefore initially proposed a separate > 'mem_share()' interface, but as was pointed out, it was not POSIX compliant. > So I guess, adding on to the existing mmap/shm support is the best way to > move forward. > > Step back a minute and think about the requirements before you. > Threads have stacks already. Sometimes they share them with each > other. Now you want to isolate each thread's stack from other threads. > But if they still want to share, then you should allow it. How? > > The suggestion is to allow threads to use mmap() to map other threads' > stacks. Some questions for you to ponder: Since those stacks exist and > have an address already, can you just fiddle with the protection > regions and return a pointer directly to the stack to allow r/w access > with sharing? > I guess if a thread makes explicit calls to mmap for stack sharing and the > access to other stacks is not granted, this can be implemented(At the > hardware level it would mean that the page table attributes would be updated > for the thread-stack that is to be mapped). > What are the limitations on the solution (based on the > number of protection regions supported in hardware)? > As was mentioned in a separate thread we would have to go with the common > minimum hardware support to support maximum targets. > Gedare > > > Regards, > > Utkarsh Rai. > > __ My rationale for suggesting Utkarsh examine the typed memory object interface, after five minutes of in-depth analysis, was that you could immediately get into the code specific to memory mapping stacks as the file descriptor would
Issues when adding a multi-port PCI serial card
I've added an 8-port RS232 PCI Mezzanine Card to the "beatnik" BSP. The
console (aka serial port) code is confusing.
I decided I should use what is in "bsp/console-termios.h" as opposed to the
"legacy console" approach, *even though* "legacy console" is used in many
recent BSPS.
* Is that correct?
That approach went well, I created a replacement shared PowerPC console in
"bsps/powerpc/shared/console/console-config.c" with only 129 lines of code and
half of it comments.
Where does the driver go: Next I had to add the PCI multi-port serial card
driver. I put it in "bsps/shared/dev/pci/mp_serial.c". The other directory
choice was "bsps/shared/dev/serial". I didn't like either, the "dev/pci" is
very associated with PCI discovery and the "dev/serial" is very associated with
the generic low-level serial driver support, even thought it has the
"legacy-console" cruft in it.
* Where should it go?
Difficulty in assigning common TTY names: Since my new shared PowerPC
"console-config.c" created "/dev/ttyS0" and "/dev/ttyS1" I wanted to name the
new serial devices with a number that started at 2, i.e., "/dev/ttyS2".
* Is there a way in the "console-termios" framework to know what the highest
"minor number" for a serial port is? I searched, gave up, and made it a
configuration item.
Next I had to figure out the best way to probe and discover the board.
* I wanted to add an RTEMS_SYSINIT_ITEM that would call a probe routine to
discover the multiport cards at the appropriate time, after "/dev/console" was
discovered but before I wanted to spawn my shell. I had trouble figuring out
what level and order I should use for the probe routine. I never got this
working, my probe routine kept getting called much later then I expected it to.
I need a pointer to the documentation to RTEMS_SYSINIT_ITEM ordering.
Finally, after initial successful loop-back testing, I tried to start an RTEMS
shell on one of the new ports.
*Here I'm trying hard to avoid all-caps because this took the most time of all
(it should have been easiest), and I gave up!*
* HOW (sorry) do you spawn a shell on a serial port? The documentation, at
https://docs.rtems.org/branches/master/shell/configuration_and_init.html that
suggests just setting the shell device name to "/dev/console", or in my case
"/dev/ttyS9", is incorrect. The shell startup is intent on using "stdin" and
"stdout".
~
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] bsps/shared/grlib/1553/b1553brm.c : addressed logic issue and unsigned_compare
And regardless of the value of count it is successful?
> On Feb 28, 2020, at 12:17 , suyash singh wrote:
>
> count is unsigned int and will always be >=0.
>
> On Fri, Feb 28, 2020 at 10:42 PM suyash singh
> wrote:
> ---
> bsps/shared/grlib/1553/b1553brm.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/bsps/shared/grlib/1553/b1553brm.c
> b/bsps/shared/grlib/1553/b1553brm.c
> index 57ef70126b..4041423541 100644
> --- a/bsps/shared/grlib/1553/b1553brm.c
> +++ b/bsps/shared/grlib/1553/b1553brm.c
> @@ -982,10 +982,8 @@ static rtems_device_driver
> brm_write(rtems_device_major_number major, rtems_devi
>
> rw_args->bytes_moved = count;
>
> - if (count >= 0) {
> - return RTEMS_SUCCESSFUL;
> - }
> - return RTEMS_UNSATISFIED;
> + return RTEMS_SUCCESSFUL;
> +
> }
>
> static rtems_device_driver brm_control(rtems_device_major_number major,
> rtems_device_minor_number minor, void *arg)
> --
> 2.17.1
>
> ___
> 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
pkg-config RTEMS BSP files in master branch cause me problems
The files that get installed (for example as "lib/pkgconfig/arm-rtems5-xilinx_zynq_a9_qemu.pc") are making my life difficult in that they add compile and link flags that are difficult to over-ride and I need to in some situations. It states clearly in the file "Warning: This stuff is experimental and may be changed at any time". Am I missing instructions on how to avoid using it in the first place, or how to over-ride it in certain situations? 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: GSOC: Call for Mentors
> On Feb 17, 2020, at 14:58 , Gedare Bloom wrote: > > Assuming we get accepted on 2/20, I will be able to start adding mentors > shortly after. Please let me know if you're interested to mentor this summer, > either in a primary or co-mentor capacity. As usual, I will provide "backup" > mentoring and high-level organization of all projects with weekly contact to > each student. Primary mentors are responsible for multiple interactions per > week (daily is best) with their student and providing strong technical > guidance. Co-mentors should stay in the loop, and possibly step in if the > primary mentor needs a break or other emergency comes up. > > Gedare > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel I will definitely co-mentor thread stack protection, I'm very interested in this. I can't be a mentor due to my current work load. 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: rtems.git force push pending
> On Feb 13, 2020, at 11:55 , Gedare Bloom wrote: > > Hello everyone, > > Due to some unfortunate mishap, the rtems.git repository needs to be > rolled back. Anyone who pulled/cloned it since February 12 will be > impacted, and probably need to re-clone. Most likely, this is going to > involve a forced push back to commit > d252e20ab5717afea2ac89543ab4e0d379434bb0 Can you explain this to those of us who are part-time git users? I pulled during this time frame, so I must "re-clone" or do a "forced push back". I assume "re-clone" means I "rm -rf" a local repository and, well, "re-clone". I will need to google to see what a "forced push back" is. What was the "unfortunate mishap"? If I were knowledgeable would I know immediately without asking? 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
Beginning work on BSP for i.MX RT 10xx (1052 specifically)
I will begin working on a BSP for the i.MX RT 10xx family. I require support for a 1052 but will be developing on a 1064 so those two variants will have some test coverage. I plan to start my work by making this a variant of the "imx" BSP. That currently supports the "i.MX7D Applications Processor". I think that the network support provided by the "libbsd" "if_ffec" driver will work with the ENET interface on the i.MX RT. I think that initial support will be a straight-forward collection of already working pieces. - If anyone has any warnings or "heads-up"s then let me know. - I haven't been working with "device trees". These are required for the "imx" BSP. Is this the preferred direction for a BSP? - If anyone has any suggestions for how to ultimately arrange things then let me know. Right now, before I've gotten started, I plan to make this BSP a variant in the "imx" BSP and to try to either re-use existing "chip" library routines or add new ones. Unfortunately this will definitely be a BSP supporting only what I need for the current application. 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
Need to disable "atsamv" watchdog to avoid reset
I noticed this while tracking down the GMAC transmit initialization on non-revA SAMV71 chips and wanted to send it as heads-up and to see if anyone understands what's happening. If I left the board doing nothing then after about fifteen or twenty minutes (I never characterized it) I would see "External reset detected" in the "ocd-remote" window and the program would restart. I put breakpoints in the RTEMS fatal exit and it was never called, so I suspected a watch-dog timer reset. I checked the RTEMS code and couldn't see anywhere the watch-dog was programmed. I checked on-line: "The Watchdog Timer (WDT) is used to prevent system lock-up if the software becomes trapped in a deadlock. It features a 12-bit down counter that allows a watchdog period of up to 16 seconds (slow the clock to around 32kHz). It can generate a general reset or a processor reset only. In addition, it can be stopped while the processor is in debug mode or idle mode. "After a processor reset, the Watchdog peripheral is enabled by default with the value of watchdog counter value equal to 0xFFF, which corresponds to the maximum value of the counter with the external reset generation enabled (bit WDT_MR.WDRSTEN at 1 after a backup reset). The user can either disable the WDT by setting bit WDT_MR.WDDIS or reprogram the WDT to meet the maximum watchdog period the application requires." This implies the board will get an external reset after sixteen seconds, not fifteen or twenty minutes, if the behavior isn't changed, but I added a "WDT_Disable(WDT);" to my code anyway and that solved the problem. I posted this to give anyone else a heads-up and also to find out if anyone understood why it would take so long for the WDT to kick in. 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
Porting RTEMS to NXP i.MX RT1020
I'm evaluating porting RTEMS to the NXP i.MX RT1020. What will take me the longest is if the ethernet peripheral isn't supported. It's referred to as the "10/100-Mbps Ethernet MAC (ENET)" and the "MAC-NET" core. The "MAC-NET" core appears to be ethernet IP going back a while. Is this interface supported by RTEMS already? I don't think so. Is it supported on FreeBSD? I wasn't successful in figuring that out, but searching for "mac-net" is problematical, "mac" has multiple hits related to networking. 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
"atsamv" BSP legacy network driver status
The "rtems-libbsd" "if_atsam.c" driver is derived from the legacy one. What's
the status of the two drivers? I ask because I'm trying to do some small
memory testing with the legacy stack on the . It is building but not working,
I don't think network packets are going out even though the build is definitely
receiving broadcast packets because I see the number of incoming receive
interrupts increasing.
My first attempts crashed because the attach function unconditionally
de-referenced "config->hardware_address", most legacy drivers conditionalize
the de-reference. I modified the driver to do something similar to what the
"libbsd" driver does.
After that everything appears to work except networking isn't working. I put
the system on its own little section of a managed switch and I don't see any
packet activity. The app is running a shell with "netstat" and I can see the
count of receive interrupts going up.
Before I go much further I have a few questions.
- What's the usage of the "atsamv" driver? I know there are issues associated
with the external SRAM, clock speeds, and maybe clock references. But is the
legacy driver used, only the "libbsd" driver used, or neither?
Thanks -
Peter
The diffs I made to the driver are:
diff --git a/bsps/arm/atsam/net/if_atsam.c b/bsps/arm/atsam/net/if_atsam.c
index 9665aa1..5c84cdc 100644
--- a/bsps/arm/atsam/net/if_atsam.c
+++ b/bsps/arm/atsam/net/if_atsam.c
@@ -1181,6 +1181,10 @@ static int if_atsam_driver_attach(struct
rtems_bsdnet_ifconfig *config)
const if_atsam_config *conf = config->drv_ctrl;
int unitNumber;
char *unitName;
+/* This is sort of what the libbsd library does for the lack of a MAC
address.
+ * except the final byte is 0x11 + unit.
+ */
+static const uint8_t mac_addr[] = { 0x0e, 0xb0, 0xba, 0x5e, 0xba, 0x11 /*
+ unit */ };
if (conf != NULL) {
sc->Gmac_inst.retries = conf->mdio_retries;
@@ -1191,7 +1195,11 @@ static int if_atsam_driver_attach(struct
rtems_bsdnet_ifconfig *config)
}
/* The MAC address used */
- memcpy(sc->GMacAddress, config->hardware_address, ETHER_ADDR_LEN);
+if (config->hardware_address) {
+memcpy(sc->GMacAddress, config->hardware_address, ETHER_ADDR_LEN);
+} else {
+memcpy(sc->GMacAddress, mac_addr, ETHER_ADDR_LEN);
+}
memcpy(sc->arpcom.ac_enaddr, sc->GMacAddress, ETHER_ADDR_LEN);
/*
*** Configuration command is:
../rtems/configure \
--target=arm-rtems5 \
--enable-rtemsbsp=atsamv \
--prefix=/opt/customer/rtems-5/ \
--enable-networking \
--enable-posix \
--disable-smp \
--disable-multiprocessing \
--enable-tests \
--enable-cxx \
--enable-maintainer-mode
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
How does the dynamic loader (libdl) hook in to gdb?
I'm trying to hook the SLAC / Til Straumann PowerPC remote debugger stub in to what's loaded by "libdl" via "dlopen()". *I know* this should be integrated into "libdebugger", and I do keep my eye on that, but I need to keep what is working working and working well. The "libdl" code has support for GDB both finding out when shared libraries are loaded and resolving the new symbols in "rtl-debugger.c". It's based on NetBSD and Android. I don't know how to get this code to kick in. I hacked the "libdl" "rtl" command to add an option for "rtl list -m", an option that is "rtl list -gm" (Run time loader list a map in a GDB flavor) so that after I load a library such as "loaded_lib" the command will produce something like: add-symbol-file loaded_lib -s .text 0x12c0708 -s .rodata 0x12cbb88 -s .data 0x12ce910 -s .bss 0x12cea18 After pasting the output of the "rtl list -gm" command into GDB everything works wonderfully. There are no remote-stub commands that support this, as far as I can tell, and I want to figure out how to do this based on the existing remote-stub interface. Editorial note: If I can do it with "add-symbol-file" I should be able to do it from the remote interface, but so it goes. My question is: How, without modifying GDB, can I add a symbol table after loading something via "dlopen()"? The interface in "rtl-debugger.c" imply that GDB will poke around and set breakpoints based on a SVR4 dynamic loader in order to locate the information, but I can't figure out how to do 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
What do you want to study in GSOC 2020?
Niteesh, what do you want to study? Go over what most interests you most about
working in a real-time environment like RTEMS, and not about working on the
RPI, and look at the earlier GSOC projects. Propose an ideal project for
yourself and get some feedback.
> On Dec 28, 2019, at 05:12 , Christian Mauderer wrote:
>
> On 28/12/2019 07:12, Niteesh wrote:
>>
>>
>> On Sat, 28 Dec, 2019, 3:51 AM Christian Mauderer, > <mailto:l...@c-mauderer.de>> wrote:
>>
>>On 27/12/2019 19:06, Niteesh wrote:
>>> Is there something else that I could work on? I am interested in
>>taking
>>> part
>>> GSOC of 2020. And I want to learn as much as possible.
>>
>>Do you search tasks specific to raspberry or general ones? Do you search
>>something for GSoC or just to warm up?
>>
>> Anything is fine as long as I am learning something. Since rpi3 is the
>> only hardware I have, I am interested in tasks specific to raspi and
>> general ones which do not require any hardware.
>
> For raspberry I think you could continue to get it running on RPi3. My
> suggestion would be to replace the table based initialization (which is
> handled by console-termios-init.c) with one based on the fdt that is
> similar to the one in the imx BSP. That will allow to use the same
> binary on RPi2 and RPi3. But please do that in an extra patch after the
> one that you currently have sent to the mailing list.
>
>
> Some other raspberry specific topics could be the following. Note that
> this are only suggestions. I don't want to force you to do any of them
> if you don't like them:
>
> - Documentation how you run an application in QEMU / on real hardware
> for the user manual:
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#raspberrypi
> (I hope I didn't miss a patch that you already sent ;-) )
>
> - A configuration for RTEMS tester that uses the QEMU or real hardware
> (I think the pi3 allows network boot?). This allows regular test runs
> for this BSP:
> https://docs.rtems.org/branches/master/user/testing/index.html and
> https://docs.rtems.org/branches/master/user/tools/tester.html
>
> - Chris created a boot image generator last year. It would be great if
> you could add a configuration to create raspberry SD images to it:
> https://docs.rtems.org/branches/master/user/tools/boot-image.html
>
> - You can pick basically any component that isn't already there and
> integrate it. If you want to work with libbsd: Testing or porting
> Ethernet support could be something.
>
> - You most likely want to do something with RPi in your GSoC too. So
> maybe some comments ("x is already done", "y seems to be still open")
> for the ticket for it would be nice too: https://devel.rtems.org/ticket/2899
>
>
> For non raspberry topics: We have a lot of open bugs where everyone is
> happy if they are closed: https://devel.rtems.org/query
>
> A lot of them might are even out of date and just need someone who reads
> them and asks whether they can be closed.
>
>>
>>
>>>
>>> On Fri, Dec 27, 2019 at 5:07 PM Christian Mauderer
>>mailto:l...@c-mauderer.de>
>>> <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
>>>
>>> On 27/12/2019 12:20, Niteesh wrote:
>>> > I have sent the patch. I also sent a documentation update
>>for the
>>> > quick-start section
>>> > a few months ago. But no one took a look at it. Can you have a
>>> look at it?
>>>
>>> I'll try to have a look at it soon.
>>>
>>> >
>>> > https://www.mail-archive.com/devel@rtems.org/msg20965.html
>>>
>>> If you don't get any responses to a patch please just send a
>>reminder
>>> one or two weeks later. It's quite likely that the patch just
>>slipped
>>> the attention.
>>>
>>> Normally I leave documentation patches to our native speakers.
>>They spot
>>> a lot of errors that I won't be able to find.
>>>
>>> Can you please send a ping for the patch. You can add me to CC
>>and for
>>> this one I would suggest to CC Chris Johns too.
>>>
>>
> ___
> 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: New Build System Status
> On Nov 15, 2019, at 10:05 , Sebastian Huber > wrote: > > Hello, > > I nearly finished the conversion script for the BSPs. I can now configure 194 > BSP variants with the default BSP option values. Some BSPs need modifications > by hand, e.g. linker command files and special boot files. There are now > about 2000 YAML files. It needs about 11 seconds to build the pickle cache > from the YAML files: > > $ time ./waf bsp_list | wc >194 1943238 > > real0m11.324s > user0m11.222s > sys 0m0.075s > > Afterwards it is much faster: > > $ time ./waf bsp_list | wc >194 1943238 > > real0m0.691s > user0m0.622s > sys 0m0.043s > > time ./waf bsp_defaults | wc > 16794 84819 566576 > > real0m1.127s > user0m1.064s > sys 0m0.049s > > I had no time to work on the user documentation. I will be very busy with > other things in the next two or three weeks. > > I made some experiments with the clang compiler and it works in principle. > You can configure the compiler per BSP, e.g. you can build the same BSP with > gcc and clang in one configuration file. For example: > > [sparc/erc32_gcc] > COMPILER = gcc > INHERIT = erc32 > > [sparc/erc32_clang] > COMPILER = clang > INHERIT = erc32 > > -- > Sebastian Huber, embedded brains GmbH > I think clang has support for PowerPC/SPE including a FreeBSD port. I hope to get time to test that, but if anyone else is interested and has time please test out building such a BSP. (PowerPC/SPE is gone in GCC) 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: Adding RTEMS_INTERRUPTED
> On Oct 4, 2019, at 14:04 , Joel Sherrill wrote: > > Hi > > I am now looking at the second phase of processing -C to generate > SIGINTR is > to have read() return -1/EINTR. I want to specifically add this support to > termios > although I think other file types would have to address this independently, > > For termios, we need rtems_deviceio_read() to return -1/EINTR but it returns > -1/errno > based on rtems_status_code from rtems_io_read(). The issue is that we don't > have > anything that maps to EINTR in the rtems_status_code enumeration. > > Is there any objection to adding RTEMS_INTERRUPTED as a status code? > > I am open to suggestions for a better name. > Do you see a use for RTEMS_INTERRUPTED instead of to support EINTR defined behavior? If you don't I'd name it RTEMS_EINTR so that it isn't overloaded. 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
What opens stdout? printf() fails after rtems-tester printf() succeeds.
I've started testing the PowerPC MVME5500 "beatnik" BSP on the mainline. I've
run through the majority of the RTEMS tests, with some failures, but when I
went to run any basic programs they do not produce any output. They are
obviously running, I can put in a "sleep(3)" and observe it, but no output.
I looked at what rtems-tester does and see it wraps "printf()" and friends. I
found that if:
- I add CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION to my
configuration;
- I used "rtems_test_printf()" that output via "rtems_test_printf()" works.
After that I tried this in my _POSIX_Init(), to see if file descriptor 1 was
open:
const char *hello="Hello to FD 1\r\n";
size_t n = strlen(hello);
size_t output;
rtems_test_printf("rtems_test_printf %s: Hello...\n", __func__);
if ( (output = write(1, hello, n)) != n) {
printk("%s: write() returned %d not %d: %s\n", __func__,
(int)output, (int)n, strerror(errno));
}
The output is:
rtems_test_printf _POSIX_Init: Hello...
_POSIX_Init: write() returned -1 not 15: Bad file number
So file descriptor 1 isn't opened. What establishes the standard open file
descriptors that isn't being called in my update?
I *think* I have the GDB stub working, I had to modify it to bring it
up-to-date, but I'd rather see a console message like "GDB stub starting up..."
before I go further.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to
interception and tampering.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
rtems tester: Why does rtems_test_assert() just exit?
Most of the failures I see on “beatnik” are detected by “rtems_test_assert()”. That prints the assertion and calls exit, e.g. on beatnik: ] allocate most of memory - attempt to fail chroot - expect ENOMEM ] ../../../../../../rtems/c/src/../../testsuites/psxtests/psxchroot01/test.c: 126 status == -1 ] fatal source: RTEMS_FATAL_SOURCE_EXIT, error code: 0 ] bsp_fatal_extension(): RTEMS terminated -- no way back to MotLoad so I reset the card ] Printing a stack trace for your convenience :-) The failure is detected by the tester when the test platform requests a “tftp” transfer at an unexpected time: ] Subnet IP Address Mask = 255.255.248.0 ] => tftp: re-requesting exe; target must have reset ] Network File Load in Progress... => target reset condition detected => target reset: ./power-ctl 1 off-on ] Error Status: 0081 - File not found. This takes at least 10 seconds using “motload” and the power switch I’m using. Why doesn’t "rtems_test_assert()” output something that shows the test failed so that the reset can happen then? 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
Where are results of rtems-tester test results archived?
I’ve searched but can’t find anywhere. I’d like to see the results of the tests on all architectures to compare to what I see on PowerPC-beatnik. 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
rtems-tester initial port getting "'NoneType' object is not iterable"
I’m bringing up the rtems-tester for the PowerPC “beatnik” bsp. I’m impressed with how easy it is to implement (well done, Chris). But after doing all the easy work, and just as I thought my initial run of the “samples" was about to exit successfully, the script faulted and gave me the error "TypeError: 'NoneType' object is not iterable”. I’ve pasted the output of my run below. There’s no useful information in the output of the log file. It ends with the summary of what passed, failed, and the time it took, the same as you see below in the pasted output. I looked at the called-out line in the python code. It’s trying to generate reports, I think. Maybe I missed a required configuration step to specify a format that isn’t detected until this happens? - What have I neglected to send? - Anybody seen this? I couldn’t find it via searches. This is the console output from when I ran the test. *Note that “ltimer.exe” is not a real RTEMS sample test, and that’s why it shows up as an invalid result.* [dufault@gen6 lou_files]$ ./my_beatnik.sh RTEMS Testing - Tester, 5 (12bd8f77bad4) [ 1/14] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 W:0 | powerpc/beatnik: base_sp.exe [ 2/14] p:1 f:0 u:0 e:0 I:0 B:0 t:0 i:0 W:0 | powerpc/beatnik: capture.exe [ 3/14] p:1 f:0 u:1 e:0 I:0 B:0 t:0 i:0 W:0 | powerpc/beatnik: cdtest.exe [ 4/14] p:2 f:0 u:1 e:0 I:0 B:0 t:0 i:0 W:0 | powerpc/beatnik: cxx_iostream.exe [ 5/14] p:3 f:0 u:1 e:0 I:0 B:0 t:0 i:0 W:0 | powerpc/beatnik: fileio.exe [ 6/14] p:3 f:0 u:2 e:0 I:0 B:0 t:0 i:0 W:0 | powerpc/beatnik: hello.exe [ 7/14] p:4 f:0 u:2 e:0 I:0 B:0 t:0 i:0 W:0 | powerpc/beatnik: loopback.exe [ 8/14] p:5 f:0 u:2 e:0 I:0 B:0 t:0 i:0 W:0 | powerpc/beatnik: ltimer.exe [ 9/14] p:5 f:0 u:2 e:0 I:0 B:0 t:0 i:1 W:0 | powerpc/beatnik: minimum.exe [10/14] p:6 f:0 u:2 e:0 I:0 B:0 t:0 i:1 W:0 | powerpc/beatnik: nsecs.exe [11/14] p:7 f:0 u:2 e:0 I:0 B:0 t:0 i:1 W:0 | powerpc/beatnik: paranoia.exe [12/14] p:8 f:0 u:2 e:0 I:0 B:0 t:0 i:1 W:0 | powerpc/beatnik: pppd.exe [13/14] p:9 f:0 u:2 e:0 I:0 B:0 t:0 i:1 W:0 | powerpc/beatnik: ticker.exe [14/14] p:10 f:0 u:2 e:0 I:0 B:0 t:0 i:1 W:0 | powerpc/beatnik: unlimited.exe Passed:11 Failed: 0 User Input: 2 Expected Fail: 0 Indeterminate: 0 Benchmark: 0 Timeout:0 Invalid:1 Wrong Version: 0 Wrong Build:0 Wrong Tools:0 - Total: 14 Average test time: 0:00:40.583694 Testing time : 0:09:28.171711 Traceback (most recent call last): File "../rtems-tools/tester/rt/cmd-test.py", line 42, in test.run(sys.argv[1:], command_path = base) File "/home/dufault/development/rtems/rtems-tools/tester/rt/test.py", line 455, in run for report_format in report_formats: TypeError: 'NoneType' object is not iterable [dufault@gen6 lou_files]$ 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: llvm on CentOS 7
> On Sep 16, 2019, at 10:36 , Joel Sherrill wrote:
>
> Hi
>
> Running log as I work through this.
>
> Build failed because I didn't have cmake. Double-checked and sb-check wouldn't
> have reported this. Not sure we should report it missing unless we can
> designate
> something as "needed by some packages" or let folks know which one(s).
>
> Loaded cmake, then got this beauty:
>
> /usr/bin/cmake -Wno-dev -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=Release
> -DCMAKE_INSTALL_PREFIX=/home/joel/rtems-work/tools/5
> '-DPACKAGE_VERSION=8.0.1 (RTEMS 5, RSB
> 4b7af073000d612b21b9dece538d2bcc85c0c240)'
> -DLLDB_CODESIGN_IDENTITY=llvm ../llvm-8.0.1
> -- Configuring incomplete, errors occurred!
> CMake Error at CMakeLists.txt:3 (cmake_minimum_required):
> CMake 3.4.3 or higher is required. You are running version 2.8.12.2
>
> Plenty of people on the net say to download and build it but it turns
> out that EPEL
> has a cmake3 RPM. That's a very respectable repo (unlike Ghettoforge which
> also
> had it).
>
> yum erase cmake
> yum install cmake3
>
> That installed /usr/bin/cmake3 which the build doesn't know about so I
> symbolically
> linked /usr/bin/cmake3 to ${HOME}/bin/cmake.
>
> This didn't work because it checks for /usr/bin/cmake so I made that
> symlink to cmake3.
>
> This resulted in a failure further along.
>
> -- Detecting CXX compile features - done
> CMake Error at cmake/modules/CheckCompilerVersion.cmake:40 (message):
> Host GCC version should be at least 5.1 because LLVM will soon use new C++
> features which your toolchain version doesn't support. Your version is
> 4.8.5. You can temporarily opt out using
> LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN, but very soon your toolchain won't be
> supported.
> Call Stack (most recent call first):
> cmake/modules/CheckCompilerVersion.cmake:45 (check_compiler_version)
> cmake/config-ix.cmake:13 (include)
> CMakeLists.txt:590 (include)
>
>
> -- Configuring incomplete, errors occurred!
> See also
> "/home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/build/CMakeFiles/CMakeOutput.log".
> shell cmd failed: /bin/sh -ex
> /home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/do-build
> error: building rtems-llvm-8.0.1-x86_64-linux-gnu-1
>
> Looks like I need to move to a machine with newer gcc. There is a
> floor on the host environment without doing some work. I think the
> CentOS machine I use to do test builds of our tools from
> gcc/binutils/newlib master should work since it has installs of
> various newer gcc.
>
> That may take until I get home.
You can also install “devtoolset-7” from the CentOS Software Collection Sig
(https://wiki.centos.org/SpecialInterestGroup/SCLo). I have that installed.
devtoolset-7-binutils.x86_64 2.28-11.el7
@centos-sclo-rh
That will give you gcc 7.3.1 and friends:
[dufault@fubar ~]$ /opt/rh/devtoolset-7/root/bin/gcc --version
gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[dufault@fubar ~]$
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] rtems: Make rtems_version_control_key() safer
> On Sep 9, 2019, at 22:00 , Chris Johns wrote:
>
> I would prefer we provide an interface to say the version control key has been
> set rather than exposing how we manage it. I think the change to not return
> NULL
> is the correct one. What about adding ..
>
> bool rtems_version_control_key_valid( void )
> {
> return strlen( rtems_version_control_key( ) ) != 0;
> }
>
> I have a feeling we may wedge ourselves in the future with users having code
> to
> check the length.
>
> Chris
I usually want both, that is, I always want the consistent error code interface
(0 vs !0) and I frequently want more convenient interfaces.
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] record: Add support for interrupt handlers
Don’t take it too far off-line, I want to follow. But do take it out of “support for interrupt handlers…”. > On Sep 5, 2019, at 01:29 , Chris Johns wrote: > > I think we can take C++ development styles offline and chat personally, maybe > in > person 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] psxmsgq05: Added priority unblocking mq tests
> On Aug 30, 2019, at 03:08 , Sebastian Huber > wrote: > > [...] >> +/* forward declarations to avoid warnings */ > > Static functions don't need forward declarations to avoid warnings. ... because you should order the definitions properly. Only if two static functions need to reference each other do you need to forward declare one. That’s a rare situation. 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: Which Python version for new tool code?
> On Aug 2, 2019, at 11:28 , Sebastian Huber > wrote: > >> As best I can tell, no official repository includes Python 3. There are >> un-official addon repos >> with Python 3. >> >> The users who are using RHEL 7 are unlikely to allow those repos to be used. > > Puh, this is a bit unexpected. So at least everything related to the build > system must be Python 2.7 compatible. > > Doorstop requires Python 3.5: I’m not sure there are many developers on RHEL7 without access to a Python 3 that can be used as part of RTEMS developer tools. I definitely agree there are many who can’t use Python 3 for anything that ships to run on RHEL7, but for development Red Hat licensees can use the Red Hat Software Collections and someone like me can use EPEL. Both have 3.5 and 3.6 available. I don’t use “software collections” but I did a quick google. 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
Incompatible rpcUdpInit() and nfsInit() in rtems-libbsd
The follwing commit below in libbsd added “verbose” flags to both rpcUdpInit() and nfsInit(). Code using libbsd needs a change to compile. I don’t like adding a compile time check. Shall I change the RTEMS ones to match even if the flag doesn’t do anything? [dufault@fubar rtems-libbsd]$ git log ./rtemsbsd/include/librtemsNfs.h commit 761ae78e0528ac5c1f46df11e9bea453ac6c82dd Author: Chris Johns Date: Thu Jun 30 13:32:29 2016 +1000 Make the license message viewable with a verbose option. The license details can be viewed if you mount with a -v option: # mount -i nfs -o "-v" 1.2.3.4:/mnt /mnt [dufault@fubar rtems-libbsd]$ grep rpcUdpInit ./rtemsbsd/include/librtemsNfs.h /** Priority of daemon; may be setup prior to calling rpcUdpInit(); /** CPU affinity of daemon; may be setup prior to calling rpcUdpInit(); rpcUdpInit(bool verbose); [dufault@fubar rtems-libbsd]$ 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
build of libbsd for powerpc fails with error: redefinition of 'eieio'
I have a build failure with the MVME5500 “beatnik” BSP. Therefore I tried to build the “psim” BSP and have the same failure: the FreeBSD PowerPC “cpufunc.h” and the RTEMS PowerPC “io.h” headers both define static inline "eioeio()" functions. - RTEMS, libbsd, RSB and the build tools are up-to-date as of this AM. - Building for arm xilinx_zynq_a9_qemu succeeds. - I’ll work-around it but I believe I must have something locally screwed up, I can't find any recent changes associated with this. CONFIGURATION: # project configured on Tue Jul 16 12:07:03 2019 by # waf 2.0.13 (abi 20, python 20705f0 on linux2) # using ./waf configure --rtems-tools=/opt/flatland/opt/rtems-5/ --rtems=/opt/flatland/opt/rtems-5/ --prefix=/opt/fl atland/opt/rtems-5/ --rtems-bsps=powerpc/psim BUILD FAILURE: [1217/1915] Compiling freebsd/sys/kern/kern_sysctl.c In file included from ../../freebsd/sys/sys/systm.h:45:0, from ../../rtemsbsd/powerpc/include/linux/slab.h:35, from ../../linux/drivers/soc/fsl/qbman/dpaa_sys.h:35, from ../../linux/drivers/soc/fsl/qbman/qman_priv.h:33, from ../../linux/drivers/soc/fsl/qbman/qman.c:35: ../../freebsd/sys/powerpc/include/machine/cpufunc.h:168:1: error: redefinition of 'eieio' eieio(void) ^ In file included from /opt/flatland/opt/rtems-5/powerpc-rtems5/psim/lib/include/bsp.h:59:0, from ../../rtemsbsd/include/rtems/bsd/local/opt_dpaa.h:1, from ../../linux/drivers/soc/fsl/qbman/qman.c:3: /opt/flatland/opt/rtems-5/powerpc-rtems5/psim/lib/include/libcpu/io.h:53:20: note: previous definition of 'eieio' was here static inline void eieio(void) ^ Waf: Leaving directory `/home/dufault/development/rtems/rtems-libbsd/build/powerpc-rtems5-psim-default' Build failed -> task in 'bsd' failed with exit status 1 (run with -v to display more information) ERROR: Waf configure on rtems-libbsd failed Zynq dufault@gen6 lou_files]$ 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
Conditionalize make behavior e.g. disable --gc-sections
What is best practice to change build behavior? e.g. I need to use --whole-archive/--no-whole-archive in one place but --gc-sections breaks it and that's turned on for the BSP (xilinx_zynq_a9_qemu). I’ve done this in the .cfg files for the BSP: ifneq ($(RTEMS_GC_SECTIONS_DISABLE),1) LDFLAGS_GC_SECTIONS_DISABLE = -Wl,--gc-sections endif (...) LDFLAGS = $(LDFLAGS_GC_SECTIONS_DISABLE) and then I set RTEMS_GC_SECTIONS_DISABLE=1 in the one Makefile where I need it. I don’t see similar patterns, is this the way to do 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/2] rcmd.c: Removed references to unsupported functions
> On May 4, 2019, at 02:37 , Chris Johns wrote: > > On 4/5/19 2:30 pm, Joel Sherrill wrote: >> On Fri, May 3, 2019, 8:18 PM Chris Johns > <mailto:chr...@rtems.org>> wrote: >>On 4/5/19 9:16 am, Joel Sherrill wrote: >> > On Fri, May 3, 2019, 6:04 PM Chris Johns ><mailto:chr...@rtems.org> >> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote: >> > >> > On 4/5/19 7:44 am, Lou Woods wrote: >> > > From: Lou Woods >> > > >> > > rcmdsh() and innetgr() are referenced by rcmd, but aren’t >>available >> > > in libbsd and are unresolvable external symbols when >>libbsd.a is >> > > processed by the RTL. >> > >> > Why does this not show up when we statically link? >> > >> > I wonder if this is related to separate sections where a >>function in a >> > file is present but no used and it not linked but is with the >>RTL? >> > >> > Statically linking an exe normally wouldn't have hit this unless you >> > referenced rcmd. Ld wouldn't have pulled it out of the library. >>Oh your app is referencing `rcmd`? >> No. Lou tracked down the symbols that the RTL showed as undefined. That led >> us to look into rcmd and rcmdsh. I spotted the fork/exec and realized some >> chunk had to be removed. Rcmdsh in whole and parts of rcmd. > > What do the module dependencies look like? See ... > > https://docs.rtems.org/branches/master/shell/dl_commands.html#rtl-list > > I am sorry I am not following why the rcmd.c file is being loaded. If nothing > references any symbols in it it should not be loaded it. In the code Lou is looking at it is referenced. > >> > FWIW rcmdsh.* needs to be dropped out of the build. It requires >> > fork/exec so will never work. >>Should this change be a build system change or is this needed plus the >>build system change? >> Both. Rcmdsh.* should not be in libbsd. > > Does the `#if __rtems__` formatting conform to CONTRIBUTING.md ? It looks to > me like some extra lines and `#else` with out `__rtems__`. > > 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
Run time linker allocator locking hangs RTEMS
022f R_ARM_THM_MOVW_AB .LC0
0008 0230 R_ARM_THM_MOVT_AB .LC0
000c 0b0a R_ARM_THM_CALL puts
There are no unwind sections in this file.
Symbol table '.symtab' contains 12 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 NOTYPE LOCAL DEFAULT5 $d
2: 0 NOTYPE LOCAL DEFAULT5 .LC0
3: 0 NOTYPE LOCAL DEFAULT1 $t
4: 0 SECTION LOCAL DEFAULT1
5: 0 SECTION LOCAL DEFAULT3
6: 0 SECTION LOCAL DEFAULT4
7: 0 SECTION LOCAL DEFAULT5
8: 0 SECTION LOCAL DEFAULT6
9: 0 SECTION LOCAL DEFAULT7
10: 000120 FUNCGLOBAL DEFAULT1 foo
11: 0 NOTYPE GLOBAL DEFAULT UND puts
No version information found in this file.
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_optimization_goals: Aggressive Debug
Tag_CPU_unaligned_access: v6
Disassembly
Zynq dufault@gen6 fubar]$ arm-rtems5-objdump --disassemble --source foo.o
foo.o: file format elf32-littlearm
Disassembly of section .text:
:
0: b580push{r7, lr}
2: af00add r7, sp, #0
4: f240 movwr0, #0
8: f2c0 movtr0, #0
c: f7ff fffe bl 0
10: bf00nop
12: bd80pop {r7, pc}
Zynq dufault@gen6 fubar]$
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
Run Time linker and relocation of multiple local labels
I’m porting a large vxWorks application and I’m trying to download “ld -r”
files as you can on vxWorks using the run-time loader. At least on ARM I can’t
get it to work, it uses the first local address it sees for all occurrences.
Example: Label .LC2 is used in two places, once for the “r” in an fopen() and
later for a format string. In both cases the address used is 0x419f14, the
address of “r”.
First is the readelf output, then the disassembly, then debugging output from
the RTL.
FIRST OCCURRENCE OF .LC2 used as “r” in fopen()
readelf:
0020 152f R_ARM_THM_MOVW_ABS_NC 0008 .LC1
0024 1530 R_ARM_THM_MOVT_ABS 0008 .LC1
002a 162f R_ARM_THM_MOVW_ABS_NC 002c .LC2
002e 1630 R_ARM_THM_MOVT_ABS 002c .LC2
0034 450a R_ARM_THM_CALL fopen
Disassemble:
if ((fd = fopen(string, "r")) == (0)) {
2a: f240 0100 movwr1, #0
2e: f2c0 0100 movtr1, #0
32: 6878ldr r0, [r7, #4]
34: f7ff fffe bl 0
RTL:
rtl: THM_MOVT_ABS/THM_MOVW_ABS_NC 0x341f2c0 @ 0x4196dc in bad
rtl: rel: sym:.LC2(22)=00419f14 type:47 off:002a
rtl: THM_MOVT_ABS/THM_MOVW_ABS_NC 0x7114f649 @ 0x4196e2 in bad
rtl: rel: sym:.LC2(22)=00419f14 type:48 off:002e
rtl: THM_MOVT_ABS/THM_MOVW_ABS_NC 0x141f2c0 @ 0x4196e6 in bad
rtl: rel: sym:fopen(69)=000d33c1 type:10 off:0034
SECOND OCCURRENCE of .LC2 used for the printf format string:
readelf:
07a8 2c2f R_ARM_THM_MOVW_ABS_NC 013c .LC2
07ac 2c30 R_ARM_THM_MOVT_ABS 013c .LC2
07b0 330a R_ARM_THM_CALL printf
Disassemble:
7a6: 68f9ldr r1, [r7, #12]
7a8: f240 movwr0, #0
7ac: f2c0 movtr0, #0
7b0: f7ff fffe bl 0
RTL:
rtl: rel: sym:.LC2(44)=00419f14 type:47 off:07a8
rtl: THM_MOVT_ABS/THM_MOVW_ABS_NC 0x7014f649 @ 0x419e60 in
/opt/flatland/arch/arm-stubs-vxstubs/bin/sys-bad
rtl: rel: sym:.LC2(44)=00419f14 type:48 off:07ac
rtl: THM_MOVT_ABS/THM_MOVW_ABS_NC 0x41f2c0 @ 0x419e64 in
/opt/flatland/arch/arm-stubs-vxstubs/bin/sys-bad
rtl: rel: sym:printf(51)=000daac9 type:10 off:07b0
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: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets
You’re confusing the Sony/IBM/Toshiba SPU (Synergistic Processing Unit) that
has some SPEs (Synergistic Processing Elements) with the Motorola then
Freescale then NXP then ? E500 with the SPE (Signal Processing Extension).
I’m using a processor with SPE on the Phytec MPC5554, but directly in a limited
way. See below.
There is continuing work to add SPE to LLVM/Clang. I don’t follow it closely
but see activity in January and February. I found the following comment this
AM (https://github.com/crosstool-ng/crosstool-ng/issues/1152, and not that I
know what Rust is):
"Just as a heads-up: There have been many improvements in LLVM regarding
PowerPCSPE thanks to the work of Justin Hibbits. LLVM works so well now that
even Rust can be used on PowerPCSPE.”
I don’t know how the work will progress or how ready RTEMS is for LLVM/Clang.
I’m directly using the SPE via downloaded and assembled assembly language
libraries (MPC5500_libdsp2_v06, MPC5500_spe_linear_algebra_v1_8). However,
falling back to proper context saving and soft-float to track new versions of
GCC would be a major change in timing and a can of worms.
I expect RTEMS with SPE-PowerPC will be stuck at GCC 8 and RTEMS version-locked
as well.
It’s too bad there is no compiler support from NXP because the ETPU approach
(extended Time Processing Unit, special simple processors with canned routines
that can be downloaded) that are on the chips worked well for custom motor
control, more valuable than the SPE. ETPU appears to be ending it’s life
anyway with a replacement from some Bosch peripheral. I’ll be recommending EOL
for PowerPC/SPE and will be looking for a different approach.
> On Apr 2, 2019, at 10:06 , Joel Sherrill wrote:
>
> Hi
>
> We knew this was coming. My recollection is that we have a single BSP this
> would impact. But that has already been impacted by SPU being split into a
> separate gcc target post GCC 7. And that has not been addressed yet anyway.
>
> What's the plan for SPU?
>
> -- Forwarded message -
> From: Ulrich Weigand
> Date: Tue, Apr 2, 2019 at 4:46 AM
> Subject: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets
> To: ,
> Cc: ,
>
>
> Hello,
>
> the spu-elf target in GCC supports generating code for the SPU processors
> of the Cell Broadband Engine; it has been part of upstream GCC since 2008.
>
> However, at this point I believe this target is no longer in use:
> - There is no supported Cell/B.E. hardware any more.
> - There is no supported operating system supporting Cell/B.E. any more.
>
> I've still been running daily regression tests until now, but I'll be
> unable to continue to do so much longer since the systems I've been
> using for this will go away.
>
> Rather than leave SPU support untested/maintained, I'd therefore
> propose to declare all SPU targets obsolete in GCC 9 and remove
> the code with GCC 10.
>
> Any objections to this approach?
>
> Bye,
> Ulrich
>
>
> gcc/ChangeLog:
>
> * config.gcc: Mark spu* targets as deprecated/obsolete.
>
> Index: gcc/config.gcc
> ===
> --- gcc/config.gcc (revision 270076)
> +++ gcc/config.gcc (working copy)
> @@ -248,6 +248,7 @@ md_file=
> # Obsolete configurations.
> case ${target} in
>*-*-solaris2.10* \
> + | spu*-*-* \
>| tile*-*-* \
> )
> if test "x$enable_obsolete" != xyes; then
> --
> Dr. Ulrich Weigand
> GNU/Linux compilers and toolchain
> ulrich.weig...@de.ibm.com
>
> ___
> 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
BSP for Microchip ATSAMA5D27-SOM1-EK1
I need to evaluate this for a multi-chip application. This part is a result of Microchip’s take-over of ATMEL. I’m double-checking that to create a BSP based on this I should start with the existing ATSAMV7 BSP, I think the peripherals (e.g. network chip and so on) are the same as the existing ATSAMV7 port. 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: GCC 8 PowerPC Argument Changes
What’s the context where -mno-spe is used? The last time I followed this the SPE support in the powerpc target was to be discontinued and a powerpcspe target was to be introduced. > On Feb 9, 2018, at 16:17 , Joel Sherrill <j...@rtems.org> wrote: > > Hi > > I am using GCC 8 to test my bsp_specs changes. On the > powerpc -mno-spe is gone. > > I don't know of a case where we have a BSP that checks > if GCC supports an argument or not. I think we have just > changed the custom file when we upgraded GCC. > > Any thoughts on the correct argument or better approach > than just to change the custom file when we bump GCC? > > Thanks. > > ___ > 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: Obsolete powerpc*-*-*spe*
> On Feb 14, 2017, at 22:08 , Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: > > Looks like embedded PowerPC is going to die in GCC: > > Forwarded Message > Subject: Obsolete powerpc*-*-*spe* > Date: Mon, 13 Feb 2017 21:07:03 -0600 > From: Segher Boessenkool <seg...@kernel.crashing.org > <mailto:seg...@kernel.crashing.org>> > To: g...@gcc.gnu.org <mailto:g...@gcc.gnu.org> > CC: dje@gmail.com <mailto:dje@gmail.com> > > > > Hi all, > > I propose to mark powerpc*-*-*spe* as obsolete in GCC 7. This includes > the spe.h installed header file, all the __builtin_spe* intrinsics, the > -mfloat-gprs= command-line option, and the support for the SPE ABIs. > > No one has properly tested these targets in a long time (the latest > testresults I could find are from July 2015, >1000 failures), and the > SPE support makes a lot of code much more complex. > > Any objections to this obsoletion? GCC 7 will then be the last release > with support for SPE (it will need --enable-obsolete to build these > targets), and we will delete the SPE support during GCC 8 development. I’ve been traveling and just noticed this. I use this target in three applications with RTEMS. Who else in the RTEMS community is using this? The spe.h header file has been hopelessly broken forever, that’s not an issue. I build and use the “libdsp2” library for SPE. This is primarily assembler and I hope the assembler support for SPE is not affected, but I‘m not sure. I assume the major issue will be the removal of support for -mfloat-gprs and SPE ABIs. Can someone with GCC knowledge comment about the possibility of pared-back support? I’m guessing little or no hope based on the comment that “SPE support makes a lot of code much more complex” and SPE support with the ABI would be needed to use the DSP library and single precision floating point with the -mfloat-gprs registers. I think this is going to put those applications into maintenance mode and make that target inappropriate for new RTEMS applications. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering This email, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering. Contact HDA to discuss methods we can use that ensure secure communication. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: C11 Re: [PATCH 3/6] termios: Use C11 mutex for input/output
Can someone help clarify the issue? Is this a “required compiler to build RTEMS” question? That is, are the compilers currently required to build the RTEMS Sebastian modified guaranteed to support C11 mutexes, and is it desirable to be more conservative about what compiler is needed? If C11 mutexes guarantee what Sebastian needs and unknown compiler support isn’t required then allow it. Note that I haven’t researched this, I’m just guessing that the C11 mutexes may guarantee less than the classic semaphores, and are being implemented at the compiler level, and that this minimum level of compiler support is OK for building RTEMS. > On Dec 14, 2016, at 16:15 , Chris Johns <chr...@rtems.org> wrote: > > On 15/12/2016 00:39, Sebastian Huber wrote: >> Use C11 mutexes instead of Classic semaphores as a performance >> optimization and to simplify the application configuration. > > The use of C11 mutexes has not been agreed too and we need to discuss > this in more detail before we allow use within RTEMS. I would like to > see positive agreement from all core maintainers before this and similar > patches can be merged. > > RTEMS has required the use of the Classic API because: > > 1. Available on all architectures, BSPs and tool sets. > 2. Always present in a build. > 3. Was considered faster than POSIX. > > The Classic API provides a base level of required functionality because > it is always available in supported tool sets and leads to the smallest > footprint because we do not need to link in more than one API. > > I understand things change and move on so it is great to see this change > being proposed and our existing base line being challenged. > > I see from your performance figures C11 mutexes are better and the > resources are allocated as needed and used which is a better model than > the Classic API's configuration table. This is nice. > > Do all architectures and BSPs have working C11 support? > > Is there tests in the RTEMS testsuite for C11 threading services? > > What target resources are used to support this API, ie code and RAM usage? > > Would the "tiny" footprint be smaller if all internal services including > compiler thread support are made C11? Could this actually be done? Parts > of POSIX has been creeping in over time so the position is a little > confused at the moment. I am not sure about a bits and pieces approach, > maybe a full switch is made. > > Does C11 work on LLVM (I hear support is close)? > > Where is the C11 API implemented? Is the threading code outside the > RTEMS source tree and what effect does that have on those looking to > certify RTEMS? > > Does a change like this require a coding standard update? > > 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, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering. Contact HDA to discuss methods we can use that ensure secure communication. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Clarify DFLT and PRIO "wait_operation" field in rtems_monitor_task_dump() in pthreads in 4.12
I’m moving an older application to 4.12 and having performance issues compared to “4.11” (aka “4.10.99”) from around 2012. I have pthreads that are showing up as DFLT and PRIO in the “pthread” command in the shell. For example, here: --- [/] # pthread ID NAME CPU PRI STATE MODESEVENTS WAITID WAITQUEUE -- 0b0100010 253 SUSP P:T:nA NONE [DFLT] 0b010002 grid 0 128 Wsem P:T:nA NONE 1a010006 00262a78 [PRIO] 0b010003 sokmon 0 55 Wsysev P:T:nA NONE [DFLT] 0b010004 sokmon 0 129 Wsysev P:T:nA NONE [DFLT] 0b010005 tmsync 0 129 DELAY:Wisig P:T:nA NONE 00236260 [FIFO] 0b010006 log 0 129 Wsem P:T:nA NONE 3b010001 00275588 [FIFO] 0b010007 fset 0 129 Wsem P:T:nA NONE 3b01001e 00275a10 [FIFO] 0b010008 frm 0 25 Wsem P:T:nA NONE 3b010003 002755d8 [FIFO] 0b010009 publsh 0 128 Wjatx P:T:nA NONE [DFLT] 0b01000a frm 0 25 Wsem P:T:nA NONE 3b010007 00275678 [FIFO] 0b01000b publsh 0 128 Wjatx P:T:nA NONE [DFLT] 0b01000c ss_srv 0 128 Wsysev P:T:nA NONE [DFLT] 0b01000d muxmon 0 128 Wsem P:T:nA NONE 1a010016 00262ef8 [PRIO] 0b01000e commute 0 1 Wsem P:T:nA NONE 3b01000b 00275718 [FIFO] 0b01000f servo0 17 Wsem P:T:nA NONE 3b010013 00275858 [FIFO] 0b010011 tclsrv 0 55 Wsysev P:T:nA NONE [DFLT] [/] # --- I started everything all pthreads with the SCHED_FIFO policy (I have a single wrapper around pthread_create() that I use), and I’m guessing this field has nothing to do with that. Some are now DFLT and PRIO. I note that both WAITID and WAITQUEUE are always 0 in the DFLT case. - Does PRIO mean the priority is boosted? I don’t expect that, especially for the “muxmon” or “sokmon” threads. - What does DFLT mean? Peter - Peter Dufault HD Associates, Inc. Software and System Engineering This email, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering. Contact HDA to discuss methods we can use that ensure secure communication. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Trying to build mvme5500 "Beatnik" for 4.11, option manager (no-foobar.rel: No such file or directory) issue?
I’m trying to update my MVME5500 “beatnik” BSP application from 4.7 to 4.11 and when I get to the final step to link my application I get what follows. [dufault@take5 rtems]$ make powerpc-rtems4.11-g++: error: /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-dpmem.rel: No such file or directory powerpc-rtems4.11-g++: error: /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-msg.rel: No such file or directory powerpc-rtems4.11-g++: error: /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-mp.rel: No such file or directory powerpc-rtems4.11-g++: error: /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-part.rel: No such file or directory powerpc-rtems4.11-g++: error: /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-signal.rel: No such file or directory powerpc-rtems4.11-g++: error: /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-timer.rel: No such file or directory powerpc-rtems4.11-g++: error: /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-rtmon.rel: No such file or directory make: *** [/home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/bin/grid] Error 1 If I look at what I’m trying to do I see I’m linking to these "no-foobar.rel” directly. (I inserted some to make it clear): [dufault@take5 rtems]$ make -n mkdir -p /home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/bin; \ powerpc-rtems4.11-g++ -u rpcUdpInit -u nfsInit -B/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/ -specs bsp_specs -qrtems /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-dpmem.rel /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-msg.rel /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-mp.rel /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-part.rel /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-signal.rel /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-timer.rel /opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-rtmon.rel -g \ -o /home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/bin/grid \ /home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/opt/flatland/exesrc/gridmain/rtems/_init.o /home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/opt/flatland/exesrc/gridmain/rtems/grid.o /home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/opt/flatland/exesrc/gridmain/rtems/main.o /home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/opt/flatland/exesrc/gridmain/rtems/mvme5500.o -lgrid -lzboard -lacromag -lvme -lembedtcl -lecseqtcl -lecseq -lmrsfile -lpowerpc -lmotors -lrtems_osintf -lzboard -lposix_wrap -lrtems-gdb-stub -lregex -lsearch -lbsd -lcexp -lspencer_regexp -ltecla_r -lpmbfd -lpmelf -ltelnetd -lnfs -L/home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/lib -L/opt/stepper/opt/powerpc-beatnik-rtems/lib -lregex -lsearch -lbsd powerpc-rtems4.11-objcopy -Obinary /home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/bin/grid /home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/bin/grid.bin [dufault@take5 rtems]$ If I remove the section bracketed by “” the link finishes cleanly, but I haven’t had much luck figuring out what generates this. I get problems when I try to boot the binary, but I want to fix this before proceeding further. - Am I correct that this is some kind of initialization of optional managers? - Does anyone recognize where I should be looking? Peter - Peter Dufault HD Associates, Inc. Software and System Engineering This email, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering. Contact HDA to discuss methods we can use that ensure secure communication. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Should rtems_error() use fprintf()?
I’m answering only by looking at this email and not hunting through the source. But if “rtems_error()” can easily be replaced by either "fprintf(stderr, …)" or "printk()" then deprecate it with that recommendation. I’ve often had spirited discussions with clients because I think "fprintf(stderr, …)" needs to be supported cleanly in an embedded environment (as early as possible, and in as many environments as possible, leaving an escape hatch for a “printk()” in an ISR etc), since if the customer can’t use “fprintf(stderr, …)" they can’t use libraries easily. The customer usually specifies a special “my_error_prinft(...)" that they want to use instead of “fprintf(stderr, …)”, and if that’s what “rtems_error()” is then deprecate it. > On Mar 16, 2016, at 15:27 , Joel Sherrill <j...@rtems.org> wrote: > > Hi > > I know this is a very old piece of code and predates printk() but should > this routine be changed to use printk()? > > Is it still safe? Especially in light of SMP demands. > > --joel > ___ > 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, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering. Contact HDA to discuss methods we can use that ensure secure communication. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: How will user's compile with Makefiles? Was: Re: large bss size for sample applications
Chris, Makefile isn’t custom support, it’s legacy support. For better or for worse, if you add barriers to Makefiles you raise eyebrows in the legacy community. They can understand an effort to adapt from BSD make to GNU make, but a lack of Makefile support is a check-box not checked. I don’t know of any other build systems that have the footprint of “make”. Yes, the twisty auto* mess is a mess, but it does promise Makefile support. If you think time has passed this issue by I’d like to know, I don’t think it has. > On Oct 1, 2015, at 16:27 , Chris Johns <chr...@rtems.org> wrote: > > Where does this leave other build systems? What if each build system's > users start to request custom support? Allowing custom support adds an > extra burden to the RTEMS maintainers to make sure no one breaks. RTEMS > developers are not build system experts so this just dilutes our > efforts. We need to find a suitable middle ground for everyone. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering This email, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering. Contact HDA to discuss methods we can use that ensure secure communication. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: How will user's compile with Makefiles? Was: Re: large bss size for sample applications
I think there should be a requirement that you can deploy an RTEMS release at a site strictly using Makefiles. Not develop RTEMS or build RTEMS, but deploy RTEMS. I would prefer, but won’t go so far as to say it is a requirement, that one should be able rebuild a deployed BSP with changes via Makefiles. The barriers to using RTEMS in a subsystem at a company not committed to RTEMS must be kept as low as possible, and the additional work to someone suggesting RTEMS (me) must be kept as low as possible. > On Sep 26, 2015, at 11:13 , Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > > > On September 26, 2015 9:52:37 AM CDT, "Thomas Dörfler" > <thomas.doerf...@embedded-brains.de> wrote: >> Peter's statement gets a +1 for me. Makefile integration IMHO makes >> using RTEMS in many development systems rather easy. Forcing Waf for >> user development is a drawback. >> >> >> How can we avoid this? >> > > There are two pieces here. > > + a file with the list of tools, flags, etc. > + the existing application Makefile structure. > > The application Makefile infrastructure is so old it predates automake. Long > ago, I had a shell script called automake to generate them. This is before > even releases on tape were shipped. Yes, pre-ftp. > > The first piece captures basic information required to integrate into any big > system. > > The second is obsoleting an application Makefile system that has been present > since before RTEMS was on ftp. I have no idea how widely it is used. But we > don't have a formal decision on it that has been through user community > review. I think all the core developers wouldn't mind removing it but we have > no idea of the impact. > > If there is a high impact, we may be able to capture it as something not used > inside RTEMS but as a kit for users. It rarely changes and depends on the > first piece which I think we still need to publish with a BSP. > > A hard requirement is that we can't force a build system on users. We can > provide guidance for popular options we may not personally use but that's > about it. Instructions for Eclipse or Visual Studio integration for example. > >> Wkr Thomas. >> >> >> >> >> Ursprüngliche Nachricht >> Von: Peter Dufault <dufa...@hda.com> >> Datum: >> An: Gedare Bloom <ged...@rtems.org> >> Cc: Amar Takhar <v...@darkbeer.org>,"rtems-de...@rtems.org" >> <devel@rtems.org> >> Betreff: Re: How will user's compile with Makefiles? Was: Re: large bss >> size for sample applications >> >> >> >> I don’t like this requirement. I think it’s fine for development but >> want to be able to deliver a package that will integrate into a >> client’s Makefile based build system where they can make changes and >> re-build. In other words, I don’t mind if building a BSP or updating >> RTEMS requires waf, but want to be able to deploy and make minor >> changes without it. >> >> Up to now I’ve been able to get the existing Makefile fragments to work >> at multiple sites with a little work. >> >>> On Sep 26, 2015, at 09:04 , Gedare Bloom <ged...@rtems.org> wrote: >>> >>> The comment below, made in the users ml, caught me off guard. How >> will >>> user's applications build when RTEMS is built with Waf? >>> >>> If there is a complex answer, then this conversation belongs here on >>> the devel ml until we can sort it out. >>> >>> Gedare >>> >>> On Sat, Sep 26, 2015 at 2:36 AM, Chris Johns <chr...@rtems.org> >> wrote: >>>> On 25/09/2015 11:04 pm, Jeff Webb wrote: >>>>> On 09/25/2015 07:59 AM, Gedare Bloom wrote: >>>>>>> The next task for me will be to set up a simple out-of tree C or >> C++ >>>>>>> POSIX >>>>>>> application. >>>>>>> >>>>>>> Thanks again for all the help! >>>>>>> >>>>>>> -Jeff >>>>>>> >>>>>> >>>>>> Simple examples for out-of-tree builds exist in the >> examples-v2.git >>>>>> repository with the "RTEMS Application Makefile" approach using >> custom >>>>>> Makefiles, and with the "RTEMS Application Waf" approach using >>>>>> wscripts and a git-submodule for waf support. The former is an >> older, >>>>>> established way to build applications linking to an 'installed' >> RTE
Re: Memory protection on RTEMS?
> On Sep 9, 2015, at 19:02 , Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > As Sebastian mentioned if you make the task stack accessible by only > a single stack, you have to be careful not to pass pointers to objects > on the stack into paths where they will be used by another task. I’ve worked on multi-processor systems with this attribute and I think it’s a good option, stack was private and “cheap” in terms of overhead on a processor. If you use shared memory semantics you'll have portable code that works on multi-process (process, not processor) systems, it requires a little more design formalism up front. Peter --------- Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
SMC91111 CYG_ASSERT(Unexpected rx packet) on Phytec MPC5554
In my application using 4.11 I’ve started encountering a CYG_ASSERT() “Unexpected rx packet” assertion. I’m not sure what I’ve changed to cause it, or if it is an issue introduced by 4.11. I’ve seen it four times now, three times before any software change and once after the change described below, and what it does is to make the system totally unusable through the serial port console or network. The CYG_ASSERT() macro in that driver boils down to while (1) printf(“assertion_message”);”, and that then requires manual intervention to push the hardware reset button to get the application started again. The watchdog is being triggered by the high-priority control loop that continues to run, maybe a defect in my code. I changed this CYG_ASSERT() to instead print the warning once and continue on to free the resource that it’s complaining about. The fourth time I saw this issue is after this change, and the application printed the message once, and everything then continued to work without any apparent issue. It’s still up and running a day later though the issue hasn’t happened again. It could be that my hack is leaking some kind of resource that will hurt in the long run. A couple of questions / observations: - That CYG_ASSERT must be changed to do something more reasonable, in most situations a network driver issue shouldn’t just hang up the system. Recommendations? - Has anyone seen this? I’m not sure how many platforms are using SMC9 other than Phytec MPC5554 and a Gaisler variant. If anyone is familiar with that chip I’d really appreciate speculation as to what situation triggers this. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
